Help for crash

Hi,
 From time to time my Seaside image crashes and I'm puzzled because there is no change in PharoDebug.log nor in access.log, suddenly the image process, puff... is gone.
Have you any hint? What should I look at?

I'm on linux lucid, cog vm, pharo 1.4, seaside 3.0.7 and nginx as reverse proxy

Tx
 Dave

which cog vm?
it should be a .dmp somewhere (where the image is, or where the vm is)

cheers,
Esteban

On Jul 29, 2012, at 11:11 AM, Dav <[hidden email]> wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Esteban,

Cog is:
VM: unix - i686 - linux-gnu - CoInterpreter VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 22 2012, StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid: bec8cdf0-4e06
-4975-8c02-e882fadf4df3 Jun 22 2012, https://git.gitorious.org/cogvm/blessed.git Commit: 744bfe905c78a1a5d408680a8780367ea77e0549 Date: Fri Jun 1 15:17:41 2012 +0200 By: Esteban Lorenzano


There is no dmp, sigh.
Dave

EstebanLM wrote

which cog vm?
it should be a .dmp somewhere (where the image is, or where the vm is)

cheers,
Esteban

damn... then I'm going to guess :P

I can bet that your problem is that you are running out of external semaphores :)

Here is the thing: by default, VM has an incredible small amount of external semaphores to use (external semaphores are used to the VM to signal the image that something is happening, for instance: incoming data in socket, etc.)
I think the number is 256 (don't know, because my image right now is answering 10m, which is also another stupid number, but in the other range).
Since each socket consumes 3 external semaphores (one for in, one for out and the other I don't remember, he), Seaside (and any web application) tends to empty the default available external semaphores.

So, to fix it, best way is to fix the vm... and there is already a change proposed by Igor to Eliot around, but still not integrated (or even discussed)... so, for now, you need to do it in the "hacky way":

go to

VirtualMachine>>#maxExternalSemaphores:

when it says:

        inProduction := false.

just change that line for

        inProduction := true.

voila, you have up to 65535 semaphores to open :)
also you can execute:

Smalltalk vm maxExternalSemaphoresSilently: 65535.

which is less crapy, but It creates probably unnecessary storage for external semaphores.

anyway, try that and let us know if that solves your problem. Otherwise the absence of dmp file means "correct vm exit", even if you are not expecting it. So is not a crash, is an image problem :)

Esteban

On Jul 29, 2012, at 11:39 AM, Dav <[hidden email]> wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

EstebanLM wrote

damn... then I'm going to guess :P

yep :-)

I can bet that your problem is that you are running out of external semaphores :)

Here is the thing: by default, VM has an incredible small amount of external semaphores to use (external semaphores are used to the VM to signal the image that something is happening, for instance: incoming data in socket, etc.)
I think the number is 256 (don't know, because my image right now is answering 10m, which is also another stupid number, but in the other range).
Since each socket consumes 3 external semaphores (one for in, one for out and the other I don't remember, he), Seaside (and any web application) tends to empty the default available external semaphores.

Is there a doc somewhere I can look at?

So, to fix it, best way is to fix the vm... and there is already a change proposed by Igor to Eliot around, but still not integrated (or even discussed)... so, for now, you need to do it in the "hacky way":

go to

VirtualMachine>>#maxExternalSemaphores:

when it says:

        inProduction := false.

just change that line for

        inProduction := true.

voila, you have up to 65535 semaphores to open :)

Ok, cool I'm gonna try it, thanks

also you can execute:

Smalltalk vm maxExternalSemaphoresSilently: 65535.

which is less crapy, but It creates probably unnecessary storage for external semaphores.

anyway, try that and let us know if that solves your problem. Otherwise the absence of dmp file means "correct vm exit", even if you are not expecting it. So is not a crash, is an image problem :)

I see :)
Cheers
 Dave

Esteban

On Jul 29, 2012, at 11:39 AM, Dav <[hidden email]> wrote:

> Hi Esteban,
>
> Cog is:
> VM: unix - i686 - linux-gnu - CoInterpreter
> VMMaker-oscog-EstebanLorenzano.160 uuid:
> bec8cdf0-4e06-4975-8c02-e882fadf4df3 Jun 22 2012,
> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.160 uuid:
> bec8cdf0-4e06
> -4975-8c02-e882fadf4df3 Jun 22 2012,
> https://git.gitorious.org/cogvm/blessed.git Commit:
> 744bfe905c78a1a5d408680a8780367ea77e0549 Date: Fri Jun 1 15:17:41 2012 +0200
> By: Esteban Lorenzano
>
>
> There is no dmp, sigh.
> Dave
>
>
>
> EstebanLM wrote
>>
>> which cog vm?
>> it should be a .dmp somewhere (where the image is, or where the vm is)
>>
>> cheers,
>> Esteban
>>
>>
>>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Help-for-crash-tp4642032p4642036.html
> Sent from the Seaside General mailing list archive at Nabble.com.
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside