什么可能“中断调试器”在Visual Studio（也许std :: string？） [英] What could possibly "break the debugger" in Visual Studio (maybe std::string?)

问题描述

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

Consider setting a breakpoint on the following line, and stepping into it using the Visual Studio debugger (in a fully-cleaned and rebuilt debug build):

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

原来，此步骤将带您到此功能：

It turns out this step in will take you to this function:

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

事实证明，当你再多走几步，在 parse（）调用之后的最后一行，一切都在新构造的 URI 对象中有效，具体为：

And it turns out that when you take a few steps more and pause on the final line after the parse() call, all is well in the newly constructed URI object, specifically:

• 已正确解析;


• 可以展开 this c $ c>指针以查看正确分配的成员变量（例如，将its_host，_path和_scheme成员分别设置为somewhere.com，/ test / path和http）; li>在此阶段的指针指向一个合法的内存（例如0x002AEE20）位置，在那个位置，我可以看到我有信心是URI对象 std :: string 变量，一个 int ）。



• it has been parsed correctly;
• one can expand the this pointer to see correctly assigned member variables (e.g. its_host, _path and _scheme members are set to "somewhere.com", "/test/path" and "http" respectively);
• the this pointer at this stage points to a legitimate memory (e.g. 0x002AEE20) location, and at that location one can see what I am confident is the URI object (a set of std::string variables, and one int as it happens).

但是，一个步骤之后，一个返回到原始代码行，突然：

However, after a single step more, one returns to the original code line, and suddenly:

• 在Autos或Watch调试器窗口中展开 testUri 对象会导致 std :: string 无法读取的成员（有读取字符的字符的错误），但...


• 构造的对象所在的内存保持不变，并且...


• 确认 testUri 的地址指向未更改的内存

• expanding the testUri object in the "Autos" or "Watch" debugger windows leads to std::string members that cannot be read (there are "errors reading characters of string"), and yet...
• the memory where the constructed object resides remains unchanged, and...
• the address of testUri is confirmed to point to the unchanged memory

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

How can this be? Is the VS debugger broken? What broke it?

这是一系列奇怪的问题，试图在多线程MFC项目中获取POCO库。我不知道MFC或多线程应该对Poco有什么影响，但我经历了一个星期的奇怪 - 通常有 std :: string 对象 - 我想到底部。所有建议跟踪什么是发生非常感谢。

This is the latest in a sequence of weird issues trying to get POCO Libraries up and going in a multi-threaded MFC project. I have no idea if the MFC or the multi-threading should have any impact on Poco, but I have experienced a week of weirdness -- often with std::string objects involved -- and I'd like to get to the bottom of it. All suggestions for tracing what is occurring greatly appreciated. I'm running VS2015 Community if that make a difference.

推荐答案

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

As mentioned in the comments, trying to mix different builds (i.e. both release and debug) within the same project can cause issues like this.

然而，在这种情况下，是不同的编译器的混合 - 建立在看起来是VS2010条件下，而Poco库是在VS2015条件下构建的。

In this case, however, it was the mixing of different compilers -- most of the project was built under what seem to be VS2010 conditions, while the Poco libraries were built under VS2015 conditions.

我不是100％确定更宽的项目正在编译之前，因为它最近从VS2010升级到VS2015，在此过程中， Platform Toolset 设置没有显示在 .vcxproj 文件。我现在（重新）为每个构建配置引入了一个 Platform Toolset ，并将其设置为 v100 Poco与 build_vs100.cmd 脚本。一切似乎都按预期工作。

I'm not 100% sure of the conditions under which the wider project was being compiled before, since it was recently upgraded from VS2010 to VS2015, and in the process, the Platform Toolset setting did not show up in the .vcxproj file. I have now (re-)introduced a Platform Toolset for each build configuration and set it to v100, and also rebuilt Poco with the build_vs100.cmd script. Everything seems to work as expected now.

我跟踪这是因为观察到应用程序正在编译与 / MDd （多线程调试DLL代码生成），但链接器尝试链接到d版本的Poco库，而不是mdd版本。当编译器上线时，链接器会正确链接mdd版本。

The way I tracked this down was to observe that the application was being compiled with /MDd (multi-threaded debug DLL code generation), yet the linker was attempting to link to the "d" versions of the Poco libraries, not the "mdd" versions. When the compilers were brought into line, the linker correctly linked the "mdd" versions as one would expect.

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

Since all library linking in Poco is intended to be automatic (see the #pragma directives in PocoFoundation.h), the incorrect library selection was due to changed preprocessor definitions (POCO_STATIC was not being defined). I did not bother to check why this was.

这篇关于什么可能“中断调试器”在Visual Studio（也许std :: string？）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！