Debug a Multithreaded Race Condition

Debugging Multithreaded Programs

Multithreaded programs are notoriously difficult to debug because bugs often depend on exact timing and thread interleaving. A race condition that crashes in production may disappear entirely when you single-step through the code.

Essential GDB Thread Commands

• info threads: List all threads with IDs and states
• thread 2: Switch GDB's context to thread #2
• thread apply all bt: Backtrace all threads simultaneously
• set scheduler-locking on: Prevent other threads from running while stepping
• break foo thread 2: Breakpoint that fires only in thread 2

For example, if two threads both execute shared_counter++ without a mutex, the final count will be less than expected because the read-modify-write is not atomic.

For This Exercise

You will create pthreads that race on a shared counter without synchronization and document the GDB commands to detect the race. This mirrors the pattern that ThreadSanitizer flags and that engineers triage with thread apply all bt in production deadlock investigations.

Reproducing Race Conditions

Set set scheduler-locking step to hold other threads while you inspect shared state. Use watch shared_counter to break the instant any thread writes to the variable. Compare the backtraces from thread apply all bt when the counter has an unexpected value to see which threads were in the critical section simultaneously. ThreadSanitizer flags the race, but GDB confirms the exact interleaving.