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

旧城等待， 2022-03-21 12:38 244阅读 0赞

### C++ delete指针后依然可以访问的问题 ###

*  一，第一个dump分析
 *  二，第二个DUMP分析
 *  三，VC6.0和VS2015下delete指针验证
 *  四，结论

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

# 一，第一个dump分析 #

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

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

# 二，第二个DUMP分析 #

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

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

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

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

# 四，结论 #

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

[20190201111425444.]: /images/20220321/e8b89beb474e4a049b830d1163d1c7b6.png
[20190201170347662.]: /images/20220321/1570306e2c674249bd3873b9c6cd663f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70]: /images/20220321/02e5d9c622124323a5c5dc2f9cd378ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 1]: /images/20220321/f054480d07064a178d876d73be82832c.png
[20190201112855514.]: /images/20220321/e96fdbe14701406c9f586b6e84b32307.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 2]: /images/20220321/83da206fe0054ca28d17736af0a59cbd.png
[20190201113003917.]: /images/20220321/69f3ce1343ab4565b07d62caa42daedb.png
[20190201113015429.]: /images/20220321/ad967293fa374ba08c9be5a2c197f3db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 3]: /images/20220321/6009196dfb34420fbad8b759a8475505.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 4]: /images/20220321/4add3b9247694b36bcd87ccbe60a543d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 5]: /images/20220321/efe5d04555d342e6a8a63b7f4eeac7ab.png