alansa@ati-uk.com 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.