Boost 在重载 new/delete 运算符时会导致无效块
我遇到一个问题，该问题似乎是在 Boost 调用 Boost:runtime:cla::parser::~parser 期间发生的无效内存块。当对该对象调用全局删除时，C++ 断言内存块无效：
dbgdel.cpp(52):
/* verify block type */
_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));
我所做的一项调查显示，问题的发生是由于 new/delete 运算符的全局重载造成的。这些重载被放置在单独的 DLL 中。我发现只有当 DLL 在 RELEASE 中编译而主应用程序在 DEBUG 中编译时才会出现问题。
所以我认为，在重载 new/delete 运算符时，Release/Debug 构建风格可能会在 Boost/CRT 中产生这样的问题。因此，即使在释放模式下，我也尝试使用重载函数显式调用 _malloc_dbg 和 _free_dbg ，但它没有解决无效堆块问题。
知道问题的根本原因是什么吗？这种情况可以解决吗？
我应该强调的是，这个问题是在我开始使用 Boost 时才出现的。在此之前，CRT 从未抱怨过任何无效内存块。那么这可能是 Boost 内部的错误吗？
谢谢！
I have a problem which appears to a be an invalid memory block that happens during a Boost call to Boost:runtime:cla::parser::~parser. When that global delete is called on that object, C++ asserts on the memory block as an invalid:
dbgdel.cpp(52):
/* verify block type */
_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));
An investigation I did revealed that the problem happened because of a global overloading of the new/delete operators. Those overloadings are placed in a separate DLL. I discovered that the problem happens only when that DLL is compiled in RELEASE while the main application is compiled in DEBUG.
So I thought that the Release/Debug build flavors might have created a problem like this in Boost/CRT when overloading new/delete operators. So I then tried to explicitly call to _malloc_dbg and _free_dbg withing the overloading functions even in release mode, but it didn't solve the invalid heap block problem.
Any idea what the root cause of the problem is? is that situation solvable?
I should stress that the problem began only when I started to use Boost. Before that CRT never complained about any invalid memory block. So could it be an internal Boost bug?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，如果一种运行时类型的内存分配被另一种类型释放，则不能将使用发布 CRT 的模块与调试 CRT 混合使用运行时（可能还有其他问题，但内存分配问题似乎是最常见的）。
解决方案是使用针对调试运行时构建的模块，以及针对发布运行时构建的模块 - 不要混合两者。
微软的解释可以在这里找到：http://msdn.microsoft.com/en-我们/library/ms235460.aspx
In general you cannot mix modules that use the release CRT with the debug CRT if memory allocation from one type of runtime is freed by the other runtime (there might be other issues, but memory allocation problems seem to crop up the most).
The solution is to use modules that are built against the debug runtime with each other, and modules that are built against the release runtime with each other - don't mix the two.
Microsoft's explanation can be found here: http://msdn.microsoft.com/en-us/library/ms235460.aspx