当前位置: 首页 > >

free一个合法的地址也会导致crash?

发布时间:

场景描述

在Windows*台上使用C++开发了一个服务,其中组合了各种各样的第三方组件,一般以lib/dll和头文件的形式使用。有这样一种场景,如下图所示,应用程序申请了一段内存ptr, 但在调用lib.dll的函数接口中其调用了free(ptr)。一般来说我们也尽量避免在一个组件中申请内存,而在另一个组件中释放,这里恰巧是一个bug导致了跨组件的内存申请和释放。

那么请各位读者思考一下,这样会有问题吗?如果你是一个老司机,也许已经发现,在某些情况下会在调用free(ptr)的时候导致程序crash。


为何crash

熟悉Windows编程的读者应该了解如下图所示,操作内存的方式有如下几种:
(1) 直接VirtualAlloc之类的函数,可以申请一段虚拟地址空间,并且使用这段空间
(2) 直接使用HeapCreate, HeapAlloc之类的函数,来创建堆,并且使用堆。也就是说Windows的进程可以有多个堆,一般进程启动有一个默认的堆。而Heap的底层实际是采用VirtualXXX之类的函数进行控制的。
(3) Local或者Global Memory API,主要是从进程默认堆中申请或者释放内存
(4) CRT库中调用malloc去申请内存,而这里是本文的重点。其底层实际是使用的Windows Heap API实现。
(5) 最后一个就是Memory Mapped File。

在第一个章节我们描述的内存申请释放场景,是采用了CRT库的方式。CRT库的链接方式有四种:


/MT 静态链接进你的组件。也就是说当你采用这个编译选项的时候CRT的的代码也被链接进了你的DLL或者Exe。/MD 这种链接方式,实际上在应用程序运行的时候,才会加载对应的CRT库的DLL。/MTd/MDd主要针对Debug Build,链接的方式和上面两种一一对应,不再赘述。

那么我们再来看下第一章节的场景,他们分别采用如下编译方式:APP.exe采用/MD编译,也就是会在运行的时候,装载CRT库的DLL,调用的malloc也是在这个DLL里面。lib.dll 采用的/MT编译,那么在调用free的时候会调用链接在lib.dll中的CRT库中的free

留给读者一点时间,这样的场景调用会有什么问题呢?


这个问题涉及到的是CRT库malloc的实现问题,之前我们已经了解到了CRT库采用的是HeapXXX 相关的API。那么CRT库是采用HeapCreate创建了新的堆,还是使用进程默认堆呢?


微软的CRT库是开源的,lib.dll采用的是VS2010编译的,CRT库会使用HeapCreate创建新的堆。而APP.exe采用的是VS2015编译的 (因为App.exe和lib.dll不是同一个团队做的,有可能编译器版本不同),其对应版本的CRT库是使用的系统默认堆。那么APP.exe中malloc的内存是系统默认堆里申请并且管理的,而在lib.dll中free却会从自己创建的堆中去寻找,寻找不到对应的分配的地址,从而导致了程序Crash。


那么这个章节留两个问题给大家,如果APP.exe和lib.dll继续使用原先的链接CRT库的方式:


    APP.exe和lib.dll均采用VS2010编译,第一章节的场景还会Crash吗?APP.exe和lib.dll均采用VS2015编译,第一章节的场景还会Crash吗?

如果这两个问题能够回答正确,说明你已经理解这个问题啦。如果没有答出来,欢迎我们一起讨论。


建议

在编程的道路上,到处都是坑,有新的挖的也有前人留下的坑。那么就尽量用自己的经验去防御性编程,减少可能存在的坑:


    在一个应用程序中,所有自己可控的组件均采用/MD的方式去链接CRT库尽量不要在一个模块中申请内存,在另外一个模块中释放。比如你实现一个动态链接库(DLL),提供一个接口FuncA申请并返回内存地址,那么最好提供一个接口FreeXX去释放FuncA申请的内存。


最后是个人微信公众号,文章CSDN和微信公众号都会发,欢迎一起讨论。



友情链接: