必须用gdb ./prog启动GDB后执行(gdb) target remote | vgdb连接，因Valgrind启用--vgdb=yes后在虚拟CPU上运行程序并内置gdbserver，需严格按提示两步操作才能实现内存状态级调试。
valgrind --vgdb=yes 启动后，gdb 怎么连上去
Valgrind 本身不直接运行程序，而是用虚拟 CPU 重执行指令并插桩监控。要让它支持 gdb 实时交互，必须显式启用 --vgdb=yes（部分旧版本需加 --vgdb-error=0 强制启动 vgdb 监听）。启动后 Valgrind 会输出类似 ==12345== You must now run: gdb ./myprog 和 (gdb) target remote | vgdb 的提示 —— 这不是建议，是必须照做的两步。
常见错误现象：
- 没加
--vgdb=yes就直接在 gdb 里输target remote | vgdb→ 报错vgdb: command not found或连接拒绝 - 用了
--vgdb=yes但没等 Valgrind 输出提示就急着连 gdb → gdb 卡在Remote debugging using | vgdb不动，因为 vgdb 还没 ready - 系统 PATH 里没有
vgdb脚本（某些精简版 valgrind 安装包会漏掉）→ 手动指定路径：target remote | /usr/lib/valgrind/vgdb
gdb 连上后，哪些命令真正有用
连上不是为了看堆栈，而是要利用 Valgrind 的“内存状态快照”能力。普通 gdb 看不到未初始化值或越界地址的语义，而 vgdb 模式下可以：
-
monitor v.info：查看当前 Valgrind 内存状态概览（比如有多少块未释放、是否检测到非法访问） -
monitor v.set_log_level 2：提高 Valgrind 日志级别，让后续continue时输出更细粒度的访问记录 -
monitor v.wait：暂停程序执行，但保持 Valgrind 的内存跟踪上下文，适合配合stepi单指令走查 - 遇到
Invalid read of size 4报告后，在 gdb 中用info registers查rdi/rsi寄存器值，再结合x/4xb $rdi看实际读了哪片内存
注意：break 和 watch 在 vgdb 模式下基本无效 —— Valgrind 已接管所有内存操作，断点由它内部触发，gdb 只负责接收信号和展示上下文。
为什么不能只用 gdb 或只用 valgrind
单独用 gdb 看到 Segmentation fault 时，往往已经晚了：崩溃点只是内存破坏的“果”，不是“因”。比如 free(ptr) 后又写了 ptr[0] = 1，gdb 崩在 ptr[0] 那行，但问题根源在几层调用前的 free。
- Valgrind 的
memcheck能在free后第一次访问ptr时就报Invalid write，并给出free和write两处完整调用栈 - 但 Valgrind 默认不显示变量名、局部作用域或寄存器内容 —— 这些得靠 gdb 的
print、info locals补全 - 两者合用的关键时机是：Valgrind 报出某次非法访问 → 记下地址和行号 → 在 gdb 中
list定位源码 →print查变量值 → 判断是逻辑错还是生命周期错
track-origins=yes 之后怎么查未初始化来源
加了 --track-origins=yes 的 Valgrind 日志里，如果出现 Use of uninitialised value，后面会多一行 by 0x...: some_func (file.cpp:22)，但这只是“使用点”，不是“定义点”。要回溯源头，得靠 gdb 配合：
- 先在 Valgrind 日志里找到报错的指令地址（如
0x4008F5） - 在 gdb 中用
info line *0x4008F5定位源码行，然后disassemble /m看汇编和 C 代码对应关系 - 若该行是条件跳转（如
test %rax,%rax），用print $rax看寄存器值；若为函数参数，用info args查传入值 - 重点检查：数组声明后是否 memset、结构体是否用
{0}初始化、new 出来的对象是否调用了构造函数
这个过程容易忽略的是：未初始化值可能来自 memcpy 拷贝了一块未清零的栈内存，或者 mmap 分配的页未 touch 就直接读 —— 此时 track-origins 会指向系统调用，得顺着 strace 再查一遍。
