[Vm-dev] [Pharo-dev] eventual crashes pharo vm

[Eliot Miranda]

Hi Henry, Hi Marcus,

On Sun, Aug 13, 2017 at 5:08 AM, henry <henry at callistohouse.club> wrote:

> Hi all. I was testing with this eventual_test package and it blows up the
> pharo 6.1 vm. I'd welcome pointers
>
> http://www.squeaksource.com/TurquoiseTesting.html
>
> - HH
>

I took a look at this and I think you've found a bug in the
mustBeBooleanMagic: code.  What's happening is a mustBeBoolean in
Integer>>* due to evaluating
    10 * 42 eventual
in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument

Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and
does ^super * anInteger (where anInteger is the NearERef).  So that
evaluates Integer>>*

Integer>>* aNumber
"Refer to the comment in Number * "
aNumber isInteger ifTrue:
[^ self digitMultiply: aNumber
neg: self negative ~~ aNumber negative].
^ aNumber adaptToInteger: self andSend: #*

aNumber, being a NearERef, answers a PromiseERef for the isInteger send,
and this provokes a mustBeBoolean for the isInteger ifTrue: [...

After the mustBeBooleanMagic: the stack looks wrong. The activation of
Integer>>*, which is about to do
    ^ aNumber adaptToInteger: self andSend: #*
does not have enough items on the stack.  Instead of containing
    a NearERef (for 42)
    10
     #*
it contains
    a PromiseERef (for 42 eventual isInteger)

and the send of #adaptToInteger:andSend: ends up taking more form the stack
than the VM can handle and it crashes.  The bug appears to be with the use
of sendNode irInstruction nextBytecodeOffsetAfterJump in
Object>>mustBeBooleanMagic: since execution should resume at bytecode 55
below, but does so at bytecode 57

41 <10> pushTemp: 0
42 <D0> send: isInteger
43 <AC 09> jumpFalse: 54
45 <70> self
46 <10> pushTemp: 0
47 <70> self
48 <D1> send: negative
49 <10> pushTemp: 0
50 <D1> send: negative
51 <E2> send: ~~
52 <F3> send: digitMultiply:neg:
53 <7C> returnTop
54 <10> pushTemp: 0
55 <70> self
56 <24> pushConstant: #*
57 <F5> send: adaptToInteger:andSend:
58 <7C> returnTop

So the positioning of the context's pc must be before any argument
marshaling for the next send, not simply the send itself.

Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC
and resumePC temporaries at the beginning and capture them via
    initialPC := context pc.
at the beginning and then
context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump)
to see what I'm seeing.


Phew.  Glad it's not a VM bug :-)

HTH
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170816/ca09ffcf/attachment-0001.html>