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 <pbristow <at> hetp.u-net.com> 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.
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 <pbristow <at> hetp.u-net.com> 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 <stdlib.h> #include <crtdbg.h> which promises "With _CRTDBG_MAP_ALLOC defined, the display also shows you the file where the leaked memory was allocated. The number in parentheses following the file name (20, in this example) is the line number within the file." But there is no filename or line number :-( (but the line {3485} normal block at 0x004811B0, 42 bytes long. Data: <class boost::mat> 63 6C 61 73 73 20 62 6F 6F 73 74 3A 3A 6D 61 74 looks as though it is the start of boost::math - of which (since this IS Boost.Math) there are zillion references;-) And these look like floating point template parameters... {2536} normal block at 0x00483530, 12 bytes long. Data: <long double > 6C 6F 6E 67 20 64 6F 75 62 6C 65 00 {1587} normal block at 0x004834C0, 7 bytes long. Data: <double > 64 6F 75 62 6C 65 00 {637} normal block at 0x004831E8, 6 bytes long. Data: <float > 66 6C 6F 61 74 00 So I'm still puzzled if/where I should look for a problem.
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