Archive for debugging

debugging remote exceptions works

Posted in consulting, Context, Smalltalk, Spoon with tags , , , , , , on 20 November 2014 by Craig Latta
a debugger for a remote unhandled exception

a debugger for a remote unhandled exception

I have debugging working for remote unhandled exceptions. My motivating use case was debugging messages not understood by the Context console’s embedded web server. The console is a headless app. In development, I run it with a remote-messaging connection to a headful system. Now, when there is an unhandled exception (like a message not understood), the exception requests that the headful system open a debugger (as its default action).

Before opening the debugger, the headful system replaces the sender of the first relevant context on the headless system with the last relevant context on the headful system, hiding all the remote-messaging-related contexts in between. The picture above shows an example of this. On the headful system, I sent “zork” to an object on the headless system. The debugger shows a continuous context stack which spans the two systems. This all works with little special handling in the debugger because of the complete transparency of remote messaging. It doesn’t matter that the contexts and methods that the debugger is manipulating happen to be remote.

Another VM debugging trick: halting

Posted in consulting, Smalltalk, Spoon with tags , , , , on 31 December 2013 by Craig Latta

Just another little VM debugging trick I use… In one of my VM plugins I include a little C function called “breakHere”, which Smalltalk can call as a primitive. I put a breakpoint on it in the C debugger, and then have a convenient way to break in the C debugger from Smalltalk.

VM debugging trick: browsing object memory snapshots made from the C debugger in the simulator

Posted in Smalltalk, Spoon with tags , , , , , , on 17 December 2013 by Craig Latta

Recently I made use of a virtual machine debugging trick that I don’t think I’ve written about here. The virtual machine simulator is a great way to browse around the state of object memory at the point of a VM crash, but it’s relatively slow (I measured it at about 3,000 instructions per second in my sonification work). The time it takes to get to that point might be prohibitively long.

Instead, you can run to that point in the C debugger (I use lldb on Mac OS), and make a snapshot by invoking primitiveSnapshot() manually. Then, open a simulator on that snapshot and browse the objects to your heart’s content. Depending on the error, you might even be able to modify the objects such that the active process may proceed, and you can snapshot a repaired object memory from the simulator.

Image

toward a virtual machine browser

Posted in Naiad, Smalltalk, Spoon with tags , , on 27 November 2013 by Craig Latta

I just had an idea for the design of a “virtual machine browser”, for browsing the internal state of a running virtual machine simulator and the objects of the memory it’s running. Something more sophisticated than printing the debug support messages to the Transcript.

%d bloggers like this: