Christian, I just did a rebuilt with boost 1.33 and it appears you are correct (great work getting at this thing). Here is what I get (much more useful now): WARNING: Visual Leak Detector detected memory leaks! ---------- Block 22086 at 0x06CE6028: 24 bytes ---------- Call Stack: l:\boost\boost_1_33_0\libs\thread\src\mutex.inl (55): `anonymous namespace'::new_critical_section l:\boost\boost_1_33_0\libs\thread\src\mutex.cpp (48): boost::mutex::mutex l:\boost\boost_1_33_0\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex l:\boost\boost_1_33_0\libs\thread\src\once.cpp (174): boost::call_once l:\boost\boost_1_33_0\libs\thread\src\tss_hooks.cpp (150): on_thread_exit l:\boost\boost_1_33_0\libs\thread\src\thread.cpp (117): thread_proxy The thread 'Win32 Thread' (0xfa0) has exited with code 0 (0x0). f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E7D28E (File and line number not available): RegisterWaitForInputIdle Data: 88 AA 07 00 FF FF FF FF 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 ........ ........ ---------- Block 22085 at 0x06CB9C98: 8 bytes ---------- Call Stack: l:\boost\boost_1_33_0\libs\thread\src\tss_hooks.cpp (29): `anonymous namespace'::init_threadmon_mutex l:\boost\boost_1_33_0\libs\thread\src\once.cpp (174): boost::call_once l:\boost\boost_1_33_0\libs\thread\src\tss_hooks.cpp (150): on_thread_exit l:\boost\boost_1_33_0\libs\thread\src\thread.cpp (117): thread_proxy f:\vs70builds\3077\vc\crtbld\crt\src\threadex.c (241): _threadstartex 0x77E7D28E (File and line number not available): RegisterWaitForInputIdle Data: 28 60 CE 06 01 CD CD CD (`...... ........ Visual Leak Detector detected 2 memory leaks.
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Christian Henning Sent: Thursday, August 25, 2005 10:49 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost.Thread memory leak reported
Here are some statistics of void* new_critical_section() and void delete_critical_section(void* mutex)
inside mutex.inl .
Basically I put a breakpoint in both functions. The order of calls until I close my application is like:
(1) new_critical_section -> new at 0x003265e4 (2) new_critical_section -> new at 0x7c227dce (3) delete_critical_section -> delete at 0x00327840 (4) new_critical_section -> new at 0x00327a28 (5) delete_critical_section -> delete at 0x00326650
The first thing is: the number of calls to new_critical_section() is equal to the number of calls to delete_critical_section(). That shouldn't be, I suppose.
Also, the addresses of "new at" and "delete at" are never the same. I suppose that shouldn't be, as well.
Now to my memory leaks output:
Detected memory leaks! Dumping objects -> {196} normal block at 0x00327B08, 24 bytes long. Data: < > 18 AF 14 00 FF FF FF FF 00 00 00 00 00 00 00 00 {195} normal block at 0x00327A28, 8 bytes long. Data: < {2 > 08 7B 32 00 01 CD CD CD Object dump complete.
The second leak ( object no: 195 ) is cleary the memory that was allocated in (4) , see statistics. This memory is never deallocated. So this leak is correct. A mutex, by the way, is 8 bytes on my machine. Also, the three "CD"'s make me little worried. "CD" usually means not initialized.
The first leak is a little more mysterious. Since I don't to who the memory belongs to. I will try to figure this out a little more.
Any ideas someone? Christian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users