用 --suppressions 加自定义 suppress 文件屏蔽系统库报错；先用 --gen-suppressions=all 生成原始规则，再人工筛选 libc/libstdc++/libpthread 相关块，保存为 system.supp，并显式指定加载。
Valgrind 怎么屏蔽系统库的报错和警告
直接结论：用 --suppressions 加自定义 suppress 文件，而不是靠 --gen-suppressions=all 无差别捕获。后者会把所有第三方调用链（比如 glibc、libstdc++ 内部 malloc/free、pthread 初始化）都当“问题”吐出来，反而淹没了你代码里的真实错误。
为什么系统库提示多得离谱
Memcheck 默认不区分“你的代码”和“系统库代码”。只要检测到内存操作（比如 malloc 调用栈里混着 __libc_start_main 或 std::string::_M_create），它就照单全收。尤其在 C++ 程序里，std::vector 构造、异常处理帧、RTTI 初始化这些动作，全是系统库内部触发的“可疑”行为，但它们本身合法且不可控。
- glibc 的
__libc_malloc和__libc_free经常被标记为 “still reachable”，其实只是 libc 自己缓存了 arena - libstdc++ 的静态对象析构顺序导致的 “definitely lost” 报告，实际是标准库生命周期管理逻辑，不是你漏
delete - pthread 库初始化时分配的 TLS key、stack guard 页面，会被当成非法读写
怎么写一个靠谱的 suppress 文件
别手写。先跑一次带 --gen-suppressions=all 的最小复现：
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all --gen-suppressions=all ./myapp 2> /tmp/suppress.raw
然后人工过滤：/tmp/suppress.raw 里只保留以 { 开头、包含 libc、libstdc、libpthread、ld-linux 等关键词的块，删掉所有你代码路径（比如 src/、main.cpp）相关的 suppress 块。最后把剩下内容存为 system.supp。
- suppress 规则必须匹配完整调用栈，哪怕只差一层函数名，就失效
- 不要 suppress
invalid read/write类错误——这类是真 bug，系统库极少触发，一旦出现大概率是你传了野指针进strlen或memcpy - 对 glibc 2.30+，注意 suppress 中的
fun:行可能含__libc_malloc@GLIBC_2.2.5这种带版本号符号，需保持一致
运行时如何正确加载 suppress 文件
必须显式指定，Valgrind 不会自动读 ~/.valgrindrc 或环境变量：
valgrind --suppressions=system.supp --tool=memcheck --leak-check=full ./myapp
- 可叠加多个 suppress 文件：
--suppressions=a.supp --suppressions=b.supp - 如果 suppress 文件路径不对，Valgrind 默认静默忽略，不会报错——这是最常被忽略的失败点
- 交叉编译环境下（如 ARM），确保
system.supp是在目标平台生成的，因为 glibc 符号名和调用栈深度可能和 x86 不同
真正难的是 suppress 的粒度控制：压得太死会漏掉你代码调用系统函数时传参错误（比如 memcpy(dst, src, -1)），放得太松又满屏噪音。建议每次只 suppress 一类明确已知安全的行为，比如 “glibc malloc arena 缓存”，而不是整个 libc。
