MS Visual Studio Windows 中的发布模式与调试模式

Question

我正在使用 MSVS 9 (VS 2008)。我的应用程序以及共享库（dll）（我用来链接我的应用程序）也是 c++ 环境。现在观察以下情况：

1. 当共享库/dll 以调试模式构建并且我的应用程序也以调试模式构建时 结果：应用程序成功执行

2. 当共享库/dll 以发布模式构建并且我的应用程序也以发布模式构建时 结果：应用程序成功执行

3. 当共享库/dll 以 Release 模式构建并且我的应用程序也以 Debug 模式构建时 结果：应用程序在没有从调用堆栈中加载任何符号的情况下崩溃。

   调用栈：

   ntdll.dll!76e94684()
   [下面的帧可能不正确和/或丢失，没有为 ntdll.dll 加载符号]

   ntdll.dll!76e7d55f()
   ntdll.dll!76e5fa18()
   ntdll.dll!76e2b3c8()

当我尝试在我的应用程序中使用以下 SetName() 和 GetName() 定义时会出现此问题。

    using namespace std;
    void main()
    { 
        Schema * schemaExp = new Schema();
        schemaExp -> SetName("ExpSchema");
        string srctable;
        srctable=schemaExp->GetName();
        cout <<"\nConnection EXPORT using the target table:" << srctable.c_str()  << endl;
        delete schemaExp;
    }

架构类定义：

    using namespace std;
    class Schema
    {
       public:
       TELAPI_EXPORT void   SetName(char *name); 
       TELAPI_EXPORT string     GetName(); 
      protected: 
       string tableName; 
    };
    void Schema::SetName(char *name)
    { 
       string str(name);
       tableName = str; 
    }
    string Schema::GetName()
    {
      return tableName;
    }

注意：以上只是我的应用程序的一部分，我的应用程序仅在 #3 中崩溃，并且在上面的 #1 和 #2 情况下工作正常

请帮我解决这个问题。非常感谢任何形式的帮助。

提前致谢。

Answer 1

当共享库/dll 在发布模式下构建并且我的应用程序也在调试模式下构建时结果：应用程序在没有从调用堆栈加载任何符号的情况下崩溃。

这是因为这不是受支持的配置。默认情况下，Debug 和 Release 目标链接到不同版本的 CRT，它们（除其他外）使用不同的内存分配策略并且彼此不兼容。

这只是更一般规则的扩展，即您不应该混合链接到不同版本 CRT 的库。所有项目都需要匹配。正如您已经看到的那样，当他们这样做时，一切正常。

有一些解决方法，但要做到正确还需要做很多工作。本质上，您要确保所有内存分配都在单个 DLL 中隔离，这样就不会跨越模块边界。您需要从 DLL 中导出特定函数来分配和释放内存，以确保分配内存的堆管理器与销毁它的堆管理器相同。当您使用 new 和 delete 运算符时，您不能依赖这种情况。坦率地说，在这种情况下，我看不出所有这些努力如何为您带来任何有用的东西。

请注意，这与是否启用优化无关（默认情况下，它们适用于发布版本，而不是在调试版本中）。该设置与链接的 CRT 版本正交。碰巧“调试”和“发布”目标暗示了多个选项。您可以为一个项目打开优化并为另一个项目关闭它们，这应该可以工作，只要您确保它们都链接到相同版本的 CRT。但同样，我真的看不出这样做的意义……如果你想为一个启用优化，为什么要为另一个抑制它们？

相关：Mixing debug and release library/binary - bad practice?

Answer 2

这不应该是一个崩溃，只是现在，通常你会在 Windows 内存管理器中得到一个调试中断，以警告你你的程序正在破坏堆。 Windows 中调试堆的一项功能，可在 Vista 及更高版本中使用。在“输出”窗口中查找消息。

启用符号服务器也很重要，这样堆栈跟踪变得可读且准确。使用工具 + 选项、调试、符号执行此操作，然后勾选预定义的 msdl.microsoft.com 服务器名称前面的复选框。为符号存储选择一个好的临时目录。当您再次启动程序时，它会在开始运行之前滚动一段时间，下载符号文件。这只会发生一次。您现在应该得到一个高度可读的堆栈跟踪，现在也可以返回到您的 main() 方法。

您通常会发现，跨模块边界公开 C++ 类是一件棘手的事情。不止一件事情可能出错，这里的一种故障模式是 Schema 类对象在 DLL 边界的两侧大小不同。这是因为 Debug 构建设置，_HAS_ITERATOR_DEBUGGING #define 很重要。它在 Debug 版本中默认打开，在 Release 版本中关闭。不错的调试功能，但他们实现它的唯一方法是向标准 C++ 库类添加字段。这使得调试版本中的 std::string 更大。这使您的 Scheme 课程更大。您现在正在绕过这个问题，故障模式是 DLL 的 Debug 版本和 EXE 的 Release 版本。 Scheme 类构造函数会在初始化字符串时破坏堆，因为分配给对象的空间不够大。

另一种故障模式是您的进程中有两个版本的 CRT，即应用中的调试版本和 DLL 中的发布版本。他们不会使用相同的堆来分配。当您在一个中分配并在另一个中释放时，哪个会出错。您的 GetName() 方法返回的字符串存在该问题，它是在 DLL 中的 GetName() 方法中创建的，并且在您的 EXE 中的方法调用后将被销毁。通过错误的分配器。在您再次对堆执行某些操作（例如删除您的 Scheme 对象）之前，不会检测到由此导致的堆损坏。如果您不使用 /MD 构建代码，您还将调用此故障模式。顺便说一句，这个问题在 VS2012 中得到了解决，现在所有分配都是从默认进程堆中进行的。

使用一致的构建设置对于模块边界的生存至关重要。设置您的 VS 解决方案以便始终始终为 DLL 使用正确的构建不是问题，只需确保 DLL 项目与 EXE 项目位于相同的解决方案中。

但请注意，您将来很可能会遇到麻烦，DLL 有自己的诀窍，并且有朝一日可能会被使用另一个版本的编译器构建的应用程序使用。卡布姆然后。设计您的 DLL 接口以使这种情况永远发生是很有可能的，但您将不得不放弃公开 C++ 对象。 C 风格的接口是后备，COM 将其提升为对象模型的方式也是一个好方法。当然，这非常严格，只有在您不能保证 EXE 和 DLL 始终同时构建和部署时才考虑这一点。