> 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 <
[hidden email]>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
Locked
