Debug library crashes when linked with Release build

[Dave Johansen]

I just converted a solution from Visual Studio 2003 to Visual Studio
2005 and the Debug mode seems to be running just fine, but the Release
mode crashes on the following code:

std::ifstream in("myfile.txt" );
float value;
in >value; //The crash happens here in the getloc() function

The above code is actually from a library built in Debug mode that is
linked into the Release build of the executable. Does anyone have any
ideas of what could be causing this? Or how I could fix it (other than
switching the library to release mode, because that's currently not an
option)?

Thanks,
Dave

[Mark Salsbery [MVP]]

Re: Debug library crashes when linked with Release build

The library is a static library?

There can be big problems linking to two versions of the same library.
Each will have its own set of internal variables, each will have its own
heap, one of them probably isn't even initialized, etc.

Mark


--
Mark Salsbery
Microsoft MVP - Visual C++


"Dave Johansen" <davejohansen@g mail.comwrote in message
news:cfde0337-3f99-4f24-b4a7-141458420ebf@8g 2000hse.googleg roups.com...

I just converted a solution from Visual Studio 2003 to Visual Studio
2005 and the Debug mode seems to be running just fine, but the Release
mode crashes on the following code:
>
std::ifstream in("myfile.txt" );
float value;
in >value; //The crash happens here in the getloc() function
>
The above code is actually from a library built in Debug mode that is
linked into the Release build of the executable. Does anyone have any
ideas of what could be causing this? Or how I could fix it (other than
switching the library to release mode, because that's currently not an
option)?
>
Thanks,
Dave

[steeve.mercier@gmail.com]

Re: Debug library crashes when linked with Release build

On Apr 10, 10:53 am, Dave Johansen <davejohan...@g mail.comwrote:

On Apr 9, 12:44 pm, Dave Johansen <davejohan...@g mail.comwrote:
>
>
>

On Apr 8, 3:45 pm, Dave Johansen <davejohan...@g mail.comwrote:

>

On Apr 8, 3:33 pm, "Ben Voigt [C++ MVP]" <r...@nospam.no spamwrote:

>

Dave Johansen wrote:
On Apr 8, 2:52 am, Ismo Salonen <Ismo.Salo...@c odeit.fiwrote:
>--snip--

>

>It does no more work because some classes have different sizes in
>debug vs. release mode. In debug mode ( _DEBUG defined) the classes
>contains extra fields for runtime checks. When release mode is
>compiled the classes memory footprint is smaller thanm in debug mode
>and debug mode writes memory locaations it should not ( those, now
>nonexistent debug variables).

>

>This worked in 2003 because it did not have such sophisticated debug
>helpers ( e.g iterator debugging). Using such combination
>(debug&release ) in same executable was never supported, it worked by
>pure luck (or if you *really* knew what to do) .

>

>br
>ismo

>

I think that the claim that it "worked by pure luck" is not correct.
It worked because there's no standard compliant reason why it
shouldn't. I understand that the debug mode now supports more advanced

>

You can't hide behind the standard here, because you defined _DEBUG, which
begins with underscore+capi tal letter and as such is reserved for the
compiler or library implementation. When you start messing with reserved
identifiers you are completely implementation-dependent.

>

Beyond that, the standard requires that the one-definition rule be
respected. Frequently this requires having the same macro definitions
across the whole project, including static libraries, because although ODR
doesn't apply to macros, macros control the definitions of other things.

>

checks and such, but there's no reason that this couldn't have been
done without maintain existing features (an additional preprocessor
directive that allowed the additional checks to be disable would have
solved the problem). I understand why things broke and the change
makes sense from a certain perspective, but claiming that it "has to
be that way" just isn't true.

>

I believe there are other macros (why would you need a new directive???)
that control the extra checks.

>

Dave

>

I agree 100% and I understand why things are the way they are, but I
still believe that they are this way by choice and not by some
external, uncontrollable force. The versions of Visual Studio prior to
2005 stand as a testament to this, because what I am trying to do was
allowed and functioned properly before Visual Studio 2005. I also
agree 100% that mixing debug and release libraries isn't recommended,
but that doesn't mean that it should be impossible.
Dave

>

I did a little more digging and it turns out that the iterator
debugging stuff can be disabled (which fixes the problem I was having)
by defining _HAS_ITERATOR_D EBUGGING as 0. You can read more about it
here:http://msdn2.microsoft.com/en-us/lib...39(VS.80).aspx

>

Thanks everyone for all of the help and advice,
Dave

>
I would like to make a correction and state that turning off the
iterator debugging didn't fix all of the problems that I was having
with mixing debug and release builds, so I guess that this is just a
semi-undocumented breaking change for Visual Studio 2005.
>
Dave

Hi,

I went through the same frustration when I moved our company software
from VS 2003 to VS 2005. I also tried to fix with the
_HAS_ITERATOR_D EBUGGING=0, but with partial success only. Is there a
way to "emulate" the VS2003 behavior with regards to mixing debug and
release CRT? From the thread below, I understand that the only clean
way out of my problems would be to revise all APIs and use only basic
data types in them...

Steve