Re: Problem in std::string, or unsupported mix of options.
On 12 Feb, 22:05, "Stephan T. Lavavej [MSFT]" <s...@microsoft.com>
wrote:
This bug, which is thoroughly fixed in VC10, is different from
the Swap Bug, which was fixed in VC9 RTM.
Compiling with /MDd /D_HAS_ITERATOR_DEBUGGING=0
/D_SECURE_SCL=0 won't help here (I've verified that it still
crashes).
I was going to answer Igor that in the actual code, we had
_SECURE_SCL set to 0 as well. I'd dropped it in the example,
since changing it didn't change anything.
The underlying problem is that before VC10, std::string was
separately compiled into msvcp90d.dll, which was built with
HID=1 SCL=1. This has a really hard time talking to user code
built with different options. VC8 and VC9 had what I refer to
as "broken library magic" that makes this work in most cases.
Unfortunately, most isn't all, and there were bugs in this in
all of VC8 RTM, VC8 SP1, VC9 RTM, and VC9 SP1. Previously,
the only bugs in VC9 SP1 that I were aware of involved
ostringstream str(), but this bug operates on the same
principle (operator+() returns a string by value, and that's
separately compiled into the DLL - you really don't want to
know all of the gory details).
I suspected something along these lines. I've seen quite a few
problems with g++ due to different libraries being compiled with
or without _GLIBCXX_DEBUG (which is more or less the equivalent
of _HAS_ITERATOR_DEBUGGING), and when tracking the problem in
the debugger, I found the debugger showing msvcp90d.dll rather
than my executable. And while I'm not really too sure how the
debugger decides what to display here (this was in the stack
window), the addresses in the disassembled code were in a
different area than those in my own code, which also suggests a
different DLL.
You should upgrade to VC10 as soon as possible (we've got a
"go live" Release Candidate that was just released).
I'll inform my management, but they make the decisions, not I.
You
should certainly be running VC9 SP1 now, in order to avoid the
HID/SCL bugs we've already fixed.
We're still using VC8, but just out of curiousity, how do you
determine the patch level of the compiler? If I just invoke cl
at the command line, I get:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version
14.00.50727.762 for 80x86
Which doesn't even tell *me* it's VC8. (I assume it's VC8
because that's what my boss told me it was. Also, the path is
through c:\Program Files\Microsoft Visual Studio 8.) And I
don't even get to see this (or the command line) when I invoke
it from Visual Studios.
As a workaround, my experiments indicate that avoiding op+()
will do the trick - you can instead say string ret; ret +=
stuff; ret += more stuff; return ret; and that will create the
string on your side instead of in the DLL.
OK. I'll give it a try.
It still surprises me, because we have a significant code base
compiled like this, using the same options, and the problem has
never appeared for others. Most of the other code is in DLL's,
which plug in to other software (Excel, etc.). Could that make
a difference?
--
James Kanze