Valgrind不是调试器，其运行会改变程序地址和栈帧，VSCode断点对其无效；需用--vgdb=yes --vgdb-error=0启动Valgrind，再通过cppdbg扩展attach到其GDB server端口。
Valgrind 报错但 VSCode 断点不触发？先确认是否真在目标进程里跑
Valgrind 不是调试器，它把你的程序当“黑盒”重执行一遍，所有地址、栈帧、线程 ID 都会变。你在 VSCode 里设的断点对 Valgrind 的运行毫无作用——它根本没走 VSCode 的调试通道。
真正能联动的方式只有一种：让 Valgrind 暂停并等待 GDB 连接，再用 VSCode 的 cppdbg 扩展 attach 上去。前提是你的程序得在 Valgrind 启动后卡住，而不是直接跑完退出。
- 启动命令必须加
--vgdb=yes --vgdb-error=0，否则 Valgrind 不开 GDB server -
--vgdb-error=0表示一启动就暂停（适合定位初始化阶段的踩内存），若想在第 N 个错误时暂停，改用--vgdb-error=N - Valgrind 输出里会显示类似
==12345== TO CONTROL THIS PROCESS USING vgdb和端口（如12345），记下这个 PID 和端口
VSCode 要 attach 到 Valgrind 的 GDB server，不是你原程序的进程
很多人误以为要 attach 到自己编译出的 a.out 进程，其实该 attach 的是 Valgrind 自己起的 GDB server 实例——它监听在本地某个端口，代理了被测程序的全部调试请求。
你需要一个专用的 launch.json 配置，类型为 cppdbg，且 mode 必须是 attach，不能是 launch：
立即学习“C++免费学习笔记（深入）”；
{
"configurations": [
{
"name": "Attach to Valgrind",
"type": "cppdbg",
"request": "attach",
"processId": 0,
"pipeTransport": {
"debuggerPath": "/usr/bin/gdb"
},
"MIMode": "gdb",
"miDebuggerServerAddress": "localhost:12345",
"logging": { "engineLogging": true }
}
]
}
-
processId必须设为0（VSCode 会忽略它，靠miDebuggerServerAddress连） -
miDebuggerServerAddress填 Valgrind 输出里的端口，比如localhost:12345 - 确保本地已安装
gdb，且版本 ≥ 7.12（旧版不支持 Valgrind 的 GDB protocol 扩展）
复现踩内存时，别依赖 --track-origins=yes 就完事
这个参数确实能告诉你野指针的来源地址，但它本身不降低性能开销，反而会让 Valgrind 运行慢 3–5 倍；更关键的是，它只能追溯到分配/释放点，无法还原调用链上下文——比如你看到 0xabc123 是从 malloc 来的，但不知道哪条分支调用了它。
- 优先配合
--num-callers=20（默认只有 12 层），避免栈回溯被截断 - 加
--read-var-info=yes（GCC 编译需带-g），能让 Valgrind 解析变量名和作用域，报错时显示in function 'parse_config' at config.cpp:42这类信息 - 如果程序有 fork，记得加
--trace-children=yes，否则子进程的内存问题会被忽略
VSCode 里看到的堆栈全是 Valgrind 内部函数？关掉 --keep-stacktraces=yes
默认 Valgrind 会压缩重复栈帧、合并相似调用路径，导致你在 VSCode 的 call stack 窗口里看到一堆 vgPlain_* 和 ml_* 符号，根本找不到自己的代码。
这不是 VSCode 显示问题，而是 Valgrind 主动做了栈折叠。解决办法是显式关闭它：
- 加上
--keep-stacktraces=no（注意是no，不是off或false） - 同时确保编译时用了
-O0 -g，否则优化会抹掉帧指针，GDB 无法正确展开栈 - 若仍看到大量
???，检查是否链接了 stripped 的系统库（如libc.so.6），可临时用apt install libc6-dbg补全调试符号
最麻烦的一环其实是环境一致性：Valgrind 看到的内存布局和你平时 run 的完全不一样，同一个 bug 在 Valgrind 下可能提前 crash，也可能延迟暴露。别指望一次复现就稳准狠，得反复调参数、切入口、看日志。
