前两天偶然发现，又有内存泄漏了。昨天仍然在写Lua脚本，于是没怎么管它，今天早上起来wc时，突然觉得这内存泄漏实在是眼中钉，肉中刺，一定要解决。
首先是发现，只有在程序中打开过文件后，才会有内存泄漏，而且泄漏的数量跟打开文件的数量似乎是成正比的。于是开始查看打开文件部分的代码，发现这部分代码实在写得太简单了，几乎不存在泄漏的机会，绝大部分函数都是立马将请求转发到Lua脚本去了，我假设Lua脚本不会出现泄漏。
于是我尝试新建一个文档而不保存，发现果然没有泄漏！这就说明泄漏可能的两个来源，一个是读写文件时，一个是根据文件类型作出不同响应时。接着，尝试打开一个txt文件，也没有泄漏，这说明第一个猜测的泄漏源不成立，那么把注意力集中在第二点上。
我先是怀疑是不是lexer相关的代码引起的泄漏。于是又用程序打开cpp文件，这是一种处于中间状态的文件，程序能认出这种文件的类型，应用相应的lexer对其着色，折叠等，但不做更多的操作。果然也没有泄漏，再打开lua文件，又有泄漏。仔细回忆了一下lua文件和cpp文件的区别，大概最有可能的两处是符号视图和代码片段视图，这两个视图在打开lua文件时是会被操作的，而打开cpp文件则没有。
这时，我先去看了一下符号视图，先把刷新视图的代码屏蔽掉。编译运行，没有泄漏。已经将范围缩小到这个函数内了，再只屏蔽添加新节点的代码，发现又有泄漏了，说明泄漏不在添加新节点的代码上。通过一段一段地屏蔽代码，直到最后发现，是我自己写的Xerces-C++的封装类在从字符串中载入xml文档后，就会有泄漏，所以可以确定问题出在这个载入函数中。
打开这个函数的代码看了看，非常简单，只有3行代码，其中第1行就new了一个对象，后面却没有任何释放的动作。在后面加了一句delete，重新编译测试，确实没有泄漏了！还有一个Lua使用Xerces-C++的绑定库，也要做相应的修改。
解决，安逸！
支付宝扫一扫
微信扫一扫