Re: Wx::Perl seems to be leaking memory

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.
>