Debug Assertion Failed! Expression: _pFirstBlock == pHead

最新推荐文章于 2021-05-17 09:51:07 发布

转载最新推荐文章于 2021-05-17 09:51:07 发布 · 683 阅读

Debug 同时被 2 个专栏收录

17 篇文章

订阅专栏

8 篇文章

订阅专栏

本文解析了在Visual Studio上开发C++程序时遇到的vector析构函数异常问题，探讨了DebugAssertionFailed错误的原因，并提供了可能的解决方案，包括正确配置运行库参数。

转自：http://blog.youkuaiyun.com/giantpoplar/article/details/47295877

最近在VS上开发C++程序时遇到了这个错误：

Debug Assertion Failed! Expression:_pFirstBlock == pHead

如图：

点击Abort之后，查看调用栈，发现异常在函数return时被时产生，进一步看是vector的析构函数被调用时产生，以前没开发过C++项目，没什么经验，这个错误让我很困惑，第一，我电脑上并没有f盘；第二，我并没有调用析构函数；第三，这到底是个什么错误。

第一个问题，大概是一个虚拟的分区吧，第二个问题，我的vector变量是在一个函数体内部声明使用的，函数返回的时候，自动变量生命期结束，C++应该会调用vector的析构函数来释放这个对象，就在这个时候发生了异常。

关于第三个问题，我在网上查了一些资料，发现大概有以下几种情况

①混淆了 Debug和Release情况，有时Debug和Release所需要的库是不一样的，如果你只导入了Release的链接库，而没有导入Debug的链接库，而编译运行时又选择了Debug模式，就可能出现这种问题，这时要把Debug的链接库添加进去可能就会解决。

②可能是在一个多线程模块了运行了一个单线程库，内存在dll一侧被分配，在使用一侧被释放，可能导致一个内存管理器在分配内存，另一个内存管理器在释放同一片内存区域，导致错误。

C++的STL是单线程的，我在函数内部使用了vector，这个函数在一个多线程的环境里，大概就是这个错误产生的原因。

一个解决方式就是设置运行库为/MDd

工程上右键-》属性-》C/C++=》所有选项

关于运行库几个参数

多线程(/MT)
多线程调试(/MTd)
多线程 DLL (/MD)
多线程调试 DLL (/MDd)

名字后带d的是debug库,名字含D是动态链接，含T是静态链接

C 运行时库                                         库文件
MultiThread(static link)MT                     libcmt.lib
Debug multiThread(static link)MTd           libcmtd.lib
MultiThread(dynamic link)MD                 msvert.lib
Debug multiThread(dynamic link) MDd      msvertd.lib

另：使用std::string时产生这个错误的解决方法

http://stackoverflow.com/questions/18882760/debug-assertion-failed-expression-pfirstblock-phead

补充说明：（来自上面那篇文章）

Runtime Library config

If the MSVC Runtime library is set to Multi-threaded Debug DLL (/MDd), then this is no problem (it works fine).
If the MSVC Runtime library is set to Multi-threaded Debug (/MTd), then it will throw this error, which can be fixed with the following instructions.

Memory allocated in Memory Manager A and freed in Memory Manager B ...

The problem is that memory is allocated on the .dll side, then that same memory is freed on the application side. This means that memory manager A is allocating memory, and memory manager B is releasing that same memory, which generates errors.

The solution is to make sure that all memory passed back is not allocated in the DLL. In other words, the memory is always allocated on the application side, and freed on the application side.

Of course, the DLL can allocate/free memory internally - but it can't allocate memory that is later freed by the application.