OK, this is fixed. �Thanks, Jon. �The bug was that the pop of the folded constant did not record the implicit send in the folding, hence pc mapping was wrong. �i.e. 1-1 gets folded away to 0, and the code generator marks the result 0 as being the result of a send, but then the result gets discarded (when it is popped) without being noted in the pc map. �In the machine code there needs to be at least a nop generated, and in the map there needs to be an entry, to correspond to the send of +, so that when machine code pcs are mapped to bytecode pcs there are the correct number of entries in the map. �In the above case, the VM converts the interpreted frame to a machine code frame (coincidently) on the 20th iteration and needs to map the bytecode pc to the correct machine code pc to continue in machine code. �But because of the missing entry in the map for 1-1, the pc mapping machinery answered 0, and the VM ended up jumping into the void.

Thanks very much for the bug report!


On Fri, Nov 30, 2012 at 9:07 AM, Jon Anderson <jonkanderson@gmail.com> wrote:
Hi all,

I don't post to lists often, but I thought some of you might be
interested in these few lines of code that crash the CogVM on both
Linux and Windows. �File-in the Smalltalk code below, then evaluate
[nil crashCogVM]. �The code uses [1-1] but it could use [1+1] or
[56+98]. �I put the code on nil, but that is not important either. �I
think the important thing is that the primitive (+ or -) is evaluated
but the result is not assigned into any variable. �Also important is
that the code is put into a loop that I assume has been JIT optimized.
The image I used is Pharo 1.4 one-click with latest update #14459.
This code does not crash StackVM. Have fun! - Jon.

!UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'!
crashCogVM
� � � � " Evaluate [
� � � � � � � � nil crashCogVM ]"

� � � � | i |
� � � � i := 20.
� � � � 1 to: i do: [:d | 1-1 ]
! !




--
best,
Eliot