<div>To let you know what I tried, trying to learn about this system as I dig into it, I added isInteger to the #blockedSelectors of NearERef. This crashed the squeak vm when I ran the test, and as I look into how blockedSelectors is used it smashes the resolver. What seems to be needed is a list of immediateSelectors, though that may grow to be a sizeable list. This causes me to think there must be a different approach between async and sync code.<br></div><div><br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user ">- HH<br></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: Re: [Vm-dev] [Pharo-dev] eventual crashes pharo vm<br></div><div>Local Time: August 16, 2017 11:46 PM<br></div><div>UTC Time: August 17, 2017 3:46 AM<br></div><div>From: henry@callistohouse.club<br></div><div>To: Eliot Miranda <eliot.miranda@gmail.com><br></div><div>Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org>, Pharo Development List <pharo-dev@lists.pharo.org>, Marcus Denker <marcus.denker@inria.fr><br></div><div><br></div><div>Hi Eliot,<br></div><div><br></div><div>I have disabled that test for the time being. It will require some deeper thought regarding immediate selectors, I think, and I am deep into another area right now. As mustBeBoolean is from inside the VM, a different approach may be the right solution. A part of me thinks autocoercion between msg sending (async) and msg calling (sync) is what is needed, but I want continuation-based VatSemaphores to prevent a liveness lock on the event loop to support. Again, I have not thought deep enough in this area.<br></div><div><br></div><div>Thanks again for your help,<br></div><div><br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user ">- HH<br></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [Pharo-dev] eventual crashes pharo vm<br></div><div>Local Time: August 16, 2017 10:32 PM<br></div><div>UTC Time: August 17, 2017 2:32 AM<br></div><div>From: eliot.miranda@gmail.com<br></div><div>To: henry <henry@callistohouse.club><br></div><div>Marcus Denker <marcus.denker@inria.fr>, Pharo Development List <pharo-dev@lists.pharo.org>, Squeak Virtual Machine Development Discussion <vm-dev@lists.squeakfoundation.org><br></div><div><br></div><div dir="ltr"><div>Hi Henry,<br></div><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Wed, Aug 16, 2017 at 6:33 PM, henry <span dir="ltr"><<a href="mailto:henry@callistohouse.club">henry@callistohouse.club</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.<br></div><div><br></div><div>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?<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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.<br></div></blockquote><div><br></div><div>Yes that's an issue There is already a problem with #==. It needs to be symmetric for correctness.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>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. <br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Thank you for investigating this.<br></div></blockquote><div><br></div><div>You're welcome.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div><br></div><div class="m_5600713812245111431protonmail_signature_block">- HH<br></div><div class="HOEnZb"><div class="h5"><div><div><br></div><div><div><br></div><div>On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br></div></div><blockquote class="m_5600713812245111431protonmail_quote" type="cite"><div dir="ltr"><div>Hi Henry, Hi Marcus, <br></div><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Sun, Aug 13, 2017 at 5:08 AM, henry <span dir="ltr"><<a href="mailto:henry@callistohouse.club">henry@callistohouse.club</a>></span> wrote: <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)"><div>Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers <br></div><div><br></div><div><a href="http://www.squeaksource.com/TurquoiseTesting.html">http://www.squeaksource.com/Tu<wbr>rquoiseTesting.html</a> <br></div><div><br></div><div class="m_5600713812245111431gmail-m_7806948026423193907protonmail_signature_block"><div class="m_5600713812245111431gmail-m_7806948026423193907protonmail_signature_block-user">- HH<br></div></div></blockquote><div><br></div><div>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<br></div><div> 10 * 42 eventual<br></div><div>in RefsTest>><wbr>testFailureArithmeticPrimitive<wbr>sWithPromiseArgument<br></div><div><br></div><div>Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>*<br></div><div><br></div><div>Integer>>* aNumber<br></div><div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>"Refer to the comment in Number * " <br></div><div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>aNumber isInteger ifTrue:<br></div><div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>[^ self digitMultiply: aNumber <br></div><div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>neg: self negative ~~ aNumber negative].<br></div><div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>^ aNumber adaptToInteger: self andSend: #*<br></div><div><br></div><div>aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [...<br></div><div><br></div><div>After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do<br></div><div> ^ aNumber adaptToInteger: self andSend: #*<br></div><div>does not have enough items on the stack. Instead of containing<br></div><div> a NearERef (for 42)<br></div><div> 10<br></div><div> #*<br></div><div>it contains<br></div><div> a PromiseERef (for 42 eventual isInteger)<br></div></div><div><br></div><div>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: <wbr>since
execution should resume at bytecode 55 below, but does so at bytecode 57 <br></div><div><br></div><div><br></div><div class="gmail_extra">41 <10> pushTemp: 0<br></div><div class="gmail_extra">42 <D0> send: isInteger<br></div><div class="gmail_extra">43 <AC 09> jumpFalse: 54<br></div><div class="gmail_extra">45 <70> self<br></div><div class="gmail_extra">46 <10> pushTemp: 0<br></div><div class="gmail_extra">47 <70> self<br></div><div class="gmail_extra">48 <D1> send: negative<br></div><div class="gmail_extra">49 <10> pushTemp: 0<br></div><div class="gmail_extra">50 <D1> send: negative<br></div><div class="gmail_extra">51 <E2> send: ~~<br></div><div class="gmail_extra">52 <F3> send: digitMultiply:neg:<br></div><div class="gmail_extra">53 <7C> returnTop<br></div><div class="gmail_extra">54 <10> pushTemp: 0<br></div><div class="gmail_extra">55 <70> self<br></div><div class="gmail_extra">56 <24> pushConstant: #*<br></div><div class="gmail_extra">57 <F5> send: adaptToInteger:andSend:<br></div><div class="gmail_extra">58 <7C> returnTop<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via<br></div><div class="gmail_extra"> initialPC := context pc.<br></div><div class="gmail_extra">at the beginning and then<br></div><div class="gmail_extra"><div class="gmail_extra"><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"></span>context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump)<br></div></div><div class="gmail_extra">to see what I'm seeing.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Phew. Glad it's not a VM bug :-)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">HTH<br></div><div class="m_5600713812245111431gmail_signature"><div dir="ltr"><div><span class="size" style="font-size:small"><div>_,,,^..^,,,_<br></div><div>best, Eliot<br></div><div><br></div></span></div></div></div></div></div></blockquote></div></div></div></blockquote></div><div><br></div><div><br></div><div><br></div><div>-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span class="size" style="font-size:small"><div>_,,,^..^,,,_<br></div><div>best, Eliot<br></div></span></div></div></div></div></div></blockquote><div><br></div></blockquote><div><br></div>