Another idea is that as soon as you detect the problem, you send the SIGUSR1 signal to the VM from another terminal.
$ kill -SIGUSR1 thePID
When the Pharo process receives the SIGUSR1 signal it will output a dump with
- the C execution stack
- the Pharo execution stacks
Maybe for debugging this case you don���t want to use the launcher, and you want to manually launch the VM from a terminal, so you���ll have more control and see the output (maybe you���re already doing it, but just in case).
G.
Hi Sabine,On Dec 8, 2020, at 10:49 AM, Sabine Manaa <manaa.sabine@gmail.com> wrote:
���Hi,
I have the following problem:
sometimes, after restarting my Pharo 8 image on mac, it is not responsive
and it blows up the memory.
I tried with commandline handler
eval "self halt"
and with
Smalltalk addToStartUpList:
but both is too late - the Image starts and blows up and is not responsive.
I can not interrupt it and it grows to several GB memory (eg after 20
seconds 10 GigaByte! ) and I have to kill it.
Anyone having an idea what I can do to find the reason for this?
Run the system under a low level debugger (lldb, gdb).Put a break point on the function sqAllocateMemorySegmentOfSizeAboveAllocatedSizeInto, which is called when the heap must grow to allocate new objects.When the system hits the breakpoint for the second or third time call the function printCallStack()and be patient; it will print a lot of stack.There is also a command line argument to limit the maximum size of the heap. So an alternative might be to restrict the heap to a few megabytes above the image size and see if you get a crash.dmp file when the vm exits when the system runs out of memory.HTH
Sabine
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html