VC6.0中std::string析构函数崩溃问题分析

Dear 丶 2023-08-17 15:34 113阅读 0赞

### VC6.0中std::string析构函数崩溃问题分析 ###

*  一，问题描述
 *  二，std::string源码分析(VC6.0)
 *  三，问题分析与解决

# 一，问题描述 #

今天程序停止运行时出现了崩溃，分析dump文件查看堆栈如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70]  
     可以看到程序是在std::string析构函数中执行free操作时崩溃的，顺着堆栈往上看，发现是由于std::set容器导致的，查看代码，只有一个变量：g\_reportAccSet，该容器存储的是std::string类型，填充代码如下：  
![在这里插入图片描述][20190926185720574.png]  
     m\_pConfig就是一个配置文件操作类，VEC\_CLIENTBP域是在主程序中赋值的。由于g\_reportAccSet是一个全局变量，当dll从主程序中释放时，会调用内部元素的析构函数，也就是std::string的析构，而堆栈分析也恰好是挂在std::string的析构函数中。  
     由此推测std::string的拷贝构造函数是浅拷贝，导致主程序堆空间中申请的内存在dll中被释放而引起的崩溃（我们的程序都是MT），下面我们分析VC6.0中的std::string源码。

# 二，std::string源码分析(VC6.0) #

STL到目前经历了四个稳定版本，分别是C++98，C++11，C++14，C++17，虽然各个编译器使用的STL厂商不完全一致，但是基本实现都差不多。这四个版本中区别最大的就是C++98和C++11（中间C++98的补丁版忽略不计，像vs2008,vs2010用的就是c++98的补丁版，vc7，vc8，vc9，，，）.  
![在这里插入图片描述][20190926190201588.png]  
     打开vc6.0的安装目录的Include文件夹，我本地是C:\\Program Files (x86)\\Microsoft Visual Studio\\VC98\\Include，找到XSTRING文件，这里面就是basic\_string的实现（basic\_string是模板类，std::string和std::wstring就是basis\_string的不同具体类型模板类，所以basic\_string=std::string），使用notepad++打开：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 1]  
     可以看到basic\_string的拷贝构造函数中，使用本地的allocator来存储一份被拷贝源的allocator副本（allocator就是basic\_string中管理内存的类，它的实现在XMEMORY文件中，感兴趣的可以自己去看），也就是说std::string的拷贝构造只是一个浅拷贝，源对象和目的对象共用一份内存。由于是浅拷贝，所以说basci\_string使用了copy\_on\_write机制，也就是通过引用技术来实现资源的释放，而引用计数值在它的成员函数\_Ptr中：\_Ptr\[-1\]。

数组下标设为-1，是在内存分配时多分配一个ch来实现的，然后将分配的地址+1赋值给\_Ptr，那么Ptr\[-1\]就是分配的首地址所指向的值。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 2]  
     再来看析构函数~basic\_string()，析构中主要又调用了\_Tidy（true）函数，我们直接看它的实现：  
![在这里插入图片描述][20190926190326636.png]  
当引用计数为0，或者引用计数达到了\_FROZEN值时，则释放这一块内存。其中\_FROZEN定义为：  
![在这里插入图片描述][20190926190405103.png]  
     将它定义为255的原因是因为\_Ptr是char\*（或wchar\*），每一个下标指定元素都是char型（或wchar）,char的范围为0-255，所以限制最多只能经过255次拷贝，避免越界。  
     由此可以确定vc98中的std::string是通过浅拷贝来实现的，cplusplus官网上也证实了这一点：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 3]

# 三，问题分析与解决 #

VEC\_CLIENTBP域的填充的数据源是在主程序中的std::vector<std::string> m\_vReportAcct变量，而该变量是类Connect的成员变量。当停止运行时，首先delete了Connect对象，那么它的成员变量m\_vReportAcct也会被清空，导致std::string的引用计数变为0。之后再释放dll，全局变量g\_reportAccSet开始清空，由于std::string的引用计数此时为0，会调用free来释放内存。Exe主程序和dll模块不在同一个堆空间，exe申请的堆内存不能再dll中释放，此时会导致崩溃。  
     最简单的解决方案就是在g\_reportAccSet填充时，不要直接拷贝m\_vReportAcct中的std::string对象，而改为c\_str()构造，代码改写如下：

![在这里插入图片描述][20190926191241808.png]  
**注意：  
1， 在使用vc6.0编译器的过程中，我发现很多必崩的代码却在极大多数情况下可以正常运行，也许跑了好几年都没问题，但不确定什么时候会挂。对于这种场景，我们应该从代码根源上去解决，而不是因为没有出现崩溃而觉得代码是没问题的。  
2， VC6.0的std::string是浅拷贝，但是vc7及之后的版本中，std::string都是深拷贝，也就不存在上述问题。**

参考文献：http://www.cplusplus.com/reference/string/basic\_string/basic\_string/

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70]: /images/20230810/9ff8790da73a494397754137b35d4261.png
[20190926185720574.png]: /images/20230810/105e8d8e8ebb498fb910b3f0f5364934.png
[20190926190201588.png]: /images/20230810/f12cf53a336f4b67a7c61cb4f412706d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 1]: /images/20230810/d4b92a971ec8482c8e861da334b56d6f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 2]: /images/20230810/9deec1df105c49dda67b6dd14bd3791a.png
[20190926190326636.png]: /images/20230810/b7dfcbe5527d4245a54faf7bec94ae64.png
[20190926190405103.png]: /images/20230810/c28f48e3a9b44c1d805c7bd435e84dec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JhamlhbnhpYW9mZW5kdWk_size_16_color_FFFFFF_t_70 3]: /images/20230810/2651775440cb485680b984d219ccf9c5.png
[20190926191241808.png]: /images/20230810/129919081b6a4cbabb7d90c80e62946d.png