Are memory leaks reported by Boost.Test Microsoft Memory Leak Detection Enabling spurious or real?
I've just added some code (ready for Inverse Gaussian distribution in preparation for Boost.Math). When I added one new section of kosher-looking C++ code, I started to see memory leaks reported: For example: *** No errors detected Detected memory leaks! Dumping objects -> {3485} normal block at 0x003611B0, 42 bytes long. Data: <class boost::mat> 63 6C 61 73 73 20 62 6F 6F 73 74 3A 3A 6D 61 74 {3484} normal block at 0x003635A0, 8 bytes long. Data: < 6 46 > B0 11 36 00 F8 34 36 00 ... But no filename is given as promised by http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=VS.80%29.aspx So I'm puzzled if/where I should look for a problem. (occurs for both debug and release) Or is this spurious? Should I just suppress the warnings? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
This looks like the type of memory leak that occurs after a call to: typeid(MyType).name(); see this article for a full explanation: http://support.microsoft.com/kb/140670/en-gb Personally speaking I find these leaks obscure real leaks in my code. You can solve this by disabling heap checking, then allocating typeid(MyType).name() then re-enabling heap checking. Jonathan. On 28/10/2010 13:06, Paul A. Bristow wrote:
I've just added some code (ready for Inverse Gaussian distribution in preparation for Boost.Math).
When I added one new section of kosher-looking C++ code, I started to see memory leaks reported:
For example:
*** No errors detected Detected memory leaks! Dumping objects -> {3485} normal block at 0x003611B0, 42 bytes long. Data:<class boost::mat> 63 6C 61 73 73 20 62 6F 6F 73 74 3A 3A 6D 61 74 {3484} normal block at 0x003635A0, 8 bytes long. Data:< 6 46> B0 11 36 00 F8 34 36 00 ...
But no filename is given as promised by http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=VS.80%29.aspx
So I'm puzzled if/where I should look for a problem.
(occurs for both debug and release)
Or is this spurious? Should I just suppress the warnings?
Paul
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Paul A. Bristow
But no filename is given as promised by http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=VS.80%29.aspx
You need special macro defined in your code. Read the page for details.
So I'm puzzled if/where I should look for a problem.
(occurs for both debug and release)
Or is this spurious? Should I just suppress the warnings?
Most probably it's real (unless you are using some third party software, which has leaks you can ignore. Gennadiy
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Gennadiy Rozental Sent: Thursday, October 28, 2010 2:03 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Are memory leaks reported by Boost.Test Microsoft Memory Leak Detection Enabling spurious or real?
Paul A. Bristow
writes: But no filename is given as promised by http://msdn.microsoft.com/en-us/library/e5ewb1h3%28v=VS.80%29.aspx
You need special macro defined in your code. Read the page for details.
I've added this at the head of the test file.cpp
#define _CRTDBG_MAP_ALLOC
#include
Or is this spurious? Should I just suppress the warnings?
Most probably it's real (unless you are using some third party software, which has leaks you can ignore).
Pure Boost! (and no messing with malloc or pointers (by me)). Paul PS Curiously, if I add the #define _CRTDBG_MAP_ALLOC etc to an example file (not using Boost.Test), that calls the function that caused the reports to start, I don't get any leak reports (using debug mode). PPS typeid(MyType).name(); http://support.microsoft.com/kb/140670/en-gb Which sounds plausible, but it is way out of date, so does it still apply to VC10? I'm not using typeid myself (but I suspect it is used elsewhere in Boost.Math - if not Boost.Test!). --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
participants (3)
-
Gennadiy Rozental -
Jonathan Oulds -
Paul A. Bristow