On Nov 12, 2012, at 9:32 PM, Sebastian Sastre wrote:

> sure Stef.
> 
>> Did you try with the VM with the new semaphores?
> not sure. The method below answers this question?
> 
>> and without the new semaphores handling?
> again, now sure. 
> 
>> In the two cases the primitives used looks different.
> What should I look?
sorry I was unclear. I look at the log and at the end you have recently invoked 
primitives.


>> Could you also provide a size of the image?
> it's a 53MB image but in RAM
so it does not look like large. 

> at the moment of the crash we don't know (we wanted to know but we didn't 
> catched it in fraganti)
> 
>> If the crash reproducible?
> in development in OS X no it doesn't (same data). 
> 
> in production, since we started the app with the StackVM, we are having 
> uninterrupted uptime (so far and counting…)

We should probably see if igor/esteban can have a look.
What you are saying is that it would be more a problem on linux.

> 
> sebastian
> 
> o/
> 
> 
> Pharo1.4
> Latest update: #14459
> 
> VirtualMachine>>maxExternalSemaphores: aSize 
>       "This method should never be called as result of normal program
>       execution. If it is however, handle it differently:
>       - In development, signal an error to promt user to set a bigger size
>       at startup immediately.
>       - In production, accept the cost of potentially unhandled interrupts,
>       but log the action for later review.
>       
>       See comment in maxExternalObjectsSilently: why this behaviour is
>       desirable, "
>       "Can't find a place where development/production is decided.
>       Suggest Smalltalk image inProduction, but use an overridable temp
>       meanwhile. "
>       | inProduction |
>       self maxExternalSemaphores
>               ifNil: [^ 0].
>       inProduction := true.
>       ^ inProduction
>               ifTrue: [self maxExternalSemaphoresSilently: aSize.
>                       self crTrace: 'WARNING: Had to increase size of 
> semaphore signal handling table due to many external objects concurrently in 
> use';
>                                crTrace: 'You should increase this size at 
> startup using #maxExternalObjectsSilently:';
>                                crTrace: 'Current table size: ' , self 
> maxExternalSemaphores printString]
>               ifFalse: ["Smalltalk image"
>                       self error: 'Not enough space for external objects, set 
> a larger size at startup!'
>                       "Smalltalk image"]
> 
> 
> 
> 
> 
> 
> 
> 
> On Nov 12, 2012, at 6:22 PM, Stéphane Ducasse wrote:
> 
>> thanks a lot for sharing that with us.
>> Did you try with the VM with the new semaphores? and without the new 
>> semaphores handling?
>> In the two cases the primitives used looks different.
>> Could you also provide a size of the image?
>> If the crash reproducible?
>> Stef
>> 
>> On Nov 12, 2012, at 8:12 PM, Sebastian Sastre 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
>>> 
>>> <dump.zip>
>>> 
>>> sebastian
>>> 
>>> o/
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 


Reply via email to