Re: [Boost-users] Boost.Thread memory leak reported
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha Berns Sent: Wednesday, August 24, 2005 8:48 PM To: Boost Subject: [Boost-users] Boost.Thread memory leak reported
Detected memory leaks! Dumping objects -> {146} normal block at 0x00227008, 24 bytes long. Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 00 00 00 {145} normal block at 0x00223928, 8 bytes long. Data: < p" > 08 70 22 00 01 CD CD CD Object dump complete.
Hi Elisha, Could you come up with a small test case that demonstrates the problem?
I got exactly the same error. Here is how I did it: I created a project of a MFC Application inside VC7.1 . The wizards creates the usual document/view classes. Inside the document class I placed, like Elisha, a mutex. Inside the OnNewDocument() function I put the code from Elisha: BOOL CMFCTestDoc::OnNewDocument() { if (!CDocument::OnNewDocument()) return FALSE; // TODO: add reinitialization code here // (SDI documents will reuse this document) boost::thread indexer( boost::bind(&CMFCTestDoc::run, this)); boost::mutex::scoped_lock lock(m_orphan_annotation_mutex); indexer.join(); return TRUE; } I'm using MFC in a Shared DLL and Multithreaded Debug DLL runtime libs. I can send the project files to anyone that is interessted. By the way, if I use Purify to track down the leaks, it cannot find them. Regards, Christian On 8/25/05, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha Berns Sent: Wednesday, August 24, 2005 8:48 PM To: Boost Subject: [Boost-users] Boost.Thread memory leak reported
Detected memory leaks! Dumping objects -> {146} normal block at 0x00227008, 24 bytes long. Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 00 00 00 {145} normal block at 0x00223928, 8 bytes long. Data: < p" > 08 70 22 00 01 CD CD CD Object dump complete.
Hi Elisha,
Could you come up with a small test case that demonstrates the problem?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I got exactly the same error. Here is how I did it:
I created a project of a MFC Application inside VC7.1 . The wizards creates the usual document/view classes. Inside the document class I placed, like Elisha, a mutex. Inside the OnNewDocument() function I put the code from Elisha:
BOOL CMFCTestDoc::OnNewDocument() { if (!CDocument::OnNewDocument()) return FALSE;
// TODO: add reinitialization code here // (SDI documents will reuse this document)
boost::thread indexer( boost::bind(&CMFCTestDoc::run, this));
boost::mutex::scoped_lock lock(m_orphan_annotation_mutex);
indexer.join();
return TRUE; }
I'm using MFC in a Shared DLL and Multithreaded Debug DLL runtime
Right, Those are the same project settings I'm using. The only difference is that my code is in a non-MFC class. I tested it with the VLD memory leak detector found on CodeProject and it also reports zero leaks. Elisha libs.
I can send the project files to anyone that is interessted.
By the way, if I use Purify to track down the leaks, it cannot find
them.
Regards, Christian
On 8/25/05, Sohail Somani <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Elisha
Sent: Wednesday, August 24, 2005 8:48 PM To: Boost Subject: [Boost-users] Boost.Thread memory leak reported
Detected memory leaks! Dumping objects -> {146} normal block at 0x00227008, 24 bytes long. Data: < | > 08 7C 04 00 FF FF FF FF 00 00 00 00 00 00 00 00 {145} normal block at 0x00223928, 8 bytes long. Data: < p" > 08 70 22 00 01 CD CD CD Object dump complete.
Hi Elisha,
Could you come up with a small test case that demonstrates the
Berns problem?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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
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
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
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. Regards, Christian
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.
participants (1)
-
Christian Henning -
Elisha Berns -
Peter Dimov -
Sohail Somani