How to use GDB to fix the difficult bugs.

GDB or GNU DeBugger is a utility that enables you to step through the execution of your program line by line. This helps you not only to more easily visualize the ‘flow of execution’ in your program but it also enables to sit at any given line in your application, view the application stack, the variables in memory, their addresses and stored values.

The GNU Toolset consists of many small software utilities to enable you to write and compile applications in C/C++ and many more languages. It also includes a linker and debugging utilities.

This post assumes you have the GNU Toolset setup on your platform, I have a write up on how to do this on Windows, MacOS and Linux. If you followed my guide which standardizes the same workflow across all three platforms you can follow this guide verbatim.

If you wish to compile your C++ code in prog.cpp, you can compile code using the GNU C++ compiler with the following syntax:

This will spit out your compiled code into your current working directory, you can run the code with:

Note:

You may have to mark the code executable you can do this with:

But there is bugs in my code!

If you compiled your code with the -g flag, you can debug your program using the GNU Debugger.

When gdb starts your prompt will change from bash’s $: to gdb's (gdb).

You will now have to execute your program from gdb. This works just like running your program from the terminal however you will replace the program name (arg0) with run. For example:

If you are running your code with a testcase called good2and the -v flag:

Here is how you would do the same in gdb:

The debugging process looks something like this:

The main appeal to using a debugger is that you can step through your code line by line and see what the values of each variable is as your program executes.

Knowing exactly what your variables are at a given point in execution grants important intuition into what is causing a bug in your program.

When you first start gdb on your program if you ran it the program would run execute normally. You will have to set a ‘breakpoint’ at the line of code you wish to inspect at runtime.

At the gdb prompt you can set a breakpoint using break followed by the line number.

At some point, you may be compiling multiple .cpp files into eachother.

You may want to set breakpoints in both files. You can do this in gdb using a similar syntax.

Once you set your breakpoints in gdb, run your program through gdb like you normally would, gdb will stop at your first breakpoint:

Gdb stopped at our first breakpoint prog.cpp:102, here the variable x is used. We can see the value of x at this line of execution using the print command:

Here we can see the third variable on our stack holds a std::string with the value Hello there, C++ Programmers!. This looks normal, so lets proceed to the next breakpoint using next or n.

The first line is stdout this is what is actually printed to the terminal if you ran the code normally.

The 2nd line is the line you set the your next breakpoint at.

Here it looks like we’re trying to add an integer to std::string x. In this hypothetical error, we are changing the value at the address of x* by using a the add() member function. Because this operates on a pointer the compiler may not see this as an error at compile time, and you would need gdb to catch this semantic error.

Because only real programmers use GDB. Kidding!

By stepping through and printing the variables in at select points in your program you will gain a better intution into where your execution is flowing and it can make more clear where problems lie.

Did you ever spend a ton of time trying to resolve a buffer or stack overflow? GDB will save you that time.

There are instances where you will be passing data between many .cpp files that you compiled together. You can follow a data structure through each of the files by setting breakpoints wherever that data structure is modified.

I hope this information helps and happy coding! 🎿

Related posts:

Today I found out that I’ve been hacked by somebody… They were on my account for 4 months, they knew everything about me and new all my Facebook messages it was terrifying. Almost as if they were…

EDR entered the final phase of Rogers’ Diffusion of Innovations Curve last month, five days after CrowdStrike acquired Humio, when George Kurtz described XDR (not EDR) to the US Senate as an…

My 14-year-old daughter has lots of questions about love these days. Not about the birds and the bees though, since we’ve covered all that. The information that she wants to know now is slightly more…