[IGSTK-Developers] Re: PulseGenerator memory leak

[David Gobbi]

Guess what?  I checked the dashboard today and the PulseGenerator
still had a leak.  The leak wasn't actually from m_FreeTimeout (though
it is good to have that potential source of leaks fixed).

The leak was actually caused when an invoked timeout action
added a new timeout to the beginning of the list.  When
that occurred, the added timeout was lost: not just leaked, but
completely lost from the list and never invoked.  The cvs code
has been fixed, the patch was very simple once the source of
the problem was identified.  Another score for valgrind.

Also the fix causes igstkViewRefreshRateTest to pass...
another mystery solved?

 - David


Luis Ibanez wrote:

>
> Hi David,
>
> Thanks a lot for tracking this down.
>
> Following your directions, I added the code for clearing
> the m_FreeTimeout in the destructor of the PulseGenerator.
>
> A SimpleMutexLock was also added in order to protect the
> increments and decrements of the NumberOfPulseGenerators.
>
>
>    Luis
>
>
> -------------------
> David Gobbi wrote:
>
>> Oops, forgot to mention the bug number: 2772.
>>
>> David Gobbi wrote:
>>
>>> I looked into memory leak for igstkViewTest and 
>>> igstkViewRefreshRateTest.
>>>
>>> The leaky static variable is igstk::PulseGenerator::m_FreeTimeout.  
>>> It looks like this variable is meant to store spare Timeout objects 
>>> for the sake of efficiency.
>>>
>>> There should be a static counter variable m_NumberOfPulseGenerators 
>>> so that when the last PulseGenerator object is destroyed, the 
>>> m_FreeTimeout list can be deallocated.  The code would go into the 
>>> PulseGenerator destructor.
>>>
>>
>>
>>
>
>