The Developer's Guide to DebuggingExamples, Reviews, Errata

Errata

authors@debugging-guide.com (debugging-guide.com) — Mon, 05 Jan 2009 14:31:00 +0000

Errata for "The Developer's Guide to Debugging", first printing, Aug. 2008.

If you find a bug in our book, please email us at authors@debugging-guide.com, so we can fix it in the next edition.

Chapter 4

p.43, first paragraph
Change "There is three common ..." to "There are three common ..."
Reported 9/17/08 by Christos Kontas

Chapter 7

p.91, section 7.2.2 log file code example beancounter.c
line 7, 10 Add (int) cast
line 12/13 Add return beans_arg;
Reported 8/29/08 by Markus Wloka

p.93 last paragraph.
Change "This is can be done ..." to "This can be done ..."
Reported 9/17/08 by Christos Kontas

p.94 last paragraph of 7.3
Change "Starting the program in a debugger will gets you ..." to "Starting the program in a debugger will get you ..."
Reported 9/17/08 by Christos Kontas

p.96 3rd paragraph of 7.4
Change "still in a experimental, but ..." To "still in an experimental, but ...
Reported 9/17/08 by Christos Kontas

Chapter 9

p.110, section 9.2, example. factorial.h is missing
Reported 12/29/08 by Jan Koslasz

p.121, section 9.6.4 code example test_file.cc line 9
Change delete a[]; to delete [] a;
Reported 8/29/08 by Markus Wloka

Chapter 10

