[Boost-users] Re: Memory leak reported using threads library

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2004-11-25 07:11:34

Roland Schwarz <roland.schwarz <at> chello.at> writes:

> 
> I inadvertently replied to the wrong posting.
> 
> John Maddock wrote:
> 
> > That's your problem: there must be one single rtl shared both by your 
> > code and the Boost.Threads dll: and that means using the dynamic C 
> > runtime. 
> 
> That surprises me somewhat.
> Explicitely:
> 
> mydll depending on dynamic CRT.
> 
> myapp depending on static CRT and depending on mydll.
> 
> You think this is not possible?
> Just tried it. Found no obvious problem. Are there hidden traps?
> 

This is an old-time problem MSVC programmers keep
stumbling upon. As John points out, the only safe alternative
is that every executable (EXE or DLL) in an app uses the
same *dynamic* version of the CRT: all of them debug dynamic
or all of them release dynamic. Every other option will
casue you trouble.

The biggest source of incompatibilites has to do with memory
allocation. MSVC malloc/free (and new/delete) implementation
uses an internal heap allocated at CRT initialization time.
Every instance of the CRT has its own internal heap. Now,
if module (EXE or DLL) A allocates some memory and
module B tries to free it through another copy of the CRT,
an instant crash is guranteed, because the memory
does not belong in B's internal heap. Try it: select static
CRT for every module, allocate some memory in your EXE
and let some DLL try to free that memory.

When everybody selects dynamic CRT, there's only
one copy of it across the app, and you'll find no problem.

If you restrict yourself to C-style calls where no
ownership of memory is transferred, then everything is OK,
but this is hardly possible in Boost libraries where C++ objects
are passed around.

In the case where the boundary between the EXE and the
DLL is crossed only by object *pointers*, the problem still
remains if a module tries to delete a pointer not allocated
within its CRT, but in this case there's a simple workaround:
if the class being pointed to has a virtual destructor,
then it is safe to delete a pointer everywhere, since the
destruction code, being virtual, will get executed within
the module where the object was created (as the vtable
will be pointing to that module).

Hope this sheds some light on the issue.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo