[Glass] problem update: Zinc server with Seaside (3.1)

Wed Dec 18 20:59:47 PST 2013

Johan, 

I've collected more info on two processes[1] ... first the one that gets an "index out of range error" and the other process that was sitting in the process list waiting for more input from the socket, but the socket was closed (at leasted #isConnected is false). 

I hit the out of memory earlier but didn't collect any meaningful info ... I'm assuming that the multi-threaded boy is hitting an error somewhere and spinning away like crazy ... 

Need to catch the error in progress and perhaps find out from Sven if there is supposed to be a "deadman switch" on this guy to avoid infinite errors .. 

Dale 

[1] https://github.com/dalehenrich/todeHome/blob/master/home/seaside3.1.0/stacks 

----- Original Message -----

| From: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| To: "Johan Brichau" <johan at yesplan.be>
| Cc: glass at lists.gemtalksystems.com
| Sent: Wednesday, December 18, 2013 6:39:13 PM
| Subject: Re: [Glass] problem update: Zinc server with Seaside (3.1)

| Here's the stack:

| 1. OffsetError(AbstractException)>>_signalWith: @5 line 25
| 2. OffsetError(AbstractException)>>signal @2 line 47
| 3. ByteArray(Object)>>_error:args: @15 line 11
| 4. ByteArray(Object)>>_errorIndexOutOfRange: @2 line 6
| 5. ByteArray>>at: @4 line 13
| 6. SocketStream>>next @13 line 10
| 7. ZnLineReader>>processNext @5 line 4
| 8. ZnLineReader>>nextLine @3 line 3
| 9. ZnRequestLine>>readFrom: @3 line 3
| 10. ZnRequestLine class>>readFrom: @3 line 3
| 11. ZnRequest>>readHeaderFrom: @2 line 2
| 12. ZnRequest(ZnMessage)>>readBinaryFrom: @2 line 3
| 13. ZnRequest class(ZnMessage class)>>readBinaryFrom: @3 line 3
| 14. [] in
| ExecBlock1(ZnZincServerAdaptor)>>configureServerForBinaryReading @2
| line 4
| 15. [] in
| ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>readRequest:
| @3 line 6
| 16. [] in
| ExecBlock0(ZnSingleThreadedServer)>>withMaximumEntitySizeDo: @2 line
| 6
| 17. [] in ZnMaximumEntitySize class(DynamicVariable
| class)>>value:during: @3 line 9
| 18. ZnMaximumEntitySize class(ExecBlock)>>ensure: @2 line 12
| 19. ZnMaximumEntitySize class(DynamicVariable class)>>value:during:
| @6 line 10
| 20.
| ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>withMaximumEntitySizeDo:
| @5 line 5
| 21.
| ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>readRequest:
| @2 line 6
| 22. [] in
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>readRequestSafely:
| @2 line 4
| 23. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42
| 24.
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>readRequestSafely:
| @3 line 5
| 25.
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeOneRequestResponseOn:
| @2 line 7
| 26. [] in
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn:
| @2 line 10
| 27. [] in ZnCurrentServer class(DynamicVariable class)>>value:during:
| @3 line 9
| 28. ZnCurrentServer class(ExecBlock)>>ensure: @2 line 12
| 29. ZnCurrentServer class(DynamicVariable class)>>value:during: @6
| line 10
| 30.
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn:
| @4 line 8
| 31. [] in
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn:
| @2 line 9
| 32. ZnManagingMultiThreadedServer(ExecBlock)>>ensure: @2 line 12
| 33. [] in
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn:
| @2 line 10
| 34. [] in ExecBlock0(ExecBlock)>>ifCurtailed: @2 line 6
| 35. ExecBlock0(ExecBlock)>>ensure: @2 line 12
| 36. ZnManagingMultiThreadedServer(ExecBlock)>>ifCurtailed: @3 line 8
| 37. [] in
| ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn:
| @2 line 11
| 38. GsProcess>>_start @7 line 16
| 39. UndefinedObject(GsNMethod class)>>_gsReturnToC @1 line 1