p.140, section 10.5.1. Code example MyCLass.h, line 4.
Change MyClass::MyClass() { to MyClass() {
Reported 8/29/08 by Markus Wloka

p.160 2nd paragraph
Change "and by adding a new argument and between..." to "and by adding a new argument "and" between..."
Reported 9/17/08 by Christos Kontas

p.161 2nd paragraph
Change "Of course, It is also easy to corrupt ..." to "Of course, it is also easy to corrupt ..."
Reported 9/17/08 by Christos Kontas

Chapter 11

p.170, section 11.1.1. Change "line brakes" to "line breaks"
Reported 12/29/08 by Jan Koslasz

Chapter 12

p.185, section 12.1.1. Compile command for myfile.cpp
Change > gcc -Wall myfile.cpp to > g++ -Wall myfile.cpp
Reported 8/29/08 by Markus Wloka

p.188 2nd paragraph
Change "Sometimes, execution it is no longer intended ..." to "Sometimes, execution is no longer intended ..."
Reported 9/17/08 by Christos Kontas

Appendix B

p.198, section B.3.1 Cygwin
Change "GDB, gprof, and Valgrind" to "GDB and gprof. Unfortunately, Valgrind is not part of Cygwin."
Reported 11/28/08 by Markus Wloka. (Ouch! That hurt.)

Examples

authors@debugging-guide.com (debugging-guide.com) — Sun, 02 Nov 2008 22:01:00 +0000

Here are the source code examples from our book:

examples080904.zip Version from Sep 04, 2008

Book Reviews, November 2008

authors@debugging-guide.com (debugging-guide.com) — Sun, 02 Nov 2008 21:34:00 +0000

By Prof. John E. Savage, Brown University, Providence, RI, USA, November 2008

This book provides an excellent treatment of debugging techniques in C/C++ and is must-read for all serious software engineers. It contains practical advice and introduces a wide variety of debugging methods, ranging from the simple to the sophisticated. The book will prove valuable to the novice and the expert programmer alike. The illustrations and examples will be particularly useful to the new programmer for whom debugging is often ignored to their detriment later on. The expert will find the many specialized debugging tools and techniques interesting and useful. This is the rare book that will appeal to both audiences.

By Prof. Laurent Michel, University of Connecticut, Storrs, CT, USA, November 2008

This book is unique in many respects. First, there is no other book I know of that covers the topic of program debugging even though I found myself educating countless engineers on how to properly and methodically debug programs. Up to now, this knowledge is passed down "in the field" from experienced software writers to their younger colleagues. Second, it is quite comprehensive and covers a pleasantly broad set of topics ranging from the type of bugs and their origin to memory debugging, parallel program debugging, runtime monitoring, link-time related bugs or even profiling. Third, the book can be enjoyed cover to cover with gems (astute way to use debugging tools) that will surprise every software programmers save, perhaps, the most seasoned veteran. Students will find the book equally pleasant as it remains truly accessible and should be read by every person who intends to major in software engineering. Debuggers are wonderful tools, yet extremely rich. It can take years to discover/develop debugging methods. The book will help all newcomers to zero in on the critical tools and methods. The material is made extremely relevant with a substantial amount of efforts devoted to the discussion of specific concrete tools (e.g., gdb, valgrind, gprof, quantify, dmalloc, etc..). The focus is unmistakably on UNIX related tools (albeit with a clear effort to show the equivalent tools in a Microsoft setting).

As a brief summary, the book start in chapters 1 through 3 by discussing the nature and source of bugs, which classes of bugs exist (from benign to mid and severe) and finally how to get started with the simplest form of debugging: tracing and inspecting. Chapters 4 through 6 focus on memory related issues, i.e., they focus on memory leaks, memory corruption, memory protocol violations (e.g., double delete) as well as memory performance profiling and improvements. Chapter 7 briefly touches on debugging parallel code (a truly difficult task). Chapter 8 and 9 focus on problem related to the build/link/run process and environment. The last three chapters cover more advanced topics for sophisticated instrumentation/observation techniques (e.g., conditional breakpoints, watch points, signaling, dealing with statics, dump analysis and runtime changes to the state).

Naturally, it is quite difficult to cover every single aspects and tools related to the debugging process so some tools are not covered in the book. The sole omission that is noteworthy is the DTrace tools (created at SUN and available on both Solaris and Apple Mac OS X) which offers an amazing array of instrumentation tools. This does not however diminish the value of the text that I will highly recommend to my own students. A second edition will surely address this omission.

All in all, this is an excellent text that will please many developers who will most certainly find themselves referring back to it again and again. Highly recommended.

Book Reviews, October 2008

authors@debugging-guide.com (debugging-guide.com) — Mon, 20 Oct 2008 13:00:00 +0000

By Prof. Dr. Andreas Koch, TU Darmstadt, Germany, October 2008

While the focus of this work is somewhat narrower than the title suggests, it does an excellent job of covering the debugging of C/C++ programs with a non-exclusive emphasis of the Linux and Unix environments. It contains a wealth of practical advice, ranging from basic methodology and debug-friendly code style to detailed usage examples of a plethora of dedicated software tools.

The easy-to-read text allows beginners to get started by introducing the use of a classical source-level debugger such as GDB. It then proceeds to cover a wide variety of techniques, some of them often unfamiliar to even experienced developers (e.g., the use of LD_DEBUG). Among the most useful parts of the book is the discussion of a number of open-source and commercial debugging tools based on practical examples, including memory and performance optimization and the debugging of multi-threaded parallel programs. Both the specific use of the tool (such as command line options) as well as the interpretation of its output are well explained. These descriptions considerably lower the barrier-of-entry for using the sometimes very powerful multi-function tools (e.g. valgrind) and give the reader a good base for diving into the tool-specific documentation.

In summary, the book should be quite helpful for most C/C++ developers. I definitely will recommend it to my students who are working on such projects.

By Johannes Stahl, Cupertino, CA, USA, October 2008

Are you a marketing executive in the software tools industry? Then this is the book for you. If you have written your last line of C-code more than a decade ago, such as myself, you will find that the world has evolved quite a lot from "printf" debugging.

If your customer is no longer calling the hotline, but starts to elevate the issue to you, it is time for you to understand, what is going on behind the scenes in your engineering organization. What are the secret ingridients of their debugging soup to cure the problem?

The book offers a very comprehensive review of all relevant techniques. It shows the basics as well as advanced techniques and can serve as a good reference for the challenges and solutions of software tools debugging. The authors do a good job of balancing the book for readability for novices and as well offering practical examples which drill a little deeper.

I highly recommend the book for anybody managing complex software tools. Know what your engineering team is talking about - more power to you!

By Christos Kontas, Greece, October 2008

I am a software programmer and one of the readers of your book "The Developer's Guide to Debugging".

I've just read your book about debugging and I may say I found it unexpectedly very interesting. Not only the examples about debugging are excellent (an always fascinating literature issue), I also got amazed from the systematic approach on debugging tools and techniques and their categorization.

Debugging is indeed a very crucial ability for each developer, and yet is almost always disregarded and ignored by most of us. Maybe it's because of its hard nature, but this is, of course, no excuse.

Book Reviews, September 2008

authors@debugging-guide.com (debugging-guide.com) — Mon, 20 Oct 2008 09:00:00 +0000

By Peter Toft, Denmark, September 2008

I have been working with software for many years, and with Linux systems for 15 years professionally. When maintaining and developing software you know that you have to use "debugging tools", but most users will simply resort to "printf" when debugging C/C++ code. This book tries to make a difference here. The book both described how the C/C++ tool chains work, and then systematically describes which tools to use in which context - and describes the tool usage in many examples. The book has a bias towards Linux (UNIX) systems, but is also relevant for Windows developers.

When debugging you can most often spend LOTS of time. I was skilled already before reading the book - but there were quite a few places in the book I had to mark "this is very clever, and I have to try this asap". The end result after reading the book is that you can do way more effective debugging with open source SW tools like gdb and valgrind.

When I above write "tries", then I must also add the word "succeeds". This is a good book. If you want to be a more productive C/C++ developer buy the book. It will help you a lot.

Peter Toft Danish Open Source evangelist, writer, blogger, conference organizer, and Senior specialist in algorithm design too :)

By Sandro Rigo, Campinas, Brazil, September 2008

I have been teaching computer programming to CS and CE undergraduate students in their early stages of their courses. One of the toughest concepts to teach is debugging. It is common to see them relying on printf-based techniques to debug their programs even in the last stages of the course, just because they did not invested enough time on learning an appropriate approach to SW debugging.

That is exactly where this book can be very valuable, presenting a systematic approach for debugging and a lot of interesting tricks/techniques that any code developer can benefit from.

This book is a very interesting reading for SW developers, I am sure that even the most experienced ones can find at least a couple of useful tricks to add to their arsenal against the most annoying bugs.

By Prof Dr W. Rosenstiel, Universität Tübingen, Germany, September 2008

The Developer's Guide to Debugging

The book The Developer's Guide to Debugging is a detailed introduction to the world of "debugging" in C/C++-programs. The authors explain by means of many examples a huge amount of debugging-tools (GDB, Valgrind etc.). The authors also take into account special cases, like the debugging of parallel programs. So, tools as well as debugging-techniques are described. There is also a particular chapter dealing with performance-optimization, to be exact, with the debugging that affect the efficiency of the program. The book not only offers a helpful survey to beginners, but also to experienced "bug-hunters". At the end of each chapter there appears a list giving further literature. This indeed is quite helpful when it comes to certain debugging-topics. There is one thing that could be criticized and that is the short index, but that is compensated by the precise structure.

To summarize, this is a very helpful book for software developers which I strongly recommend to read and use.

By Andrea Kroll, September 2008

Printf is a great tool, but not the answer to all debugging problems. Reading this book I realized that there are a lot more tools out there available to everyone. They are equally easy to use and provide a lot more help to find even the nastiest bugs in any kind of SW application. It is clear that the writers have a lot of experience with supporting users and customers at different level of SW expertize, while being SW developers themselves. They provide a step by step description of various interesting tricks. They do not assume that you are the SW guru with years and years of SW development experience. Still there are surprising new approaches for the experts not only in the advanced debugging chapter. The examples are easy to reproduce and work.

The book is even entertaining. You can read it cover to cover, while meeting the bug-family with all their flaws and their tricks to hide, together with people, I am sure you will recognize.

This is a must read for SW engineers, if you want to be more productive and maybe finally get some sleep, because you got your boss (or your customer) off your back.