
Boost 1.53 Chrono version 2 VC 2008 Win7-64 If I #include <boost/chrono.hpp> and run my program, on program exit the VC debugger reports about 40 memory leaks. I don't have to actually use chrono, just include the header. A little trial-and-error with #include statements tracked this down to boost\chrono\io\duration_units.hpp. It looks like there are a couple of "new" allocations in the constructor for duration_units_default_initializer_t that are never deleted. As a test I added a destructor that did delete[] on them, and that fixed the memory leaks. However, there is some logic with the initialized_ variable in the constructor that leads me to suspect that this is not a viable solution for real code. :-) Can anyone suggest a better solution for this? Or failing that, give me any ideas about what this code is actually doing and/or how I might proceed? There is a good chance that someone will say "that's not a real memory leak, it's allocated once and never deleted, but it goes away when your program exits. Don't worry about it". The problem with that answer is that when you have 40 or 50 memory leaks that are "normal", everyone stops paying any attention to the memory leak report and you start adding (unintentionally) real memory leaks in your code. Thanks for your help, Don

Hi Don, On Fri, Feb 8, 2013 at 2:24 PM, Don <dm413-boost@intielectronics.com> wrote:
Boost 1.53 Chrono version 2 VC 2008 Win7-64
If I #include <boost/chrono.hpp> and run my program, on program exit the VC debugger reports about 40 memory leaks. I don't have to actually use chrono, just include the header.
Can this link be of any help? http://lists.boost.org/boost-users/2012/05/74531.php Regards, Christian

we use Boost.Chrono too. MFC applications incorrectly report memory leaks, which can easily be solved.

On 2/12/2013 7:17 PM, Vicente J. Botet Escriba wrote:
Le 12/02/13 18:13, gast128 a écrit :
we use Boost.Chrono too. MFC applications incorrectly report memory leaks, which can easily be solved. Hi,
if you have some patches to propose to avoids this incorrect reports I would try to include them.
Best, Vicente
Ah it is not a library problem but a MFC problem. MFC does its leak detecting in a global object '_AFX_DEBUG_STATE'. The trick is to link MFC as early as possible (so it gets unloaded as late as possible which triggers the dtor of that object late, which does the leak detection late etc.). A way to do that is to put mfc100d.lib (for vc10) as first entry in the 'additonal properties' entry under the linker options in Visual Studio. Having said that, it is not sure if the user shares the same problem.
participants (4)
-
Christian Henning
-
Don
-
gast128
-
Vicente J. Botet Escriba