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.
