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

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 757212 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 8/6/2012 8:02:13 AM
Access Restriction Public


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.
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

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
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)