(Windbg调试三)C++ delete指针后依然可以访问的问题

     这两天在定位一个BUG:我们的程序运行过程中,点击停止运行,程序偶现无响应和崩溃,此时无查询操作(因为当并发查询的时候,有出现其他bug,特意确定没有查询)。最终发现是delete指针导致的问题,写篇文章备份记录下此次定位问题的经过,以及总结。
     在此次分析问题的过程中,总共捕捉到了2个Dump文件(注意,环境现场和我们自己的机子都是64位环境,需要在C:\Windows\SysWOW64里找到taskmgr.exe,即32位的任务管理器,再进行转储操作),下载两个版本程序对应的集成包,取出pdb和map文件。

一,第一个dump分析

     配置好Windbg环境,打开dump,首先查看EXCEPTION CODE为C000005,看到这就推测是地址问题,比如野指针访问,数组越界,无效地址等等。
在这里插入图片描述
     然后再看具体的堆栈信息:
在这里插入图片描述
     可以看到是在停止运行时,卸载各个组件时崩溃的,再往上看也看不出有效信息了,而Windbg也没有给出有可能会导致崩溃的地址信息建议。
     下面是基于目前dump分析自己的两种推测。
推测一:
     由于考虑到FreeLibrary时,如果组件中的线程没有终止会导致程序异常,经过检验代码,在FreeLibrary之前,都已经退出各个组件中的线程了,同时也可以通过~*kb命令,查看各个线程的堆栈如下:
在这里插入图片描述
     篇幅有限,图就不截全了,总共有6个线程,一个主线程,另外五个都是t2sdk相关线程(公司研发中心提供的网络通信库)。所以,这种推测也被推翻。(题外话:我们的程序在加载组件时,有打印日志,但是卸载组件时,却没有打印日志,这一点对于我们查找卸载到哪一个组件时崩溃很有难处,后续需要加上这个日志。)

推测二:
     由于此时程序表现出来的是“无响应”现象,推测是否是主程序中的UI线程(主线程)和其他线程死锁导致的?在Windbg中用~locks命令看出此时堆栈中的锁的情况如下:
在这里插入图片描述
     扫描了500多个锁,此时程序中只有两个锁,第一个锁77d920c0是由1b2c线程所拥有的,通过上面的~*kb命令,可以知道1b2c也就是主线程,ntdll!LdrpLoaderLock中的锁,也是FreeLibrary中实现的锁(此锁用于保护在DllMain做保护,具体可以自己下去了解)第二个锁,是在hq_bjsxsb.dll组件中的hq_bjsxsb!SpecialDeal+46b31位置,执行命令u hq_bjsxsb!SpecialDeal+46b31,查看具体的地址如下所示:
在这里插入图片描述
     通过之前讲过的计算偏移地址的方法,计算出偏移地址为479f0,但是在map文件中找不到任何地址信息。而且这两个锁的LockCount(表示还有多少个线程在等待这个临界区)都是0,也就是说当前没有线程在阻塞等待它们。此路不通。
     从这一个dump文件中还没有定位到具体原因。

二,第二个DUMP分析

     由于目前信息定位不出有问题的代码,那么只能尽可能复现了,运气比较好,我操作了几次,就在同样的环境下复现了,取出dump,分析如下:
在这里插入图片描述
     从这里可以看到最上面的信息,已经定位到hq_bjsxsb.dll中了,但是具体的代码信息没有,我们往下看,WinDbg给我们提示了可能地异常地址,如下所示:
在这里插入图片描述
     由于之前介绍过根据map文件来定位代码具体行号,此处不再重复介绍,我们根据偏移地址,得到代码行号为DealXSB.cpp中的第243行代码,是个析构函数入口:
在这里插入图片描述
     程序为什么会突然崩溃在这里呢,查看g_pDbfSqliteSynImpl变量,发现在UnPrepare函数中,已经进行了Uninit和Release操作,其中,Release函数中进行了delete this操作,但是没有把它赋空,导致这里对已经delete的指针进行二次访问,会造成未定义现象,这也能解释地通为什么第一次出现的时候是程序无响应,而第二次程序直接崩溃。下面我们对deleet的指针仍能够继续访问这一现象继续分析。

三,VC6.0和VS2015下delete指针验证

     想起了之前学习C++基础知识的时候,总是看到书上或者听到其他人说“指针delete后,一定要置空”,当时以为delete一个指针后,这一块区域就已经不存在了,那么再对这个指针进行任何操作,都会导致程序崩溃,可事实呢?为什么上述现象的程序可以运行这么长时期而没有出现崩溃问题呢,为什么上述现象不是必现的?让我们通过代码来验证。
在这里插入图片描述
     这是在VC6.0编译器上编译出的程序,我们可以看到在delete t操作之后,我们仍旧可以访问它的成员函数,输出成员变量(输出一个随机值),并且对该成员变量进行赋值,能输出改变之后的成员变量值。更令人不可思议的在后面,我们再用vs2015编译器做同样的测试。

在这里插入图片描述
     此时程序中断,但是在delete t之后,还是可以调用成员函数,只是当访问成员变量的时候,程序会中断(Debug和Rlease不一样)。
     对这两个编译器,在delete t后对a进行变量监视,发现在VC6.0中,此时变量a的地址还是有效的,但是在vs2015中a的地址却是不可访问的。由此可见,不同编译器对于这种未定义的错误表现不一样,使用不同编译器运行的程序表现也不一样,但是很明显,vs2015的检错能力更强。

四,结论

     delete指针时,编译器到底干了什么呢?在so上查询到同样的问题,有人解答过:
在这里插入图片描述
     delete一个指针时,指针指向的内存区域并不会被清空,因为这样会占用CPU周期,此时它是一个危险的指针,会造成一些未定义的现象。像这样的代码有可能会工作很多年,只会在某个时候崩溃,因为程序中的其他地方发生了一些小的改变导致。这也很好地解释了为什么我们Delete一个指针后要将其置为NULL,是为了保证我们使用的是一个有效的指针,而不是会造成不可预知错误的野指针。
     C ++不会阻止你写入内存中的任意位置。当我们使用new或分配内存时malloc,C ++会在内存中找到一些未使用的空间,将其标记为“已分配”(以便不会意外地再次分发),并为我们提供其地址。当使用delete操作指针, C ++会将其指向的内存区域标记为“未分配”,并可能将其交给任何要求它的人。我们仍然可以写入并从中读取,但此时,其他人可能正在使用它。当我们在内存中写入该位置时,可能会覆盖其他位置分配的某些值,特别是类指针,根据类的结构去分配内存大小时,改变内容,那么内存大小也就改变了,再去操作类对象或类成员就会出错。
     因此,切记,delete指针后,一定要将其置空。

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页