CODEWITHSUNDEEP
c++visual-studiodebuggingpoco-libraries
omatai
omatai

Reputation: 3728

What could possibly "break the debugger" in Visual Studio (maybe std::string?)

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));
}

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:

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

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

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.

Upvotes: 0

Views: 167

Answers (1)

omatai
omatai

Reputation: 3728

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.

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.

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.

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.

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.

Upvotes: 1

Related Questions