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

From: gast128 (gast128_at_[hidden])
Date: 2004-11-23 06:04:55

Roland Schwarz <roland.schwarz <at> chello.at> writes:

> 
> 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
This was a joke: the c++ standard chose for stability and therefore ended up 
in weird constructs. So I think boost follows the path in fixing/refactor 
things, instead of sticking to (incorrect) old versions. This has my 
preference too.

> 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....)
See my other response. I guess we both noticed the same, but this can be 
circumvented by loading the mfc71d.dll as one of the first (e.g. after 
ntdll.dll).

> 
> >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.)
Alexandrescu discusses in his book 'Modern C++ Design' singletons and the 
problem of destroying it (chapter 6). There can be a problem if the singletons 
are called again in exit code. While this can be a problem, I guess in 
practice it will not happen often, or can be circumvented. The m-leak I 
noticed is in tss_hooks.cpp, in fct 'init_threadmon_mutex'.

> 
> But I agree it _is_ ugly and it should be removed for any reason, no matter.
It would be nice. For the moment I will discourage the use of the thread 
libraries because of this issue, although it is a nice library.

Wkr,
me