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

Eliot Miranda eliot.miranda at gmail.com
Thu Aug 17 02:32:34 UTC 2017


Hi Henry,

On Wed, Aug 16, 2017 at 6:33 PM, henry <henry at callistohouse.club> wrote:

> That is good news, that it is due to this code doing funniness than a VM
> issue. This code trying to bring asynchrony within a synchronous
> environment brings new issues.
>
> What do you think that right solution is to the issue of a call
> expected to be immediate, change out to go eventual until the arguments
> resolve?
>

I'm not informed enough to know.  One could implement mustBeBoolean in the
ERef hierarchy and resolve the promise before going on.  One could rely on
the mustBeBooleanMagic: if one wanted a fully lazy system.  I don't know
the trade-offs between the two.  I do know that while the
miustBeBooleanMagic: solution is cool and fun it is extremely slow.  So if
performance is an issue use the first approach.



> How can it be structured correctly on the stack without generic functions?
> I think with the double dispatch of an eventual but I have not spend much
> time in this particular area.
>

Yes that's an issue  There is already a problem with #==.  It needs to be
symmetric for correctness.


> Preventing the vm from crashing would be a good interim step but even here
> I am not sure how to go about crafting a solution.
>

Well, the issue is simply that the wrong pc is chosen for the continuation
after the mustBeBoolean.  I'm sure the right answer is straight-forward to
obtain.



> Thank you for investigating this.
>

You're welcome.


>
> - HH
>
>
> On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
> 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
>
>


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


More information about the Vm-dev mailing list