Home Dashboard Directory Help

VS2010 Debugger: watching std::string with _ITERATOR_DEBUG_LEVEL = 0 does not work by Brian Kramer


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 640602
Opened: 1/31/2011 12:05:50 PM
Access Restriction: Public
User(s) can reproduce this bug


std::string's representation may not be identical across binaries. When using _ITERATOR_DEBUG_LEVEL = 0, you may or may not get the expected result when watching instances of std::string.

For more information on the symtoms of the problem, see:

Sign in to post a comment.
Posted by Microsoft on 7/21/2011 at 3:50 PM

Thanks for reporting this bug. We've fixed it, and the fix will be available in VC11.

Summarizing the problem and solution: the STL, including basic_string, can be compiled in 5 different modes (release IDL=0/1, debug IDL=0/1/2, with release IDL=0 and debug IDL=2 being the defaults). We have 5 static LIBs, so /MT and /MTd always work. But we have only 2 DLLs. Therefore, in VC10, I removed any mention of basic_string from the DLL's exports. Unfortunately, I missed something. The DLL import LIBs, msvcprt[d].lib, are special. A source file, locale0_implib.cpp, is compiled and then injected into the import LIB as an ordinary object file, so it's essentially statically linked to user code even when compiling as /MD or /MDd. And basic_string was dragged into locale0_implib.cpp. This triggers an ODR violation for users with non-default IDL settings, which manifested itself here as a debugger visualization problem.

The solution was to make locale0_implib.cpp as minimal as possible, and avoid dragging in basic_string. This had the additional benefit of cutting msvcprt[d].lib's size nearly in half, from about 1 MB to 500 KB.

Since other people will probably see this and ask, I should state for the record: because this fix required invasive surgery, breaking binary compatibility, it is impossible for us to release this as a hotfix for VC10.

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Brian Kramer on 2/3/2011 at 6:46 PM
Thanks Jeffery.

Since IDL=1 has the same effect as IDL=0 (insofar as we are concerned), and it has the same layout as IDL=2, we are using this instead. (i.e. we are not blocked by this bug.)

Note that I added another note in the repro--it illustrates the arbitrariness of the PDB generation by the compiler.
Posted by Microsoft on 2/3/2011 at 3:03 PM
Hi Brian,

Thanks for reporting this issue; we are able to reproduce this issue.

Further research shows that when _ITERATOR_DEBUG_LEVEL = 0 is defined, the std::string will choose a different base class in the derived chain. However, the PDB generated by the VC compiler is still emitting the type information the same as "_ITERATOR_DEBUG_LEVEL = 0" is not defined. Since debugger reads the PDB to parse the std::string type layout, wrong PDB causes wrong interpretation in the watch window.

We have forwarded this bug to the VC++ compiler team. I will let you know when they fixed this issue.

Jeffrey Tan
Visual Studio Debugger Team
Posted by Microsoft on 1/31/2011 at 6:30 PM
Thanks for your feedback.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 1/31/2011 at 12:59 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.