使用gdb调试多线程程序可有效定位竞争条件：先通过ulimit和core_pattern启用核心转储以捕获崩溃现场，用gdb加载core文件分析；对运行中程序可用attach附加到pid，结合info threads和thread n查看各线程状态；通过break设置线程特定或全局断点，配合print观察共享变量访问顺序；利用条件断点和commands命令自动化日志输出，减少干扰；最终结合代码审查验证mutex等同步机制正确性，排查线程切换与数据可见性问题。
多线程程序在运行时容易出现竞争条件（Race Condition），导致程序行为不稳定、结果不可预测，甚至崩溃。Linux 下结合 GDB 调试工具可以有效定位和分析这类问题。下面介绍如何使用 GDB 进行多线程调试，帮助排查竞争问题。
启用核心转储以捕获异常状态
当多线程程序因竞争引发崩溃（如段错误）时，生成 core dump 文件是第一步。确保系统允许生成 core 文件：
- 执行 ulimit -c unlimited 开启 core 文件生成
- 设置 core 文件命名格式：echo '/tmp/core.%e.%p' > /proc/sys/kernel/core_pattern
- 程序崩溃后，用 gdb ./program core 加载现场
使用 GDB 附加到正在运行的多线程程序
若程序卡死或行为异常但未退出，可直接附加调试：
- 通过 ps aux | grep program_name 获取进程 PID
- 执行 gdb ./program PID 或在 GDB 中输入 attach PID
- 进入调试环境后，可用 info threads 查看所有线程列表
- 用 thread N 切换到指定线程，查看其调用栈 bt
设置断点并观察共享资源访问顺序
竞争常发生在多个线程同时读写同一变量或结构体。GDB 支持在线程上下文中设断点：
- 使用 break file.c:line thread all 在所有线程到达某行时中断
- 或针对特定线程：break file.c:line thread 2
- 配合 print variable 观察共享数据的变化过程
- 利用 step 和 next 单步执行，确认临界区是否被正确保护
结合日志与条件断点缩小问题范围
纯断点可能干扰线程调度，难以复现问题。建议增加日志输出关键操作：
- 在加锁、解锁、读写共享变量前后打印线程 ID 和时间戳
- 在 GDB 中使用条件断点：break file.c:line if counter == 5
- 使用 commands 定义断点触发时自动打印信息并继续运行
- 避免频繁中断影响线程交互逻辑
基本上就这些。GDB 提供了基本的多线程调试能力，但要真正解决竞争问题，还需配合代码审查，确认互斥锁（mutex）、条件变量等同步机制是否正确使用。不复杂但容易忽略的是线程切换时机和共享数据的可见性问题。
