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 <
sven@stfx.eu> 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 <siguctua@gmail.com> 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 <sebastian@flowingconcept.com> 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.