青岛建设系统一体化网站,扁平图标网站,云南电商网站开发,西安网站制作托目录 1、问题说明 2、初步分析 3、查看任务管理器#xff0c;并使用GDIView工具分析 4、GDIView可能对Win10兼容性不好#xff0c;显示的GDI对象个数不太准确 5、采用历史版本比对法#xff0c;确定初次出现问题的时间点#xff0c;并查看前一天的代码修改记录 6、将…目录 1、问题说明 2、初步分析 3、查看任务管理器并使用GDIView工具分析 4、GDIView可能对Win10兼容性不好显示的GDI对象个数不太准确 5、采用历史版本比对法确定初次出现问题的时间点并查看前一天的代码修改记录 6、将修改的代码与测试现象结合起来最终定位问题 7、事后的思考 8、最后 VC常用功能开发汇总专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/124272585C软件异常排查从入门到精通系列教程专栏文章列表欢迎订阅持续更新...https://blog.csdn.net/chenlycly/article/details/125529931C软件分析工具从入门到精通案例集锦专栏文章正在更新中...https://blog.csdn.net/chenlycly/article/details/131405795C/C基础与进阶专栏文章持续更新中...https://blog.csdn.net/chenlycly/category_11931267.html       最近在项目中遇到了一个GDI对象泄漏问题排查该问题也用了不少时间其问题场景和排查方法很有代表性今天将当时排查的过程做个详细的记录和总结以供大家借鉴或参考。 1、问题说明 某天早上来公司上班有同事反馈我们开发的PC客户端软件的UI界面显示出问题了窗口中部分区域与按钮等显示不全应该是部分界面绘制失败了但软件并没有崩溃。同事说前一天晚上他们为了测试移动APP使用我们的PC端软件和移动app进行了联动进行了一夜的拷机测试早上来就发现PC客户端出了上述问题。他们没有关闭软件保留着现象及现场喊我们过去看看是怎么回事。 2、初步分析 于是我到同事那边去查看现象根据以往经验感觉很有可能是GDI句柄泄漏引起界面绘制异常当程序的GDI对象接近1万个时界面就会出现绘制失败显示不全的问题。 在Windows系统中每个进程的GDI对象总数是有上限的上限就是10000个当接近或达到这个上限时界面就会绘制失败甚至程序会出现闪退崩溃。 类似的问题前几天有同事反馈过但其没保留现象直接将程序重启了所以当时没有进行分析这次这个同事反馈的这个问题从现象上看和之前同事反馈的问题是类似正好借此机会详细排查一下。 3、查看任务管理器并使用GDIView工具分析 为了验证GDI对象泄漏的猜想先是打开系统的任务管理器去查看软件进程的GDI对象总数。打开任务管理器点击详细信息标签页找到目标软件进程看到进程的GDI总数确实有异常已经达到了9999个差1个就到1万的上限了如下所示 ​       正常情况下进程在某个时刻使用的GDI对象总数也就几百个左右最多也就1000多个此处居然达到了9999个肯定是有GDI对象泄漏了。使用完的GDI对象没有调用DeleteObject等接口将之释放掉这样会导致程序中占用的GDI对象越来越多如果有GDI对象泄漏的代码在频繁的执行那么泄漏会很明显到任务管理器中可以看到目标进程的GDI对象总数在持续不断的上升可能很快就要达到10000个上限了。 默认情况下任务管理器的进程列表中不会显示进程的GDI总数需要右键点击列表头在弹出的右键菜单中点击“选择列” ​然后在弹出的窗口中找到GDI对象选项 ​勾选上即可看到进程的GDI对象总数。 正常情况下进程的GDI对象最多只会有上千个如果有好几千一般可能是有GDI对象泄漏。 4、GDIView可能对Win10兼容性不好显示的GDI对象个数不太准确 仅仅通过任务管理器中的GDI对象总数判断出有GDI对象是不够的因为GDI对象有多种比如常见的GDI对象有Pen用来划线的画笔、Brush用来填充区域颜色的画刷、Bitmap用来绘制图片的位图、Font用来控制文字显示大小及字形的字体、Region区域、DC用来绘制窗口的设备上下文等如下 为了有针对性的排查我们还需要知道具体是哪种类型的GDI对象有泄漏这就需要使用GDI对象查看工具GDIView。于是在同事的电脑上到GDIView官网上下载了GDIView工具因为当前Windows系统是64位的所以要下载64位的GDIView64位系统上不能运行32位的GDIView直接运行会报错按讲64位系统是支持32位程序的可能是GDIview工具自己的限制如下 启动64位GDIView工具后看到All GDI数目为9999 ​查看其他具体类型的项只有Bitmap位图对象数目比较多但只有1000多个1436个其他类型的GDI对象都比较少那这个9999总数主要是由哪个对象泄漏引发的呢从最后的分析结果看是Bitmap对象泄漏引起的那Bitmap对象数应该有好几千个为啥GDIView中只显示1000多个应该是GDIView工具对Win10系统兼容性不好显示的各个GDI对象的数目有问题之前我们在Win7和XP系统上用GDIView工具排查过GDI泄漏问题GDIView中显示的各个类型的GDI对象都是比较准的。 5、采用历史版本比对法确定初次出现问题的时间点并查看前一天的代码修改记录 GDIView中看不到具体是哪个类型的GDI泄漏这样我们就没法进行有针对性的排查。好在我们有个脚本控制的自动化代码编译系统只要有修改代码每天都会自动编译版本生成程序的安装包如下所示 于是我们只能使用历史版本比对法取几个时间点的版本安装包多次安装并执行程序然后再采取二分法取版本看看是从哪天开始有这个问题的然后我们查看前一天提交的代码可能就能找到排查问题的线索了。 历史版本比对法比较适用相对独立的客户端程序虽然是个比较笨重、原始的办法但很多时候都比较有用我们在项目中已多次使用。 最终通过对比发现从2022年12月15日开始编译的版本都有内存泄漏的问题12月14日的版本是没问题的。于是在SVN上查看前一天12月14日的代码提交记录看看可能是修改哪一处的代码引发的。但12月14日当天修改的代码是处理业务服务器重连问题修改了相关的逻辑但这些修改的代码都和GDI绘制没关系为啥会触发GDI对象泄漏呢很是奇怪到此排查问题的线索似乎又断了。 6、将修改的代码与测试现象结合起来最终定位问题 12月14日之前业务服务器的重连功能都是有问题的12月14日修改代码后重连功能就没问题了。这时测试同事又提供了一个关键的线索用当前最新的版本的客户端软件登录公网上的通用平台是没有GDI对象泄漏的但登录公司内部的内网测试平台就有GDI对象泄漏。这两个平台有啥差别导致同一个版本的客户端软件登录后有不同的表现呢 于是结合修改的代码12月14日修改的代码是关于某类业务服务器断链后的重连代码12月14日之前的重连代码都是有问题的。难道是两个平台上某个业务服务器的连通状态是不一样的于是用客户端分别登录这两个平台查看日志看看两个平台的所有业务服务器的连接状态。果然是有差异的公网平台上的所有业务服务器都是能正常连接的但内网测试平台上某个业务服务器一直是连不上的一直在不断重连业务服务器连不上时会自动去重连。 于是查看触发重连时的整个流程的所有代码然后果然找到了问题重连的流程中会去调用一个接口去自动生成一张图片调用CreateCompatibleBitmap API函数去创建一个Bitmap位图对象但这个Bitmap位图对象在使用完后没有调用DeleteObject将Bitmap对象释放掉所以导致了GDI对象泄漏。问题代码片如下 HDC hdc ::GetDC( NULL ); HDC memDC ::CreateCompatibleDC( hdc );HBITMAP hBitmap, hOldBitmap; // 调用CreateCompatibleBitmap创建一个与设备描述表兼容的位图问题就出在这个 hBitmap ::CreateCompatibleBitmap( hdc, nWidth, nHeight ); hOldBitmap (HBITMAP)SelectObject( memDC, hBitmap ); ::SetBkColor( memDC, WHITE_BRUSH ); // 区域刷白// 设置字体 // 字体创建 LOGFONT lf; u32 dwXDpi GetDeviceCaps( hdc, LOGPIXELSX ); // 得到当前显示设备的水平单位英寸像素数; if ( dwXDpi ! 0) {nPointSize static_castu32( nPointSize * 96.0 / dwXDpi ); } memset( lf, 0, sizeof(LOGFONT) ); lf.lfHeight -MulDiv ( nPointSize, GetDeviceCaps ( hdc, LOGPIXELSY ), 72 ); lf.lfWidth lf.lfHeight/2; lf.lfOutPrecision OUT_STRING_PRECIS; lf.lfQuality CLEARTYPE_QUALITY; lf.lfWeight FW_NORMAL; _tcscpy( lf.lfFaceName, _T(微软雅黑) ); HFONT hFont ::CreateFontIndirect( lf );::SetBkMode(memDC, TRANSPARENT); ::SetTextColor( memDC, RGB( 213, 242, 253 ) ); HFONT hOldFont (HFONT)::SelectObject( memDC, hFont );RECT rcDest; rcDest.left 0; rcDest.top 0; rcDest.right nWidth; rcDest.bottom nHeight;if ( emLogoPos emTopLeft_Api || emLogoPos emBottomLeft_Api ) {::DrawText( memDC, strName, strName.GetLength(), rcDest, DT_LEFT | DT_SINGLELINE ); } else {::DrawText( memDC, strName, strName.GetLength(), rcDest, DT_RIGHT | DT_SINGLELINE ); }//::BitBlt( hdc, 0,0,nWidth,nHeight, memDC,0,0, SRCCOPY );CUIString strFile GetSelfFilePath() LOGO_BMP_FILE; SaveBitmapToBmpFile( hBitmap, strFile, LOGO_DPI_32 );::SelectObject( memDC, hOldFont ); ::SelectObject( memDC, hOldBitmap );if ( hFont ! NULL ) {::DeleteObject( hFont ); }if ( NULL ! memDC ) {::DeleteDC( memDC ); } ::ReleaseDC( NULL, hdc ); 代码结尾处释放了Font字体对象和DC对象但忘记释放Bitmap对象。在代码片的结尾处应该调用DeleteObject将之前创建的Bitmap对象释放掉即 if ( hBitmap ! NULL ) {::DeleteObject( hBitmap ); } 修改后的代码块如下 ​ 因为测试平台上某个业务服务器始终有问题客户端连接不上一直在不断的重连所以这段包含GDI对象泄漏的代码在持续不断的执行这样在长时间的拷机运行之后导致程序的GDI对象总数达到了9999个。至此终于找到产生GDI对象泄漏的源头修改代码后编译版本再安装运行就不再有内存泄漏了。 这个地方也说明一个问题GDIView在Win10系统中运行显示的各类型的GDI对象的数目是不准确的。本问题中是Bitmap对象有泄漏Bitmap对象应该有好几千个才对结果GDIView中显示的Bitmap对象只有1000多个这个显示不准确的问题下次要注意了。其实一开始看到Bitmap对象有1000多个就应该觉察到Bitmap对象有问题了一般情况下不可能有这么多的 此外之前也写过一篇使用GDIView排查GDI对象泄漏的案例感兴趣的话可以查看对应的文章 使用GDIView工具排查GDI对象泄漏问题https://blog.csdn.net/chenlycly/article/details/125399896 7、事后的思考 这段生成图片的代码是十多年前写的出自于一个刚毕业的应届生之手应该是因为经验不足写出的代码不规范在使用完创建的GDI对象之后应及时地将对象释放掉。我们平时一再地强调写代码一定要规范要尽量考虑的全面一些否则可能会埋下一些或大或小的隐患。 此外这段GDI对象泄漏的代码掩藏的比较深在业务服务器都能正常连接的平台上比如给客户使用的商用平台不会触发GDI泄漏。公司内部的测试平台正好这段时间业务服务器有问题触发了客户端软件的重连流程才将这个内存泄漏的问题暴露出来。 在公司内部测试基本没问题的软件拿到客户的机器上拿到各式各样的运行环境中可能会出现这样那样的问题比如复杂组网环境中的网络连通问题、软件运行异常等。公司内部的测试及运行环境毕竟是有限的很多潜在的问题可能很难暴露出来。 8、最后 该问题实例中的问题可能并不是很难但整个问题的排查方法和思路以及不同场景下的不同表现现象的启示都很有参考价值。所以本文详细记录了整个问题的排查过程以供大家借鉴或参考。