I haven't quite gotten to the bottom of this, but here is what I've found
so far.

The problem is that the low space notification is executing in the context
of the event tickler process, while whatever method is running way with
the memory is running in another process and does not get suspended.
I can confirm this with OSProcess trace commands embedded in #lowSpaceWatcher,
and a hacked up version of #createStackOverflow that forces a halt before
the system hangs up.

Furthermore, if the event tickler process is terminated, low space
notification starts working as expected. So it must be some interaction
of these processes, and it does not happen unless the event tickler is
running.

What I can't figure out is how the low space signal is getting handled
in the context of the event tickler process, when the low space watcher
process is the one that is waiting on the semaphore. The low space signaling
in the VM interpreter seems simple and straightforword, so it has to be
something on the image side ... I just can't spot it.

Anybody have an idea?

I've attached a copy of the hacks I'm using to debug this in case anyone
wants to reproduce the problem without hanging their image.

Dave


On Sun, May 16, 2004 at 10:43:08AM -0700, Tim Rowledge wrote:
> "David T. Lewis" <lewis at mail.msen.com> wrote:
> 
> > On Wed, Apr 28, 2004 at 10:36:16PM -0600, tim at sumeru.stanford.edu wrote:
> > > 
> > > This appears to be the same problem mentioned in recent reports of not
> > > being able to interrupt a recursive process. If something is making the 
> > > low space signal not work properly - leaving the runaway process
> > > careering like a drunken driver down the roadway of memory loss - then
> > > one of our major system safeguards is inneffective. Not good.
> > 
> > [Background on this thread: Squeak hangs up and crashes with out-of-memory
> > condition due to low space alarm not working. Observed on Unix/Linux VM.]
> Also on RISC OS  and win32 (IIRC)
> > 
> > I can't quite get a handle on what is happening here, but I am fairly
> > sure that it is *not* a problem with the low space signal. The signal
> > is properly created in the VM. It is caught by the waiting low space
> > watcher process, and the notifier is being displayed. *After* these
> > things take place, Squeak crashes with an out of memory condition,
> > as if the original runaway recursive process had proceeded without
> > interruption (although I don't think this is what is literally happening).
> I did a whole load of test runs for this a while back and it really
> does seem like the problem proces keps on running despite the notifier. 
> 
> > One other observation: The problem does not occur in MVC. The combination
> > of Morphic and a Unix/Linux VM is apparently needed to make the problem
> > occur.
> Just tried again for 3.7, 3.6, 3.5 and 3.2 in both morphic and mvc and
> none of them behave 'properly'. 3.6 & 3.5 morphic shewed notifiers but
> still crashed. None of the others even shewed a notifier. 
> 
> 
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: EOS: Erase Operating System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StackOverflowDebugging-dtl.1.cs.gz
Type: application/x-gunzip
Size: 1564 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040522/4dd304aa/StackOverflowDebugging-dtl.1.cs.bin