Valgrind Memcheck 默认仅拦截 malloc/free/new/delete，无法识别自定义分配器；必须通过 VALGRIND_MALLOCLIKE_BLOCK 和 VALGRIND_FREELIKE_BLOCK 手动注册内存块，并确保调用时机、指针一致及线程安全。
Valgrind 无法自动识别自定义分配器，必须手动注册
Valgrind 的 Memcheck 默认只拦截标准符号：malloc、free、new、delete 等。如果你用了自定义分配器（比如基于 mmap 的池、arena_alloc、或封装了 std::pmr::memory_resource），它完全看不到这些调用，也不会记录对应内存块——结果就是：泄漏不报、越界不拦、UAF 漏检。
解决路径只有一条：用 Valgrind 提供的客户端请求（client request）机制，在你的分配/释放函数里显式通知 Memcheck。
- 在分配入口调用
VALGRIND_MALLOCLIKE_BLOCK(ptr, size, rzB, is_zeroed)，告诉 Memcheck “这块内存归我管” - 在释放入口调用
VALGRIND_FREELIKE_BLOCK(ptr, rzB)，让它从活跃表中移除 - 必须包含头文件
valgrind/valgrind.h，且仅在编译时定义VALGRIND宏才生效（运行时无开销） -
rzB参数指“redzone 大小”，一般设为 0；若你分配器自带前后填充区，可填实际字节数用于越界检测
为什么直接拦截 malloc 不行？
很多人尝试用 LD_PRELOAD 覆盖 malloc，再在 wrapper 里调用 real_malloc + VALGRIND_MALLOCLIKE_BLOCK。这在纯 C 场景可能凑效，但在 C++ 中极易崩：
- C++ new 表达式可能不走
malloc（如全局重载operator new或类内operator new） - 标准库容器（
std::vector、std::string）可能绕过malloc直接调用__libc_malloc或 mmap - ASan 和 Valgrind 同时启用会冲突，而
LD_PRELOAD拦截又和 ASan 的插桩逻辑打架
所以，最稳的方式是侵入你的分配器源码，在真正申请/释放内存后立刻发 client request，不依赖符号劫持。
常见错误：注册了但没看到泄漏报告
即使加了 VALGRIND_MALLOCLIKE_BLOCK，仍可能漏报泄漏，原因通常是：
- 忘记在释放路径调用
VALGRIND_FREELIKE_BLOCK—— 内存块永远标记为 “definitely lost” - 释放时传入的
ptr和分配时不同（比如返回的是用户区起始地址，但注册的是页首地址） - 多线程环境下未加锁保护 client request 调用（Valgrind client requests 是线程安全的，但你的分配器状态可能不是）
- 用
VALGRIND_MAKE_MEM_UNDEFINED标记了整块内存，却忘了后续 write 操作仍可能触发 uninit-read 报告
检查是否生效的最快办法
别等跑完程序看 leak summary，先确认 Valgrind 真的“看见”了你的分配：
- 加
--trace-malloc=yes运行，观察输出里有没有你分配器函数名或地址附近的malloc-like 日志 - 故意在分配后立即读取未初始化区域，看是否触发
Use of uninitialised value—— 若不报，说明VALGRIND_MALLOCLIKE_BLOCK没生效或is_zeroed=1设错了 - 用
--leak-check=full --show-leak-kinds=all，重点看still reachable和possibly lost块的调用栈，是否能回溯到你的分配器函数
自定义分配器和 Valgrind 的协作，本质是“主动上报”而非“被动监控”。漏掉任意一个 VALGRIND_FREELIKE_BLOCK，就等于在内存地图上留下一个永久黑点。
