Debugging a bug that wasn't.

[bryce at kampjes.demon.co.uk]

I'm testing and debugging before the 0.14 release. The major benefit
is faster compile times and better generated code. There's around a
10% gain or loss for the macro benchmarks depending on what's
compiled.

The bug was triggered by the below code. Originally it was compiling
"^[42] value". The set-up shown below is what generates the fault
without needing to compile the code. The fault was odd because it
wasn't crashing, and wasn't stuck in an infinite loop but the image
had locked up. 

I was investigating by interrupting execution with gdb and looking at
both the Smalltalk stack using "p printCallStack()" and the C stack
using "where". Normally, if compiled code was corrupting the object
memory it would crash fairly quickly. That it kept executing, which
could be seen because the Smalltalk stack kept changing was weird.  If
the GC's got a corrupt view of the object memory then normally it'll
end up really corrupting it when it decides to try to interpret the
middle of an object as an object header.

The "Error signal." at the front of the test is because running the
test will lock up the image. This allows the rest of the suite to
be run.

    testInterruptCausesCrashes
	"Crashing is a failure"
	| processes |
	Error signal.
	self compileExpression: 'self createPoint'.
	processes := (1 to: 10) collect: 
	    [:each| [[(ExuperyProfiler
               spyOn: [(Delay forMilliseconds: 500) wait])
	         queueCompilationCommandsOn: SharedQueue2 new] repeat] fork.
	"Force a garbage collect on every allocation"
	SmalltalkImage current vmParameterAt: 5 put: 1.
	10000 timesRepeat: [self example].
        Exupery log: 'after running example'.
	"Reset garbage collects to a sensible value"
	SmalltalkImage current vmParameterAt: 5 put: 4000.
	processes do: [:each| each terminate].

    createPoint
	"^ 10 @ 20"

What I think is happening is the 10 profiling processes end up
consuming all the time and starving the user level process so it
never completes and never resets the garbage collector's collection
rate to a sane value. Having produced the lockup twice without any
compiled code, I'm reasonably happy that this is the case.

Bryce