Visual Studio 中什么可能“破坏调试器”（可能是 std::string？）答案

【问题标题】：What could possibly "break the debugger" in Visual Studio (maybe std::string?)Visual Studio 中什么可能“破坏调试器”（可能是 std::string？）
【发布时间】：2016-03-01 05:23:56
【问题描述】：

考虑在以下行设置断点，并使用 Visual Studio 调试器（在完全清理和重建的调试版本中）单步执行：

Poco::URI testUri( "http://somewhere.com/test/path" );

原来这一步会带你进入这个功能：

URI::URI(const char* uri):
    _port(0)
{
    parse(std::string(uri));
}

事实证明，当您在parse() 调用之后多走几步并在最后一行暂停时，新构造的URI 对象中一切正常，具体而言：

已正确解析；
可以展开this 指针以查看正确分配的成员变量（例如，其_host、_path 和_scheme 成员分别设置为“somewhere.com”、“/test/path”和“http”）；
此阶段的this 指针指向合法内存（例如0x002AEE20）位置，在该位置可以看到我确信的是URI 对象（一组std::string 变量和一个@987654328 @碰巧）。

然而，多走一步，又回到原来的代码行，突然：

在“Autos”或“Watch”调试器窗口中扩展 testUri 对象会导致无法读取 std::string 成员（存在“读取字符串字符时出错”），但...
构造对象所在的内存保持不变，并且...
确认testUri的地址指向不变的内存

这怎么可能？ VS调试器坏了吗？是什么弄坏了它？

这是试图让 POCO 库启动并进入多线程 MFC 项目的一系列奇怪问题中的最新一个。我不知道 MFC 或多线程是否会对 Poco 产生任何影响，但我经历了一周的怪异——通常涉及std::string 对象——我想深入了解它.非常感谢所有有关跟踪正在发生的事情的建议。如果有影响，我正在运行 VS2015 社区。p>

【问题讨论】：

你有可以发的小repro吗？您可能还需要发布您正在使用的特定 Poco 库构建的下载位置以及您正在使用的构建选项。
也许某些东西——你的应用程序或库——是在发布模式下编译的？优化和缺少调试信息会导致调试器显示奇怪的东西。例如，您的对象可能全部或部分驻留在寄存器中，并且在内存中没有实际表示。
感谢您的提示...我正在检查。我可以报告的是 Poco 库应该根据各种编译器开关自动选择和链接。我有一个多线程调试版本......这应该意味着 PocoFoundationmtd.lib 是链接的。但是......如果我重命名 PocoFoundationmtd.lib 以使其无法找到，那么我的应用程序仍然可以构建。这听起来像是一个非常可靠的线索:-)

标签： c++ visual-studio debugging poco-libraries

【解决方案1】：

如 cmets 中所述，尝试在同一个项目中混合不同的构建（即发布和调试）可能会导致这样的问题。

然而，在这种情况下，它是不同编译器的混合——大部分项目是在似乎是 VS2010 的条件下构建的，而 Poco 库是在 VS2015 的条件下构建的。

我不能 100% 确定之前编译更广泛项目的条件，因为它最近从 VS2010 升级到 VS2015，并且在此过程中，Platform Toolset 设置没有出现在 @ 987654322@ 文件。我现在（重新）为每个构建配置引入了 Platform Toolset 并将其设置为 v100，并且还使用 build_vs100.cmd 脚本重建了 Poco。现在一切似乎都按预期工作了。

我跟踪这个的方法是观察应用程序正在使用/MDd（多线程调试 DLL 代码生成）编译，但链接器试图链接到 Poco 库的“d”版本，不是“mdd”版本。当编译器上线后，链接器就如预期的那样正确链接了“mdd”版本。

由于 Poco 中的所有库链接都是自动的（请参阅 PocoFoundation.h 中的 #pragma 指令），因此不正确的库选择是由于更改了预处理器定义（POCO_STATIC 未定义）。我没有费心去检查为什么会这样。

【讨论】：