6293LowSpaceWatcherFix-dtl considered harmful

David T. Lewis lewis at mail.msen.com
Fri Apr 1 03:44:03 UTC 2005


On Thu, Mar 31, 2005 at 06:27:02PM -0800, Andreas Raab wrote:
> Hi David -
> 
> Thanks for the history. Is there any post with a thorough analysis of 
> the sequence of events that made things go wrong, and consequently, why 
> changing the code the way you did would address this the problem? I'm 
> asking, because I am still not clear about why a change in this 
> particular place would make any difference on the low space watcher 
> behavior whatsoever (neither did the debugging facilities you sent along 
> seem to be related to Project>>interruptName:).

Hi Andreas,

I'm afraid that my memory is not too clear on the details at this point,
other that what I pulled out of the BFAV postings.  There were a few
other messages, but the heart of it was what I sent to you.

If you can wait until this weekend, I will spend some time figuring
out where this "fix" went wrong, and hopefully send you a more helpful
response (I have been looking at it this evening, but I am out of time
and energy until the weekend).

<speculation>
I think there is some difference in the way the low space semaphore is
being handled, versus the way the user interrupt semaphore is being handled.
Obviously I mis-diagnosed it, and I also did not consider the impact on
the user interrupt handler.  Perhaps the real problem is related to 
"Debugger openInterrupt: labelString onProcess: preemptedProcess" not
being able to open the debugger in time to stop the runaway recursion,
but that's just a guess at this point (and obviously my guesswork has
been less than satisfactory).
</speculation>

I believe it is true that the VM crash will happen only if:
- VM is running with fixed memory allocation (hence you will not see
  it on the Windows VM).
- Current project is Morphic (MVC is OK).
- Background processes (e.g. event tickler) are running at higher
  priority than the UI process.

With respect to the debugging facilities that I sent, the output on
stdout (console) for Squeak running a Unix VM with fixed memory
allocation looks like this (note, I added one additional debugging
line here to indicate when the debugger is about to be opened, hence
my speculation above):

lewis at dtlewis:~/squeak/squeak3.7> squeak -memory 10m Dev
3048:2445:Project class>>interruptName::about to open debugger with label Space is low
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 0
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 1
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 2
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 3
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 4
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 5
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 6
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 7
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 8
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 9
2561:3864:SystemDictionary>>createStackOverflow::low space signal already received, continuing with recursion depth: 10
2561:3864:SystemDictionary>>createStackOverflow::terminate recursion at depth: 10


More later,

Dave




More information about the Squeak-dev mailing list