--freelist-vol 控制 Memcheck 空闲块缓存容量，决定能追踪多少已释放但未重用的堆块；值过小导致 use-after-free 漏报，过大增加开销；需结合 --freelist-big-blocks=no 及平台限制合理调优。
—freelist-vol 控制 Memcheck 的空闲块缓存容量
这个参数直接影响 memcheck 工具内部用于追踪已释放但尚未重用的堆内存块（即“freelist”）的哈希表大小。它不改变检测逻辑，只决定能记住多少个刚 free 掉的块。值太小会导致旧释放块被挤出缓存，从而漏报 use-after-free；值太大则增加内存开销和查找延迟。
常见错误现象：UAF 检测时有时报、有时不报
尤其在频繁分配/释放小对象的程序中，如果 --freelist-vol 默认值（通常为 20,000,000 字节）不够用，memcheck 会提前丢弃部分已释放块的元信息。结果就是：同一段代码跑多次，偶尔触发 Invalid read of size X，偶尔完全沉默——这不是随机 bug，而是缓存溢出导致的检测盲区。
- 默认值对多数桌面程序够用，但在嵌入式或高吞吐服务中常显不足
- 若日志里反复出现
Warning: set address range perms: large range或freelist is full（需加-v查看），基本可确认是此参数瓶颈 -
--freelist-vol=50000000可临时缓解，但治标不治本；更稳的方式是配合--freelist-big-blocks=no避免大块挤占索引空间
与 --freelist-big-blocks 的协同影响
--freelist-big-blocks=yes/no 决定是否把大于 1MB 的释放块也纳入 freelist 管理。设为 yes（默认）时，一个大块就可能吃掉几万个 slot，直接拉低小块的留存率。所以调高 --freelist-vol 前，先确认是否真需要监控大块 UAF：
- 调试常规指针误用 → 设
--freelist-big-blocks=no，再按需调--freelist-vol - 怀疑 mmap/mremap 引发的 UAF → 保留
yes，但必须同步大幅提高--freelist-vol（如200000000） - 值单位是字节，不是数量；实际缓存块数 ≈
freelist-vol / avg_block_size，别按“能存多少个 malloc”来估算
ARM/AArch64 交叉编译环境下的特殊注意点
在 Cortex-A9/A73 等老平台交叉编译的 Valgrind 中，--freelist-vol 的上限受宿主机 configure 阶段的 size_t 宽度和目标 libc 的 malloc 实现约束。曾有案例：buildroot 构建的 glibc 2.28 + kernel 5.10 组合下，设 --freelist-vol=300000000 导致 valgrind 启动即 segfault——因为内部 freelist 结构体字段溢出。此时必须回退到 200000000 并启用 --freelist-big-blocks=no 来保功能。
真正容易被忽略的是：这个参数的生效前提是 memcheck 能完整加载目标程序的堆布局。如果交叉编译时没对齐 libc 头文件版本，或 valgrind 自身用了不匹配的 sysdeps 补丁，--freelist-vol 再大也救不了 UAF 漏检。
