Book Review - The Art of Debugging with GDB, DDD, and Eclipse

The first chapter is called "Some Preliminaries for Beginners and Pros". The motivation for learning proper debugging skills (instead of endless printf chains) is explained. A few general debugging guidelines are listed (use debuggers to confirm your assumptions about the program state, use binary search to find the location where the program state begins to differ from your assumption, ...) and the tools GDB, DDD, and Eclipse are introduced. Options which are generally available in most debuggers are described (Step Into, Step Over, Set Breakpoint, ...). To conclude the first chapter, the user is walked through the first debugging session of the book, first with GDB and afterwards with DDD and Eclipse.

The second chapter is called "Stopping to Take a Look Around" and is all about breakpoints. The concept of breakpoints is introduced. Breakpoints are set, deleted, modified, managed in breakpoint lists, and so on. The reader is told about conditional breakpoints and how to set and manage them. At the end of the chapter, watchpoints and how they differ from breakpoints are explained as well as the difference between hardware and software breakpoints.

Taking a look at program state is the obvious next step after a breakpoint was hit so the third chapter is called "Inspecting and Setting Variables". In this chapter the reader learns how to view the values of variables, static and dynamic arrays, and C++ structures. He is furthermore told about the available value formatting options and about a few valuable GDB best-practices for printing values. For cases where value inspection is not sufficient this chapter also explains how to change variable values during a debugging session.

The fourth chapter, "When a Program Crashes", puts the material learned in the previous chapters to good use. The first half of this chapter explains how programs can crash when accessing either unallocated parts of the memory or allocated memory for which the programs do not have sufficient access rights. Stack, heap, page tables, Linux signals, and core files are explained and how all these things work together during program crashs. The second half of the chapter provides an extensive example debugging session (using a self-written string class with six bugs) that shows what a typical debugging session of a crashing program could look like.

The fifth chapter, "Debugging in a Multiple-Activities Context", contains a few more hands-on approaches to debugging. This chapter is all about debugging of multi-threaded programs and multi-process applications like client/server applications. Using the four examples client/server via sockets, multi-threaded via pthreads, distributed programming via MPI (Message Parsing Interface), and distributed programming via OpenMP (shared memory), thread and process-related debugging commands are introduced. The buggy sample programs that are debugged during this chapter contain typical multiprocessing bugs like deadlocks and race conditions.

The sixth chapter is a very short chapter called "Special Topics". It is divided into two sections. The first section gives a few tips on what to do in case your code does not even compile. The second section gives a few hints on what to consider when debugging a console "GUI" application that was written using the curses library.

The seventh chapter is called "Other Tools". All kinds of other development tools which might be useful to produce bug-free code are introduced. This includes everything between using a proper IDE and compiler settings to tools like static source code analyzers and system call loggers.

The last chapter is called "Using GDB/DDD/Eclipse for Other Languages". It contains a few small example debugging sessions not for C and C++ programs but for Java, Perl, Python, SWIG, and Assembly programs.

Alright, this was the description of the book. So far, so good. Now for my thoughts about it. The first thing I wondered is who the audience of this book is supposed to be. This is a bit difficult to answer. I think the official stance of the authors is that this is a book for beginners and more experienced programmers who want to improve their debugging skills. I do not share this characterization though. In my opinion the book is for students only. Let me explain.

The book starts at the very beginning of debugging. You do not need to have any kind of prior knowledge about debugging or debuggers. Anybody who has ever used a debugger seriously for a few weeks knows all the things mentioned in this book (except for the GDB command trivia if you do not use GDB). For this reason I expect every single professional programmer out there to not need the book. OK, I've heard that there are professional programmers that do not know how to use a debugger (properly). I refuse to believe they really exist though.

The choice of GDB as the primary debugger to be described is also odd. I have this feeling that GDB is a debugger most programmers never come in contact with. Most programmers probably work on Windows (where GDB use is rare), use sophisticated IDEs like Visual C++ or Eclipse that shield them from low-level text-based debugging, or they program in languages like Java where GDB is at best a second choice. GDB is probably a debugger people come in contact with only after they have some programming experience. These people do not need to be told what a breakpoint is and they can figure out the GDB commands they want from its manual.

Another problem with the book is that writing books about debugging is hard. Curiously it is not hard because debuggers and debugging are so difficult but because they are so simple. Debuggers are not nearly as mysterious or complicated as some people might believe. They are pretty straight-forward and their functionality (defined here as "things users can do with them") is very limited. My view might be warped here because I have implemented a few debuggers for myself and for open-source projects in the past decade and, in fact, I get paid to implement debuggers at work too (one of them being a custom GDB client).

A few years ago I TA'd introductory C++ classes in college. I introduced debuggers on the fly whenever someone had a problem during lab class that I could not solve just by looking at the code. My introduction to debuggers (the Visual C++ debugger, not GDB) went like this:

1. OK, by right-clicking here you can set a breakpoint. Breakpoint means the program stops here when we execute it.
2. Run the program, watch the program stop at the breakpoint.
3. Mouse-over a variable or use the watch window to find out the values of variables.
4. Click here to single step, that means we execute the next line. Then we can look at the variable values again.
5. If you want to know more about the debugger, read the manual.

The whole thing took maybe three minutes and my students were instantly hooked and they began to check out other debugger functions. In the GDB book though, these five steps are stretched to more than 110 pages.

I fear that there is just not enough material to write a complete book about introductory debugging techniques. Even if we forget that 110 pages of the book were used to describe breakpoints and looking at variable values there are a few other issues. The seventh chapter (Other Tools) has more than 20 pages and is not at all about Debugging with GDB, DDD, and Eclipse (as the book title promises). This chapter might just as well have been left away. Even if I acknowledge that the information presented in this chapter is useful for writing bug-free code I am not happy with this chapter because neither unit testing tools nor code coverage tools, two tool classes I consider very important, are mentioned.

The sixth chapter (at least the first half) and the eighth chapter are of dubious value because they are just so different from the other chapters. By removing them the book would have less than 200 pages.

While writing this review I had a brief look at the GDB manual. At 29 chapters and appendices A to H one might at first glance believe that there is a lot of material that could be covered in a book about GDB. On second glance this impression seems to be wrong. Most of the topics covered in the manual are also covered in the book and those which are not covered in the book are so specific that nearly no reader of a general debugging book would be interested in reading about them.

Books about debugging only seem to work when you have a clear target that you want to debug. Books like the UNIX System Crash Dump Analysis Handbook or Advanced Windows Debugging are interesting to read because of their clear focus on the target, not on a specific debugger. The GDB book focuses on the debugger instead of the target. This leads to audience problems (written for beginners or not?) and content problems (debuggers are just not very difficult to use so you have to write a lot about trivial content to fill a book).

You might have gotten the impression that I believe that the GDB book is bad. Let me correct this impression though. The book is not bad. The existing content is well-written and well-edited. The explanations are clear, the sample source code is well-written, the example debugging sessions are easy to follow, and so on. If you are new to debugging and you want to learn about GDB this book might be what you need. I am only questioning whether the audience for this book (or for any general-purpose debugging book) actually exists or whether 50% of the readers are bored by the first half of the book and the other 50% are not advanced enough to get the second half.