最直接有效的方式是使用 --suppressions 加载压制规则文件，如 /usr/lib/valgrind/default.supp，以过滤 libc/libstdc++ 等系统库的无关报错；启用 --trace-children=yes 会因监控子进程而显著增加系统库提示；--leak-check=full 虽显示详细调用栈但含大量系统符号，需配合压制规则人工过滤；添加 -fno-omit-frame-pointer 可提升栈回溯准确性，使压制更可靠。
怎么屏蔽 libc / libstdc++ 的报错信息
Valgrind Memcheck 默认会检查所有内存操作，包括系统库（如 libc、libstdc++）内部的 malloc/free、栈访问等。这些提示通常和你自己的代码无关，反而干扰定位真实问题。
最直接有效的方式是使用 --suppressions 加载压制规则文件，把系统库相关的错误过滤掉。
- Ubuntu/Debian 系统一般自带默认压制文件，路径类似
/usr/lib/valgrind/default.supp或/usr/share/doc/valgrind/examples/default.supp，运行时加上--suppressions=/usr/lib/valgrind/default.supp即可 - 如果找不到，可从 Valgrind 源码目录复制：
cp $VALGRIND_SRC_DIR/extras/suppressions/* .，再选一个通用的（如glibc-2.5.supp） - 自定义压制规则必须以
{开头、}结尾，且每条规则需匹配错误堆栈中的函数名或库路径，例如压制malloc在vg_replace_malloc.c中的调用链 - 压制文件不生效常见原因是：路径写错、规则没覆盖到实际报错堆栈里的函数名、或用了
--tool=memcheck但压制文件里写了其他工具名
为什么 --trace-children=yes 会让系统库提示变多
启用 --trace-children=yes 后，Valgrind 会递归监控子进程（比如程序 fork 出的 sh、grep、python 等），而这些子进程往往大量调用系统库，触发一堆无关的 Invalid read 或 Use of uninitialised value 报告。
除非你明确要查子进程里的内存问题，否则建议：
- 默认关闭：不加该参数，或显式写
--trace-children=no - 只在需要时临时开启，并配合
--suppressions+ 子进程专用压制规则 - 避免在自动化测试脚本中无条件启用，否则日志体积暴增、关键线索被淹没
leak-check=summary 和 leak-check=full 对系统库提示的影响
--leak-check=summary 只统计泄漏总数，不展开每个泄漏块的调用栈；而 --leak-check=full 会逐个打印分配点，其中大量指向 __libc_start_main、std::string::_M_create 这类系统符号——它们不是你的泄漏源，只是泄漏发生在系统初始化阶段或 std 容器内部。
实用建议：
- 排查自己代码的泄漏，优先用
--leak-check=full+--suppressions，再人工过滤掉栈顶含libc、libstdc++、ld-linux的报告 - 做 CI 快速兜底时，用
--leak-check=summary配合--errors-for-leak-kinds=definite,possible，跳过still-reachable（这类多数来自系统缓存） - 注意
still-reachable不等于泄漏，它常由 glibc 的mallocarena 预留、C++ static 对象延迟析构等引起，无需压制，但也不该计入“失败”判定
编译时加 -fno-omit-frame-pointer 能减少系统库干扰吗
不能直接减少系统库提示，但它能让 Valgrind 更准确地把错误归属到你自己的函数，而不是卡在 __GI___libc_malloc 这种模糊符号里。
原因在于：GCC 默认开启 -fomit-frame-pointer（尤其 -O2 及以上），导致调用栈丢失帧指针，Memcheck 只能靠 heuristics 推断调用路径，容易把你的 foo() 错判成 malloc 内部调用；加上 -fno-omit-frame-pointer 后，栈回溯更干净，系统库函数和你代码的边界更清晰，压制规则也更容易写准。
所以它不是“少看”，而是“看得更准”，进而让压制更可靠：
- 必须搭配
-g使用，否则行号仍是问号 - 即使用了
-O2，也建议强制加-fno-omit-frame-pointer，比降级到-O0更实际 - Clang 用户对应选项是
-mno-omit-leaf-frame-pointer
真正难处理的不是系统库提示本身，而是它和你代码混在同一个调用栈里——比如 your_func → std::vector::push_back → malloc，压制规则若只匹配 malloc，会把整个链干掉；若只匹配 your_func，又压不住后续泄漏。这时候得靠 --show-leak-kinds 分层过滤，再人工扫一眼栈底是不是你写的函数名。
