On Tue, Apr 07, 2009 at 09:27:59PM -0400, Matthew Persico wrote: > Well, it is worse than that. I don't think the problem is destruction > order. I think the problem is related to inheritance, class objects > and a bad design decision. You see, what I neglected to show in my > examples, because I forgot it was there is this: > > 1) Inheritance can be divined from the names: > > LTH > LTH::Config > LTH::Mqueue > LTH::Message > LTH::Message::ETN > > 2) But LTH has a class-level member, called 'config' and it is, um, an > LTH::Config. When we create an LTH::Config, we do this: > > $self->config($self); > > Now all the LTH objects get the config with no work. But I bet that > having a class-static instance of a child class as a member of the > parent class is probably NOT a Good Thing at global destruction time; > there is probably a bad loop in there. > > We'll probably rename is Config::LTH so that it does not extend LTH.
Or you could just not have it extend LTH, and keep its name. (As an aside, anything that can be the parent of a 'Config', a 'Mqueue', and a 'Message' probably shouldn't really be the parent of any of them, and they should each consume one or more roles that encapsulate whatever functionality you're trying to share instead.) In any case, your 'bad loop' scenario is only a potential problem *outside* of global destruction, when it could theoretically cause memory leaks. Your bug almost certainly has to do with LTH::Message::DEMOLISH assuming that its references are to objects that haven't yet been GC'ed. You didn't show the code for save_conn() or save_conn_is_open(), though, so I can't be sure. hdp.