Squeak low on space...

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:

3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3
Squeak3.9alpha of 4 July 2005 [latest update: #7021]
Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686
GNU/Linux
default plugin location: /usr/local/lib/squeak/3.9-8/*.so

uname -a returns:

Linux a05-0535b.kn.vutbr.cz 2.6.22.9-61.fc6 #1 SMP Thu Sep 27 17:45:57
EDT 2007 i686 i686 i386 GNU/Linux

I'm using GNOME in Fedora Core 6.

Cheers,

Elod

Space is low
17 October 2007 12:20 am

VM: unix - a SmalltalkImage
Image: Squeak3.9 [latest update: #7067]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /home/kironskye/squeak
Trusted Dir /home/kironskye/squeak/secure
Untrusted Dir /home/kironskye/squeak/My Squeak

Delay>>wait
        Receiver: a Delay
        Arguments and temporary variables:

        Receiver's instance variables:
                delayDuration: 17
                resumptionTime: 1223781
                delaySemaphore: a Semaphore()
                beingWaitedOn: false

WorldState>>interCyclePause:
        Receiver: a WorldState
        Arguments and temporary variables:
                milliSecs: 20
                currentTime: 1223764
                wait: 17
        Receiver's instance variables:
                hands: an Array(a HandMorph(3216))
                activeHand: a HandMorph(3216)
                viewBox: 0@0 corner: 1400@975
                canvas: a FormCanvas on: DisplayScreen(1400x975x32)
                damageRecorder: a DamageRecorder
                stepList: a Heap(StepMessage(#stepAt: -> a SimStateMorph(1568))(a SimStateMorph...etc...
                lastStepTime: 1223764
                lastStepMessage: nil
                lastCycleTime: 1223761
                commandHistory: a CommandHistory
                alarms: a Heap()
                lastAlarmTime: 1223764
                remoteServer: nil
                multiCanvas: nil

WorldState>>doOneCycleFor:
        Receiver: a WorldState
        Arguments and temporary variables:
                aWorld: a PasteUpMorph(1622) [world]
        Receiver's instance variables:
                hands: an Array(a HandMorph(3216))
                activeHand: a HandMorph(3216)
                viewBox: 0@0 corner: 1400@975
                canvas: a FormCanvas on: DisplayScreen(1400x975x32)
                damageRecorder: a DamageRecorder
                stepList: a Heap(StepMessage(#stepAt: -> a SimStateMorph(1568))(a SimStateMorph...etc...
                lastStepTime: 1223764
                lastStepMessage: nil
                lastCycleTime: 1223761
                commandHistory: a CommandHistory
                alarms: a Heap()
                lastAlarmTime: 1223764
                remoteServer: nil
                multiCanvas: nil

PasteUpMorph>>doOneCycle
        Receiver: a PasteUpMorph(1622) [world]
        Arguments and temporary variables:

        Receiver's instance variables:
                bounds: 0@0 corner: 1400@975
                owner: nil
                submorphs: an Array(a SystemWindow(965) a FlapTab<Class Diagrams>(1791) "Class ...etc...
                fullBounds: 0@0 corner: 1400@975
                color: (Color r: 0.97 g: 0.98 b: 1.0)
                extension: a MorphExtension (2543) [eventHandler = an EventHandler]  [other:  (...etc...
                borderWidth: 0
                borderColor: (Color r: 0.03 g: 0.02 b: 0.0)
                presenter: a Presenter (1246)
                model: a MorphicModel(3376)
                cursor: 1
                padding: 3
                backgroundMorph: nil
                turtleTrailsForm: nil
                turtlePen: nil
                lastTurtlePositions: nil
                isPartsBin: nil
                autoLineLayout: false
                indicateCursor: nil
                resizeToFit: nil
                wantsMouseOverHalos: nil
                worldState: a WorldState
                griddingOn: nil


--- The full stack ---
Delay>>wait
WorldState>>interCyclePause:
WorldState>>doOneCycleFor:
PasteUpMorph>>doOneCycle
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[] in Project class>>spawnNewProcess {[[World doOneCycle.  Processor yield.  false] whileFalse.  nil]}
[] in BlockContext>>newProcess {[self value.  Processor terminateActive]}

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:
--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Dear All,

If possible I would like to encourage package developers to support two
conventions for cleaning up images

Firstly to remember to adopt the memory hogs convention (which is rarely
used) of implementing #freeSomeSpace.

Although the lowspace watcher currently requires potential memory hogs
to register themselves, I propose implementing the methods anyway, with
a utility method available via 'SmalltalkImage current freeSpace' to
invoke an image wide belt tightening.

#freeSomeSpace would be for cleaning out caches and so forth that would
not imped normal functioning.

examples:

Utilities-class-#freeSomeSpace
        self cleanseOtherworldlySteppers

Secondly to formalize #cleanUp as a message that users will send in
order to try and tidy up an image as much as possible before saving or
deploying.

examples:

In Seaside this would require:

WACachedDocument class-#cleanUp
    self clearCache
WAHalo-class-#cleanUp
    self initialize
WAKom-class-#cleanUp
    self stop
WARegistry class-#cleanUp
    self clearAllHandlers

In DynamicProtocols this would require
DynamicProtocols-#cleanUp
    self invalidateCache

I am sure there are many other instances where this would be useful.

how about it?

Keith

A very good proposal. I think this protocol is best to include to
Kernel library in future squeak releases, such as Behavior or Class.
So, it will be a common scenario to call SomeClass cleanUp , to ask it
for tidy up the space.


On 17/10/2007, Keith Hodges <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.