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
Wkr wrote: 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.