c++ - MFC:为什么会发生这种堆损坏？ (array_s.cpp/afxcoll.inl)

Question

崩溃代码
当调用第三行(“删除”命令)时，以下代码通过堆损坏使我的程序崩溃(程序退出):

1: CStringArray* pStringArray = new CStringArray();
2: ClassInDll::addToStringArray(_T("asdf"), *pStringArray);
3: delete pStringArray;

和

1: ClassInDll::addToStringArray(CString s, CStringArray& sa){
2:  sa.Add(s);
3: }

addToStringArray() 是静态的

请注意，这实际上不是我的代码，而只是我可以重现错误的最低限度。它也可以用 CArray 重现。

我验证了，堆损坏确实 不是 发生之前 该代码行通过gflags /p /enable MyExe.exe /full

堆栈跟踪:


似乎是什么问题



dll依赖
MFC源码


1
CStringArray 创建
MyExe.exe > MFC
...\Microsoft Visual Studio 10.0\VC\atlmfc\src\mfc\array_s.cpp

2
内部数组分配
MyExe.exe > MyDll.dll > MFC
...\Microsoft Visual Studio 10.0\VC\atlmfc\include\afxcoll.inl

3
删除
MyExe.exe > MFC
...\Microsoft Visual Studio 10.0\VC\atlmfc\src\mfc\array_s.cpp


内部数组没有像创建它一样被删除的事实可能是错误的。 (如果我错了请纠正我)

项目设置
我确保在 MyExe.exe 和 MyDll.dll 中使用相同的 MFC 设置，即:





MFC的使用
在共享 DLL 中使用 MFC

使用 ATL
不使用 ATL

字符集
使用 Unicode 字符集


我在 Debug模式下测试，所以没有优化。

问题
MyDll.dll 不是唯一加载的 dll，并且项目依赖项(对第三方 dll 等)有太多的影响，所以我无法将所有这一切作为我的问题的一部分。
所以我的问题归结为:

我的假设是否正确，即 array_s.cpp 和 afxcoll.inl 彼此不兼容？

是什么让一段代码调用array_s.cpp，而另一段调用afxcoll.inl？

还有什么问题？

我已尝试将其关闭并再次打开；)
先感谢您!

更新
PaulMcKenzie 指出，如果我针对不同的 CRT 进行构建，情况就是如此。一个是“多线程调试 DLL”，另一个是“多线程 DLL”。尽管如此，在使两者相等之后，问题仍然存在。 This page声明如果在 Windows 10 上使用 VS 2015 及更高版本并具有项目设置以便使用相同的运行时库，则在运行时使用相同的 CRT 库(因此应该使用相同的堆，对吗？)。
我已经确定，“项目属性 -> C/C++ -> 代码生成”中的每个条目在 exe 和 dll 中完全相同。

Answer 1

在模块(EXE 和 DLL，或不同的 DLL)之间传递 MFC 对象(甚至通过指针)是一项非常棘手的工作。如果您只是在 DLL 中使用类，那么您应该(至少)使用 AFX_MANAGE_STATE DLL 中的宏(见 here)。
但是，如果您的 DLL 定义了它自己的 MFC 派生类(您的 ClassInDll 似乎是这样)，它应该真正构建为 MFC Extension DLL。 .
构建扩展 DLL(甚至使用“常规”MFC DLL)的整个过程过于广泛，我无法在此处为您提供任何可用的源代码。但是，从上面的第二个链接中，以下部分可能与您看到的问题相关(粗斜体是我的):

Memory Management

MFCx0.dll and all MFC extension DLLs loaded into a clientapplication's address space use the same memory allocator, resourceloading, and other MFC global states as if they were in the sameapplication. This is significant because the non-MFC DLL libraries andthe regular MFC DLLs do the exact opposite and have each DLLallocating out of its own memory pool.

If an MFC extension DLL allocates memory, that memory can freelyintermix with any other application-allocated object. Also, if anapplication that dynamically links to MFC fails, the protection of theoperating system maintains the integrity of any other MFC applicationsharing the DLL.

Similarly other global MFC states, like the current executable file toload resources from, are also shared between the client applicationand all MFC extension DLLs as well as MFCx0.dll itself.