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

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-11-24 09:04:38

alansa_at_[hidden] wrote:
<snip>
> 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.

As might the on-demand allocations by the CRT.

> However I do remember had one experiment where i filled up a vector with 
> a load of stuff and hey presto, no leak.

Right, because its memory is automatically freed in the same context as 
it is allocated.

> 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?

It is your executable, of course.

> 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.

Right.  However, if part of Boost.Thread is compiled inline in your 
executable, any (de)allocations that part performs will be done using 
your executable's heap.

> And I never ever get a crash, just a leak.

Really I don't see a whole lot of point trying to work out exactly 
what's going wrong here.  Given that there are well-known problems with 
statically linking to the CRT while dynamically linking to C++ 
libraries, which can be fixed by dynamically linking to the CRT, why not 
just do that?

Ben.