Here's what I did to check:

use Gtk;
Gtk->init;
Gtk->set_locale;
print "$$\n";

sleep 7;
for(1..200) {
  my $o = new Gtk::Window;
  bless $o => 'Gtk::MJD';
  undef $o;
  print "$_\n";
}
sleep 7;



package Gtk::MJD;

BEGIN { @ISA = 'Gtk::Window' }

sub DESTROY {
  my $self = shift;
  print "$self being destroyed.\n";
  $self->SUPER::DESTROY;
}
[download]

This is a little complicated. I take the Gtk::Window ibjects and re-bless them into package Gtk::MJD. This is a package that inherits all of Gtk::Window's methods, so that the objects behave exactly the same. The only exception is the DESTROY method. When Perl thinks it is time to destroy an object, because no part of the program has a reference to it any more, it will call Gtk::MJD::DESTROY. This just prints a message on the terminal and then dispatches to the real DESTROY method via SUPER::DESTROY.

The output from the program shows that the objects are not being destroyed each time through the loop. Instead they are all hanging around until the program exits, and then they are all destroyed at once.

The only thing that can prevent object destruction of an object is an outstanding reference to the object. Since you don't have one (you undefed it) someone else must have one. Therefore it's not your fault.

I suggest that you write up your problem and send it to the Gtk maintainers as a bug report.

It is worth noting that two years later, this behaviour still persists. I tried Google et all to see whether there maybe was an explicit specification that this behaviour should be expected and came up empty handed. (Of course, if anyone else can point me somewhere I will gladly stand corrected.) It can be a show stopper..

Makeshifts last the longest.

Gtk::Window docs say

Windows which are told to manage() are not deleted until they are sent the destroy signal.

.

Tracing this through to Class Gtk::Object reveals a method destroy() which states

This can be used to tell toplevel widgets that they should die if they are managed().

---

Nah! Your thinking of Simon Templar, originally played by Roger Moore and later by Ian Ogilvy

Unless it has circular references, or involves some sort of XS component that doesn't malloc() (whatever the XS function to return memory back to Perl's pool) properly, it should be reclaimed by the internal garbage collection schemes correctly.

I saw exactly what you described, though, in that every ten seconds it would eat up another small chunk of my memory. If I could think of a good object to use that didn't have XS components, I'd try that demo over.

Here the object does go out of scope as the variable associated with the object is my'd to the loop.

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

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.

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!