[squeak-dev] Process bug introduced in 3.10

bryce at kampjes.demon.co.uk bryce at kampjes.demon.co.uk
Sun Apr 27 15:03:55 UTC 2008

Igor Stasenko writes:
 > I removed the MessageTally  and added outer fork , just to not lock ui
 > when test running. Everything works fine.
 > | processes |
 > [
 > 100 timesRepeat:
 >        [processes := (1 to: 10) collect: [:each|
 > 		[ [ ((Delay forMilliseconds: 500) wait) ] repeat ] fork ].
 >        (Delay forSeconds: 1) wait.
 >        processes do: [:each| each terminate].]
 > ] fork
 > In your test, a MessageTally will pop up a zeons windows, do you
 > really think its needed to be placed in test?
 > I suspect that it can work fine, but because of too many morphs
 > created it either run out of memory or spends too much time trying to
 > redraw screen. Also, since morphic was not designed with concurrency
 > in mind, adding morphs to world from different processes may lead to
 > race and damage different containers it using.

Thanks Igor, here's a bit more background and a reworked test. I
didn't realise that I was using Morphic in multiple threads in the
3.10 "clean" version of the test.

Here's the real test I started from:
	| processes  |
		compileMethod: #critical:
		class: Semaphore.
	processes := (1 to: 10) collect: [:each| [[(ExuperyProfiler spyOn: [(Delay forMilliseconds: 500) wait]) queueCompilationCommandsOn: SharedQueue2 new] repeat] fork ].
	(Delay forSeconds: 1) wait.
	processes do: [:each| each terminate].

Yes, it does need the profilers, they are there to generate plenty of
process switches to trigger a bug.

My next attempt at formulating a version of the same bug that'll
run in a vanilla 3.10 image is:

   100 timesRepeat:
	[processes := (1 to: 10) collect: [:each| [[(MessageTally new spyEvery: 1 on: [(Delay forMilliseconds: 500) wait]) ] repeat] fork ].
	(Delay forSeconds: 1) wait.
	processes do: [:each| each terminate].]

Debugging in an image with Exupery loaded (to provide logging to a
file only) it's locking up in "processes do: [:each| each terminate]"

It look's like the VM is still alive from poking around with gdb but
that the UI process is dead. In lockup printAllStacks is showing 87
profiling processes. The only other processes running are the idle
process and the finalisation process.


More information about the Squeak-dev mailing list