Re: [Boost-users] [Chrono] Memory leak in Chrono?

13 Feb 2013

      ...
Subject: Re: [Boost-users] [Chrono] Memory leak in Chrono?
From: "Vicente J. Botet Escriba" 
Date: 2/12/2013 1:17 PM
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.
Vincente,

I am using MFC, but I don't believe this is a MFC false-leak report.

I added a destructor for duration_units_default_initializer_t, like this (near the end of chrono/io/duration_units.hpp):

         ~duration_units_default_initializer_t()
           {
             if (duration_units_default_holder<CharT>::initialized_)
             {
               delete[] duration_units_default_holder<CharT>::n_d_valid_units_;
               duration_units_default_holder<CharT>::n_d_valid_units_ = 0;
               delete[] duration_units_default_holder<CharT>::valid_units_;
               duration_units_default_holder<CharT>::valid_units_ = 0;
               duration_units_default_holder<CharT>::initialized_ = false;
             }
     	  }

This solves the memory leak, and seems to work fine for my simple test program. But n_d_valid_units_, valid_units_, and initialized_ are static variables, so I assume you want to only create these variables once.

When run with my test program and step through it in the debugger, only one instantiation of duration_units_default_initializer_t occurs. (That is, once for each char type, single-byte and wide.) This occurs when the duration_units_default_initializer is instantiated (at the very end of duration_units.hpp). Since this is a global variable, this occurs during application startup and the destructor runs during application shuttdown. But presumably this can occur in some other situations, otherwise why would you have all the logic of making valid_units_ etc. class-static variables. I don't think I understand enough about what is going on to propose a robust solution.

Thanks for your help,
Don