--show-below-main=yes 使valgrind在内存泄漏报告中展开main函数之上的调用帧（如全局构造、libc初始化），从而定位main前分配却未释放的内存源头；默认仅显示main及以下堆栈，导致此类泄漏堆栈被截断为???。
什么是 --show-below-main=yes 的实际效果
默认情况下，valgrind --tool=memcheck 在报告内存泄漏堆栈时，会把 main 函数作为调用链的“顶点”，只显示从 main 开始往下的调用路径。如果某块泄漏内存是在 main 之前分配的（比如全局构造函数、静态变量初始化、甚至 libc 启动代码中分配），这些堆栈会被截断，只显示 ??? 或直接省略，导致你完全看不到泄漏源头。
--show-below-main=<yes></yes> 控制的就是这个行为：设为 yes 时，Valgrind 会尝试展开 main 之上的调用帧（即 C runtime 初始化阶段），让那些“藏在 main 外面”的泄漏也能带出可读堆栈。
什么时候必须加 --show-below-main=yes
以下场景下不加这个选项，基本查不到泄漏根源：
- 使用了 C++ 全局对象，其构造函数里调用了
new或malloc，但析构函数没释放 - 静态局部变量首次进入作用域时分配内存（如
static std::vector<int> v(1000);</int>） - 链接了某些第三方库（如某些日志库、配置解析器），它们在
main前就完成初始化并分配资源 - 程序用
atexit()注册了清理函数，但该函数没真正执行（比如程序被信号终止）
此时 --leak-check=full 会报泄漏，但堆栈只到 __libc_start_main 就断了 —— 加上 --show-below-main=yes 才可能看到具体是哪个全局对象或初始化函数干的。
--show-below-main=yes 的代价和限制
它不是万能开关，有明确副作用和前提条件：
- 需要程序编译时带
-g调试信息，否则即使开了也展不开符号 - 对 stripped 二进制或某些 musl libc 环境，效果有限，仍可能显示
??? - 开启后报告体积明显变大，尤其当程序依赖大量静态初始化逻辑时
- 它只影响泄漏堆栈的“向上展开”，不影响未初始化内存、越界等其他错误的检测能力
典型命令组合：valgrind --leak-check=full --show-reachable=yes --show-below-main=yes ./myapp
容易忽略的关键点
很多人以为只要加了 --leak-check=full 就万事大吉，其实泄漏堆栈是否完整，取决于三个参数协同：--show-reachable=yes 决定是否报告“还有指针指向但已脱离作用域”的块；--show-below-main=yes 决定能否看到 main 之上的分配点；而 --leak-resolution=low（或 med）有时反而比默认 high 更容易合并相似泄漏，避免堆栈被过度折叠 —— 这三者缺一不可，尤其在排查 C++ 静态生命周期问题时。
