in reply to Object reference disappearing during global destruction

You really need to clean up yourself - i.e., assuming your objects are already in a hierarchy, or can be put in a hierarchy, then destroy them yourself. If you're working with a collection of objects, for example, maintain a global array or something and keep a list of your objects in there. Then go through and remove them yourself before Perl does.

The problem with removing objects is when they refer to each other - obviously, the destructor needs to stop somewhere and start removing things. If you can guarantee that doesn't happen, you can write some simple code to destroy the objects before they get de-allocated. You then get to pick what order stuff happens. Presumably your objects are some kind of tree structure, and you can jsut start at the leaves and work inwards. If you have something more complicated than that, you need to think about the order in which things will get removed - perhaps you have some corner-case data structure which is causing problems (e.g. a loop)?

  • Comment on Re: Object reference disappearing during global destruction

Replies are listed 'Best First'.
Re: Re: Object reference disappearing during global destruction
by khkramer (Scribe) on May 15, 2002 at 19:43 UTC

    I actually do a lot of clean-up management. There are 10k lines of code in this set of modules, and many dozens of objects get created at the beginning (and destroyed at the end) of even a one-liner invocation. But I've always depended -- at bottom -- on the basic reference-counting rules to make sure that object destruction happens in a safe order (and assumed that this should work even during global destruction). Avoiding circular references and other destroy-time problems has always been a big concern: making sure there are no memory leaks in this code was a primary goal from the very beginning of development.

    But I would tend to think that you're right about there being some corner-case oddity here. I guess, to re-state the question, what could cause the following sequence of events:

    1. during normal operation: $foo->{bar} => Some::Object::Ref=HASH(0x86ed4c0)
    2. global destruction begins
    3. at some point during global destruction $foo->{bar} = undef happens -- without any statement to that effect being executed, (and Some::Object::Ref=HASH(0x86ed4c0) is still around and accessible by other means).

    The debugger shows that no code undefs $::index->{_def}. So, either:

    1. The interpreter is allowed to reach in and yank references out from under objects during global destruction. (And perhaps this is what chromatic is saying about throwing reference counting by the board when the interpreter is ready to exit.)
    2. The debugger is wrong.
    3. Or, I'm an idiot, and there's something quite different going on here that I've managed to miss completely.
[reply]

In Section Seekers of Perl Wisdom