Re^2: sub DESTROY: Strange ordering of object destruction

ikegami - you are spot on here. To get a better understanding of the actual timing of the call to DESTROY, I used your suggestion (in the cb) of adding the following END block:

END {
  warn "Global Destruction starting";
}
[download]

Sure enough, the destruction is happening during global destruction, despite the undef $A much earlier. As clarified in the CB, during global destruction objects are destroyed in any order, so one should never assume that just because A holds a reference to B that A a will be destroyed before B.

To be honest, this still surprises me. Once I called undef $A there were no more variables storing a reference to A. i.e. the code was essentially nothing more than

sub {
  my $a=SomeClass->new($arg1, $arg2, ...);
  undef $a;
  exit();
}
[download]

Wouldn't that undef result in the reference count for whatever was created by SomeClass->new going down to 0? If not, why not? There are no circular refrences in SomeClass - it stores only a reference to B and some pure scalars (strings, numbers). B is a third party class that has no knowledge of A and no way to pass in a reference to A, so a circular reference A->B->A isn't possible.

If yes, in the CB you said that destruction happens as soon as the reference count goes to 0. However, destruction is still happening only after the END block executes. Why?

In any case, thanks, again, for the END block suggestion in the CB.

Update: added comment about circular references.

Comment on Re^2: sub DESTROY: Strange ordering of object destruction Select or Download Code

Replies are listed 'Best First'.
Re^3: sub DESTROY: Strange ordering of object destruction by Corion (Patriarch) on Mar 03, 2011 at 11:57 UTC
Maybe the object itself keeps itself alive? Maybe it has child objects that keep the parent alive too? My guess is that your object `SomeClass` will never get released until global destruction. My advice is to rip out code from SomeClass until it starts getting released at the appropriate time, and then slowly putting the code (and the SomeClass-internal calls to the code) back in until the leak reappears.	[reply] [d/l]
Re^4: sub DESTROY: Strange ordering of object destruction by Anonymous Monk on Mar 03, 2011 at 12:07 UTC
Maybe the object itself keeps itself alive? Maybe it has child objects that keep the parent alive too? I find Data::Dump::Streamer can be really useful for finding out, I used it in HTML::TableExtract Memory Usage. Devel::Cycle might be quicker :)	[reply]
Re^3: sub DESTROY: Strange ordering of object destruction by Anonymous Monk on Mar 03, 2011 at 11:49 UTC
going down to 0? If not, why not? Yes it would, but only as long as nothing else held a reference to $a, including $a itself	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks