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

From: alansa_at_[hidden]
Date: 2004-11-24 07:49:41

Wkr wrote:
 
>>I am working now on a project, which solution consists of 73 vc-projects
(more 
>>than 2500 files) and it does not leak memory in its main loop, thanks to
the 
>>debug crt of m$. We have overwritten the new and delete operator like m$
in 
>>MFC does so we get accurate memory leak reporting. If you take this
business 
>>serious one can not allow any memory leak reported by the debug crt.

Of course, malloc and new are not the only ways to consume memory. Virtual
Memory, Memory Mapped files, COM memory allocation functions etc etc. And
the leak can be in library code over which we have much less control (other
than to not use it) and therefore weaker support for leak finding and
detection.
 
It turns out we don't have a leak anywhere in our code. If we don't use
boost::thread then no leak, if we use boost::thread and use CRT dynamically
rather then statically then no leak.
 
 
Ben wrote:

>>Multithreaded configurations of MSVCRT allocates some per-thread memory 
>>as needed, e.g. for the object that localtime returns a pointer to.  To 
>>ensure that this memory is freed at thread exit, you must either use a 
>>DLL configuration of the CRT or ensure that all threads that call into 
>>it are started using the _beginthread or _beginthreadex function.  The 
>>Boost.Thread DLL is not (and cannot be) linked to the same CRT that is 
>>statically linked into your executable, so neither of these conditions 
>>is satisfied.
 
>>If I remember correctly, any memory allocated in your executable cannot 
>>be deallocated in the Boost.Thread DLL, or vice versa, since they have 
>>separate heaps.  I would expect an attempt to do so to result in a 
>>crash, but it might in some cases be silently ignored, resulting in a
leak.
 
 
I have considered this and it still may be the answer or lead to an answer.
 
Yes indeed they have separate heaps
 
It may explain why the leak is steeper depending on what the function does.
However I do remember had one experiment where i filled up a vector with a
load of stuff and hey presto, no leak.
 
if I have a function that allocates and deallocates memory on the heap and I
use it as a thread using boost::thread, then when memory deallocations are
performed by that thread is it the boost dll that is doing the deallocation
or is it my exe?
 
One would assume it was my exe since the deallocation code is in my exe.
Surely there is no code in the threads dll to deallocate my memory.
 
And I never ever get a crash, just a leak.