trivial use of threads AND crt mem check exits with memory leak
I always get the memory leak trace at the end of this post when I run a trivial application that uses boost threads (source below). I'm compiling with multi-threaded debug dll (/MDd). I'm building a console app. It's on win32/xpsp2 with vc8. I haven't found any thread shutdown code to run in the boost threads documentation. Have I missed another compiler or linker option? I'd really like to use leak detection so I know I'm not losing memory in my own code. Thanks, Tom Titchener #define WIN32_LEAN_AND_MEAN #include <crtdbg.h> #include <stdio.h> #include <iostream> #include <boost/thread.hpp> using namespace std; void CRTSetup(void) { _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); _CrtSetDbgFlag(_CRTDBG_DELAY_FREE_MEM_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); _CrtSetDbgFlag(_CRTDBG_CHECK_ALWAYS_DF | _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG)); _CrtSetReportMode( _CRT_WARN, _CRTDBG_MODE_FILE ); _CrtSetReportFile( _CRT_WARN, _CRTDBG_FILE_STDOUT ); _CrtSetReportMode( _CRT_ERROR, _CRTDBG_MODE_FILE ); _CrtSetReportFile( _CRT_ERROR, _CRTDBG_FILE_STDOUT ); _CrtSetReportMode( _CRT_ASSERT, _CRTDBG_MODE_FILE ); _CrtSetReportFile( _CRT_ASSERT, _CRTDBG_FILE_STDOUT ); } void dummy(void) { cerr << "dummy" << endl; } void main() { CRTSetup(); boost::thread t(dummy); t.join(); } dummy Detected memory leaks! Dumping objects -> {145} normal block at 0x003575D8, 24 bytes long. Data: < < > 00 3C 15 00 FF FF FF FF 00 00 00 00 00 00 00 00 {144} normal block at 0x003575A0, 8 bytes long. Data: < u5 > D8 75 35 00 01 CD CD CD Object dump complete.
Tom Titchener wrote:
I always get the memory leak trace at the end of this post when I run a trivial application that uses boost threads (source below).
Could it be that you are running 1.33 version? This issue already is fixed in upcoming 1.34. Nevertheless I'll try your code with 1.34 to be sure, but I haven't access to a windows box right at the moment. Roland
I always get the memory leak trace at the end of this post when I run a trivial application that uses boost threads (source below). I can confirm that this happens with boost 1_33_1 and dissapears with
Hi Tom the current version from CVS (named 1_35 there, don't know anything about 1_34 thought). I am running vc8 and/or vc7.1. with 1_33_1 the leak looks like this: --------- Block 98 at 0x008B9C40: 24 bytes ---------- Call Stack: f:\vs70builds\6030\vc\crtbld\crt\src\newop.cpp (12): operator new c:\devlibs\boost_1_33_1\libs\thread\src\mutex.inl (55): `anonymous namespace'::new_critical_section c:\devlibs\boost_1_33_1\libs\thread\src\mutex.cpp (48): boost::mutex::mutex c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\devlibs\boost_1_33_1\libs\thread\src\once.cpp (174): boost::call_once c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\devlibs\boost_1_33_1\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\6030\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E6608B (File and line number not available): GetModuleFileNameA Data: 18 4A 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 .J...... ........ 00 00 00 00 00 00 00 00 ........ ........ ---------- Block 97 at 0x008B9BF8: 8 bytes ---------- Call Stack: f:\vs70builds\6030\vc\crtbld\crt\src\newop.cpp (12): operator new c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\devlibs\boost_1_33_1\libs\thread\src\once.cpp (174): boost::call_once c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\devlibs\boost_1_33_1\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\6030\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E6608B (File and line number not available): GetModuleFileNameA Data: 40 9C 8B 00 01 CD CD CD @....... ........ --------- Cheers Amanjit
I always get the memory leak trace at the end of this post when I run a trivial application that uses boost threads (source below). I can confirm that this happens with boost 1_33_1 and dissapears with
Amanjit - Yes, I'm running 1.33. I'll upgrade and post if it's still a problem. But it sounds like it won't be! Thanks, TT -----Original Message----- From: Amanjit Gill [mailto:amanjit.gill@gmx.de] Sent: Saturday, December 23, 2006 1:24 PM To: boost@lists.boost.org Cc: Tom Titchener Subject: Re: [boost] trivial use of threads AND crt mem check exits with memory leak Hi Tom the current version from CVS (named 1_35 there, don't know anything about 1_34 thought). I am running vc8 and/or vc7.1. with 1_33_1 the leak looks like this: --------- Block 98 at 0x008B9C40: 24 bytes ---------- Call Stack: f:\vs70builds\6030\vc\crtbld\crt\src\newop.cpp (12): operator new c:\devlibs\boost_1_33_1\libs\thread\src\mutex.inl (55): `anonymous namespace'::new_critical_section c:\devlibs\boost_1_33_1\libs\thread\src\mutex.cpp (48): boost::mutex::mutex c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\devlibs\boost_1_33_1\libs\thread\src\once.cpp (174): boost::call_once c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\devlibs\boost_1_33_1\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\6030\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E6608B (File and line number not available): GetModuleFileNameA Data: 18 4A 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 .J...... ........ 00 00 00 00 00 00 00 00 ........ ........ ---------- Block 97 at 0x008B9BF8: 8 bytes ---------- Call Stack: f:\vs70builds\6030\vc\crtbld\crt\src\newop.cpp (12): operator new c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex c:\devlibs\boost_1_33_1\libs\thread\src\once.cpp (174): boost::call_once c:\devlibs\boost_1_33_1\libs\thread\src\tss_hooks.cpp (150): on_thread_exit c:\devlibs\boost_1_33_1\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\6030\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E6608B (File and line number not available): GetModuleFileNameA Data: 40 9C 8B 00 01 CD CD CD @....... ........ --------- Cheers Amanjit
participants (3)
-
Amanjit Gill -
Roland Schwarz -
Tom Titchener