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

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

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

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

Thanks anon, I will investigate further and then report.

I'll let you know what happens.

Hi Anon,

Thanks for your continuing interest!

Is there some way I can decode the octal references and therefore maybe step through any arrays or hashes looking for content?

Regards.

Maybe, i never tried, i got by with narrow/review. why not try the other mod?

then do a code review looking for references

looking for CIRCULAR references which you can weaken of Scalar::Util