| ----- Original Message -----

| | From: "Dale K. Henrichs" <dale.henrichs at gemtalksystems.com>
| 
| | To: "Johan Brichau" <johan at yesplan.be>
| 
| | Cc: glass at lists.gemtalksystems.com
| 
| | Sent: Wednesday, December 18, 2013 6:26:01 PM
| 
| | Subject: Re: [Glass] problem update: Zinc server with Seaside (3.1)
| 

| | Johan,
| 

| | I've finally started monkeying with this and the first thing I ran
| | into (running this under tODE and trying to duplicate the GemTools
| | error condition) was an error involving SocketStream and an
| | apparent
| | buffer overflow ... it looks to me that SocketStream>>next has no
| | logic to refill the buffer once it is full ... at least I got a
| | stack in which the ByteArray buffer was accessed at slot 4097 (1
| | larger than the buffer):
| 

| | There are three other processes floating around as well ... I'll
| | keep
| | digging ...
| 

| | Dale
| 

| | ----- Original Message -----
| 

| | | From: "Johan Brichau" <johan at yesplan.be>
| | 
| 
| | | To: glass at lists.gemtalksystems.com
| | 
| 
| | | Sent: Sunday, December 15, 2013 1:20:20 PM
| | 
| 
| | | Subject: [Glass] problem update: Zinc server with Seaside (3.1)
| | 
| 

| | | Hi all,
| | 
| 

| | | I’m working on the Zinc server adaptor for Seaside 3.1 but I got
| | | stuck.
| | 
| 

| | | Launching the following from Gemtools brings up the server and
| | | makes
| | | it respond to requests nicely. Trying to do the same from a topaz
| | | session though, immediately throws an out-of-mem exception.
| | 
| 

| | | WAGsZincAdaptor startOn: 8383
| | 
| 

| | | If you break the blocking call in Gemtools and run the line above
| | | again, you also run out-of-mem after a couple of times (but only
| | | after _also_ connecting to the server from your web browser).
| | 
| 
| | | First question about this is why that does not happen in gem
| | | tools?
| | | I
| | | tried turning the auto commit off but that did not change
| | | anything.
| | 
| 

| | | Following advice in [1], I started investigating from gemtools
| | | and
| | | got this for the byte sizes in temp obj memory on 75% full:
| | 
| 

| | | #'ByteArray'->22153440, #'GsMethodDictionary'->3073088,
| | | #'GsMethodLookupCache'->2224064, #'GsProcess'->562224,
| | | #'String'->415504, #'Array'->340168, #'SocketStream'->322680,
| | | #'ExecBlock'->201664, #'VariableContext'->175552,
| | | #'SocketStreamSocket'->150696, …0
| | 
| 

| | | The process browser shows over 100 threads displayed as follows:
| | 
| 

| | | (priority=25) ready [oop= …. ]
| | 
| 

| | | I guess this is where Dale started having nightmares. The stack
| | | traces show the out-of-mem always happens in the
| | | ZnNetworkingUtils>>setSocketStreamParameters: method.
| | 
| 

| | | All of this is using the current Zinc version on github for
| | | gemstone
| | | 3.1 [2] and my version of the Seaside 3.1 port [3]
| | 
| 
| | | To try, load Seaside from my repo, load the ‘Zinc-Seaside’ group
| | | from
| | | the baseline and hit the above.
| | 
| 

| | | Any ideas are welcome
| | 
| 

| | | Johan
| | 
| 

| | | [1]
| | | http://gemstonesoup.wordpress.com/2008/11/19/gemstone-101-managing-out-of-memory-situations/
| | 
| 
| | | [2] https://github.com/glassdb/zinc/tree/gemstone3.1
| | 
| 
| | | [3] https://github.com/jbrichau/Seaside31
| | 
| 
| | | _______________________________________________
| | 
| 
| | | Glass mailing list
| | 
| 
| | | Glass at lists.gemtalksystems.com
| | 
| 
| | | http://lists.gemtalksystems.com/mailman/listinfo/glass
| | 
| 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131218/45a358ba/attachment-0001.html>