is the same smalltalk code with same primitives, but not same vm. I have spotten this problem time to time, and I have the feeling of being something related to the JIT (that's why my first suggestion to Sebastian was to use the StackVM). Most probably: some optimization flags behaves slightly different in different platforms and then some operations made by the jitter ends trying to access invalid memory segments.
but as I said, is just a "feeling", since is really hard to catch and I don't have real proof (besides the "indirect one": it works fine if we took off the jit). Esteban On Nov 13, 2012, at 11:00 AM, Sven Van Caekenberghe <[email protected]> wrote: > These situations are very hard to debug by outsiders, for the community to > help we need a reproduceable case that does not depend on internal or private > services. > > The stacktrace is not exceptional as far as I can see: it is trying to read a > response until EOF, after a POST. > > It is quite strange that it would work with the stack VM, since the same > Smalltalk code is then running, using the same primitives. Maybe the other VM > just postpones/changes the way it fails. > > Running out of semaphores is a resource management problem, caused directly > or indirectly from certain usage patterns. Again, see the first sentence. > > I would advice running units and/or stress tests on the server or on a Linux > VM with UI on your Mac. > > Bughunts are never easy… > > On 13 Nov 2012, at 00:33, Igor Stasenko <[email protected]> wrote: > >> yeah the dumps are really strange.. >> seems like most of the times crashing at this point: >> >> 0xffc05bd8 M ZnChunkedReadStream>next -613198972: a(n) ZnChunkedReadStream >> 0xffc05bfc M ZnUTF8Encoder>nextFromStream: -613185216: a(n) ZnUTF8Encoder >> 0xffc05c30 M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) >> ZnStringEntity >> 0xffc1333c M BlockClosure>on:do: -613184868: a(n) BlockClosure >> 0xffc1336c M [] in ZnStringEntity>readUpToEndFrom: -613186408: a(n) >> ZnStringEntity >> 0xffc1338c M String class(SequenceableCollection >> class)>new:streamContents: -679940384: a(n) String class >> 0xffc133ac M String class(SequenceableCollection >> class)>streamContents: -679940384: a(n) String class >> 0xffc133d8 M ZnStringEntity>readUpToEndFrom: -613186408: a(n) ZnStringEntity >> 0xffc133f4 M ZnStringEntity>readFrom: -613186408: a(n) ZnStringEntity >> 0xffc13414 M ZnEntity class>readFrom:usingType:andLength: -678925448: >> a(n) ZnEntity class >> 0xffc13440 M ZnEntityReader>readFrom:usingType:andLength: -613217204: >> a(n) ZnEntityReader >> 0xffc13474 M ZnEntityReader>readEntityFromStream -613217204: a(n) >> ZnEntityReader >> 0xffc13490 M ZnEntityReader>readEntity -613217204: a(n) ZnEntityReader >> 0xffc134ac M ZnResponse(ZnMessage)>readEntityFrom: -614400344: a(n) >> ZnResponse >> 0xffc134c8 M ZnResponse>readEntityFrom: -614400344: a(n) ZnResponse >> >> On 12 November 2012 16:12, Sebastian Sastre <[email protected]> >> wrote: >>> Hi guys, >>> >>> I'm sorry for this news. >>> >>> We have a web app that's is increasingly crashing in production (on linux). >>> >>> In development (OS X) we couldn't reproduce >>> >>> We are falling back to the StackVM >>> >>> Here is some dump data we could get >>> >>> sebastian >>> >>> o/ >> >> -- >> Best regards, >> Igor Stasenko. > >
