05.03.07

idea: debugging tool

Posted in programmer productivity at 10:38 am by ducky

As a followup to my previous post about debugging tools, I realized that you could pretty easily add a feature to an IDE that could automatically and very quickly find where hangs were taking place for a certain class of hangs.

What causes hangs?

Hangs happen when something doesn’t stop when it should. This means either

  • a loop control structure (for, while, etc) has a test that never is FALSE, so it never stops
  • a recursive call doesn’t terminate
  • a resource is busy

Let’s look at the loop control case first. It is hugely interesting to figure out the location of the boundary between code that is in the loop and code that is not in the loop. The “lowest” (where main is at the absolute bottom) stack frame that is in the loop will be where the test is not getting the right boolean value, and that’s where you want to start debugging.

For a recursive call, the location in the stack keeps changing, but the same lines of code keep getting executed. Again, the “lowest” frame that is in the loop will be where the recursive structure gets kicked off. Again, that’s an interesting place to start debugging.

If you are hanging because of a resource — a lock or a network connection or something like that — is busy then popping into the debugger should show you exactly where the code is blocked. I don’t have an idea for how to improve the process of finding that because it’s pretty simple.

Tool enhancement

So how do you find the boundary between in and out of the loop?

  1. Start running in the debugger; pause manually when you are pretty sure you are in the hang.
  2. Press a “do magic” button.
  3. Have the IDE set breakpoints at all current lines in all current frames. Set a timeout timer to 0.
  4. Have the IDE resume execution.
  5. If execution hits a breakpoint, have it remove the breakpoint, reset the timer and go to step 4.
  6. If the timeout timer reaches a certain value (1 sec? 5 sec? this will depend upon the problem; the user will need to set this), pause execution again.
  7. The frame above the top frame that has a breakpoint set will be the frame that has the incorrect loop test. The IDE magic should put the user into the frame above the top frame that has a breakpoint.

This should be relatively easy to do. Again, I’m tempted to do it, but worried about taking time away from other things.

Comments are closed.