Re^10: Detecting memory leaks.

Hi Anon,

So using your narrow review method, the following (ie one function using a hash object)

        
        my $count1 =  Devel::Leak::NoteSV(my $handle);
            $booking_dlg->{booking_main} = Wx::Panel->new($booking_dlg
+, wxID_ANY, wxDefaultPosition,[$gl_cfg->{monitor_resolution_x}, $gl_c
+fg->{monitor_resolution_y}],  wxNO_BORDER, "" );
    
        my $count2 =  Devel::Leak::CheckSV($handle );
        print "Count1 = '",$count1,"'\n";
        print "Count2 = '",$count2,"'\n";
        print "Diff = '",$count2-$count1,"'\n";
[download]

Gives me:


new 0x9d741e8 : 
new 0x9d56f70 : 
new 0x9d44858 : 
new 0x9d38270 : 
new 0x9d382d0 : 
old (1):
 0 
Count1 = '594970'
Count2 = '594974'
Diff = '4'
[download]

Maybe I'm using the wrong mental model, but I don't really see how this could be, unless there are new objects being created by Wx::Panel, which are then referred to by references in $booking_dlg->{booking_main} and therefore not dropping out of scope.

What do you think?

Regards

Comment on Re^10: Detecting memory leaks. Select or Download Code

Replies are listed 'Best First'.
Re^11: Detecting memory leaks. by wrog (Friar) on May 07, 2015 at 15:51 UTC
You are passing in `$booking_dlg` to `Wx::Panel::new`, which is presumably creating a `Wx::Panel` object, which recursively refers to at least 3 other objects. If any of these other objects saves the reference to `$booking_dlg`, then you have a circularity of the form: `$booking_dlg->{booking_main} == Wx::Panel object, (Wx::Panel object)->{foo} == other object (other object)->{bar} = $booking_dlg` [download] which will preserve the `Wx::Panel` object, the other object, and the `$booking_dlg` object forever unless `->{booking_main}` gets reassigned sometime later. (and if `$booking_dlg` is simply being tossed later on, there's your leak right there) (Update: Well, okay, it could also be (`Wx::Panel` object)`->{foo} = $booking_dlg` directly and the other 3 objects are just being dragged along for the ride. It only takes one such reference to ruin your day...)	[reply] [d/l] [select]
Re^11: Detecting memory leaks. by Anonymous Monk on May 08, 2015 at 03:00 UTC
Umm I think something went wrong , things seem different from what I remember and from what it apparently is, I'm unsure of stuff now Consider this program Read more... (9 kB) "new f new p" is not supposed to leak 400 scalars "new f child p" is not supposed to leak 400 scalars because the reference is supposed to be a weak reference "new f child p destroy" is not supposed to leak 200 scalars, circular reference or no circular reference, Destroy is supposed to clean them all up ... So maybe this is just taskmanager lying to me, or Devel::Cycle lying, or I'm really mis remember how this used to work or how its supposed to work, but I'm pretty sure this is a bug that needs to be reported to rt://Wx :) you should report it Heck, consider these oneliners Read more... (1105 Bytes) My winxp taskmanager tells me memory keeps increasing with these programs ... well its pretty much not supposed to Dang	[reply] [d/l] [select]
Re^12: Detecting memory leaks. by Steve_BZ (Chaplain) on May 11, 2015 at 16:09 UTC
Hi Anon, I posted on the Wx::Perl Mailing list and got this reply: See http://docs.wxwidgets.org/3.0/classwx_window.html#a6bf0c5be864544d9ce0560087667b7fc details for wxWindow::Destroy. As you have determined, top level windows you create need to be destroyed with $win->Destroy; The C++ structure for a Wx::Frame contains a reference to the associated Perl SV. So that SV won't go away until the C++ structure is deleted - which will never happen until your event loop is running. Regards Steve	[reply]
Re^13: Detecting memory leaks. ( Wx::wxTheApp()->ProcessIdle; ) by Anonymous Monk on May 13, 2015 at 07:54 UTC
Here is $app->Dispatch which is running the event loop manually one event at a time , this should clean up the memory but it doesn't update: it finally does, solution is to pair $window->Destroy; Wx::wxTheApp()->ProcessIdle; don't know at what point in wxwidgets history ProcessIdle became required/necessary for memory reclamation, I don't remember needing to do that explicitly, but it seems it has, werid but a solution is a solution :) whew sanity restored `#!/usr/bin/perl -- use strict; use warnings; use Wx; my$app=Wx::SimpleApp->new; for(1..10){ for(1..2000){ my $f =Wx::Frame->new; $f->Close; $f->Destroy; undef $f; $app->ProcessIdle; ## CRITICAL ## can also be written as ## Wx::wxTheApp()->ProcessIdle; #~ $app->Dispatch for 1..1000; $app->Dispatch for 1..10; } scalar<>; } __END__` [download]	[reply] [d/l]
Re^14: Detecting memory leaks. ( Wx::wxTheApp()->ProcessIdle; ) by Steve_BZ (Chaplain) on May 14, 2015 at 19:57 UTC
Re^15: Detecting memory leaks. ( Wx::wxTheApp()->ProcessIdle; ) by Anonymous Monk on May 14, 2015 at 23:23 UTC
Re^13: Detecting memory leaks. by Anonymous Monk on May 13, 2015 at 07:19 UTC
That is easy to say, but there is no code to prove it I posted Re^11: Detecting memory leaks. because it disproves that theory, event loop is running, memory is growing	[reply]
Re^12: Detecting memory leaks. by Steve_BZ (Chaplain) on May 09, 2015 at 20:16 UTC
Thanks anon, I will investigate further and then report. I'll let you know what happens.	[reply]


Keep It Simple, Stupid
	PerlMonks