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. > El 9 dic 2020, a las 6:35, Eliot Miranda <[email protected]> escribió: > > Hi Sabine, > >> On Dec 8, 2020, at 10:49 AM, Sabine Manaa <[email protected]> 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 >> <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html>
