This was the first thing I fixed in my image, but it's just a fix for the
symptoms, and not the cause. Also, this fix has no effect in a running 
image, until [Sensor installInterruptWatcher] is evaluated, because the 
existing process is still running the old method in the loop.

It seems like new UI processes share the WorldState object with other 
UI processes, so I'll have to come up with a workaround for this.

Another unrelated problem I see here is that the SoundService's registry 
is not used as it was designed:

 	SoundService registeredClasses anySatisfy: #isBehavior "==> false"

Instances are registered instead of classes, which may be benefical, but 
it causes some trouble here. In my image there are three registered 
SoundServices: a DummySoundSystem, a BaseSoundSystem, and another 
DummySoundSystem. If classes were used, then the code would have prevented 
the double registration.

Levente


On Sun, 15 Mar 2015, Chris Muller wrote:

> Levente wrote:
>
>> ... I think the error can occur if you use the same WorldState object from multiple UI processes (but doing that is a bad
>> idea).
>
> So there it is, that big stack (from my other post) is the
> userInterruptWatcher waking up from my pressing the interrupt key.
> How did it find its way into WorldState to do some
> drawWorld:submorphs:invalidAreasOn:'ing?  It happened before
> userInterruptWater even attempted to open the debugger, because it
> first executes:
>
>   SoundService default shutDown.
>
> and even though the SoundService's 'default' instance was nil, it
> needed to construct one just so it can forthwith tell it to #shutDown.
> Brilliant!  :)
>
> It gets better.  The system has to know *which kind* of SoundService
> it should construct before it can construct it and tell it to
> shutDown.  But there are two!  BaseSoundSystem and DummySoundSystem.
> But, oh, which one?  Hm, maybe best in this situation to pop up a menu
> to ask the user (not)!
>
> And so to pop up such a menu it is now into the WorldState machinery
> and image meltdown.
>
> I hope papering over it with this simple guard before the insanity
> starts in lowSpaceWatcher will help, but something feels unsettling
> about the distance between the cause and the symptom.
>
> Accessing WorldState from multiple UI processes is a bad idea, for
> sure, but IF it happens, the penalty is of a locked image is pretty
> strict..
>
>
>
> On Sun, Mar 15, 2015 at 10:12 PM,  <commits at source.squeak.org> wrote:
>> Chris Muller uploaded a new version of Kernel to project The Trunk:
>> http://source.squeak.org/trunk/Kernel-cmm.911.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Kernel-cmm.911
>> Author: cmm
>> Time: 15 March 2015, 10:12:04.602 pm
>> UUID: 0d5cd697-a536-47ec-8c0c-0b8b38bf297a
>> Ancestors: Kernel-ul.910
>>
>> - Don't create a SoundSystem just to send #shutDown to it, so that its lazy-initialization will not try to pop up a menu asking the user which type to create and, in the process, invoking WorldState behaviors from outside the UI process and colliding with the new intercycle pause implementation.
>>
>> =============== Diff against Kernel-ul.910 ===============
>>
>> Item was changed:
>>   ----- Method: InputSensor>>userInterruptWatcher (in category 'user interrupts') -----
>>   userInterruptWatcher
>>         "Wait for user interrupts and open a notifier on the active process when one occurs."
>> -
>>         [ InterruptSemaphore wait.
>>         Display deferUpdates: false.
>> +       SoundService defaultOrNil ifNotNil: [ : soundSystem | soundSystem shutDown ].
>> -       SoundService default shutDown.
>>         Smalltalk handleUserInterrupt ] repeat!
>>
>>
>
>