valgrind memcheck 默认调用栈深度为12层，由--num-callers=12硬编码设定；该值可调至最大50，但实际显示深度受限于调试符号、帧指针保留（-fno-omit-frame-pointer）及编译优化等级。
Valgrind Memcheck 默认调用栈深度是多少
Valgrind Memcheck 默认只记录 --num-callers=12 层调用栈，这是硬编码的默认值。当你看到错误报告里只有 3–4 层（比如 malloc → foo → main），大概率不是栈被截断了，而是上层调用本身就没进栈帧——比如内联函数、编译器优化（-O2）导致帧丢失，或调用路径经过 glibc 的间接跳转（如 __libc_malloc → malloc）。
真正能调的，只有 --num-callers 这个参数；它控制的是 Memcheck 在检测到错误时，最多往回追溯多少层函数调用。最大允许值是 50，再大 Valgrind 会报错：invalid --num-callers value。
怎么增大调用栈深度 直接加参数即可，不需要改源码或重编译 Valgrind：
示例命令：
valgrind --tool=memcheck --num-callers=24 ./my_program
常用取值建议：
-
--num-callers=16：覆盖大多数带中间封装（如 RAII、wrapper 函数）的 C++ 场景 -
--num-callers=24：应对较深的模板展开或回调链（如 event loop + lambda + std::function） -
--num-callers=32：仅在确认问题出在极深调用链且其他手段无效时尝试（性能下降明显）
注意：--num-callers 只影响错误报告里的栈帧数量，不影响检测逻辑本身；它不会让原本“消失”的帧重新出现——如果编译时用了 -O2 -fomit-frame-pointer，再调高也没用。
为什么调高了还是看不到关键函数 常见原因不是参数不够，而是底层信息缺失：
以下情况即使设 --num-callers=50 也无济于事：
- 目标二进制没调试符号（
strip过或没加-g编译），Valgrind 只能显示地址，无法还原函数名 - 使用了
-fomit-frame-pointer（GCC/Clang 默认开启），导致栈帧链断裂，callers失去遍历依据 - 调用经过 JIT 代码（如 Lua、Python 扩展）、信号处理函数或
mmap分配的可执行页，Memcheck 不跟踪这些区域的控制流 - 错误发生在
libc内部（如qsort里的比较函数崩溃），而你的回调函数没被正确符号化
验证方式：运行 valgrind --tool=memcheck --debug-dump=syms ./my_program 2>/dev/null | head -n 20，看是否有大量 ??? 或地址行；若有，优先补符号和关优化。
配合使用的必要选项
单靠 --num-callers 效果有限，必须搭配以下设置才能让长栈真正“可读”：
--demangle=yes（默认开启，但显式写上更稳妥）：避免 C++ 符号全是 _ZSt6vector... 这种乱码
--read-var-info=yes（Valgrind ≥ 3.20）：帮助定位变量作用域，对理解栈中局部变量越界有帮助
--suppressions=mysupp.supp：过滤掉已知的 libc/glibc 假阳性，避免长栈被噪音淹没
最关键的是编译环节：gcc -g -O0 -fno-omit-frame-pointer —— 尤其 -fno-omit-frame-pointer，它是长栈可追溯的前提
--num-callers 调到 24 后仍看不到关键函数，大概率该回去检查编译参数和调试信息了。
