[squeak-dev] How to crash CogVM or InterpreterVM while debugging
karlramberg at gmail.com
Sat Jun 27 17:07:27 UTC 2015
On Sat, Jun 27, 2015 at 6:21 AM, Eliot Miranda <eliot.miranda at gmail.com>
> On Fri, Jun 26, 2015 at 9:10 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> Hi Marcel,
>> On Thu, Jun 25, 2015 at 5:45 AM, marcel.taeumel <Marcel.Taeumel at hpi.de>
>>> Hi, all.
>>> Try this (on a Windows machine?):
>>> v := [^ true].
>>> v value.
>>> A debugger appears with BlockCannotReturn. Try proceed. The VM will
>>> My image is 4.6, but it also happens 4.5 with a #2776 CogVM. ...and also
>>> 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
> 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.".
Seems like the most sane thing to do here.
> 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
>> self initialPC -> self endPC 17->24
>> And so it's easy to check whether a context's pc is in range before
>>> View this message in context:
>>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev