<div dir="ltr">Hi Marcel,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 25, 2015 at 5:45 AM, marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, all.<br>
<br>
Try this (on a Windows machine?):<br>
<br>
v := [^ true].<br>
v value.<br>
<br>
A debugger appears with BlockCannotReturn. Try proceed. The VM will crash.<br>
My image is 4.6, but it also happens 4.5 with a #2776 CogVM. ...and also in<br>
Squeak 3.9 with an interpreter VM. However in 3.9, I can hit proceed at<br>
least once--the second click crashes the VM.<br>
<br>
Why's that?<br></blockquote><div><br></div><div>It's because the pc is left pointing at the bytecode following the return, not the return itself, so when one proceeds one starts to execute random code. If you try the same thing in the TackInterpreter you can proceed without crashing the VM but executing the method produces (when I tried it) an MNU form sending the message selector 3 (the Integer 3) to nil.l This is because the VM was executing the trailer bytes of the method.</div><div><br></div><div>Here's the bytecode for the method:</div><div><br></div><div><div>17 <8F 00 00 01> closureNumCopied: 0 numArgs: 0 bytes 21 to 21</div><div>21 <span class="Apple-tab-span" style="white-space:pre"> </span><79> return: true</div><div>22 <81 C0> storeIntoLit: v</div><div>24 <7C> returnTop</div></div><div><br></div><div>When the cannot return is raised, the block activation's pc ends up being 22, /not/ 21. So when one proceeds the VM executes the storeIntoLit:, which is bad because there isn't even anything on the stack to store. So chaos ensues.</div><div><br></div><div>David, what's the pc in an Interpreter VM?</div><div><br></div><div>There are two solutions I can think of. One is to leave the pc positioned at the return, and one is to have the proceed machinery check that the bytecode pc is valid and not proceed if it isn't. I prefer the latter. Adding support for the former requires more metadata to be generated in methods and hacks to the pc mapping machinery which usually deals with addresses immediately after something (e.g. a send is mapped at the return address for the send, the instruction following the call of the send). It's pretty clear that the proceed attept is bogus here and the image could easily cause an error. e.g.</div><div><br></div><div>self embeddedBlockClosures collect: [:ea| ea startpc -> ea endPC] an OrderedCollection(21->21)<br></div><div>self initialPC -> self endPC 17->24<br></div><div><br></div><div>And so it's easy to check whether a context's pc is in range before proceeding.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
Marcel<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/How-to-crash-CogVM-or-InterpreterVM-while-debugging-BlockCannotReturn-tp4834042.html" rel="noreferrer" target="_blank">http://forum.world.st/How-to-crash-CogVM-or-InterpreterVM-while-debugging-BlockCannotReturn-tp4834042.html</a><br>
Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>