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).
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150626/6aaa7d32/attachment.htm