> I can go quite deep. The crash occurs inside Parser>>method:context: .
> 
> I get the same crash with
> 	"self halt. Interpreter translate: 'InterpTest.c' doInlining: true."

Jupp. I found it. It's actually quite interesting what's going on here:
Your'e basically simulating the Parser in both expressions. Now, the
parser obviously needs to look up the literals from a method to translate
and it therefore calles Symbol>>hasInterned:ifTrue: quite some times
(to be exact, #hasInterned:ifTrue: is actually called by the Encoder but
this doesn't matter for the purpose of this explanation).
Ok, so #hasInterned:ifTrue: checks if a given string is already defined as
a symbol. It does so by looking up the symbol tables and doing a little
search in it.

Now to the simulation in the debugger: This stuff is run by ContextPart
(see category instruction decoding and system simulation) but for now
we're only interested in message sends. Whenever a message send is
simulated the compiled method is checked for containing a primitive.
Getting deeper into the simulation ContextPart needs to determine if this
primitive could be successfully executed or not so it can activate the
associated Smalltalk code in the case of primitive failure.
Getting even more deeper into this, ContextPart checks success or
failure of a method by returning #simulatorFail in the case of a problem.

Aha! And that's the point. The assumption is that NO PRIMITIVE CAN EVER
RETURN #simulatorFail IN THE CASE OF SUCCESS!!!! However, due to
#simulatorFail being a Symbol, a lookup in the symbol table by the parser
ACTUALLY CAN RETURN #simulatorFail.

Now, this brings us into big, big, trouble. Since the simulation thinks
that the lookup in the symbol table failed, it hands over control to the
smalltalk code. Now, this code is Object>>at: in our case and the error
code says that if the argument is an integer it has to be out of range for
the primitive to fail. Since the argument *is* an integer this leads to an
errorSubscriptBounds: leading to the raise of a debugger, leading to a new
window being opened, leading to a new process being forked --- all from
within the simulation which finally leads to a system crash. Q.E.D.

That's it,
     Andreas

PS. How to solve this?! Well, most likely by making a special singleton
symbol not showing up in the symbol table for indicating primitive
failure (for instance by using the #clone primitive which - by the way -
works on Symbols even though it shouldn't ;-).

-- 
Linear algebra is your friend - Trigonometry is your enemy.
+===== Andreas Raab ============= (raab at isg.cs.uni-magdeburg.de) =====+
I Department of Simulation and Graphics      Phone: +49 391 671 8065  I
I University of Magdeburg, Germany           Fax:   +49 391 671 1164  I
+=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+