Master C++ Debugging: GDB and Valgrind from Basics to Advanced

In C++ development, more than 70% of time is spent on debugging and optimization. Mastering GDB and Valgrind is like having a key weapon that makes code fly.

1. GDB: The "surgical knife" for C++ programmers

GNU Debugger (GDB) is the most powerful debugging tool in Linux environments and a must‑have skill for C++ developers. It lets you inspect program state and analyze crashes while the program runs.

Installation and basic usage

# Install GDB
sudo apt-get install gdb

# Compile with debug information
g++ -g main.cpp -o program

# Start GDB debugging
gdb ./program

Core debugging commands

Breakpoint management – precise control of program flow

# Set breakpoint
(gdb) break main.cpp:15   # set breakpoint at line 15
(gdb) break functionName   # set breakpoint at function entry
(gdb) info breakpoints    # list all breakpoints
(gdb) delete breakpoint 1 # delete breakpoint 1

# Conditional breakpoint – trigger only under specific condition
(gdb) break 25 if i == 100   # pause at line 25 when i equals 100

Program execution control – step through code logic

(gdb) run               # start program
(gdb) continue          # continue to next breakpoint
(gdb) next              # execute next line (skip function calls)
(gdb) step              # step into function
(gdb) finish            # run to end of current function

Variable inspection and modification – monitor program state in real time

(gdb) print variableName   # print variable value
(gdb) print *pointer       # dereference pointer
(gdb) set variable = value # modify variable value
(gdb) watch variable       # set watchpoint, pause when variable changes

Practical case: debugging a segmentation fault

// Problematic code
#include <iostream>
using namespace std;

int main() {
    int* ptr = nullptr;
    *ptr = 42;  // segmentation fault!
    return 0;
}

Debugging steps with GDB:

# Compile and debug
g++ -g segfault.cpp -o segfault
gdb ./segfault

(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x00000000004004c6 in main () at segfault.cpp:6
6           *ptr = 42;

(gdb) backtrace
#0  0x00000000004004c6 in main () at segfault.cpp:6

(gdb) print ptr
$1 = (int *) 0x0  # confirm pointer is nullptr

2. Valgrind: The "ultimate killer" for memory problems

Valgrind is the gold standard for detecting memory management issues, uncovering leaks and out‑of‑bounds accesses that GDB may miss.

Installation and basic usage

# Install Valgrind
sudo apt-get install valgrind

# Basic memory check
valgrind --tool=memcheck ./program

# Detailed memory check
valgrind --leak-check=full --show-leak-kinds=all ./program

Core detection features

Memory leak detection – find hidden memory losses

valgrind --leak-check=full ./program

==12345== LEAK SUMMARY:
==12345==    definitely lost: 100 bytes in 1 blocks
==12345==    indirectly lost: 200 bytes in 2 blocks

Out‑of‑bounds detection – catch array overflows and similar errors

// Example of out‑of‑bounds access
int arr[10];
arr[10] = 42;  // overflow!

Valgrind reports:

==12345== Invalid write of size 4
==12345==    at 0x400123: main (example.cpp:15)
==12345==  Address 0x12345678 is 0 bytes after a block of size 40 alloc

Practical case: detecting a memory leak

#include <iostream>
using namespace std;

void createMemoryLeak() {
    int* leaky = new int[100]; // allocated memory not freed
    // forgot delete[] leaky;
}

int main() {
    createMemoryLeak();
    return 0;
}

Run Valgrind:

valgrind --leak-check=full ./memory_leak

==12345== 400 bytes in 1 blocks are definitely lost
==12345==    at 0x4C3017F: operator new[](unsigned long)
==12345==    by 0x400123: createMemoryLeak() (memory_leak.cpp:4)
==12345==    by 0x400135: main (memory_leak.cpp:9)

3. Advanced techniques and combined workflows

GDB + Valgrind combination

# Run Valgrind with GDB support
valgrind --vgdb=yes --vgdb-error=0 ./program

# In another terminal, connect GDB
gdb ./program
(gdb) target remote | vgdb

Automation script

#!/bin/bash

echo "Compiling program..."
g++ -g -O0 $1 -o debug_program

echo "Running Valgrind check..."
valgrind --leak-check=full ./debug_program

echo "Starting GDB debugging..."
gdb ./debug_program

Performance analysis with Callgrind

# Use Callgrind for profiling
valgrind --tool=callgrind ./program

# Visualize results with KCachegrind
kcachegrind callgrind.out.*

4. Common questions and solutions

Q: GDB shows "No symbol table found" A: Re‑compile with the -g option.

Q: Valgrind reports "Address 0x0 is not stack'd" A: Usually caused by dereferencing a null pointer; ensure the pointer is not nullptr.

Q: How to debug multithreaded programs? A: Use info threads to list threads and thread <id> to switch.

5. Best‑practice summary

Always compile with the -g flag to retain debugging information.

Run Valgrind regularly during development, not only after bugs appear.

Combine version control with debugging to pinpoint when issues were introduced.

Write unit tests and use debugging tools together to ensure code quality.

Developing a debugging mindset is more important than mastering tools; great C++ programmers are not those who never write bugs, but those who can quickly locate and fix them.