Valgrind启动后需手动用GDB连接：终端1运行valgrind --vgdb=yes --vgdb-error=0 ./myapp，终端2运行gdb ./myapp后执行(gdb) target remote | vgdb，再输入continue开始执行。
valgrind --vgdb=yes 启动后 gdb 怎么连上去
--vgdb=yes 不是让 valgrind 自动开个 gdb 服务，而是让它内置一个 gdbserver，并等待外部 gdb 主动连接。它本身不阻塞、不报错，但也不会自动“弹出”调试界面——你得手动开第二个终端去连。
- 启动时加
--vgdb-error=0最稳妥：表示「一启动就暂停，等 gdb 连上再跑」，避免程序飞快执行完、错过断点 - 如果只写
--vgdb=yes而没配--vgdb-error，valgrind 可能直接运行程序，gdb 连上去时早已退出 -
vgdb命令必须在 PATH 中；多数发行版装 valgrind 时会自带，可运行which vgdb确认
典型流程：
终端 1：valgrind --vgdb=yes --vgdb-error=0 ./myapp arg1
终端 2：gdb ./myapp → (gdb) target remote | vgdb
连上后，(gdb) continue 才真正开始执行
target remote | vgdb 报 “Connection refused” 怎么办
这个错误基本说明 vgdb 没找到正在运行的 valgrind 实例，或权限/路径不对。
- 先确认 valgrind 进程还在：在终端 1 看到类似
==12345== (action on error) vgdb me的提示，才代表它已就绪并暴露了调试接口 -
vgdb默认找最近一次启动的 valgrind；如果同时跑了多个 valgrind，可用vgdb --pid=12345显式指定（PID 来自 valgrind 日志第一行） - 某些容器或 chroot 环境里，
vgdb可能无法访问 /proc 下的进程信息，这时得换用target remote :1234配合--vgdb-port=1234显式端口 - 不要尝试用
gdb attach去 attach valgrind 进程本身——那是 attach 到 valgrind 主进程，不是被测程序
连上后为什么 gdb 看不到源码行号或变量名
因为 valgrind 运行的是“合成 CPU”，gdb 看到的指令地址不是原始二进制地址，符号表映射需要额外支持。
- 编译时必须带
-g，且不能 strip；file ./myapp应显示 “with debug_info” - valgrind 启动命令里别加
--read-var-info=no（默认是 yes） - 如果仍显示
???，用(gdb) info line *$pc看当前 PC 是否能反查到行号；不能的话，大概率是编译没带调试信息，或优化等级太高（-O2以上可能内联掉函数，干扰栈回溯） - 对于 inlined 函数，
(gdb) info registers和(gdb) x/10i $pc是更可靠的底层检查手段
gdb 里 set variable、break、watch 能正常用吗
能，但行为和原生调试略有差异：
-
break可设在函数名、源文件行号、甚至汇编地址，valgrind 会把断点翻译到它自己的 IR 层，基本都生效 -
watch内存观察点支持，但性能开销极大，--track-origins=yes会进一步拖慢；非必要不开启 -
set variable修改变量值有效，但注意：若该变量被编译器优化进寄存器（未显式volatile），改了内存也未必影响实际逻辑 - 多线程下，
info threads显示的是 valgrind 模拟的线程 ID，不是 OS 线程 tid；切换用thread N即可，但注意 valgrind 的线程调度是协作式的，真实并发行为会被序列化
实际调试中最容易被忽略的一点：valgrind 的“暂停”不是原子操作——比如你在 malloc 返回后立刻下断点，但 valgrind 可能在 malloc 内部多个检查点都停一次，导致 gdb 停在意外位置。这时候配合 --trace-syscalls=yes 或日志里的 ==PID== 前缀，盯住具体哪一行输出，比盲目设断点更可靠。
