Ah, well you need to look at the ProcessBrowser moprhit can warn you  
about run away processes, and show which processes are running, and  
let you look at their stacks and invoke debug on a process.

Likely you are

a) allocating many objects and running into the upper limit of how  
much memory you can allocate on your machine, or the upper limit for  
the Squeak VM

Depending on which VM you use it sets an upper limit of 1GB or 512MB  
memory usage, also you might pass in a parm on the command line that  
is forcing some limit, say 64m or 128m.
Also of course if your unix machine is say limited to 128MB of real  
plus virtual memory, asking for 512MB of virtual memory won't happen,  
well it will be
granted upto the limits.   Most VM's are limited to 2GB and memory  
under the 2GB address unless they have been compiled using patchs for  
32bit clean VMs that
were worked on earlier this spring, then you might expect memory >  
2GB. For 64bit VMs perhaps you can have 4GB images, but I don' t know  
anyone who has tested this.

b) some background process is doing some sort of recursive call and  
consuming all memory for the Context instances for each stack frame.  
This is harder to catch since
it's usually quickly fatal.

The Space is low message you see is a result of

SystemDictionary>>lowSpaceWatcher

the LowSpaceSemaphore is signalled by the VM
when it finds the amount of space left over after doing an  
incremental and full GC and growing the VM memory along with the  
space demand is less than the
low space threshold.  Of course if the VM cannot allocate the space  
we end up with self error: 'out of memory'.

I know the current VM's set the VM special object  
ProcessSignalingLowSpace to help indicate which process triggered the  
low memory allocation. This might
of course NOT be the process that is causing the problem.  Not sure  
where in the Smalltalk code we access the information in  
ProcessSignalingLowSpace.


Therefore on the Space is low message use the ProcessBrowser morph to  
figure out what is happening.  Also providing the results of the  
'Help>>VM Statistics" menu item is useful for more debugging.


SInce you are using the Unix VM, you can launch the VM using gdb, and  
then if you halt on the error: 'out of memory'.  you can invoke "call  
(int) printAllStacks()" to call an interpreter procedure that prints  
all the process stacks to sysout and could provide valuable debugging  
information.

On Oct 16, 2007, at 3:31 PM, Elod Kironsky wrote:

> Hi!
>
> During my experimentations with Player/Stage under Squeak, I came  
> upon a strange "behavior". Squeak randomly crashes, and I don't  
> know why. Probably it's due to a memory leak or something, because  
> I can see a very quick memory consumptions jump in top. Basically  
> Squeak runs for a time completely normally, consuming like 3.8 MB  
> of memory. Then it just jumps to 16 MB and Squeak crashes.  
> Sometimes I get a warning, that Squeak is low on space/memory. I'm  
> attaching the log generated. I'm heavily spawning processes and  
> using socket communication, so I guess the problem will be in  
> process handling somewhere or in socket usage. Can you figure out  
> something from the log? Here is what I get for squeak -version:
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===