--read-var-info=yes启用DWARF变量信息解析，使Memcheck报告精确到变量名、作用域和类型（如'buf[5]'越界读），但需编译时带完整-g调试信息且未strip；对Invalid read/write、未初始化值等错误提升可读性，内联函数或符号mangling场景下效果受限。
–read-var-info 会启用 DWARF 变量信息解析
这个选项会让 Memcheck 在报告中额外显示变量名、作用域和类型信息，前提是你的程序编译时带了 -g 且保留了完整的 DWARF 调试信息（比如未被 strip 或链接时未加 --strip-debug）。
它本身不改变检测逻辑，但让错误报告从「地址 + 偏移」升级为「p->next 字段越界读取」这类可读性更强的描述。尤其在结构体嵌套、指针解引用、数组成员访问等场景下，能直接定位到出问题的变量符号，而不是靠堆栈回溯猜。
哪些错误类型会因此变详细
-
Invalid read/write：报告里会出现类似by 0x4011AB: foo (main.c:23) — reading variable 'buf[5]' (size=1) -
Use of uninitialised value：不再只说“uninitialised byte”，而是标出uninitialised value was created by a heap allocation of size 64, variable 'config' (main.c:17) -
Conditional jump or move depends on uninitialised value：能指出是哪个局部变量或结构体字段导致的条件判断不可靠
容易忽略的限制和坑
这个选项不是万能的，以下情况它帮不上忙：
- 编译时没加
-g，或者用了-g1（只保留基本行号），DWARF 中没有变量位置信息 →--read-var-info无效果 - 内联函数（
inline或编译器自动内联）中发生的错误，变量作用域可能丢失或指向外层函数 - C++ 模板实例化后的符号名会被 mangling，即使有调试信息，Valgrind 也未必能还原成可读的模板参数形式
- 静态局部变量或全局变量若被优化掉（如
static const int x = 42;被常量折叠），DWARF 中可能根本不记录
要不要开？看调试阶段
开发期建议默认加上：valgrind --read-var-info=yes --leak-check=full ./myapp。它增加的开销极小（远小于 --track-origins=yes），但对理解错误根源帮助很大。
上线前做回归扫描时可以关掉——毕竟你已经知道常见模式，且日志体积更小；但如果遇到新类型的崩溃点，临时补上这个选项，往往能省掉半小时查源码的时间。
最常被忽略的是：它依赖调试信息完整性，而很多 CI 构建流程会悄悄 strip 掉 .debug_* 段，结果开了也没用。
