Linux 生产环境 C/C++ 内存泄漏排查实战：基于 eBPF 的精准定位

目录

在 Linux 环境下开发 C/C++ 程序时，内存泄漏是开发者最常面临的棘手问题之一。尤其是在对实时性和稳定性要求极高的工业控制场景（如带 RT 补丁的内核、CODESYS 运行时环境）中，传统的重型内存检测工具往往不再适用。

本文将通过一次真实的生产环境排查案例，详细讲解如何结合系统监控命令与现代 eBPF 技术，在不影响业务运行的前提下，精准定位并修复内存泄漏问题，同时深入解析 Linux 动态链接机制中的一个常见避坑点。

背景知识：为什么放弃 Valgrind 而选择 eBPF？

在测试环境中，Valgrind (Memcheck) 是排查 C/C++ 内存泄漏的“黄金标准”，它能精确指出哪一行代码分配的内存未被释放。然而，Valgrind 的原理是使用虚拟 CPU 解释执行程序，会导致程序运行速度骤降 10 到 50 倍。

在生产环境或实时（RT）系统中，这种巨大的性能损耗是不可接受的，极易导致看门狗超时或业务完全宕机。因此，我们需要采用​轻量级的动态追踪技术​：

  1. ​基础排查​：使用 top、pmap、pidstat 等 Linux 内置工具进行宏观确诊。
  2. ​深度定位​：使用基于 eBPF 技术的 bcc-tools（特别是 memleak 工具）。eBPF 直接在内核态 Hook 底层的 malloc 和 free 函数，性能开销极低，是带业务跑的生产环境首选。

问题排查实战一：主干业务的大规模内存泄漏

1. 现象观察与确诊

首先，我们在设备上使用 pidstat 命令监控目标进程（PID: 2787）的内存使用情况：

root@localhost:/opt/codesys/plc# pidstat -r -p 2787 1
Linux 6.1.80-rt26-pk-2026021001 (localhost.localdomain) 	04/15/26 	_x86_64_	(8 CPU)

15:44:30     UID      PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
15:44:31       0     2787     32.00      0.00 3432576 1060748  13.44  codesyscontrol.
15:44:32       0     2787     33.00      0.00 3432576 1060748  13.44  codesyscontrol.
15:44:33       0     2787     32.00      0.00 3432576 1061012  13.45  codesyscontrol.
15:44:35       0     2787     32.00      0.00 3432576 1061276  13.45  codesyscontrol.
...

2. 核心指标分析

从上述数据中，我们提取出三个关键的“确诊”指标：

  • ​RSS（常驻内存）持续增长​：从 1060748 涨到 1061276，每两秒钟增加约 264 KB，这是内存泄漏的铁证。
  • ​VSZ（虚拟内存）稳定不变​：维持在 3432576 KB。这表明进程并没有频繁向操作系统请求大块的新地址空间（没有大量扩充 mmap 或 brk），而是在其已申请的庞大虚拟空间内，不断向尚未分配物理内存的页面写入数据。
  • ​minflt/s（次要缺页异常）完美印证泄漏速度​：缺页异常稳定在 32.00 次/秒。Linux 默认一页为 4KB，32 * 4KB = 128 KB/秒。两秒钟恰好是 256 KB，与 RSS 的涨幅完美吻合。

3. 使用 eBPF 抓取现行 (定位)

确诊泄漏后，我们启动 eBPF 工具集中的 memleak-bpfcc，以 10 秒为周期抓取未释放的内存快照：

root@localhost:/opt/codesys/plc# memleak-bpfcc -p 2787 -T 10
...
[15:47:54] Top 10 stacks with outstanding allocations:
	590472 bytes in 9 allocations from stack
		sbus_write+0x38 [libsbus_v2.so]
		igp_rpc_call_with_timeout+0x1ce [libsbus_v2.so]
		led_switch+0x5f [libSupUtils.so]
		led_task_run+0x166 [libSupUtils.so]
		[unknown] [libglib-2.0.so.0.6400.6]
		[unknown]
		led_task_run+0x0 [libSupUtils.so]
...

4. 根因分析与解决方案

eBPF 的输出一针见血：在 led_task_run 后台线程中，底层总线通信库 libsbus_v2.so 的 sbus_write 函数发生了严重的泄漏。

进一步计算发现，每次调用的泄漏量约为 590472 / 9 ≈ 65608 字节 (64KB)。

  • ​原因​​：在 C 代码模块中，RPC 调用或总线发送逻辑内部通过 malloc 分配了约 64KB 的 Payload 缓冲区，但在数据发送完成后（或遇到错误分支返回时），遗漏了对应的 free() 操作。
  • ​解决方案​：在 libsbus_v2.so 的源码中，为对应的 malloc 逻辑补全 free()，并重新编译部署动态链接库。

5. 修复结果验证

替换修复后的 .so 文件后，再次通过 pidstat 观察：

