can't say anything about jit but, for what is worth, it's flawlessly up since we started using the StackVM
sebastian o/ On Nov 13, 2012, at 8:11 AM, Esteban Lorenzano wrote: > 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. >> >> > >
