最近,我们的软件在运行过程中,遇到了一个很诡异的问题。
![ab727ad600b2637999b088e16393ccc6.png](https://i-blog.csdnimg.cn/blog_migrate/20af1030302dd499288cb62ca4c4b46c.jpeg)
软件在一个测试同事的win7 32位系统上运行1个多小时后会闪退崩溃。奇怪的是,在测试该产品的主要测试人员的win10电脑上,则从未出现过这个情况。
下面详细介绍一下这个问题的排查过程,以及给我们的一些启示!
1、初步分析
![74f4cbd6f25ccee738618352f5e9dc87.png](https://i-blog.csdnimg.cn/blog_migrate/7391fd279e41634a18697ffeea4e3060.jpeg)
我们在软件中安装了异常信息捕获机制,但是软件发生闪退时,并没有捕获到有效dump文件(崩溃信息存放在dump文件中),生成的dump文件是空的!可能是在导出异常上下文信息时发生了二次崩溃,所以没有生成有效的dump文件。
这个问题在他电脑上出现过好几次了。于是,让同事将windows系统上常用的软件调试利器windbg挂载到目标进程上,看看复现闪退时能否抓到有效的信息。结果问题复现后,抓到的异常上下文对应的代码模块基本是不可能产生异常的,所以问题排查还是没有头绪!
突然无意中想到,软件是运行一两个小时后出现的,难道是软件中有内存泄漏?把进程的虚拟内存耗完了,导致再申请内存时都失败了,产生了空指针,导致空指针访问违例,导致软件闪退。这种假设可以解释windbg捕获到的不可能发生异常的代码块的现象了!
于是重新启动软件,观察了任务管理器中我们软件对应的进程的内存占用情况。看到我们软件的进程的内存一直在增长,在运行1个多小时后竟然涨到1GB多了,这下基本可以确定,肯定是内存泄漏导致的内存被耗完,从而导致软件再申请内存失败了,导致访问了空指针,导致软件闪退了!
下面就是使用一些内存泄漏的检测工具来来定位内存泄漏的模块了!
2、使用腾讯的tMemMonitor内存泄漏检测工具检测内存泄露
最开始尝试使用腾讯的tMemMonitor内存泄漏检测工具,检测一下内存泄漏发生在哪个模块中。
![7b28f674b7caab05bd95f28dd3a56814.png](https://i-blog.csdnimg.cn/blog_migrate/a4b170b5f553b194b5f0c1a9c9b25602.jpeg)
具体的做法是,使用tMemMonitor将我们的软件启动起来:
![506a09ac169cd6135d290944769743fd.png](https://i-blog.csdnimg.cn/blog_migrate/a06602d07aaee61adb2b5ded4d846d72.jpeg)
让软件运行一个多小时,让软件产生1GB以上的内存泄漏,然后关闭软件,如果检测到内存泄漏就会弹出生成检测报告的提示,打开报告就可以看到检测结果了。
注意,tMemMonitor内存泄漏检测工具只能检测release版本的程序,被检测程序必须由tMemMonitor启动,并且被监测程序在退出时必须是正常退出的。如果关闭软件时发生了崩溃,tMemMonitor是不会生成内存泄漏报告的。
检测报告中会显示发生内存泄漏的dll或exe的模块名,并且会将相关的函数调用堆栈打印出来,比如:
![0494147418080023a2bdb2b438c69ffa.png](https://i-blog.csdnimg.cn/blog_migrate/2d7157a1b001a3855b69da1ca6c5866e.jpeg)
但实际跑下来,看到检测报告,并没有看到有用的信息,检测到泄漏内存的都比较小,和实际泄漏的内存大小相差甚远!难道不是用户态的内存泄漏?是内核态的内存泄漏?
3、使用windbg检测内存泄漏
使用tMemMonitor工具分析不出来,于是又尝试使用windbg分析了一把。使用此方法之前,要预先安装好windbg工具。最新版本的windbg是从内置在微软官方的SDK中的,可以自行到微软的官方网站上下载安装。
此内存泄漏检测方法,会用到windbg安装路径下的gflags.exe和umdh.exe程序,如下所示:
![84410e2a5502817a0ebd0aad3f98367f.png](https://i-blog.csdnimg.cn/blog_migrate/e9117dfe7ae5524242e9549ef5bd6797.jpeg)
具体的操作步骤是:
1)打开cmd窗口,切换到windbg的安装目录中,比如我的安装路径是:C:Program FilesWindows Kits10Debuggersx86。
2)先使用命令设置用户态函数栈回溯标记:gflags /i xxxxxxxxx.exe +ust,具体含义可以以“gflags /?”查看gflags相关命令行的参数说明:
![b03fbceb10fb82cacda1e2f18a7127bc.png](https://i-blog.csdnimg.cn/blog_migrate/b52e786723fb39d97bcae79a511a7268.jpeg)
![0289bfbf6cd266aa979724c4eb93379e.png](https://i-blog.csdnimg.cn/blog_migrate/b2a2ff4a1855dc92ff913165d8d0e1b9.jpeg)
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支持的命令行参数,以及如何使用的:
![6d50486d93a7c7bb62f493d5a2df49ba.png](https://i-blog.csdnimg.cn/blog_migrate/a2188298de42166d301cd3cd91b6e229.jpeg)
然后让程序运行一个多小时后,让程序有足够多的内存泄漏,然后再用命令:umdh.exe -pn:xxxxxxxxx.exe -f:E:log2.txt,导出时刻2时的堆内存分配使用情况。
4)使用命令:umdh.exe E:log1.txt E:log2.txt -f:E:esult.txt,比较两个时刻中间的时间段的堆内存的增长及使用情况,找出可能出现内存泄漏的地方:
![317b29b1df858350e66dcb2563f9685a.png](https://i-blog.csdnimg.cn/blog_migrate/20dab7dbbaf10f9587951fed7a7107f9.jpeg)
这似乎还是有问题,明明泄漏了1GB多的内存,怎么检测结果中最多泄漏的那项计算出来泄漏的内存才200MB,相差的比较多的,看来windbg似乎也不可信啊!
4、使用代码分块注释的办法,定位到发生内存泄漏的模块
问题还是没查出来,这个就比较头疼了,软件马上要对外发布正式商用版本了,这个问题必须要解决啊!
最后没办法,只能采用逐步注释代码的方法,看看能否定位内存泄漏发生在哪个模块中。经多次尝试发现,与dcs数据协作模块的库有关系。然后查看了一下dcs服务器的连接状态,服务器连不上,底层一直在不断的定时重连,难道是每次重连失败后没有释放socket套接字等资源导致的内存泄漏?
于是找到相关模块的负责同事,让他们排查,排查下来后发现,确实是服务器重连失败后没有将相关资源释放掉导致的内存泄漏(使用websocket和服务器通信的)!
后来在我自己的两台电脑上验证了一下,软件运行在我win7 32位电脑上是有内存泄漏的,但在我另一台win7 64位系统上则没有内存泄漏。在测试同事的win10系统上,也详细观察了,win10系统上居然没有内存泄漏,软件运行一切正常!这个内存泄漏难道是和操作系统是强相关的?
5、进一步研究确认
知道大概的原因之后,我又用windbg和tMemMonitor都重新检测了一下内存泄漏,看看哪个工具更好用,定位的更准确!
我们选择检测的时间段内,软件已经占用了1.15GB的内存,内存泄漏估计得有900MB左右了。
此时windbg分析出来的内存泄漏模块确实是对的,如下所示:
![2cd726b4ef88fe77f68c3ebddf377611.png](https://i-blog.csdnimg.cn/blog_migrate/f53600fad24edc0eb41d4e3b44842a11.jpeg)
但是泄漏的内存只有200MB左右,这和实际的内存泄漏大小有很大的出入。当前windbg分析出的内存泄漏是用户态的,可能有部分泄漏发生在程序的内核态?
而腾讯的tMemMonitor和windbg比要逊色不少,tMemMonitor不仅检测出的泄漏内存大小比实际泄漏大小要小很多,而且根本没有定位到发生内存泄漏的模块。所以,windbg还是要强大不少的。
经后来验证,在另一台的win7 64位系统中,之前之所以没有内存泄露,是因为这台机器上登录平台的账号是没有dcs服务的权限,就不会登录dcs服务器,就不会触发dcs服务器的重连。而本例中的内存泄漏就是dcs重连失败后没有清理相关资源导致的。后来使用一个有dcs服务权限的账号在这台win7 64位系统中登录我们的软件,同样也出现了内存泄漏。
但同样的代码、同样的软件在win10系统中却没有内存泄漏,通过打印日志可以确定win10系统中也触发了dcs服务器的重连了,这可能是win10系统的内存管理机制和win7不同引起的吧!
6、总结
遇到问题后,要进行深入细致的研究,要搞清楚各种情况的来龙去脉!在详细的研究过程中要多思考多验证,会有新的发现和新的收获!