valgrind能直接定位malloc源码行号，但必须编译时加-g生成dwarf调试信息，且运行时启用--leak-check=full和--track-origins=yes；否则仅显示???或vg_replace_malloc.c等插桩位置，无法回溯至用户代码。
Valgrind 能直接定位到 malloc 调用的源码行号，但前提是程序编译时带调试信息，且运行时启用足够详细的泄漏追踪选项。
必须加 -g 编译，否则连文件名都看不到
Valgrind 不解析二进制符号表，它依赖 DWARF 调试信息还原源码上下文。没 -g，输出里只会显示 in ??? 或函数名（如 malloc），完全无法回溯到你写的那行 malloc(1024)。
- 正确编译：
gcc -g -O0 leak.c -o leak（-O0可选，但能避免内联导致调用栈丢失） - 错误编译：
gcc leak.c -o leak→ Valgrind 报告中 stack trace 里全是???或模糊的函数偏移 - 如果是 C++，还要确保没 strip 掉符号：
file ./your_program应显示 "not stripped"
--leak-check=full 和 --track-origins=yes 缺一不可
--leak-check=full 让 Valgrind 输出完整的堆栈回溯；而 --track-origins=yes 进一步补全“谁把指针弄丢了”的路径（比如指针被赋值给全局变量后未清空）。两者配合，才能看到从 main 到 malloc 的每一层调用。
- 只用
--leak-check=full：能看到malloc行号，但若中间有指针传递或存储，可能漏掉“为什么没释放”的线索 - 加上
--track-origins=yes：会多出by 0x...: some_func (foo.cpp:42)这类溯源行，尤其对“指针被覆盖/遗忘”类泄漏很关键 - 注意性能开销：后者会让运行变慢 2–3 倍，但调试阶段值得
遇到内联函数或优化代码，malloc 行号可能跳转到 stdlib 源码
某些 libc 实现（如 musl）或高优化等级下，malloc 调用可能被内联，Valgrind 显示的栈帧会停在 vg_replace_malloc.c 里——这不是你的错，而是插桩点位置。此时要往回看上一层非 vg_* 的帧：
- 典型输出片段：
==12345== by 0x4846828: malloc (vg_replace_malloc.c:381) ==12345== by 0x1092AB: create_buffer (buffer.c:33)
- 真正有用的是第二行：
buffer.c:33，即你代码里调用malloc的那行 - 如果上层全是
vg_*或libc符号，说明编译没带-g，或该malloc来自第三方库且无调试信息
动态库里的 malloc 怎么追？
如果你的泄漏来自 dlopen 加载的 so（比如插件模块），Valgrind 默认看不到其源码行号，除非满足两个条件：
- 该 so 编译时也加了
-g，且未 strip - 运行前设置环境变量：
export LD_LIBRARY_PATH=/path/to/your/so:$LD_LIBRARY_PATH，确保 Valgrind 能加载到带调试信息的版本 - 否则，Valgrind 只能显示 so 名和偏移地址（如
myplugin.so+0x1a2b），需用addr2line -e myplugin.so 0x1a2b手动转换
最常被忽略的一点：Valgrind 的 stack trace 是“分配时的调用栈”，不是“泄漏发生时的栈”。也就是说，它告诉你内存是在哪申请的，而不是在哪该释放却没释放——后者得靠你结合逻辑去判断。别指望它自动标出 missing free 那一行，它只负责把 malloc 钉死在源码第几行。
