Subject: Re: [Boost-users] [Chrono] Memory leak in Chrono?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-02-13 13:11:46
Le 13/02/13 14:30, Don a écrit :
>> Subject: Re: [Boost-users] [Chrono] Memory leak in Chrono?
>> From: "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]>
>> 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__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.
I could add this is this helps on the MFC report.
> But n_d_valid_units_, valid_units_, and initialized_ are static
> variables, so I assume you want to only create these variables once.
Right.
>
> 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 is the goal of the type (implement a singleton). This technique is
used in some Boost libraries already
> 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.
Right, this was the reason the destructor didn't do anything.
> 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.
On which other situation do you think this could occur?
Best,
Vicente
> I don't think I understand enough about what is going on to propose a
> robust solution.
>