On Wednesday 15 December 2004 11:26 pm, Jan B. Krejčí wrote:
> Hi,
>
> As an example, I've tried this:
>
> 1) I wrote to Workspace:
> [ [true] whileTrue: [] ] fork
> 2)  pressed Alt-D to run it
> 3) saved the image (took me some time, but I managed to do it)
> 4) after I restarted Squeak, black window has appeared and Squeak has
> started to eat about 80% of CPU, not reacting to any input
>
> when I started Squeak again with David's process-listing startup
> script, it did not execute (or maybe I'm not patient enough, waiting
> ten minutes). I wasn't even able to break the thread by Alt-. So maybe
> in cases like this the startup script killing the ugly processes isn't
> strong enough.
>
> I'm thinking of few possible ways to resurrect such a messed image.
> (And believe me, until I have established myself some rules, I messed
> it up many, many times. Now I carefully stop all the stuff I wrote
> before I save the image and start it again with a startup script.):

What I have done in the past is to use the InterpreterSimulator to open one 
image from another. I believe that Dan, Craig, (and others?) have gotten the 
IS working again.

At that point, you can examine things as desired.

> first - maybe the idea of "addToStartupList" is not very good and one
> should avoid this approach to make things run when starting Squeak.
>
> second - maybe the keyboard interrupt watching thread should be
> scheduled at higer priority

It's already quite high. However, since it uses the UI to display the 
debugger, if you break Morphic you're going to be in trouble.

> third - could some emergency-startup support be incorporated right into the
> VM?

Unfortunately, the VM doesn't really have any way to call back into the image.

-- 
Ned Konz
http://bike-nomad.com/squeak/