都是软件中的内存泄漏惹的祸

存储
最近,我们的软件在运行过程中,遇到了一个很诡异的问题。软件在一个测试同事的win7 32位系统上运行1个多小时后会闪退崩溃。奇怪的是,在测试该产品的主要测试人员的win10电脑上,则从未出现过这个情况。

 最近,我们的软件在运行过程中,遇到了一个很诡异的问题。

 

 

 

 

软件在一个测试同事的win7 32位系统上运行1个多小时后会闪退崩溃。奇怪的是,在测试该产品的主要测试人员的win10电脑上,则从未出现过这个情况。

下面详细介绍一下这个问题的排查过程,以及给我们的一些启示!

1、初步分析

 

我们在软件中安装了异常信息捕获机制,但是软件发生闪退时,并没有捕获到有效dump文件(崩溃信息存放在dump文件中),生成的dump文件是空的!可能是在导出异常上下文信息时发生了二次崩溃,所以没有生成有效的dump文件。

这个问题在他电脑上出现过好几次了。于是,让同事将windows系统上常用的软件调试利器windbg挂载到目标进程上,看看复现闪退时能否抓到有效的信息。结果问题复现后,抓到的异常上下文对应的代码模块基本是不可能产生异常的,所以问题排查还是没有头绪!

突然无意中想到,软件是运行一两个小时后出现的,难道是软件中有内存泄漏?把进程的虚拟内存耗完了,导致再申请内存时都失败了,产生了空指针,导致空指针访问违例,导致软件闪退。这种假设可以解释windbg捕获到的不可能发生异常的代码块的现象了!

于是重新启动软件,观察了任务管理器中我们软件对应的进程的内存占用情况。看到我们软件的进程的内存一直在增长,在运行1个多小时后竟然涨到1GB多了,这下基本可以确定,肯定是内存泄漏导致的内存被耗完,从而导致软件再申请内存失败了,导致访问了空指针,导致软件闪退了!

下面就是使用一些内存泄漏的检测工具来来定位内存泄漏的模块了!

2、使用腾讯的tMemMonitor内存泄漏检测工具检测内存泄露

最开始尝试使用腾讯的tMemMonitor内存泄漏检测工具,检测一下内存泄漏发生在哪个模块中。

 

具体的做法是,使用tMemMonitor将我们的软件启动起来:

 

让软件运行一个多小时,让软件产生1GB以上的内存泄漏,然后关闭软件,如果检测到内存泄漏就会弹出生成检测报告的提示,打开报告就可以看到检测结果了。

注意,tMemMonitor内存泄漏检测工具只能检测release版本的程序,被检测程序必须由tMemMonitor启动,并且被监测程序在退出时必须是正常退出的。如果关闭软件时发生了崩溃,tMemMonitor是不会生成内存泄漏报告的。

检测报告中会显示发生内存泄漏的dll或exe的模块名,并且会将相关的函数调用堆栈打印出来,比如:

 

但实际跑下来,看到检测报告,并没有看到有用的信息,检测到泄漏内存的都比较小,和实际泄漏的内存大小相差甚远!难道不是用户态的内存泄漏?是内核态的内存泄漏?

3、使用windbg检测内存泄漏

使用tMemMonitor工具分析不出来,于是又尝试使用windbg分析了一把。使用此方法之前,要预先安装好windbg工具。最新版本的windbg是从内置在微软官方的SDK中的,可以自行到微软的官方网站上下载安装。

此内存泄漏检测方法,会用到windbg安装路径下的gflags.exe和umdh.exe程序,如下所示:

 

具体的操作步骤是:

1)打开cmd窗口,切换到windbg的安装目录中,比如我的安装路径是:C:\Program Files\Windows Kits\10\Debuggers\\x86。

2)先使用命令设置用户态函数栈回溯标记:gflags /i xxxxxxxxx.exe +ust,具体含义可以以“gflags /?”查看gflags相关命令行的参数说明:

 

3)使用umdh.exe将时刻1时的堆内存分配情况输出到日志文件中:umdh.exe -pn:xxxxxxxxx.exe -f:E:\log1.txt。其中,umdh.exe是windows debug tools 下的一款命令行工具,它的全程是User Mode Dump Heap 这个工具会分析当前进程在堆上分配的内存。可以使用“umdh /?”查看umdh.exe支持的命令行参数,以及如何使用的:

 

