On Wed, 16 Jun 1999 11:50:43 +1000 Russell Allen <russell.allen at firebirdmedia.com> wrote: 
>I have come across this quite a lot when running and debugging PWS.  I
>haven't been able to nail it down yet.  I have been wondering whether it
>has something to do with Morphic dealing with debugging a multi-process
>image; but that's just unfounded speculation :)

Russell (and Mark),

I think you are on the right track. When the debugger starts up, it suspends the process that had the error and ...

	Smalltalk isMorphic ifTrue:
		[self openFullMorphicLabel: aString.
		^ Project current spawnNewProcess].

This is fine if the error occurred in the main event loop process (the normal case), but if the error occurred in a forked process, then there will be running two processes with the same event handling:

doOneCycleNow
	"Do one cycle of the interactive loop. This method is called repeatedly when the world is running."

	"process user input events"
	hands do: [:h |
		self activeHand: h.
		h processEvents.
		self activeHand: nil].

	self runStepMethods.
	self displayWorldSafely.

If one process yields the processor (in a #wait, e.g.) while in #processEvents, the second process could run and nil the activeHand. When the first process resumes, it assumes its activeHand is still valid when it is not. I think the key may be for the debugger to spawn a new process *only* if the suspended process was the event loop process. I'll try that out and let you know what I find.

Cheers,
Bob