Re: ctor and dtor calling different system libraries?

From:

"Doug Harrison [MVP]" <dsh@mvps.org>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 16 May 2006 12:00:39 -0500

Message-ID:

<8s0k625shljifvvla1nh65rcu07hifi2b1@4ax.com>

On 16 May 2006 07:58:14 -0700, "Victor V. Terber" <victor@terber.de> wrote:

While debugging an MSVC++.NET2003 app it turned out that sometimes the
constructor of a system class (in that case stringstream) was called
from non-debug library msvcp71.dll while the destructor of the class
was called using debug library msvcp71d.dll. Because of that the
application crashed as a destructor assertion fired.

This might happen reproducibly even if the class instance was
immediately destructed after construction without any use in between.

This behaviour was observable here and there. To be more precise: It
was not predictable if it would trigger with the class declaration on a
given source position, but if it triggered, then it triggered
completely reproducibly.

I know that it is generally a bad idea to mix debug and non-debug
system libraries. In that case it was unintentional. Because of the
complex dependencies of the application it wasn't so easy to avoid it.
But still - I naively thought that the linker would prevent such
strange behaviour.

Is there any known or even legitimate case when it might happen that
constructor and destructor of a class are picked up from different
system DLLs? Or is this only an ordinary bug?

I don't know if this is the case here, but it's possible for an object to
be created in one module (EXE or DLL) and destroyed in another, such that
the ctor and dtor that are run reside in different modules. (VC does go to
some lengths to prevent this, particularly for classes that are marked
__declspec(dllexport|dllimport), but it isn't always successful.) If those
modules are linked to different CRTs, then you can end up using different
CRT code to create and destroy the object. The linker would not detect this
problem, because it's a runtime phenomenon, and the OS loader doesn't try
to detect it.

--
Doug Harrison
Visual C++ MVP