Valgrind错误报告需精简定位：用--log-file重定向、--track-origins=yes溯源未初始化值、--num-callers=6压缩调用栈、避免冗余泄漏选项；复现问题需结合抑制规则、调试日志和线程时序捕获；CI中通过XML结构化输出与diff比对识别新增泄漏；行号显示为???时，须确保-g -O0编译、二进制未strip、动态库挂载debuglink且CMake调试设置前置。
Valgrind错误报告默认太长，怎么快速定位关键行
Valgrind默认把所有调用栈、上下文、内存快照全打出来，一眼看过去全是==12345==前缀和重复的by 0x...: main (main.c:42)。真正有用的只有“哪类错误”“在哪个源码位置触发”“是否可复现”。先过滤掉干扰信息：
– 用--log-file=report.log把输出重定向到文件，避免终端刷屏
– 加--track-origins=yes只对Use of uninitialised value类问题启用溯源（否则默认关，漏掉根因）
– 必加--num-callers=6，把默认20层调用栈压到6层，保留从malloc到出错点的主干路径
– 避免--leak-check=full和--show-leak-kinds=all同时开，后者会让泄漏分类膨胀三倍，实际只需关注definitely lost
怎么把Valgrind报告转成可复现的最小测试用例
报告里看到Invalid write of size 4 at 0x... in foo.c:87，但直接跑原程序可能因环境/数据随机不触发。要稳定复现，得反向提取触发条件：
– 用--gen-suppressions=all生成抑制规则，再手动删掉无关项，剩下真正导致该错误的函数调用序列
– 在foo.c:87附近加fprintf(stderr, "DEBUG: ptr=%p, size=%zu\n", ptr, size);，配合valgrind --trace-children=yes确认输入参数值
– 如果是多线程问题（Helgrind报的），必须用--suppressions=helgrind.supp先屏蔽系统库误报，再用--history-level=full捕获线程切换时序
– 不要依赖gdb --args valgrind ...，Valgrind本身已接管执行，GDB会干扰插桩逻辑
CI中怎么让Valgrind报告自动标记“新泄漏”而非全量比对
每天跑一次valgrind --leak-check=full，但报告里混着历史遗留泄漏，开发根本分不清哪条是本次提交引入的。关键不是“有没有泄漏”，而是“有没有新增”：
– 用--xml=yes --xml-file=leak.xml输出结构化结果，再用xmllint或Python脚本提取<error><kind>Leak_DefinitelyLost</kind>下的<what>和<stack>
– 对每次构建，把当前leak.xml和上一次基线做diff：只比对<fun>malloc</fun>之后第一层业务函数名（比如<fun>parse_config</fun>），忽略地址和行号变动
– 在Jenkins/GitLab CI里，用grep -q "New leak in parse_config" report.diff || exit 1实现阻断，而不是等人工翻报告
为什么加了-g编译仍有“???”行号，怎么修
Valgrind报告里出现at 0x...: ??? (in /path/to/binary)，说明调试符号没生效或被strip过：
– 确认编译命令含gcc -g -O0（-O2及以上可能内联函数，导致行号丢失）
– 检查二进制是否被strip：file ./myapp若显示“stripped”，立刻重编译；若显示“not stripped”，运行readelf -w ./myapp | head -n 20确认有.debug_info段
– 动态库场景下，Valgrind只读主程序符号，依赖的.so必须单独用objcopy --add-gnu-debuglink=libxxx.so.debug libxxx.so挂载调试包
– 最容易被忽略的是：用cmake时set(CMAKE_BUILD_TYPE Debug)必须在add_executable之前，否则-g不传递给目标
