Debugging with GDB

Save GDB Breakpoints

by

It wasn’t that long ago (well, okay, it was back in 2010, but anyway), that using the GDB debugger left you with the issue of how to maintain your breakpoints from one debug session to the next.

After carefully adding breakpoints, and spending time getting them in just the right place, it was a real headache to have to repeat that exercise the next time you ran a debug session – especially when you were dealing with one of those nefarious bugs that can take days to track down.

I used to list my breakpoints, copy and paste them to a file, then add them to the .gdbinit file for the next time I wanted to use them. Annoying.

Well, in case you’ve been doing the same, or if it never even occurred to you that you could preserve your perfectly positioned breakpoints between sessions, I thought I’d mention that since gdb 7.2 you’ve been able to save your breakpoints in one single step with the following command:

save breakpoints myfile.txt

Phew!

And when you want to use them again, just import them with:

source myfile.txt

Here’s a quickie screenshot where I’ve added 4 breakpoints, saved them to a bp.txt file, deleted them, listed breakpoints to show none present, then re-added them and listed them to show them after import.

Great stuff 🙂

gdb_savebreakpoint

 

 

View A Backtrace For All Threads With GDB

by

Debugging multi-threaded programs can be really tricky. GDB however, will always do its best to rescue you from whatever horrible bug you’re currently looking at. Today I wanted to show you a really nice command for viewing all the threads in your program.

This particular command is especially helpful if you ever need to diagnose a deadlock, because it will give you a complete overview of the entire system and allow you to see which locks are currently being requested.

I’m going to use the C++11 threads program from my thread tutorial to illustrate, with one minor modification – I’ve added a sleep command in the thread subroutine. The only reason I’ve done this is because it keeps my threads alive for long enough to show them all to you in the debugger. On a commercial multi-threaded system, your threads will be doing something most of the time, so my sleep command is essentially simulating my threads going off and doing important jobs 😉

Read more

Log GDB Output To A File

by

Sometimes, especially when you’re dealing with a long stack trace, or a multi-threaded stack trace, trying to view the debug output from GDB in a terminal window can be a little awkward.

Did you know that you can log specific output (or even the entire session) from within GDB to a text file?

All you have to do is type:

set logging on

at the GDB prompt.

GDB saves all output from this point in a text file called gdb.txt that resides in the directory in which you are running GDB (usually the same directory as your executable).

When you’re done you can type:

set logging off

And GDB will stop recording output.

Note that you can turn logging on and off several times and GDB will concatenate output to the gdb.txt file, so you don’t have to worry about overwriting what you’ve already got there.

If you want to record multiple files in a session you can change the filename with:

set logging file myfile.txt

Here’s a little screenshot:

gdb-file-logging

Access GDB Directly In Eclipse Luna

by

This isn’t a new feature, but it’s really useful when you’re debugging in eclipse, especially if you’re using the more advance or obscure features in GDB.

Basically, when you are debugging any program, there is a way to talk directly to GDB without using the point-and-click interface of Eclipse.

It’s called the GDB console.

It’s also really easy to find. When you are next running a debug session, just click on the console icon that is displayed in the console tab. The console usually shows your program output, but there is more than just one console!

Read more