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
|