[Glass] VM temporary object memory is full (again)

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Sat Sep 26 11:01:13 PDT 2015

On 9/25/15 1:14 PM, BrunoBB via Glass wrote:
>   Hi,
> I have a REST services and Web App being served by the same gem.
> After adding a #halt to the web app i can not start Zinc server again.
> Even if i shutdown GemStone and restart it again i always get TOM full
> immediately after evaluating:
> [WAGsZincAdaptor startOn: 8888]
>    on: AlmostOutOfMemory enable
>    do: [:ex | ex error: ex description].
> Last time i have this error if i restarted GS --> everything was ok.
> Still try to solve this :) any help is appreciated...

WAGsZincAdaptor>>startOn: forks a thread to listen on the port and when a connection is accepted, another thread is forked. The AlmostOutOfMemory exception would not likely be raised from the code called by WAGsZincAdaptor>>startOn:

The last time this happened, I suggested that you install a static AlmostOutOfMemory handler that is capable of handling an AlmostOutOfMemory no matter which thread signals the exception ... I suggested that you look at MCPlatformSupport class>>installAlmostOutOfMemoryStaticHandler: for inspiration ... this time I'll take it a step farther:)  Here's a static exception handler that will do a halt when 65% of memory is consumed:

   | handler commitThreshold |
   commitThreshold := 65.
   handler := AlmostOutOfMemory addDefaultHandler: [ :ex | self halt ].
   SessionTemps current at: #'AlmostOutOfMemoryStaticException' put: handler.
   System signalAlmostOutOfMemoryThreshold: commitThreshold

If you do this interactively, you should be able to get an idea from the stack in the debugger what is going on ... if you want to do this in a topaz session, you can put in a call to GsProcess class>>stackReportToLevel: and dump the stack to the gem log ....

More information about the Glass mailing list