VM temporary object memory is full

> On Aug 27, 2015, at 6:18 PM, BrunoBB via Glass <[hidden email]> wrote:
>
> Hi All,
>
> I think i mess up with GemStone. After having some problems with Seaside.
> Now every time i log into GemStine and after evaluate:
> WAGsZincAdaptor startOn: 8888.
>
> I get (even if a stop the stone and start it again):
> ----------------------------------------------------
> GemStone: Error         Fatal
> VM temporary object memory is full
> , old space overflow
> Error Category: 231169 [GemStone] Number: 4067  Arg Count: 1 Context : 20
> exception : 20
> Arg 1:   20
>
> [Info]: Logging out at 08/27/2015 18:15:23 PDT (1440724523)
>
> *****************************************************
> ****** GemStone Abnormal Shutdown at 08/27/2015 18:15:24 PDT
> *****************************************************
> -----------------------------------------------------
> GemStone: Error         Fatal
> VM temporary object memory is full
> , old space overflow
> Error Category: 231169 [GemStone] Number: 4067  Arg Count: 1 Context : 20
> exception : 20
> Arg 1:   20
>
> Regards,
> bruno
>
>
>
> --
> View this message in context: http://forum.world.st/VM-temporary-object-memory-is-full-tp4846466.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

> James,
>
> I think all my problems comes from Seaside and it is possible that i broke
> Seaside (trying to find out how to restore or initialize Seaside again).
> I thought that the following did the try but ..:
> WAEnvironment configureApplicationDefaults;
>     configureApplicationExceptionHandlingDefaults;
>     registerDefaultComponents;
>     registerDefaultRequestHandlers.
>
> Searching how to initialize everything again :)
>
> After:
> [WAGsZincAdaptor startOn: 8888]
>    on: AlmostOutOfMemory enable
>    do: [:ex | ex error: ex description].
>
> I got the following stacj error (after this i got the VM TOM is full):
> InternalError (AbstractException) >> _signalFromPrimitive: @5 line 15
> ProcessorScheduler >> _addDelay:to: @1 line 1
> ProcessorScheduler >> _waitForSocket:timeout: @8 line 18
> GsSocket >> readWillNotBlockWithin: @22 line 37
> SocketStreamSocket (SpSocket) >> waitForNonBlockingReadActivityUpToMs: @3
> line 6
> SocketStreamSocket >> waitForDataFor:ifClosed:ifTimedOut: @20 line 14
> SocketStreamSocket >> waitForDataFor: @2 line 6
> SocketStreamSocket >> receiveDataSignallingTimeout:into:startingAt: @2 line
> 8
> SocketStream >> receiveData @5 line 12
> SocketStream >> next @7 line 9
> ZnLineReader >> processNext @5 line 4
> ZnLineReader >> nextLine @3 line 3
> ZnRequestLine >> readFrom: @3 line 3
> ZnRequestLine class >> readFrom: @3 line 3
> ZnRequest >> readHeaderFrom: @2 line 2
> ZnRequest (ZnMessage) >> readBinaryFrom: @2 line 3
> ZnRequest class (ZnMessage class) >> readBinaryFrom: @3 line 3
> [] in  ExecBlock1 (ZnZincServerAdaptor) >> configureServerForBinaryReading
> @2 line 4
> [] in  ExecBlock0 (ZnSingleThreadedServer) >> readRequest: @3 line 6
> [] in  ExecBlock0 (ZnSingleThreadedServer) >> withMaximumEntitySizeDo: @2
> line 6
> [] in  ExecBlock0 (DynamicVariable class) >> value:during: @3 line 9
> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
> ZnMaximumEntitySize class (DynamicVariable class) >> value:during: @6 line
> 10
> ZnManagingMultiThreadedServer (ZnSingleThreadedServer) >>
> withMaximumEntitySizeDo: @5 line 5
> ZnManagingMultiThreadedServer (ZnSingleThreadedServer) >> readRequest: @2
> line 6
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> readRequestSafely: @2 line 5
> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> readRequestSafely: @3 line 6
> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >> readRequestSafely:
> @3 line 13
> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >>
> executeOneRequestResponseOn: @2 line 7
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> executeRequestResponseLoopOn:
> @2 line 10
> [] in  ExecBlock0 (DynamicVariable class) >> value:during: @3 line 9
> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
> ZnCurrentServer class (DynamicVariable class) >> value:during: @6 line 10
> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >>
> executeRequestResponseLoopOn: @4 line 8
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2 line 12
> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2 line 13
> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2 line 15
> [] in  ExecBlock0 (ExecBlock) >> ifCurtailed: @2 line 6
> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
> ExecBlock0 (ExecBlock) >> ifCurtailed: @3 line 8
> [] in  ExecBlock (ZnMultiThreadedServer) >> serveConnectionsOn: @2 line 18
> GsProcess >> _start @7 line 16
> UndefinedObject (GsNMethod class) >> _gsReturnToC @1 line 1
>
> Regards,
> Bruno
>
>
>
> --
> View this message in context: http://forum.world.st/VM-temporary-object-memory-is-full-tp4846466p4846658.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass

