« PDC2008: Can you afford not to be there?... | The future: Spatial Computing »

Parallel Stacks for multi-threaded debugging

Sat, September 27, 2008, 02:57 PM under ParallelComputing
My previous post (on active stack frame and current thread) ended by raising an issue, a solution to which I propose below.

Consider the following screenshot of code (inc. snippet from Threads window) that has hit a breakpoint and envisage the call stacks for each thread before reading the rest of this blog post:


As a developer debugging a multi-threaded app, you need the ability to view call stacks of multiple threads at the same time – not just a single one at a time. What would you wish this to look like? The obvious solution would be a window like this:


If we can get to the stage above, why not aim for a few more goals: Draw it as a call graph (method calls go from top to down) and, more importantly, visually indicate when threads share common method call paths. Here is a picture (identical info to previous picture) delivering on those goals:


The “xN” indicates that the call stack segment box is shared by N threads. To piece together the entire call stack for a thread, we mentally concatenate the boxes vertically. So the diagram above reads as follows:
"One thread started in Main. It then called A; A was called by 3 threads in total, so we can deduce that 2 other threads have started their life in A. Of the 3 threads, 2 called B (and that is where their active stack frame is right now). The remaining one thread from A called C and subsequently an AnonymousMethod from C and that is where its active stack frame is now (this is also the current thread)."

What do you think? How can you make this better or what alternative do you propose?
Comments [9] |#Permalink
Saturday, 27 September 2008 17:36:00 (Pacific Daylight Time, UTC-07:00)
I really like the idea of describing the thread callstacks as a graph.

However, the "xN" notation seems tough to wrap your mind around at first. There could be a lot of unproductive time spent reasoning about it, like "Ok, there is an x3 down here and an x1 up here, so that means....there must have been 2 threads created up here."

How about taking this idea just a step further and explicitly showing an arrow path (perhaps with a different color) for each thread? Also, the creation of a new thread can be automatically determined and shown with a specific symbol.

I made a mockup of what this might look like:
http://thevalerios.net/matt/downloads/pics/ThreadCallstackGraph.jpg

Possible usability enhancements:
- Clicking on a thread arrow highlights that arrow all the way up to the top (e.g. with a thicker line)
- Double-clicking on a method box takes you to the code
- Hovering over the thread arrow shows you a tooltip box with more information (Type of thread, ID, etc)

Just an idea -- hope that helps. :)
mattman206
Sunday, 28 September 2008 02:58:00 (Pacific Daylight Time, UTC-07:00)
Reminds me of these things:

* Future Focus: Call Hierarchy
* Charlie Calvert's Community Blog : Future Focus II: Call Hierarchy:
* Visual Studio Language Futures - Discussions: Call Hierarchy
Anonymous
Wednesday, 01 October 2008 12:11:53 (Pacific Daylight Time, UTC-07:00)
mattman206: Thanks for thinking about this.

The xN is a bit hard to wrap your head around at first, but it is actually very easy and quick to interpret once you are used to it. Of course, I could be wrong, but once you get a chance to play with this feature, ping me again. We are also thinking of changing it to say "4 Threads", so it does not need explaining every time

The arrow path idea is great for a small number of threads. However, I don't think the idea scales to, say, 16 or 64 threads :-(.

Some things you will like (along the same lines of what you suggested): hovering over the xN area will show you in a tooltip the Thread IDs. Also hovering over a method will show you a tooltip with information for all stack frames at that method (parameter info, line numbers etc). Finally, indeed you will be able to switch the current stack frame from this window. Double clicking doesn't cut it when more than one thread is in the same method, because you need to specify which one exactly: so there will be a contextmenu :-)

Keep your ideas coming!
Daniel Moth
Wednesday, 01 October 2008 12:17:42 (Pacific Daylight Time, UTC-07:00)
Anonymous: Not sure why a static analysis code editor feature reminds you of a debugging dynamic runtime feature. Either you missed the point or you need to provide more context (and a name for yourself ;))
Daniel Moth
Sunday, 12 October 2008 16:19:00 (Pacific Daylight Time, UTC-07:00)
I think you are making it too complex. At debug time, I would have ideally just liked to know call stack for thread T. For a complex project the kind of graph you have shown get really complex (may look like spider web!), hard to navigate and defeat the purpose. I would highly recommand to keep this simple. If you do want to include call stack graph, please also leave the option so developers can switch to simple flat view.
Shital
Sunday, 12 October 2008 16:28:38 (Pacific Daylight Time, UTC-07:00)
Shital: Thank you for your comments. The old Call Stack window is not going anywhere for the time being, so you don't have to worry. Devs that do not use multithreaded code can still focus on just one thread at a time. Devs that debug complex multithreaded apps, can use the Parallel Stacks window to have a holistic picture of the execution of their code and the ability to jump at any method on any stack with a couple of clicks in a single window. If they need to focus on a subset of threads or tasks, we are considering offering that via some filtering mechanism. Also note that the picture would never look like a "spider web" since the branches never come back together (that would indeed be too complex). Instead, you can think of it as an upside down cactus ;-)
Daniel Moth
Monday, 20 October 2008 07:41:00 (Pacific Daylight Time, UTC-07:00)
I like your idea of a graph but I would like to see it as the result of a log. My question below pertains to logging parallel call stacks.

I have been searching MSDN for three days now for this question (please forgive me if I have posted to the wrong forum).

Is it possible to log the call stack the current thread and append to that all the frames leading up to it? In other words, can an application (in debug or with a custom debugger, etc) trace call stack frames of parent threads up to the run command of each child? If not can a custom debugger trace the current call stack of a parent thread upon childThread.run?

Thank you very much.
Anonymous
Friday, 13 February 2009 08:27:15 (Pacific Standard Time, UTC-08:00)
Anonymous: I don't have an answer for your question and, yes, this is the wrong forum. For free online answers to generic developer questions on the Microsoft platform, please use the MSDN forums: http://forums.microsoft.com/msdn/default.aspx?siteid=1
Daniel Moth
Wednesday, 03 June 2009 06:59:56 (Pacific Daylight Time, UTC-07:00)
This already exists in a simplified form. You can download it as a plugin for Visual Studio 2008 today...
Mark O'Connor
Comments are closed.