Hi Elisha, does the number 146 in {} change if you restart the application? If not, then try put the line : _CrtSetBreakAlloc(146); in your code before you create the thread. VC7.1 will break when the 146th object is created. If I do that I end up here, in the line where the "new" is: [mutex.inl] inline void* new_critical_section() { try { LPCRITICAL_SECTION critical_section = new CRITICAL_SECTION; if (critical_section == 0) throw boost::thread_resource_error(); InitializeCriticalSection(critical_section); return critical_section; } catch(...) { throw boost::thread_resource_error(); } } Do you have the same behavior? I will do some tests to see if the critical section is also deleted correctly. Christian

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

Christian Henning wrote:

Hi guys, I think I could figure out what these two memory leaks produce.

Basically it happens when allocating memory for "threadmon_mutex" in file tss_hooks.cpp[29]. This variable is never deallocated (deleted). Which leads us two the second leaks. Since threadmon_mutex is of type boost::mutex, the first member is a pointer to a critical section. Also this pointer points to an allocated chunk of memory on the heap and since it's owner is never deleted, it's also never deleted.

I think that causes the problem and should be easily to remvove. Basically the counterpart to void init_threadmon_mutex(void) is missing.

I'm just wondering why Purify doesn't show anything.

Because Purify is smart and doesn't report false leaks.