Home Dashboard Directory Help
Search

VS 2012 RC - std::thread reports memory leak (even on stack) by Greek Fire


Status: 

Closed
 as Fixed Help for as Fixed


9
0
Sign in
to vote
Type: Bug
ID: 757212
Opened: 8/6/2012 8:02:13 AM
Access Restriction: Public
1
Workaround(s)
view
1
User(s) can reproduce this bug

Description

I noticed when using "crtdbg.h" to find memory leaks, the std::thread class, when run, always is reported as having a memory leak - even when on the stack.

I first had an array of thread objects on the heap and noticed the behaviour (even when deleting each individual thread and then the array of pointers). I then placed it on the stack and still had the memory leak reported.
Details
Sign in to post a comment.
Posted by Microsoft on 4/29/2014 at 12:32 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by Inge Eivind Henriksen on 7/21/2013 at 11:13 AM
Intel Inspector XE 2013 still reports std::mutex internal memory leaks with Visual Studio 2012 Update 3 and Windows 7. See http://stackoverflow.com/questions/17775101/intel-inspector-reports-stdmutex-memory-leaks for more information.
Posted by Microsoft on 12/17/2012 at 4:41 PM
Hi,

Thanks for reporting this bug. We've fixed it, and the fix will be available in the next release of our C++ Standard Library implementation.

Specifically, (1) we now clean up the at_thread_exit_mutex, and (2) we mark mutex (and condition_variable) allocations as "CRT blocks", which prevents them from being reported as memory leaks.

Note: Connect doesn't notify me about comments. If you have any further questions, please E-mail me.

Stephan T. Lavavej
Senior Developer - Visual C++ Libraries
stl@microsoft.com
Posted by Andreas Magnusson on 12/6/2012 at 2:36 AM
The leak is the "static _Mtx_t at_thread_exit_mutex" declared in "crt\src\thr\xnotify.c", which is allocated once for the first created std::thread but never freed. So it's not a leak per say, more of a "skipped cleaning up after me"-issue.

This is very undesirable since in our case we're failing our tests if a memory leak is detected. So for us, the first test to create a thread fails...not so good...

So the best fix IMHO would be to add an "atexit(destroy_at_thread_exit_mutex)" but only for debug builds (since we don't want it to take time in a release build when memory leaks aren't reported anyway and the memory will soon be freed anyhow).
Posted by Microsoft on 8/6/2012 at 7:39 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 8/6/2012 at 8:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.
Posted by Inge Eivind Henriksen on 7/22/2013 at 11:25 AM
Rumour is that it's fixed in Visual Studio 2013 http://blogs.msdn.com/b/vcblog/archive/2013/06/28/c-11-14-stl-features-fixes-and-breaking-changes-in-vs-2013.aspx