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