Re: Acky Memory

How do you delete an unwanted object?

The short answer: use $o->DESTROY; instead of undef $0.

The long answer involves the fact that Perl's garbage collection mechanism can be fooled. It is based on reference counting, and fails to reclaim memory as soon as it involves circular references. So you might undef your $o variable, but the underlying structure might still have a non-null reference count and thus not be freed. In order to deal with those "sticky" objects, modules can (and should) provide a DESTROY method that can be called either explicitely by the program or implicitely when an object goes out of scope.

Which by the way also answers your other question about whether you would need to do something like this: yes!

Now for the task at hand: Gtk actually provides a DESTROY method for Gtk::Window objects so you could try using it instead of undef. The weird thing though is that in your example the $o object goes out of scope at the end of each loop, so it should be reclaimed by the Garbage Collector. And as I am not familiar with the internals (nor the externals!) of Gtk I have no idea whether there is a memory leak in the module or whether this is normal.

Just to make you feel even worse here is a piece of code from the test.pl file that comes with Gtk and which looks conspicuously similar to what you wrote, they don't use DESTROY but just undef:

 sub destroy_window {
        my($widget, $windowref, $w2) = @_;
        $$windowref = undef;
        $w2 = undef if defined $w2;
        0;
}
[download]

Go figure...

Comment on Re: Acky Memory Download Code

Replies are listed 'Best First'.
Re: Acky Memory by Dominus (Parson) on Nov 12, 2000 at 18:53 UTC
This is really bad advice. Calling the `DESTROY` method on an object will not clean up its memory and can cause all sorts of weird problems because you have invoked the destructor for an object that has not actually been destroyed. You should never invoke the `DESTROY` method explicitly. When Perl sees that an object is no longer being used by anyone, it will reclaim the memory for the object automatically. Just before it does this, it will call the `DESTROY` method automatically, to perform any final cleanup that the object requires, such as closing any filehandles that it might contain. If you call `DESTROY` yourself, you will have an object in an inconsistent state, because `DESTROY` thought that the object was about to be destroyed. But it was not destroyed, because some part of the program still has a reference to it; you called `DESTROY` permaturely. And then later, when Perl sees that the object is no longer useful, it will reclaim the memory for the object and call `DESTROY` a second time. This could easily cause all sorts of havoc because a `DESTROY` method is only supposed to be called once. Finally, you run the risk of a fatal run time error because not every object has a `DESTROY` method, and if you call the `DESTROY` method on an object that doesn't have one, your program will die. Summary: never call `$o->DESTROY`.	[reply] [d/l] [select]
RE: Re: Acky Memory by mirod (Canon) on Nov 12, 2000 at 19:35 UTC
OK, I stand corrected. I was thinking of a case where the automatic GC doesn't kick in for example because the object never goes out of scope, but actually just doing `undef $o` should be enough, my apologies, and on to the Worst Nodes list!	[reply]