Memory leak reported using threads library
Dear all, Downloading and using the 1.32 version was probably not such a good idea... 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. I guess it wouldn't be difficult to resolve this one, on process exit it can be deallocated. 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. Wkr, me
IIRC there was an intentional leak in the threads library that is
cleaned up on exit (the debug crt isn't perfect.. it can report global
std::strings as leaks also), maybe this is it?
On Mon, 22 Nov 2004 22:21:03 +0000 (UTC), gast128
Dear all,
Downloading and using the 1.32 version was probably not such a good idea...
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.
I guess it wouldn't be difficult to resolve this one, on process exit it can be deallocated. 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.
Wkr, me
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Cory Nelson http://www.int64.org
Cory Nelson
IIRC there was an intentional leak in the threads library that is cleaned up on exit (the debug crt isn't perfect.. it can report global std::strings as leaks also), maybe this is it?
Are you sure? I couldn't find the corresponding 'delete'. Setting a breakpoint on 'on_process_exit', I gets fired, but this code dosen't clean it up either. As far as the m$ debug crt concerns, the reporting is correct. However one has to take great care in when the _CrtDumpMemoryLeaks function gets called. For example MFC has a global object _AFX_DEBUG_STATE, which in its destructor calls this function. The trick is then to postpone this call to the end, for example by loading the mfc71d.dll as first (and then it gets unloaded as last). Here in our production code global std::strings don't get reported. Wkr, me
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
Roland Schwarz
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
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
can 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
participants (3)
-
Cory Nelson -
gast128 -
Roland Schwarz