最常见原因是编译未加-g：Valgrind依赖调试信息显示行号，需gcc -g -O0 demo.c -o demo重编；若已加-g仍无行号，检查是否strip过或日志被冲刷，应使用--log-file输出到文件并查第二层调用栈。
编译时没加 -g，日志里全是 ???
这是最常见原因：Valgrind 要显示源码行号，必须依赖二进制中嵌入的调试信息。如果只用 gcc demo.c -o demo 编译，valgrind 就只能看到函数名或地址，甚至直接显示 ???。
解决办法很简单——重新编译，显式加上 -g：
-
gcc -g -O0 demo.c -o demo（推荐，-O0防止优化导致行号偏移） - 若必须开优化，至少用
-O1；-O2及以上会导致行号错乱，甚至误报未初始化错误 - 确认符号存在：
file demo应输出with debug_info；nm -C demo | grep main能看到带名称的符号
--log-file 没指定，终端刷屏后行号“消失”了
Valgrind 默认把报告输出到终端，但程序一长、日志一多，关键行（比如 at 0x401144: f(demo.c:6)）很容易被后续输出冲掉，看起来像“没行号”。其实它曾经出现过，只是你没截住。
必须强制重定向到文件：
- 运行时加
--log-file=valgrind.log，例如：valgrind --leak-check=full --log-file=valgrind.log ./demo - 别用
2>&1 > log这类 shell 重定向——Valgrind 自己管理输出流，shell 重定向不可靠 - 日志生成后，用
grep "definitely lost\|at.*\.c:" valgrind.log快速定位带行号的关键段
用了 -g 还是没行号？检查是否 strip 过
有些构建流程会在最后执行 strip，这会直接删掉所有调试符号，-g 白加。现象是：file demo 显示 stripped，nm demo 几乎无输出。
- 查构建脚本或 Makefile，删掉类似
strip $(TARGET)的行 - 或者改用
strip --strip-unneeded，它保留调试段（.debug_*） - 临时验证：对已生成的 binary 补加符号几乎不可能，最稳方式是重新编译+不 strip
泄漏发生在系统库或内联函数里，行号显示为 vg_replace_malloc.c
这不是你的问题，而是 Valgrind 的拦截机制所致。比如 malloc 调用栈里第一层总显示 vg_replace_malloc.c:380，真正的业务代码在下几层。
重点看调用栈的**第二层及以上**：
-
==123== at 0x484086F: malloc (vg_replace_malloc.c:380)← 忽略 -
==123== by 0x401137: f (demo.c:5)← 这才是你该修的行号 - 如果第二层还是
???，说明上一层函数被内联（inline或-O2+导致），需关优化重编
真正难搞的不是“没行号”，而是行号指向了头文件或宏展开位置——这时候得结合上下文和调用栈往上翻两层，再对照源码看实际分配点。调试符号只是线索，不是终点。
