[IGSTK-Developers] Re: PulseGenerator memory leak

[Luis Ibanez]

Hi David,

Thanks for fixing the memory leaks on the PulseGenerator.

That was a good catch !


    Luis


-------------------
David Gobbi wrote:
> 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.
>>>>
>>>
>>>
>>>
>>
>>
> 
> 
>