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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2004-11-22 18:21:03

gast128 wrote:

>Downloading and using the 1.32 version was probably not such a good idea... 
>
>  
>
Why do you think so? I am facing a similar situation in that I will need 
to rewrite parts of my code
that is using ublas. Altough I think it is worth the effort. Remember: 
boost (as I understand it) is not
intended as beeing API stable! I only expect parts beeing stable that 
are already in the standard.
Others constantly face improvement. And this is the place where it is to 
happen. Do I get something wrong?

>Now I get a mem-leak reported by the debug crt of VC 7.1. The report is 
>located in 'init_threadmon_mutex' where a global object is allocated but never 
>deleted. Before we start a discussion of what is a memory leak or not, in our 
>production code we do not accept any leak reported by VC. The past has learned 
>us that if you accept one leak, programmers/colleaques start to ignore them 
>and in the end you have 200 leaks, instead of this one.
>
Granted. However as I have found out using the MSVC memory leak 
detection can be tricky at times.
One usually must be careful not to generate false alarms. Which 
detection system do you use?
(Sidebar: wouldn't a boost::memory_debug lib be desirable?)
E.g. when inside MFC you cannot be sure when the detection code actually 
triggers, since it is called
from within a destructor of a global object.
If you are also allocating dynamic memory from a global constructor the 
leak is reported depending
on the order of constructor calls. (Don't know why MS deactivated the 
CRT detection when using
MFC....)

>I guess it wouldn't be difficult to resolve this one, on process exit it can 
>be deallocated. 
>
I guess you are refering to the (documented) leak in tss.cpp, aren't you?

    // Intentional memory "leak"
    // This is the only way to ensure the mutex in the global data
    // structure is available when cleanup handlers are run, since the
    // execution order of cleanup handlers is unspecified on any platform
    // with regards to C++ destructor ordering rules.
    tss_data = temp.release();

Getting rid of it however is not as trivial as it might seem at first 
glance, since
the TLS code is able to clean up even when used from non boost::threads.
There is also a yet to be discussed issue what should happen when the main
thread exits but a user thread is still running. (When you have a look 
at pthreads,
this is quite legal.) And what is "process exit" when speaking about 
global ctors/dtors?

>And yes I am aware of the (phoenix) singleton discussions in 
>Alexandrescu/Meyers, but really this kind of reinit of singletons after atexit 
>calls won't happen too much.
>  
>
Sorry I am not aware of this discussions, could you give me a short 
overview?
I suspect the problem is similar to when using the CRT together with the 
native CreateThread
API. In this case you are also introducing an unavoidable memory leak, 
where the
CRT's TLS doesn't get deallocated. (Or occasionally will be reallocated.)

However I already have proposed a solution to the above problem (at 
least for the windows version)
which is based on reference counting. This however requires a 
(significant) bit of rewrite
which I think Michael Glassford did not want to introduce so short 
before release.
At least the leak is intentional and well understood.

But I agree it _is_ ugly and it should be removed for any reason, no matter.

Roland