Debugging For Beginners

This post was also published at O’Reilly Programming – you can read it here.

I read an interesting article today, called Debugging for Beginners, over at O’Reilly Programming.

You all know how much I love GDB (huh? you didn’t? seriously?), so I always like to take a look at different approaches to finding those elusive problems that plague all programmers (even those with decades of experience) from time to time.

Anyhow, I headed on over and was a little bit… disappointed. You see, Brian writes in a wonderful, readable way, about topics that concern all programmers, whatever their background. But, I found that the general focus of his article was less on how to debug (even at a higher, theoretical level), and more about how to make less mistakes.

Read moreDebugging For Beginners

GDB Prompt in Colour

Just because you can.

gdb colour prompt

Yeah, I know, why bother when you can use a nice front end like Eclipse, or DDD, or CGDB or blah blah blah.

If you just like to use it in its raw form on the command line (which, let’s face it, is the best way), you can pretty-up your GDB prompt with a really simple command.

Just load up GDB and type the following:

set prompt \033[0;32m(gdb) \033[0m

to set the prompt to a lovely green colour.

Or try this:

set prompt \033[0;34m(gdb) \033[0m

to change it to a nice, eye-catching blue.

You could even add the above line to the .gdbinit file in your home directory, so you always get a nice colourful prompt without having to think about it (see here for a brief guide to using .gdbinit files).

How does that work then?

It just uses the ANSI escape sequences (essentially a collection of non-printed text formatters) for colours – I might write up the escape sequences, and fun things you can do with them, in a future post, but for now the command above breaks down as follows:

\033 – this is the “escape” character
[ – escape is always followed by an open square bracket
0;34m – this is the colour. The zero is for bold (0 for off, 1 for on). The m indicates graphics mode.
(gdb) – this is your standard prompt
\033 – another escape sequence follows
[ – with the usual square bracket
0m – this reverts the graphics mode back to the default colour

For more colours, see the list here.

GDB Core Dump Files

What’s a Core Dump?

It’s a file created when your program terminates abnormally. It contains a snapshot of the program’s state at the time of the failure.

What does it look like?

On Linux it will appear in the same location as the executable and will be named something like:

core.4196

Where the number is the process id of the program while it was running.

And what can I do with it?

You can have a look at it using GDB! GDB can read a core file to give you valuable information about a crash after the event.

Some Linux distributions have the ability to create core files disabled by default – you need to type:

ulimit -c unlimited

before running the program to allow the creation of the core file when the program terminates.

To examine a core file, just pass it to gdb:

gdb core.324

GDB will load up all the info and it will look as though you have just run the program and seen the error. You’ll be able to view a backtrace and a range of other information, but it will be a frozen “snapshot” of execution.

Instant debugging!

GDB Init Files Save Time At Startup

I can’t leave the subject of GDB alone for too long, so today I thought I’d talk about GDB init files.

Each time GDB is run, it checks first your home directory and then the current directory for the existence of a file called .gdbinit. If it finds this file, it reads the contents and runs any commands it finds there.

Note: as of version 7.5 GDB needs permission to load files from anywhere other than your home directory. See this update for further details.

This is extremely handy if you are repeatedly debugging an executable and don’t want to keep typing in the same old commands at startup.

For example, if you always put a breakpoint in a certain method because you like it as a starting point, you can specify this in the .gdbinit file, exactly as you would on the command line for GDB:

b main

And if you just can’t be bothered to keep typing ‘r’ to run GDB once it’s loaded your program, you can specify that too:

b main
r

You can also add any arguments that you repeatedly type in:

set args param1 param2
b main
r

And any configuration settings that you might want:

set prompt debug-->
set args param1 param2
b main
r

Now all you have to do is run GDB on your exe as usual, but now it will set up a custom prompt, pass in your arguments, set a breakpoint in main, and even start the program for you.

Next thing you know, you’ve got a GDB prompt at the top of the main function and you’re ready to go!