应使用硬件观察点（watch）监控共享变量地址，gdb会在该地址被写入时立即中断并停在执行写操作的线程；需先用print &shared_counter获取地址，再watch (int)0x...，注意类型匹配和平台支持。
用 watch 监控共享变量地址，触发时自动停在修改线程
直接对变量设普通断点没用——多个线程都可能写它，你不知道谁先改。必须用硬件观察点（watch），GDB 会在该内存地址被写入时立即中断，并把控制权交给正在执行写操作的那个线程。
前提是你得知道变量的地址，且目标平台支持硬件 watchpoint（x86/x64 通常支持，ARM 需确认）：
-
print &shared_counter获取地址，比如输出0x7fffe40012a0 -
watch *(int*)0x7fffe40012a0设置写观察点（注意类型要匹配） - 运行
continue，一旦有线程写这个地址，GDB 就停住，并显示当前是哪个线程（info threads中带*的那个）
注意：watch 是“写入即停”，不是“读取时停”；如果变量是结构体成员，需取到精确字段地址，不能只对结构体首地址下 watch。
用 thread apply all bt + info registers 反向定位最近写入者
当程序已卡死、无法插 watch，但你想查“刚被谁改过”，就得靠调用栈和寄存器线索交叉推断。重点不是看谁在读，而是找谁刚离开临界区或正处在写操作中间。
- 先执行
thread apply all bt，扫一遍所有线程栈，重点关注含pthread_mutex_unlock、std::mutex::unlock、或刚执行完赋值语句（如mov DWORD PTR [rax], esi）的线程 - 对可疑线程，用
thread <n></n>切过去，再执行info registers，看%rdi/%rax是否指向你关心的变量地址 - 配合
list查看当前栈帧源码上下文，确认是否真在更新该共享数据
这个方法不保证 100% 精确，但比盲猜快得多——尤其当某线程栈顶刚执行完 shared_counter++ 后进入 sleep，而其他线程全卡在 pthread_mutex_lock，那基本就是它。
用 break 在所有写操作点设条件断点，缩小嫌疑范围
如果你知道共享变量只在几个固定函数里被修改（比如只有 update_config() 和 handle_event() 会写 g_status），那就别守内存地址，直接在这些函数入口加条件断点。
-
break update_config if g_status == 0—— 只在特定状态时中断 -
break handle_event if (int)pthread_self() == 12345—— 指定线程 ID（需先用info threads查 LWP ID） - 更稳妥的是：在每个写操作行设断点，比如
break config.c:42，然后用command自动打印线程和值：break config.c:42<br>command<br>printf "Thread %d writes g_status = %d\n", $_thread, g_status<br>continue<br>end
条件断点开销小，适合线上环境轻量排查；但前提是代码可控、写点明确。如果变量被宏展开、内联函数或 asm 修改，就容易漏掉。
为什么不用 info proc mappings 或 vmmap 查写时权限？
有人想通过内存页写保护（mprotect）来捕获写入，这理论上可行，但 GDB 不提供直接命令做这事。你得自己写 ptrace 工具或用 rr 录制回放——成本远高于 watch 或条件断点。
真正容易被忽略的是：GDB 的 watch 默认只监控当前线程的地址空间，若变量在 shared memory 区（如 shm_open 映射），需确保所有线程都 attach 到同一调试会话，否则可能错过跨进程写入。这点在混合使用 pthread + fork 的场景里特别关键。
