in reply to Re^9: Detecting memory leaks.
in thread 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

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]

      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]

        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]

        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]

      Thanks anon, I will investigate further and then report.

      I'll let you know what happens.

[reply]

In Section Seekers of Perl Wisdom