您的位置:首页 > 编程语言 > C语言/C++

C++中的Dll内存问题

2017-03-31 17:34 197 查看
这两天在做一个数据结构,使用树结构,两层,第一层的数据元素为第二层的n个分支

遇到问题如下:

1:使用vector在debug下运行正常,在release下源码运行正常封装后运行失败

请教了多人,觉得可能是vector的使用问题,因为我将第一层封装为dll,而在第二层使用源文件,导致在第二层申请的内存在第一层释放时出现问题。

2:为了避免vector的内存释放问题,自己写了链表,结果出现了同样的问题,

最终将第一层和第二层都封装在一个dll内,此时运行通过(同一个heap句柄)

总结:

1:申请一个元素用new int,delete 申请多个元素用new int
,n>1; delete []  否则会出现释放内存上的问题,要配套使用,就将这个归结为一个编码规范吧,没有做进一步测试, 

2:dll内部申请内存的代码要全部封装进去,以避免系统认为内存在外部申请出现释放报错的问题,要彻彻底底的遵循一个原则,谁申请谁释放,尤其在封装为dll时必须要如此。

3:生成dll插件程序和调用程序均设置为 MultiThread DLL debug 模式,运行元程序运行正常,原设置为MultiThread debug,vector的调用是没问题的,问题在于设置引起的heap释放问题。

在一次面试中突然被问到这个问题,当时还真不明白,回来在网上找到了说法:

 因为malloc/free,new/delete都是调用HeapAlloc/HeapFree来实现来实现内存分配是释放的。

查看Windows的API可以看到,这两个函数都需要一个Heap的HANDLE做为参数。CRT库采用了全局变量来保存这个HANDLE。如果是CRT静态链接,CRT库的代码会链接到各个DLL中去,也包括这个全局变量。

也就是说,每个使用CRT静态链接的dll中都有一个自己的全局堆句柄,他们自己都在这个句柄上使用内存。当释放dll中分配的内存时由于使用的堆句柄不一致于是出错。

当使用CRT动态链接时,有于每个dll都是去调用CRT库的dll函数来分配和释放内存的,使用的是同一个句柄,所以就没有这个问题。

一般是哪里申请哪里释放,谁申请的内存由谁释放,这是封装的基本原则。   

  dll内部(对外隐藏)的内存分配,显然要dll自己处理啦。当然也可以由调用它的程序释放, 但不推荐,高内聚,且不安全 

   dll外部的由外部程序分配后传进dll,使用完后,可以由外部程序释放,也可以调用dll内部函数帮助释放。

  如果导出的是类,则可以在类中定义自我是释放的Release导出函数:   

  void   release()   

  {   

        delete   this;   

  }  

COM的内存释放就是采用这样的方法 

 总结:静态链接的dll中申请的内存,必须由内部释放;动态链接的dll中申请的内存,可以由外部释放。

一个模块一个堆,一个线程一个栈。

dll里malloc的内存,在exe里free会出错。

CRT(C运行时期库)不是使用进程缺省的堆来实现malloc(new中调用malloc)的,而是使用一个全局句柄HANDLE _crtheap来分配内存的。这个_crtheap是在XXXCRTStartUp(CRT提供的进口点函数)中创建的。  

  由于CRT静态连接,则楼主的DLL里有也有一个CRT,因此也有一个_crtheap。而在dll中的new使用dll中的_crtheap句柄分配堆,在exe中的delete使用exe中的_crtheap释放堆,当然失败!

解决办法:

1。在DLL中输出一个函数给EXE调用,专门用来释放由DLL分配的内存;

2。用GlobalAlloc()代替new,用GlobalFree()代替delete;

3。使用单一的堆,分配内存使用HeapAlloc(GetProcessHeap(),0,size),释放内存使用HeapFree(GetProcessHeap(),0,p);

4。把dll和exe的Settings的C/C++选项卡的Code   Generation的Use   Run-time   liberary改成Debug   Multithreaded   DLL,在Release版本中改成Multithreaded   DLL;这样使用一个CRT了——MSVCRT.DLL。
 

以上是在网上找到的资料,今天做过详细测试,结果如下:

测试1:使用malloc/free组合来分配和释放内存,DLL中使用malloc分配,exe中使用free释放。

我建的是Win32 DLL工程, C/C++->Code generation 设置是 Multithread DLL debug, 但是exe工程设置是MultiThread debug,所以不管怎么样,总是会抛异常. 这就间接证明了上述的描述是正确的, 若我修改exe工程设置是 MultiThread DLL debug, 那么malloc/free组合就能很好的工作起来了。

测试2:使用HeapAlloc/HeapFree组合来分配和释放内存,DLL中使用HeapAlloc分配,exe中释放。

exe的配置还是MultiThread Debug,DLL中HeapAlloc(GetProcessheap(), HEAP_ZERO_MEMORY, 1024)分配,exe中HeapFree(GetProcessHeap(), 0, p)释放,,则还是无法正常运行,还是抛异常。若exe中设置成MultiThread DLL debug就正常运行了。

测试3:还是使用HeapAlloc/HeapFree来进行,但是DLL中导出一个方法来释放DLL中分配的内存。

若exe配置是MultiThread Debug,无法正常运行,抛异常。若修改成MultiThread DLL debug正常运行。

 

所以得到的结论如下:

不管是使用malloc/free组合还是HeapAlloc/HeapFree组合,exe工程均需要设置成MultiThread DLL debug才能正常运行起来的,CSDN上的那个讨论在这儿貌似是有出入的,因为调用GetProcessHeap()得到的是当前堆(其实就跟new一样了),依然借还不在同一个地方,所以错的。而且DLL的设置不能随意修改。所以若有涉及到这种问题的,最好的办法还是在哪个模块分配的就在哪个模块释放最好,要不然反倒会引来更多的麻烦
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: