WIN內存泄漏的检测定位和解决经验总结.doc

内存泄漏的检测、定位和解决经验总结 【摘要】 结合局端MCU项目中CSS、NMS模块内存泄漏检测、修正的过程，简要介绍了内存泄漏检测的工具，提出了内存泄漏检测的一些方法(怎样对程序结构进行改造，怎样对程序进行隔离以易于进行内存泄漏检测)。总结了内存泄漏检测过程中成功和失败的体会，希望能对后来者有所启发。 【关键词】 内存泄漏 一、故障或失误概况 局端MCU项目中CSS(Conference Schedule System)、NMS（NetWork Management System）模块自2.03版本起就有内存泄露的问题，开发 NGN版本时也花过大量的精力来争取解决这个问题，虽然也修正了一些内存泄漏，但最终检测工具表面现象显示剩下的内存泄露都是所使用的开发库的代码产生的，于是也就大意的认为是所使用的ACE/TAO库本身有内存泄漏，于是无果而终，使这两个模块的内存泄漏问题一直延续到2.03.20x版本。 由于后续测试部和开发部进行测试时引入了Robot来进行自动测试，使业务操作量巨升，此时CSS模块的内存泄漏问题就更明显了，从程序启动时的13M内存，经过一两个月后可以飙升到200 M左右，正因为此局端MCU项目好几个程序都采用了看门狗的方式来定时检测程序的状态防止程序当掉。 由于问题比较严重，于是再次进行内存泄漏问题的攻关，测试时NMS模块业务操作量小内存泄漏不明显，于是此次攻关重点是查CSS的内存泄漏问题。 此次再次进行CSS行内存泄露问题的研究，力争解决CSS的内存泄露问题，实在找不到解决方案(例如为所使用的开发库的原因)也定位出具体原因供项目组参考。 二、诊断过程 2.1工具介绍 目前Windows平台上流行的内存泄露检测工具有Rational Purify、BoundsChecker、insure++，由于CSS较复杂又是多线程采用Rational Purify工具程序就启动不起来，无法进行检测；parasoft 公司的insure++工具传说中比较好用，但由于我们公司没有相应的licence无法使用；最后选择采用限制版的BoundsChecker来进行检测。 还有就是要一个好的实时检测程序使用内存状况并能实时记录下每个时刻内存使用情况的工具，我们这里使用的是本部传输产品测试部自己开发的一个小工具MemSample。(见附录1) 对于工具方面这也是个问题，若每个公司都有个统一可用工具列表，然后附上相应的使用说明就可以省了许多精力和时间。现在好多工具都是自己去浩如烟海的网上找，有些还需要licence等，这是个很大的精力浪费。 2.2诊断概况 CSS模块为后台服务程序通过访问Web页面的形式来对外提供服务，运行了该模块的程序过一段时间后机器性能明显下降，经检测为内存严重消耗。测试部使用内存监视工具MemSample对各模块的内存进行监测，发现在一个月内CSS程序占用的内存从初始的13M飙升到200多M。 由现象可以判断肯定是存在内存泄漏问题，由于CSS对外提供服务接口繁多一时不知道那个接口导致的内存泄漏，因此确定如下测试过程: 测试方法1:通过单元测试的方法来调用部分接口进行测试。 ????????? 采用CPPUNIT测试框架辅助以桩程序的方式来模拟Web页面手工操作的方式来调用相应接口进行测试。 ????????? 程序测试过程中采用内存泄漏代码级检测工具BoundsChecker全程跟踪程序中内存分配和释放情况。 ????????? 采用内存监测工具MemSample对程序占用的整体内存进行监测并采集各时间段内存占用数据。 经过第一种测试方法发现了程序中存在的一些内存泄漏，并解决之，但解决之后发现还是存在内存泄漏，通过分析发现模拟测试步骤和真实环境下的操作唯一的不同点就是： 模拟测试是在程序内部直接调用接口，而真实环境下是通过访问Web页面，Web页面再通过CORBA协议来调用程序接口。即模拟测试少了CORBA调用那部分的操作，为此重新制定第二种测试方法： 测试方法2:真实操作环境下进行测试 ????????? 由于接口繁多，重点挑一两个使用频繁的接口进行测试。 ????????? 人工访问调用所测接口的那个Web页面，不断频繁刷新，保证和真实操作环境完全一致。 ????????? 测试过程中启动内存监测工具MemSample对CSS占用内存进行监测并采集各时间段内存占用数据。 测试后发现所测接口均存在内存泄漏，每次接口调用都会有几十K的内存泄漏，此时扩展到其它接口发现所有使用CORBA协议通过Web页面调用的接口均存在内存泄漏。比较两种测试方法可以初步确定是在调用CORBA协议部分的代码出现了内存泄漏，下面进行整个检测过程详细描述。 2.3诊断过程 采用BoundsChecker检测和Rational Purif