排查Python内存分析工具无法检测到的内存泄漏问题

你遇到的情况是Python绑定的底层Native库内存泄漏的典型表现——常规Python内存工具只能追踪Python对象，无法捕获C/C++层分配的内存。针对aiortc这类依赖libav、libsrtp等底层库的项目，可从以下方向排查：

一、Python层面进阶追踪 #

• 用objgraph追踪对象增长：定期运行objgraph.show_growth(limit=10)，重点关注MediaStreamTrack、RTCPeerConnection这类aiortc核心对象的数量变化。如果这些对象长期存活未被回收，可能间接导致底层资源无法释放。
• 检查垃圾回收异常：手动触发gc.collect()后，查看gc.garbage列表，确认是否存在无法回收的循环引用对象——这类对象可能绑定了底层内存资源，导致Native层内存无法释放。

二、底层Native内存分析工具 #

1. Valgrind（Linux平台） #

直接用Valgrind追踪所有内存分配与泄漏：

valgrind --leak-check=full --track-origins=yes python3 your_script.py

建议搭建最小复现环境（比如仅维持单个RTC流），避免异步IO在Valgrind下运行过慢。重点看输出中的definitely lost项，定位到具体的底层库函数。

2. GDB内存快照分析 #

当内存占用较高时，附加到Python进程并生成内存快照：

gdb -p <你的Python进程PID>

在GDB中执行：

dump memory memory_dump.bin 0x0 (char*)sbrk(0)

用strings memory_dump.bin扫描快照中的特征字符串（比如libav的帧数据标识），判断内存被哪种底层资源占用。同时用info sharedlibrary查看加载的动态库，结合bt命令查看调用栈，定位分配内存的底层函数。

3. 系统级工具辅助定位 #

• pmap：查看进程内存映射，确认内存增长是否来自匿名堆内存：

  pmap -x <你的Python进程PID>
  

  如果anon类型的内存块持续增大，说明底层代码在不断分配堆内存且未释放。
• perf：追踪内存分配事件，定位高频分配的函数：

  perf record -e malloc -g -p <你的Python进程PID>
  perf report
  

  这能直接看到哪些底层函数在频繁分配内存，结合aiortc的C扩展源码（如src/_rtp.c）对应排查。

三、aiortc定向排查 #

• 逐步禁用功能缩小范围：关闭音频处理、RTCP报告等非核心功能，观察内存是否停止增长。比如手动调用RTCRtpSender.close()或不再使用MediaRecorder，验证是否有改善。
• 调用对象的释放接口：确保aiortc的核心对象（如RTCPeerConnection、MediaStreamTrack）在不再使用时调用close()方法，强制触发底层资源的释放。

内容的提问来源于stack exchange，提问作者Axel