[Pharo-project] Headless image hanging
Hi list, I think I asked this a while ago but never managed to find a solution, so here we go: I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it. For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is index >= 0 && index <= numSignalRequests 133 repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again... Any clues? Is this a known bug? Cheers, -- Bernat Romagosa.
Bernat, You could try to use the Finder to search the source(s) for this string or parts of it. I couldn't find it in my image⦠Sven On 17 Aug 2011, at 07:32, Bernat Romagosa wrote:
Hi list,
I think I asked this a while ago but never managed to find a solution, so here we go:
I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it.
For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is
index >= 0 && index <= numSignalRequests 133
repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again...
Any clues? Is this a known bug?
Cheers,
-- Bernat Romagosa.
On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven@beta9.be>wrote:
Bernat,
You could try to use the Finder to search the source(s) for this string or parts of it. I couldn't find it in my imageâ¦
That's an assert that is failing in the VM side. index >= 0 && index <= numSignalRequests 133 means that "index >= 0 && index <= numSignalRequests" evaluated to false, and 133 is the line number in the C code. BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Sven
On 17 Aug 2011, at 07:32, Bernat Romagosa wrote:
Hi list,
I think I asked this a while ago but never managed to find a solution, so here we go:
I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it.
For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is
index >= 0 && index <= numSignalRequests 133
repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again...
Any clues? Is this a known bug?
Cheers,
-- Bernat Romagosa.
-- Mariano http://marianopeck.wordpress.com
BTW...your VM is quite "old". Why don't you give a try with a new one? On Wed, Aug 17, 2011 at 9:35 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven@beta9.be>wrote:
Bernat,
You could try to use the Finder to search the source(s) for this string or parts of it. I couldn't find it in my imageâ¦
That's an assert that is failing in the VM side.
index >= 0 && index <= numSignalRequests 133
means that "index >= 0 && index <= numSignalRequests" evaluated to false, and 133 is the line number in the C code.
BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Sven
On 17 Aug 2011, at 07:32, Bernat Romagosa wrote:
Hi list,
I think I asked this a while ago but never managed to find a solution, so here we go:
I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it.
For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is
index >= 0 && index <= numSignalRequests 133
repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again...
Any clues? Is this a known bug?
Cheers,
-- Bernat Romagosa.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
And the assert is failing is indeed in sqExternalSemaphores.c Here: /* Signal the external semaphore with the given index. Answer non-zero on * success, zero otherwise. This function is (should be) thread-safe; * multiple threads may attempt to signal the same semaphore without error. * An index of zero should be and is silently ignored. */ sqInt signalSemaphoreWithIndex(sqInt index) { int i = index - 1; int v; /* An index of zero should be and is silently ignored. */ assert(index >= 0 && index <= numSignalRequests); if ((unsigned)i >= numSignalRequests) return 0; On Wed, Aug 17, 2011 at 9:37 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
BTW...your VM is quite "old". Why don't you give a try with a new one?
On Wed, Aug 17, 2011 at 9:35 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Wed, Aug 17, 2011 at 9:16 AM, Sven Van Caekenberghe <sven@beta9.be>wrote:
Bernat,
You could try to use the Finder to search the source(s) for this string or parts of it. I couldn't find it in my imageâ¦
That's an assert that is failing in the VM side.
index >= 0 && index <= numSignalRequests 133
means that "index >= 0 && index <= numSignalRequests" evaluated to false, and 133 is the line number in the C code.
BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Sven
On 17 Aug 2011, at 07:32, Bernat Romagosa wrote:
Hi list,
I think I asked this a while ago but never managed to find a solution, so here we go:
I have an image running under a screen session in my server, it's running my simple blog written in Iliad and nothing else. The image is a Pharo 1.2.1 on a Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] machine, the server is a VPSLink slice with Debian 5 on it.
For a very long while now I've been experiencing a weird behaviour. The image runs flawlessly and fast for a couple of days, then it hangs without any apparent reason, just stops working overnight, and the only output I get in the console is
index >= 0 && index <= numSignalRequests 133
repeatedly, and after that the website can't be accessed neither can I reach the image via VNC, so the only solution is to kill the process and fire it up again...
Any clues? Is this a known bug?
Cheers,
-- Bernat Romagosa.
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote:
BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Probably, http://code.google.com/p/pharo/issues/detail?id=4505 Hendrik fixed it for 1.4 You can manually extend the table in 1.2 like this: "Extend the external object table to allow for more sockets" Smalltalk vmParameterAt: 49 put: 8192. This is only needed for Cog VMs. Sven
Thanks all! So I extended the table, let's see how it holds up now! Mariano, I know the vm's a little bit old, but I had already tried updating to the latest one and still had the same problem. Will update it anyway now that I noticed :) Thanks again! Cheers, 2011/8/17 Sven Van Caekenberghe <sven@beta9.be>
On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote:
BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Probably, http://code.google.com/p/pharo/issues/detail?id=4505
Hendrik fixed it for 1.4
You can manually extend the table in 1.2 like this:
"Extend the external object table to allow for more sockets" Smalltalk vmParameterAt: 49 put: 8192.
This is only needed for Cog VMs.
Sven
-- Bernat Romagosa.
It was too beautiful to be true :( The previous problem is gone, but here's what's happening now: acceptHandler: Too many open files acceptHandler: aborting server 7 pss=0x9311668 socketStatus: freeing invalidated pss=0x9311668 acceptHandler: Too many open files acceptHandler: aborting server 8 pss=0x93116a0 socketStatus: freeing invalidated pss=0x93116a0 Any ideas? 2011/8/17 Bernat Romagosa <tibabenfortlapalanca@gmail.com>
Thanks all! So I extended the table, let's see how it holds up now!
Mariano, I know the vm's a little bit old, but I had already tried updating to the latest one and still had the same problem. Will update it anyway now that I noticed :)
Thanks again!
Cheers,
2011/8/17 Sven Van Caekenberghe <sven@beta9.be>
On 17 Aug 2011, at 09:35, Mariano Martinez Peck wrote:
BTW, is not this the problem of Sempahores or I don't know what that you need to change/make bigger in Cog ?
Probably, http://code.google.com/p/pharo/issues/detail?id=4505
Hendrik fixed it for 1.4
You can manually extend the table in 1.2 like this:
"Extend the external object table to allow for more sockets" Smalltalk vmParameterAt: 49 put: 8192.
This is only needed for Cog VMs.
Sven
-- Bernat Romagosa.
-- Bernat Romagosa.
On 23 Aug 2011, at 23:44, Bernat Romagosa wrote:
Any ideas?
Many people, including myself, have various images running for many weeks and even months, so it is possible. I am guessing that you are running some Seaside (maybe Pier) with one of the standard HTTP servers ? Those should not leave connections hanging open. Maybe the VNC stuff is the culprit ? I never use VNC, but the Seaside tools (Status | Config | Inspector | Browser | Dispatcher | VersionUploader) to manage and debug running servers. Just make sure you set them up with at least a password. Then you could try to find out what is happening. Sven
Yeah, I also do have several images that have been running for months without crashing, that's what's bugging me :) This is an Iliad app, I'll check both how I overrode the session class and the VNC connection to see if I can get closer to where the problem comes from. Thanks! Bernat. 2011/8/29 Sven Van Caekenberghe <sven@beta9.be>
On 23 Aug 2011, at 23:44, Bernat Romagosa wrote:
Any ideas?
Many people, including myself, have various images running for many weeks and even months, so it is possible. I am guessing that you are running some Seaside (maybe Pier) with one of the standard HTTP servers ? Those should not leave connections hanging open. Maybe the VNC stuff is the culprit ?
I never use VNC, but the Seaside tools (Status | Config | Inspector | Browser | Dispatcher | VersionUploader) to manage and debug running servers. Just make sure you set them up with at least a password. Then you could try to find out what is happening.
Sven
-- Bernat Romagosa.
participants (3)
-
Bernat Romagosa -
Mariano Martinez Peck -
Sven Van Caekenberghe