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:
- during normal operation: $foo->{bar} => Some::Object::Ref=HASH(0x86ed4c0)
- global destruction begins
- 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:
- 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.)
- The debugger is wrong.
- Or, I'm an idiot, and there's something quite different going on
here that I've managed to miss completely.