Debugging Memory Problems

Working in a language like C or C++ exposes you to all the glory and misery of memory management. The introductory programming classes at NYU are now taught in Java, and from talking to people I get the impression that most high school programming classes are as well. It's interesting to me that people can be in their third or fourth year of a computer science degree without ever having seen what happens when you double-free a pointer, but clearly this is now the majority case.

We talked about the fundamental problem of memory management, and the advantages is has over using a garbage-collected language and VM environment like Java (or Perl, or Python, or Ruby, or...) which with the power available on modern machines are honestly fairly thin. In most cases the only reasons to give up the benefits of automatic memory management involve performance or resource constraints related to embedded or similarly constrictive environments.

That said, we went over a few historical ways of finding memory leaks, and the conceptual underpinnings of automatic code annotation. In particular we talked about strategies for recording and monitoring the state of various regions of memory, and implementation details in C++ for doing this sort of thing yourself. When it comes down to it, though, the right thing to do is use valgrind. I'd have more to say, but the lecture notes are returning 404s so the details aren't available to me to go over.

GDB for the win!

I was pleasantly surprised when it turned out that my Software Engineering professor was a fan of linux, gcc, and the rest of the GNU development toolchain, but I was a little worried about gdb. There was a time when I thought it was absolutely the king of the debugging heap, but then I watched excellent developers try to use it to debug multi-threaded C++ code; It was not a pleasant sight. I had gone largely sour on gdb in general until today's lecture, which presented a few macro techniques which combine with gdb features to produce fairly advanced behavior (particularly for a command-line debugger).

First, there are a few gdb features that I never really knew about:

fin - Finishes the current function call.

cond n [expr] - Makes breakpoint n condition on expr.

jump line - go to line and continue execution from there.

call function - Call function function.

Big headaches like getting out of a function where you only cared about the behavior at the beginning, being able to step across functions without having to evaluate them, and so on go away with these features. Handy.

We also went over a few interesting gdb tricks. The best one:

You can combine ignore and run to step a program to a breakpoint immediately before it crashes. You set a breakpoint n at the place you want to stop, then ignore n . You run, and after the crash you can use info b to see how many times breakpoint n was hit. You can then ignore n this number of times, run again, and you're at the breakpoint right before your program crashes.