16:23:15     UID      PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
16:23:16       0     3605      0.00      0.00 3268868  952660  12.07  codesyscontrol.
16:23:17       0     3605      0.00      0.00 3268868  952660  12.07  codesyscontrol.
...
16:23:20       0     3605      1.00      0.00 3268868  952660  12.07  codesyscontrol.

​结果​：RSS 牢牢钉死在 952660 不再增长，minflt/s 断崖式下降并基本归零（偶尔的 1.00 属于正常的临时内存分配或栈空间伸缩）。大出血级别的泄漏被彻底修复。

问题排查实战二：甄别真假泄漏与 ZeroMQ “静脉滴漏”

在大漏口被堵住后，为了严谨起见，我们再次运行了 memleak 探测，结果发现了另外两种现象：

现象 1：转瞬即逝的分配（假阳性甄别）

在某次快照中，抓取到了以下调用栈：

[16:24:41] Top 10 stacks with outstanding allocations:
	4136 bytes in 1 allocations from stack
		get_cmd_obj+0x16 [libSupUtils.so]
		igp_rpc_call_with_timeout+0xb6 [libSupUtils.so]
		led_switch+0x5f [libSupUtils.so]
		...

但在接下来的几帧快照（[16:24:46],...）中，这个分配彻底消失了。

  • ​分析与结论​：这不是内存泄漏。eBPF 是基于定时快照的机制。如果某个合法的大对象刚好在创建后、释放前被抓拍到，就会出现在日志中。只要它在后续快照中消失，即代表其已被正常 free 回收，属于正常的临时业务内存。

现象 2：极其规律的微量泄漏 (ZeroMQ)

在日志中，另一个调用栈则呈现出典型的“滚雪球”特征：

[16:24:11] 918 bytes in 9 allocations from stack [unknown] [libzmq.so.5.2.2]
...
[16:24:26] 3978 bytes in 39 allocations from stack [unknown] [libzmq.so.5.2.2]
...
[16:25:01] 11220 bytes in 110 allocations from stack [unknown] [libzmq.so.5.2.2]
  • ​分析​：由于目标机上的 libzmq.so 剥离了符号表（stripped），所以函数名显示为 [unknown]。但数据规律极其明显：每 5 秒钟，分配次数精准增加 10 次，未释放内存精准增加 1020 字节。即程序每秒钟泄漏 2 次，每次精准泄漏 ​102 字节​。
  • ​定位与原因​​：这属于 ZMQ C-API 开发中极其经典的踩坑点。在业务代码调用 zmq_msg_recv(&msg, ...) 接收消息后，开发者通常只提取了数据，却​**遗漏了调用 zmq_msg_close(&msg)**​，导致 ZMQ 内部维护的一小块消息元数据无法回收。

拓展进阶：Linux 动态链接库间的全局变量共享机制

在排查底层 libSupUtils.so 和 libsbus_v2.so 交互时，经常会涉及多模块依赖的问题。一个经典的疑问是：

假设进程依赖两个动态库 a.so 和 b.so，而它们都共同依赖 c.so。如果 c.so 中定义了一个全局变量 d，a 和 b 访问 d 会互相影响吗？

结论是：必然会互相影响。

在 Linux 动态链接机制（ld-linux.so）下：

  1. ​唯一加载原则​：同一个共享库在一个进程的地址空间中只会加载一次。
  2. ​符号解析与映射​：链接器会将 a.so 和 b.so 中对变量 d 的访问指针（GOT 表），全部重定向到进程地址空间中 c.so 数据段的唯一物理地址上。

​工程警示与应对​：

由于共享同一块内存，在多线程环境下极其容易引发数据脏读或程序崩溃（竞态条件）。为了避免这种影响，常用的解决手段有两种：

  • ​加锁同步​：在 c.so 层面引入互斥锁（如 std::mutex 或 pthread_mutex_t）。
  • ​线程级隔离​：将变量声明为线程局部存储（Thread-Local Storage），如使用 __thread 或 thread_local 关键字。此时变量在每个线程中都会有一份独立的拷贝，从而实现逻辑上的隔离。

总结

排查 Linux C/C++ 进程内存泄漏是一个结合宏观监控与微观剖析的系统工程：

  1. 首先使用 pidstat 观察 RSS 与 minflt/s，确认泄漏的真实性和速率。
  2. 在无法承受重型性能损耗的生产/实时环境中，全面拥抱 ​**eBPF (bcc-tools)**​。
  3. 解读 eBPF 数据时，必须结合时间线对比。只有呈现“滚雪球”式持续增长的数据才是真凶，偶尔出现又消失的属于正常的业务缓存快照。
  4. 警惕 C-API 的隐式内存契约，无论是标准库的 malloc/free，还是第三方框架（如 ZeroMQ）的 init/close，确保成对出现是破局的根本保障。
↑