python 内存泄漏分析工具_python 内存泄漏调试

最新推荐文章于 2024-08-05 22:30:00 发布

weixin_39635084

最新推荐文章于 2024-08-05 22:30:00 发布

阅读量111

点赞数

文章标签： python 内存泄漏分析工具

Python-LDAP是什么？

Python-LDAP是一个第三方的开源项目，主要目标是实现python的LDAP接口，这是一个由C语言编写的Python扩展模块。

该模块的主要功能是把通过C接口调用libldap从中取出的数据，转换成为Python的对象，除此之外还有逆向转换

Python-LDAP存在的问题

C接口调用程序内存泄漏

C接口程序Python引用计数器泄漏

分析可能的泄漏点

测试自己编写的程序时，发现程序严重消耗内存。在进行53万次查询后，程序占用的内存增大了4倍

怀疑程序存在内存泄漏，经过测试，确认程序占用内存的数量的确随查询量增长而增长。确认存在内存泄漏。

判断存在三种可能性：

Python解释器存在内存泄漏

我们自己开发的Python程序未能及时释放必须手动释放的资源

TwistedCore存在内存泄漏

调用的某个Python扩展模块出现内存泄漏

可能性一：Python解释器内存泄漏

调试步骤：

首先检查了Python的Bug Manager，查看Python 2.4.1 以后，报告的和解决掉的关于Python的内存管理问题

Python近两年来只有3个关于内存泄漏方面的问题被人报告出来，两个是关于urllib2的。另一个是关于dict的未能确认的泄漏，但只是出现在对dict进行特殊的使用时。

据此判断在我的程序的使用方式下Python解释器出现内存泄漏的可能性很低。

可能性二：Python代码未能释放必须

手动释放的资源

调试步骤：

手动释放所有不需要持续使用的资源，再次测试

内存占用没有变化，依然保持原样

说明不是Python代码造成的内存泄漏

可能性三：TwistedCore存在内存泄漏

调试步骤：

查询了Twisted的Tickets系统

Twisted确实在近期出现过一些内存泄漏的情况，并且包括一个Twisted 2.1.0未修复的

升级Twisted到Twisted 2.2.0

再次测试，内存占用仍然没有变化，说明：

可能TwistedCore不存在内存泄漏

还存在未能发现的TwistedCore内存泄漏

Twisted代码比较多，结构复杂，先跳过这种可能性

可能性四：某个Python扩展模块出现内存泄漏

程序主要依赖的扩展模块就是Python-LDAP

该模块存在内存泄漏的可能比较高

如何进行调试呢？

内存泄漏调试过程

使用分析工具Valgrind对整个应用程序的运行过程进行分析

运行命令行

valgrind -v --leak-check=yes --num-callers=256 --logfile=d python d.py

发现openldap 2.3.19中libldap.so包含两处内存泄漏

ldap初始化的时候解析域名时存在的一次性泄漏

多线程并发情况下，断开连接时忘记释放的mutex

仍然泄漏

对第二个泄漏进行了修复

再次测试，发现仍然泄漏

此时valgrind的报告中只剩下一个一次性的泄漏了，这个泄漏只有49个字节

内存都让谁占了呢？

分析内存占用情况

为valgrind增加命令行参数--show-reachable=yes，这将会把还在使用的内存情况也打印出来

运行命令行

valgrind -v --show-reachable=yes --leak-check=yes --num-callers=256 \

--logfile=d python d.py

分析结果

长时间测试后发现了如下情况：

9676796 bytes in 235920 blocks are still reachable in loss record 32 of 32

at 0x3C032183: malloc (vg_replace_malloc.c:105)

by 0x80D9CA0: _PyObject_GC_Malloc (gcmodule.c:1248)

by 0x80D9D6B: _PyObject_GC_NewVar (gcmodule.c:1279)

by 0x80858D3: PyTuple_New (tupleobject.c:68)

by 0x808D9FF: PyType_Ready (typeobject.c:3167)

by 0x808D9C5: PyType_Ready (typeobject.c:3153)

by 0x807C8DB: _Py_ReadyTypes (object.c:1805)

by 0x80D1BC5: Py_InitializeEx (pythonrun.c:167)

by 0x80D1F8C: Py_Initialize (pythonrun.c:283)

by 0x80558C3: Py_Main (main.c:418)

by 0x805520C: main (python.c:23)

难道是Python解释器泄漏了？

根据上述报告分析，大量的内存都由python解释器的gcmodule控制

难道是gcmodule的回收机制出现了问题？

Python的Garbage Collector机制

Python的gc是分代垃圾回收机制，共分三代

通过引用计数判断数据单元是否可以回收

通过扩展模块gc中的接口可以分析调试垃圾回收的情况

透过GC看内存

Python的gc模块功能还是很强大的

使用get_objects( )方法可以取得当前所有不能回收的对象(引用计数不为0)的列表

存放在列表中的是所有对象的wrapper

吃内存的老鼠抓住了

通常情况下，不能释放的对象不会太多，启动时在2、3万个左右

我发现程序长时间运行后，不可释放的对象总数大量增加。

最终确认，不可释放的对象数量随查询量增大

写个循环把他们都打印出来

发现了大量的空白列表对象，并且这些空白的列表不能够被GC回收，只有一种可能性，它们的引用计数不为0

这些列表那儿来的？

在Python代码中创建的对象，使用完毕后引用计数器就会归零

我的代码中也已经手动删除了所有可以释放掉的资源，尤其是列表对象

严重怀疑，这些东西来自于Python-LDAP扩展模块

关于Python扩展模块

Python的扩展模块在操作Python对象之后，也需要改变对象的引用计数器

扩展模块中的C程序一旦忘记修改或者不能正确的修改引用计数器，这些对象就成了僵尸对象

如何找到bug？

python-ldap有2k多行C代码，虽说不是太多，但要是找起来也是大海捞针。

对Python扩展模块的机制不是很熟悉，很难看出代码的错误

给作者写信？这确实不是我们的风格，拿不出来patch，那儿好意思跟大家打招呼：）

开发任务时间紧，靠别人不如靠自己

不过问题还真是棘手，这种问题连valgrind也查不出来啦

静下心来好好想

出问题的应该肯定是Python-LDAP模块了

我的程序调用它的次数并不是很多，每次查询调一次

现在已经知道泄漏的对象是空白的列表

于是...

添加检查点

在每个调用python-ldap的语句前后都添加检查点

抓住bug了

针对每次调用添加检查点后，立刻就找到了泄漏点。正是在ldapsearch完毕，获取ldap查询结果之后，出现了一个空白的列表。经过对那段代码进行分析，仍然无法确认是那行代码写错了，因为对Python扩展模块操作引用计数器的方法不是很熟悉。当改用同步方式查询ldap的时候，发现没有泄漏出空白列表。通过比较这两种情况下代码的执行路径，发现在异步查询的情况下，在返回的ldap控制码为空的时候，python-ldap返回了一个空白的列表给python 解释器，但是并没有讲这个空白列表的引用计数器减掉，导致这个列表的引用计数一直不能清零，gc也不能回收这个对象。

问题就出在这里