Re: Wx::Perl seems to be leaking memory

Thanks for this.  Actually, my timers run all the time in  the background.

On 21/05/15 10:54, Mark Dootson wrote:
> Just one other thing that may not be obvious unless you have read 
> wxWidgets docs for wxTimer, Wx::Timer objects must be explicitly 
> destroyed.
>
> e.g. $timer->Destroy;
>
> However, in the case of Wx::Timer the ->Destroy call deletes the 
> wxWidgets object immediatley.
>
> No point in you testing this out too much until I have fixed the 
> Wx::TimerEvent SV leak problem.
>
> Mark
>
>
> On 21/05/2015 14:50, Mark Dootson wrote:
>> Hi Steve,
>>
>> $app->Yield does not cause 'idle time' to happen - so 'Destroyed' 
>> objects are not cleaned up during that call. As you have seen, on 
>> multiple calls the total number of SVs does not increase so no 
>> memeroy leak there.
>>
>> However, in constructing an example to demonstrate this I think I may 
>> have found the cause of your issues.
>>
>> Every Wx::Timer event or call to an overridden 'Notify' method leaks 
>> 1 SV. I don't have a solution but will work on it over the weekend.
>>
>> Regards
>>
>> Mark
>>
>>
>> On 21/05/2015 11:54, Steve Cookson wrote:
>>> Hmm..,
>>>
>>> On 20/05/15 17:49, Steve Cookson - gmail wrote:
>>>> If I create a few controls in a dialog, delete the dialog, use 
>>>> $app->Yield for the background processing to take place, I still 
>>>> end up with more Perl objects after the deletion than before. 
>>>
>>> Well actually, although the count builds up for the first two 
>>> calls.  After the third call, although it says it's loosing 5 
>>> pointers per call, it is not, because the total number of pointers 
>>> remains the same.  So I suppose that is OK.
>>>
>>> I have switched off my background processing using Wx::Timer and all 
>>> my memory creep stops.  So unless you think the 5 pointers matter 
>>> (and maybe it doesn't), I'm going to switch to looking at the 
>>> Wx::Timer background code as potentially a more productive avenue.
>>>
>>> Thanks
>>>
>>> Steve.
>>
>
>