On Sat, Jun 27, 2015 at 6:21 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
> 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.".
>

+1
Seems like the most sane thing to do here.

Karl

>
>   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/20150627/bee01f39/attachment.htm