On Fri, Jun 26, 2015 at 9:10 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> Hi Marcel,
>
> On Thu, Jun 25, 2015 at 5:45 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
> wrote:
>
>> Hi, all.
>>
>> Try this (on a Windows machine?):
>>
>> v := [^ true].
>> v value.
>>
>> A debugger appears with BlockCannotReturn. Try proceed. The VM will crash.
>> My image is 4.6, but it also happens 4.5 with a #2776 CogVM. ...and also
>> in
>> Squeak 3.9 with an interpreter VM. However in 3.9, I can hit proceed at
>> least once--the second click crashes the VM.
>>
>> Why's that?
>>
>
> 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.
>
> Here's the bytecode for the method:
>
> 17 <8F 00 00 01> closureNumCopied: 0 numArgs: 0 bytes 21 to 21
> 21 <79> return: true
> 22 <81 C0> storeIntoLit: v
> 24 <7C> returnTop
>
> 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.
>
> David, what's the pc in an Interpreter VM?
>
> 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).
>

Actually I don't think I'm on track here.  In fact, the return bytecode has
been dispatched and raised an error while it is executing.  So the pc being
positioned after the return is correct.  In fact, I think the interpreter
will have the pc positioned after the return also.  Hence the Cogit would
be wrong to try and map the address following the non-local retrn to the
return itself.  In fact, leaving the pc where it is now is correct.  One
*could* change the VM spec and require the VM to back up the pc in this
case.  But its a lot of effort to add to the VM (bytecodes are variable
length; certain returns are compounds, push value, return top).  I think
the right thing to do is have the image check for a valid pc before
proceeding.  The VM has raised the error correctly.  Why burden it with
dealing with a situation that shouldn't happen?  Patient: "Doctor, it hurts
when I proceed after a cannot return!".  Doctor: "Don't do that.".

  It's pretty clear that the proceed attept is bogus here and the image
> could easily cause an error.  e.g.
>
> self embeddedBlockClosures collect: [:ea| ea startpc -> ea endPC] an
> OrderedCollection(21->21)
> self initialPC -> self endPC 17->24
>
> And so it's easy to check whether a context's pc is in range before
> proceeding.
>
>
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/How-to-crash-CogVM-or-InterpreterVM-while-debugging-BlockCannotReturn-tp4834042.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>>
>
>
> --
> best,
> Eliot
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150626/560f7583/attachment.htm