Hi Norbert,

On Thu, Dec 8, 2011 at 2:04 AM, Norbert Hartl <norbert@hartl.name> wrote:

Eliot,

can you take a look at the attached crash.dmp file? My knowledge about the internals is limited so I'm not a good candidate to get a feeling what could have been gone wrong. 

If I would have to guess I would think there is a dead lock in ExternalSemaphoreTable. It looks to me as if the outgoing network connect tries to register an external object at the same time the snapshot:andQuit: tries to clear the external objects. But I know nothing how this works. 

OK, as a favour to you.  Next time you do the leg work. But all the info you need is in the dump.  First thing, the active process is the idle process:

 

Process  0x8f1d2a8 priority 10

0xbff60000 M ProcessorScheduler class>idleProcess 64373036: a(n) ProcessorScheduler class

 0x8f929b0 s [] in ProcessorScheduler class>startUp

 0x8f1d248 s [] in BlockClosure>newProcess

(you can see form the C stack trace that the VM is looping doing primitiveRelinquishProcessor)

The next process is the finalization process, which has nothing to do.

Then Process  0x8d73268 priority 20 is trying to do a connect but is blocks in a critical section trying to register one or other of the Socket's semaphores.

Then Process  0x8f23b98 priority 20 is trying to do a snapshot and is blocked in a critical section doing SmalltalkImage>clearExternalObjects.

So my guesses are either that

    a) something terminated a process that was in the critical section for registering external objects and the semaphore protecting it is missing a signal, or

    b) there is a bug in the code and that if a process is in the critical section registering an external object then SmalltalkImage>clearExternalObjects my lock-up.

But you can read Smalltalk stack traces as well as I.  Just look at them. There are only 11 of them.

Norbert

Am 07.12.2011 um 22:49 schrieb Eliot Miranda:

On Wed, Dec 7, 2011 at 10:55 AM, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:

That assumes there is an error.  Another (even more frustrating) failure arises when an image does nothing. It is very help to be able to get callstacks in that scenario.

On Mac and Linux the Cog VM responds to SIGUSR1 by dumping all stacks to crash.dmp.

 

---

From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Javier Pim�s [elpochodelagente@gmail.com]
Sent: Wednesday, December 07, 2011 1:52 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] How to resurrect an unrepsonsive image?

Probably you have a crash.dmp or a PharoDebug.log which tells you what is happening. Look at the backtrace to see what causes the error and then maybe there's some way to help you fixing it.

Cheers,

Javier.

On Wed, Dec 7, 2011 at 10:47 AM, Norbert Hartl <norbert@hartl.name> wrote:

I have a headless image that was running for a couple of days. Now it is not responding anymore. The image was running still but the sockets for http and vnc were closed and restarting the image just brings it up without any sockets opened.
Injecting something via script does not work either. I copied the image to my desktop and tried a few things but no success.
What would be a good way to get  a glimpse of what is causing problems?
I had Scheduler running that saved the image every hour. And the image itself issues http request to the outside world every 10 minutes.

thanks,

Norbert

--
Lic. Javier Pim�s
Ciudad de Buenos Aires

--
best,

Eliot