深入 memleax 工作原理：ptrace 附加与断点 Hook 如何实时追踪 malloc/free

【免费下载链接】memleaxdebugs memory leak of running process. Not maintained anymore, try `libleak` please.项目地址: https://gitcode.com/gh_mirrors/me/memleax

memleax 是一款面向"正在运行"的进程的内存泄漏检测工具：它通过ptrace 附加到目标进程，用断点 Hook实时追踪 malloc/free 等内存分配与释放调用，全程不需要重新编译、不需要重启程序，就能把"存活过久"的内存块当作泄漏实时报告出来。这篇文章不堆代码，用通俗的语言把 memleax 工作原理从附加到报告的完整链路拆解清楚，并聊聊它的性能代价与适用场景。

memleax 是什么：一款"中途上车"的内存泄漏检测利器

传统的内存泄漏检测（比如 Valgrind）通常要在程序启动前介入，等程序退出后才能拿到报告。而 memleax 的思路完全不同：

• 🎯附加运行中进程：只要目标进程还活着，就能随时"挂"上去检测；
• ⚡实时报告：内存块存活超过阈值（默认 10 秒，可用-e调整）立即报警；
• 🚫零侵入：不重新编译、不重启、不改代码，非常适合生产环境临时排查。

它的核心机制只有两件事：ptrace 附加负责"接管"进程，断点 Hook负责"监听"每一次内存调用。

memleax 工作原理第一步：ptrace 附加如何接管目标进程

Linux 的ptrace系统调用是调试器的基础设施，memleax 正是站在它肩膀上。启动后主流程（见memleax.c）会执行：

1. 附加进程：调用ptrace(PTRACE_ATTACH, pid)，目标进程随即收到一个SIGSTOP信号停下，memleax 通过waitpid确认接管成功；
2. 跟踪子孙线程：设置PTRACE_O_TRACECLONE / PTRACE_O_TRACEFORK选项，这样目标进程新建的线程、子进程也会被自动跟踪；
3. 进入监听主循环：不断waitpid等待"事件"，事件可能是断点命中、信号、新线程产生等等。

值得留意的是，memleax只跟踪新线程，不跟踪 fork 出的子进程（子进程会被直接分离）。想检测多个进程，就多跑几个 memleax。

断点 Hook 的核心：用 int 3 指令替换 malloc/free 入口

附加成功后，最关键的一步来了——如何"截获"每一次malloc/free调用？答案是：在函数的入口地址上写入一条陷阱指令。

以 x86_64 为例，memleax（见breakpoint.c与machines.h）会做这样几件事：

1. 通过符号表找到malloc、free、realloc、calloc四个函数的入口地址；
2. 用ptrace(PTRACE_POKETEXT)把入口处的第一个字节替换成0xCC（即 int 3 断点指令），同时把原始字节保存下来；
3. 当目标进程调用malloc时，CPU 执行到0xCC立即触发SIGTRAP，进程停下，memleax 的主循环收到通知。

入口断点与返回断点的"交接舞"

在入口断点处停下后，还不能立刻恢复执行，因为 memleax 需要拿到返回值（分配出来的指针）。于是它玩了一个巧妙的"交接"：

• 先把入口处的原始指令恢复，再在返回地址（从栈顶rsp读出）上也打一个断点；
• 继续运行，进程在malloc返回的那一刻再次停下；
• 这时从寄存器rax读取返回值（分配到的内存指针）、调用memblock_new记账，然后恢复返回地址处的原始指令，并把入口断点重新打回去，等待下一次调用。

这样一来，每次malloc/free都经历"入口断点 → 返回断点 → 恢复"的完整周期，memleax 也就能拿到准确的参数与返回值。参数同样来自寄存器：x86_64 下rdi是malloc的 size、rsi是free的指针，不同架构的取值规则集中在machines.h里。

内存块生命周期管理：哈希表与双向链表如何协作

拿到每次分配的信息后，memleax 要为每个内存块"记账"，这部分实现在memblock.c：