然后让程序运行一个多小时后,让程序有足够多的内存泄漏,然后再用命令:umdh.exe -pn:xxxxxxxxx.exe -f:E:\log2.txt,导出时刻2时的堆内存分配使用情况。

4)使用命令:umdh.exe E:\log1.txt E:\log2.txt -f:E:\result.txt,比较两个时刻中间的时间段的堆内存的增长及使用情况,找出可能出现内存泄漏的地方:

 

这似乎还是有问题,明明泄漏了1GB多的内存,怎么检测结果中最多泄漏的那项计算出来泄漏的内存才200MB,相差的比较多的,看来windbg似乎也不可信啊!

4、使用代码分块注释的办法,定位到发生内存泄漏的模块

问题还是没查出来,这个就比较头疼了,软件马上要对外发布正式商用版本了,这个问题必须要解决啊!

最后没办法,只能采用逐步注释代码的方法,看看能否定位内存泄漏发生在哪个模块中。经多次尝试发现,与dcs数据协作模块的库有关系。然后查看了一下dcs服务器的连接状态,服务器连不上,底层一直在不断的定时重连,难道是每次重连失败后没有释放socket套接字等资源导致的内存泄漏?

于是找到相关模块的负责同事,让他们排查,排查下来后发现,确实是服务器重连失败后没有将相关资源释放掉导致的内存泄漏(使用websocket和服务器通信的)!

后来在我自己的两台电脑上验证了一下,软件运行在我win7 32位电脑上是有内存泄漏的,但在我另一台win7 64位系统上则没有内存泄漏。在测试同事的win10系统上,也详细观察了,win10系统上居然没有内存泄漏,软件运行一切正常!这个内存泄漏难道是和操作系统是强相关的?

5、进一步研究确认

知道大概的原因之后,我又用windbg和tMemMonitor都重新检测了一下内存泄漏,看看哪个工具更好用,定位的更准确!

我们选择检测的时间段内,软件已经占用了1.15GB的内存,内存泄漏估计得有900MB左右了。

此时windbg分析出来的内存泄漏模块确实是对的,如下所示:

 

但是泄漏的内存只有200MB左右,这和实际的内存泄漏大小有很大的出入。当前windbg分析出的内存泄漏是用户态的,可能有部分泄漏发生在程序的内核态?

而腾讯的tMemMonitor和windbg比要逊色不少,tMemMonitor不仅检测出的泄漏内存大小比实际泄漏大小要小很多,而且根本没有定位到发生内存泄漏的模块。所以,windbg还是要强大不少的。

经后来验证,在另一台的win7 64位系统中,之前之所以没有内存泄露,是因为这台机器上登录平台的账号是没有dcs服务的权限,就不会登录dcs服务器,就不会触发dcs服务器的重连。而本例中的内存泄漏就是dcs重连失败后没有清理相关资源导致的。后来使用一个有dcs服务权限的账号在这台win7 64位系统中登录我们的软件,同样也出现了内存泄漏。

但同样的代码、同样的软件在win10系统中却没有内存泄漏,通过打印日志可以确定win10系统中也触发了dcs服务器的重连了,这可能是win10系统的内存管理机制和win7不同引起的吧!

6、总结

遇到问题后,要进行深入细致的研究,要搞清楚各种情况的来龙去脉!在详细的研究过程中要多思考多验证,会有新的发现和新的收获!

责任编辑:华轩 来源: 今日头条
相关推荐

2014-07-18 14:10:07

WIFI华为

2009-01-07 09:22:00

2010-09-14 11:29:43

谷歌

2010-01-12 09:25:17

Windows 7死机系统特效

2009-08-01 15:47:04

网线故障

2009-04-27 13:46:30

网络管理拷贝故障

2020-12-02 06:30:52

Nginx前缀FastDFS

2023-09-18 07:21:18

装机误区主机

2010-11-08 13:57:46

谷歌云计算

2011-01-10 15:50:40

Hotmail系统故障脚本

2019-06-03 14:23:59

AWS宕机光纤

2021-09-30 22:37:01

手机内存技术

2020-12-29 09:25:33

5G手机宽带

2018-09-29 08:36:55

宕机停机局域网

2013-07-22 09:43:29

2012-12-12 09:57:12

Chrome负载均衡

2015-02-28 14:09:48

2015-10-27 14:38:40

2013-01-15 10:30:45

Windows 8Metro

2009-07-18 16:43:09

光纤链路故障接线端面脏污
点赞
收藏

51CTO技术栈公众号