> Bruno,
>
> I have a few spare minutes...
>
> Okay, so this error was dumped to the gem log before running out of
> memory?
>
> The static handler approach might get better information for the exact
> point that you are running out of memory, but it would be interesting
> to understand the InternalError ... there are some ProcessorScheduler
> issues in older versions of GemStone, depending upon version, so I'm
> sorta curious what version of GemStone ... also depending upon what
> version of Zinc you are using an infinite loop (under error
> conditions) is possible as I recall addressing that particular
> problem  ...
>
> Buuuut, if you hadn't seen this problem prior to the re-initialize
> event it is likely that this is a side-effect as well ...
>
> What version of Seaside are you using? I will go back to your original
> message (if you already told us) and try to track down what gets
> cleared by the expressions used and work backwards from there (as I
> find the time:)
>
> Dale
>
>
> On 8/28/15 7:01 AM, BrunoBB via Glass wrote:
>> James,
>>
>> I think all my problems comes from Seaside and it is possible that i
>> broke
>> Seaside (trying to find out how to restore or initialize Seaside again).
>> I thought that the following did the try but ..:
>> WAEnvironment configureApplicationDefaults;
>>     configureApplicationExceptionHandlingDefaults;
>>     registerDefaultComponents;
>>     registerDefaultRequestHandlers.
>>
>> Searching how to initialize everything again :)
>>
>> After:
>> [WAGsZincAdaptor startOn: 8888]
>>    on: AlmostOutOfMemory enable
>>    do: [:ex | ex error: ex description].
>>
>> I got the following stacj error (after this i got the VM TOM is full):
>> InternalError (AbstractException) >> _signalFromPrimitive: @5 line 15
>> ProcessorScheduler >> _addDelay:to: @1 line 1
>> ProcessorScheduler >> _waitForSocket:timeout: @8 line 18
>> GsSocket >> readWillNotBlockWithin: @22 line 37
>> SocketStreamSocket (SpSocket) >>
>> waitForNonBlockingReadActivityUpToMs: @3
>> line 6
>> SocketStreamSocket >> waitForDataFor:ifClosed:ifTimedOut: @20 line 14
>> SocketStreamSocket >> waitForDataFor: @2 line 6
>> SocketStreamSocket >> receiveDataSignallingTimeout:into:startingAt:
>> @2 line
>> 8
>> SocketStream >> receiveData @5 line 12
>> SocketStream >> next @7 line 9
>> ZnLineReader >> processNext @5 line 4
>> ZnLineReader >> nextLine @3 line 3
>> ZnRequestLine >> readFrom: @3 line 3
>> ZnRequestLine class >> readFrom: @3 line 3
>> ZnRequest >> readHeaderFrom: @2 line 2
>> ZnRequest (ZnMessage) >> readBinaryFrom: @2 line 3
>> ZnRequest class (ZnMessage class) >> readBinaryFrom: @3 line 3
>> [] in  ExecBlock1 (ZnZincServerAdaptor) >>
>> configureServerForBinaryReading
>> @2 line 4
>> [] in  ExecBlock0 (ZnSingleThreadedServer) >> readRequest: @3 line 6
>> [] in  ExecBlock0 (ZnSingleThreadedServer) >>
>> withMaximumEntitySizeDo: @2
>> line 6
>> [] in  ExecBlock0 (DynamicVariable class) >> value:during: @3 line 9
>> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
>> ZnMaximumEntitySize class (DynamicVariable class) >> value:during: @6
>> line
>> 10
>> ZnManagingMultiThreadedServer (ZnSingleThreadedServer) >>
>> withMaximumEntitySizeDo: @5 line 5
>> ZnManagingMultiThreadedServer (ZnSingleThreadedServer) >>
>> readRequest: @2
>> line 6
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >> readRequestSafely: @2
>> line 5
>> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >> readRequestSafely: @3
>> line 6
>> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
>> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >>
>> readRequestSafely:
>> @3 line 13
>> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >>
>> executeOneRequestResponseOn: @2 line 7
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >>
>> executeRequestResponseLoopOn:
>> @2 line 10
>> [] in  ExecBlock0 (DynamicVariable class) >> value:during: @3 line 9
>> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
>> ZnCurrentServer class (DynamicVariable class) >> value:during: @6
>> line 10
>> ZnManagingMultiThreadedServer (ZnMultiThreadedServer) >>
>> executeRequestResponseLoopOn: @4 line 8
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2
>> line 12
>> ExecBlock0 (ExecBlock) >> on:do: @3 line 42
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2
>> line 13
>> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
>> [] in  ExecBlock0 (ZnMultiThreadedServer) >> serveConnectionsOn: @2
>> line 15
>> [] in  ExecBlock0 (ExecBlock) >> ifCurtailed: @2 line 6
>> ExecBlock0 (ExecBlock) >> ensure: @2 line 12
>> ExecBlock0 (ExecBlock) >> ifCurtailed: @3 line 8
>> [] in  ExecBlock (ZnMultiThreadedServer) >> serveConnectionsOn: @2
>> line 18
>> GsProcess >> _start @7 line 16
>> UndefinedObject (GsNMethod class) >> _gsReturnToC @1 line 1
>>
>> Regards,
>> Bruno
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/VM-temporary-object-memory-is-full-tp4846466p4846658.html
>> Sent from the GLASS mailing list archive at Nabble.com.
>> _______________________________________________
>> Glass mailing list
>> [hidden email]
>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>

> Dale,
>
> thanks for the detailed answer.
> [
>     WADispatcher default.
>     WASystemConfiguration allSubclasses
>       do: [ :each | each instance buildDescription ] ]
>       ensure: [ System commitTransaction ]
>
> This run without problems :)
>
> I going to start testing again...
>
> I'm using GemStone 3.2.1.
> Seaside version:
> ConfigurationOfSeaside3-JohanBrichau.226
> Seaside-Core.gemstone-JohanBrichau.818
> Seaside-GemStone-Core-dkh.67
>
> Regards,
> Bruno
>
>
>
> --
> View this message in context: http://forum.world.st/VM-temporary-object-memory-is-full-tp4846466p4846714.html
> Sent from the GLASS mailing list archive at Nabble.com.
> _______________________________________________
> Glass mailing list
> [hidden email]
> http://lists.gemtalksystems.com/mailman/listinfo/glass