• 哈希表：以指针地址为键，实现memblock_search的 O(1) 查找——当free(ptr)被 Hook 到时，能立刻找到对应记录并删除；
• 双向链表：按创建时间顺序存放所有活跃内存块，方便定期"扫荡"过期的块；
• realloc 特殊处理：原地扩容就更新大小，搬家了就"删旧建新"，保证记账不错乱。

存活超过阈值 = 疑似泄漏

memleax 会周期性地检查链表：凡是当前时间 − 创建时间 ≥ 阈值（默认 10 秒）的内存块，就被标记为"过期"（expired），并视作疑似泄漏。这个阈值非常关键：

• 排查 HTTP keepalive 长连接服务时，连接可能存活几分钟，建议调大，比如-e 360；
• 如果程序预期 1 秒内释放所有内存，可以调小，比如-e 2，尽快拿到报告。

实时泄漏报告如何生成：从地址回溯到"哪一行代码"

仅知道"某个指针泄漏了"没有意义，用户需要知道是哪行代码分配的。这就是调用栈回溯的用武之地：

1. memleax 借助libunwind的远程回溯能力（ptr_backtrace.c），从当前线程的寄存器出发，逐层回溯出完整的返回地址链；
2. 符号表（symtab.c）把地址翻译成函数名，如foo()+14；
3. 调试行信息（debug_line.c，基于 DWARF）把地址翻译成源码位置，如foo.c:12；
4. 内存映射表（addr_maps.c）则负责标出地址属于哪个动态库，如libc-2.17.so。

最终输出就是经典的实时报告：

CallStack[3]: memory expires with 101 bytes, backtrace: 0x00007fd322bd8220 libc-2.17.so malloc()+0 0x000000000040084e test foo()+14 foo.c:12 0x0000000000400875 test bar()+37 bar.c:20 0x0000000000400acb test main()+364 test.c:80

同一个调用栈第二次过期时，不再重复打印完整回溯，只显示2 times again，避免刷屏。

memleax 与 Valgrind 怎么选：实时检测的取舍

一句话总结：Valgrind 更全面，memleax 更轻便，尤其适合"生产环境线上临时救火"。

性能开销有多大：一次 malloc 就是一次陷阱

由于每次内存分配/释放都会触发一次SIGTRAP陷阱，memleax 的开销与目标进程的内存调用频率直接挂钩：

• 普通 HTTP 场景下的 nginx，影响相对轻微；
• 而 HTTPS 场景下 OpenSSL 疯狂调用malloc，开销会明显放大。

另外要注意，memleax 还存在多线程调试的已知缺陷，且只支持部分架构（x86/x86_64、armv7/aarch64、FreeBSD i386/amd64）。附加前建议先确认目标环境，并根据业务场景用-e设置合理的过期阈值。

项目现状：memleax 已停止维护，但源码值得一读

需要提醒的是，memleax已不再维护，作者推荐改用它的后续方案libleak——后者通过LD_PRELOAD环境变量直接 Hook 内存函数，实现更简单、性能影响更小。不过对于想学习"ptrace + 断点 Hook"这套底层调试技术的人来说，memleax 的源码依然是一份非常清晰的教材，核心模块只有几个文件：

• ptrace_utils.h：ptrace 系统调用的封装；
• breakpoint.c/machines.h：断点的设置、命中与参数读取；
• memblock.c：内存块记账与过期判定；
• ptr_backtrace.c/symtab.c/debug_line.c：调用栈回溯与符号翻译。

想研究源码，可以克隆仓库：

git clone https://gitcode.com/gh_mirrors/me/memleax

小结

把整个流程串起来看，memleax 的工作原理并不神秘：ptrace 附加让调试器拿到进程的控制权，断点 Hook把 malloc/free 变成可观察的事件，哈希表 + 链表完成内存块的记账与过期判定，最后用libunwind 回溯把泄漏定位到具体代码行。理解了这条链路，你就掌握了 Linux 动态调试的精髓，也为阅读其他同类工具打下了基础。

【免费下载链接】memleaxdebugs memory leak of running process. Not maintained anymore, try `libleak` please.项目地址: https://gitcode.com/gh_mirrors/me/memleax