Ubuntu Wiki

Introduction

This topic is a bit overwhelming, so I'm open to suggestions for how to narrow and customize based on the audience desire. Basically though I am going to talk about the debuggers I've written or worked on for GNU bash, GNU make, Python, and Ruby. Topics can range from historical to practical.

In the practical arena, I could show how to use to debug an GNU automake project. There could be a theoretical area such as how to structure writing a debugger. (The ones for Ruby and Python are interesting here.)

In the past people have asked me in the past, "what's the fascination with the debugger thing?" Or another favorite remark from a contractor is "I never use a debugger, I just write code". As a systems administrator one is often confronted with lots of code that you didn't write. You suspect the code might not even be written all that well, but you are more sure that there isn't much in the way of documentation or comments in the code. And you've got a problem to solve. Here is where a debugger comes into play.

I've also heard the observation that you don't need a debugger because you go into a Bash, Python or Ruby shell and just start typing statements in the language. Again if you have a high-level idea of what's going on, that's great. However the hardest part here is getting the context correct. I need a foo object from class Foo and then need to hook the bar object from class Bar (which means importing or requiring module baz) into foo before I can call this method fubar that is of interest to me. With a debugger you work on code where that's all been done for you. So in a sense a good debugger is really not all that different than a shell, it's just that the context has already been set up for you. We'll see that in the Python debugger later.

Why gdb?

Because it is

• fairly complete --- suggests how to expand lesser debuggers (e.g. pdb and ruby's debug). For example, consider signal handling.

• well known --- learning one helps learn another. It helps programs learn too!

• it's there --- why invent a new interface? Because is GPL can cull from gdb manual (with citation)

Issues in Writing or Using a Debugger

• Speed --- debuggers can slow down your program
• Matching virtual reality to reality; which naturally leads to...

• Heisenbugs (and speed contributes to this as well)

GNU bash

Historical stuff

The sordid history of trap DEBUG. Originally like other signals, it came after a statement. But for debugging you need to stop before. Think "rm -fr /" and when you'd like to know about it. It took about 2 years after I posted a suggestion for the change to get in (and I never got an acknowledgment about this). Debug support was going way too slowly. About 4 years between those releases.

Forked bash code to add debug support and timestamped history. This code was incorporated into bash 3.0. Many thanks to Masatake YAMATO.

Practical example

• PS4 trick

• Using to debug start/stop scripts.
• debugger (set_trace) trick?

Note: if you are going to debug configure scripts, you want the readarray builtin.

At this point we should have seen three paradigms of debugging that will come up over again in the other debuggers:

• line tracing
• invoking from the debugger at the outset
• calling the debugger (somehow) from inside the program.

There's one more technique that's a little hard to use in bash but is more prevalent elsewhere

• post-mortem debugging.

GNU make

I have a short (13 minute) video which is really intended to be the first part of a more extended example.

Historical stuff

It's deja vu all over again. Lessons learned in forking a project

What needed to be done (same as in bash):

• better position location reporting
• keep target stack (like a call stack)
• get tracing working first and then add a interactive command loop

Practical example

Method I use to solve a Makefile problem:

• use normal make (until failure)

• run again with remake -x

• if above doesn't work narrow target and run with remake -X target

Show:

• make basic debugging: make -d basic

• make tracing: remake -x

• post-mortem debugging
• 'step' and 'next'

• showing dependencies and write command

• Debugging a automake-generated Makefile.

Future

What's there now is good enough for me. If it's not for others I encourage involvement. Current version is somewhere between 3.80 and 3.81. Some of this could possibly get folded back into GNU Make but it may mean a regression in coding style. (Dan Fabulich has expressed interest in doing this.)

Python

Historical stuff

There are two gdb-like debuggers. The stock python debugger, `pdb`, and one that grew from that, called pydb. The name pydb is because at about the time pdb was developed Richard Wolff was working in parallel on a debugger to be embedded on `ddd`. He has since retired and with his blessing I've taken over the name and have been sort of maintaining the ddd embedding as well.

Stack frame display dilemma: do Python programmers draw their trees with the roots at the bottom?

Practical example

I have a short 15-minute video showing off some non-pdb things.

Example: how ipython handles help --- signal handling (initially added by Matt Fleming). Possibly some of the thread debugging features.

Recent and Future work

Integration into ipython was recently done. The imminent current release has a number of usability conveniences like better command completion, and pydoc help.

Remote debugging. This is needed to hook into many IDEs like Eric, IDLE, winpdb (and therefore SPE), and Eclipse. The bad news though is that each IDE has defined it's own protocol for working remotely.

Ruby

There are in fact two ruby debuggers. "debug" which comes with the base Ruby install and ruby-debug by Kent Sibilev. Both are roughly gdb like. Kent's debugger is I think is coded the cleanest of any debugger I've seen. Each command is its own class.

Practical Example

require 'debug' trick? Stopping in a Rails unit test.

Future Work

• Eclipse plugin (Done sometime in 2007 via ruby-debug-base.)

• Documentation (largely done in 2007; see http://bashdb.sf.net/ruby-debug.html)

• Regression tests. (Largely done in 2007.)
• More closely like gdb (Much progress here too; caused some incompatible changes.)