GDB无法准确还原多线程真实访问序列，因调试行为会干扰调度；应优先通过info threads和thread apply all bt查看线程锁状态与调用栈，结合watch、print和frame分析临界区，竞态验证须依赖TSan或Helgrind。
直接看线程加锁行为，别指望单步还原“访问序列”
在 GDB 中无法准确重建多线程下共享资源的实际访问时序——因为断点、单步执行本身会严重干扰调度，你看到的“顺序”大概率是调试器强加的假象。真正能信的，是线程当前持有的锁、正在等待的锁，以及它们最后一次修改共享变量的栈帧。
gdb里用info threads和thread apply all bt定位活跃线程状态
这是第一步，也是最可靠的起点。它不依赖断点，只反映当前所有线程的真实挂起位置：
-
info threads列出所有线程 ID、状态（running / sleeping / blocked）和当前函数 -
thread apply all bt打印全部线程的调用栈，重点关注那些停在pthread_mutex_lock、std::mutex::lock或临界区入口附近的线程 - 若某线程卡在
__lll_lock_wait或sem_wait，说明它正阻塞等待一个已被其他线程持有的锁
用watch观察共享变量被谁改写（慎用，易失真）
对全局变量或类成员加观察点，GDB 会在其值变更时中断。但要注意：
立即学习“C++免费学习笔记（深入）”；
- 仅适用于变量地址固定、未被优化掉的情况；编译时务必加
-g -O0 - 多线程下触发频繁，且每次中断都会暂停所有线程，极大扭曲原始执行流
- 更适合排查“谁意外改了这个值”，而非还原完整访问序列
- 示例：
watch global_counter，然后continue，看哪个线程先命中
结合print和frame检查临界区上下文
当你发现某个线程已持锁并进入临界区，用以下命令确认它正在操作哪块共享资源：
-
frame N切到对应栈帧（比如frame 2进入update_shared_data()） -
info locals查看该函数内局部变量，尤其是引用或指针所指向的内容 -
print *(shared_struct*)0x7fffe8001234直接打印共享结构体内容（需知道地址，可通过print &global_obj获取） - 注意：若变量被寄存器优化，
info locals可能显示<optimized out>，此时只能靠源码逻辑推断
真正的访问序列必须靠日志或工具链补全——GDB 单独做不到。最容易被忽略的是：你在 GDB 里看到的“先后”，往往不是真实并发顺序，而是调试器强制同步的结果。要验证竞态，得用 -fsanitize=thread 或 Helgrind，而不是靠 step/next。
