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中的接口可以分析调试垃圾回收的情况
- 具体功能请参见Python手册
透过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也不能回收这个对象。
问题就出在这里
灾难还没有过去
- 再次进行测试，程序终于不再内存泄漏了，能够健康的运行了
- 马上上线运行！
- 程序再次长大……真是福无双至，祸不单行
不要慌
- 测试的时候，明明没有泄漏了，上线了又不行这是为什么？
- 测试的时候，只测试了查的到的条件。
- 上线后，多数情况下，是查不到这个结果的
再次祭出法宝－添加检查点
这次测试查不到的情况，左测右测，再也没有空白列表了…… 再次打出所有不能释放的对象，发现不能释放的对象并没有增加 也没有太多看起来可疑的僵尸对象。添加检查点失败……
再静心想想
- 这次有什么不同：
- 不能释放的对象没有显著增加，甚至还比刚启动的时候减少了。
- 打印所有的不能释放掉的对象，没有发现大量的相同对象
推测结论
- 结论：这次不是引用计数器泄漏
还记得Valgrind么？
valgrind这次真的救了我们。通过valgrind，我们发现python-ldap的c代码部分存在一个 严重的内存泄漏。当一个ldap记录没有查到的时候，一些struct在没有释放的情况下程序 就直接返回了。
