valgrind memcheck通过--gen-suppressions=all自动生成suppression规则，每段错误后附带格式严格的{...}块，需保存为.supp文件并用--suppressions=加载；字段如错误类型、fun:函数名、obj:路径不可随意修改，且必须使用绝对路径、置于可执行文件前，否则无效。
Valgrind memcheck怎么生成 suppression 规则
Valgrind 不支持运行时“忽略”某类报错，必须通过 suppression 文件显式声明哪些错误是已知、可接受的。关键不是“屏蔽提示”，而是告诉 Valgrind：“这类调用栈我确认没问题，别再报了”。生成规则最可靠的方式是让 Valgrind 自己写——它能保证格式合法、匹配精准。
执行带 --gen-suppressions=all 的检测命令，例如：
valgrind --tool=memcheck --leak-check=full --gen-suppressions=all ./myapp
输出中每段错误信息末尾会紧跟着一个以 { 开头、} 结尾的 suppression 块，形如：
{
<font color="#888">MyKnownMallocInLib</font>
Memcheck:Addr1
...
fun:libxyz_init
...
}
把这些块复制出来，保存为 mysupps.supp，后续运行时加 --suppressions=mysupps.supp 即可跳过匹配项。
suppression 文件里哪些字段不能乱改
看似自由的 suppression 块，实际有强约束。Valgrind 匹配时严格依赖以下字段：
-
Memcheck:Addr1（或Memcheck:Param、Memcheck:Leak等）——必须与原始错误类型一致，改错就失效 -
fun:行中的函数名——若用通配符*，必须确保不会意外覆盖其他调用路径；建议优先用完整符号名 -
obj:行（如有）——指向共享库路径，若库版本升级导致路径变化，suppression 会失效
常见错误：手动删掉中间几行 fun: 试图“泛化”规则，结果匹配失败；或把 Memcheck:Leak 改成 Memcheck:Addr1，导致泄漏仍被报告。
为什么 --suppressions=file.supp 有时没效果
suppression 不生效，八成是路径或加载时机问题：
-
file.supp路径写相对路径但当前工作目录不对——一律用绝对路径，比如--suppressions=/home/user/myproj/mysupps.supp - suppression 规则匹配的是错误发生时的**实际调用栈**，不是编译后的符号名——如果程序用了
-fvisibility=hidden或 LTO，函数可能被内联或重命名，原有规则就失准 - 误把
--suppressions放在./myapp后面——参数顺序必须在可执行文件之前，否则被当成程序参数传进去
验证是否加载成功：加 --verbose 运行，Valgrind 会在启动阶段打印 “Reading suppressions from …” 和 “Used N suppressions”。
第三方库泄漏该不该 suppress
对 glibc、Boost、Qt 等成熟库的 “still reachable” 或少量 “possibly lost”，suppress 是合理选择；但对 “definitely lost” 要格外小心：
- glibc 的
__libc_malloc+pthread_create链路出现definitely lost，往往是你的线程函数没正确 join 或 detach，不是库的问题 - Qt 的
QApplication构造引发泄漏，大概率是你在main()外提前调用了 Qt 初始化函数 - 真正该 suppress 的，是像 OpenSSL 内部缓存、某些日志库的全局 buffer 这类文档明确说明“进程退出时不释放”的行为
最稳妥的做法：先用 --show-leak-kinds=all --leak-check=full 确认泄漏源头是否真的在库内部，而不是你传给它的指针被提前释放了。
suppression 不是补丁，是契约——你得清楚知道每一条规则对应什么真实行为，否则下次升级库或重构代码，它反而会掩盖新引入的问题。
