Turns out out problem here was complicated by a problem with MQSeries and the way it implemented a time out - fork a child and wait. When the forked child went away, the destruct sequence kicked in and all hell broke loose. Turning off the timeout and the fork solved the problem.
On Tue, Feb 24, 2009 at 1:56 PM, Matthew Persico <matthew.pers...@gmail.com> wrote: > I am not surprized or offended. It is complicated and I am typing this > all on my backberry since I cannot get at the group or gmail here at > work. I will let you know... > > On 2/24/09, Stevan Little <stevan.lit...@iinteractive.com> wrote: >> Matthew, >> >> I cant possible follow what you are talking about here so I will wait >> for a runnable example. >> >> Thanks, >> >> - Stevan >> >> On Feb 24, 2009, at 1:15 PM, Matthew Persico wrote: >> >>> I am conducting some experiments with small test cases to see if I can >>> duplicate the behavior in a postable case. So far, what I have >>> discovered is this: >>> I have three modules: lth::confgi lth::mqueue and amg::continuefile. >>> Turns out that after instantiating all three, I make a method call in >>> the mqueue one that in turn calls the cpan mqueue module. That appears >>> to fail in a way that causes moose to start the demolish all sequence >>> even though I have the offending call in am eval at the highest level. >>> As a second test, I stopped using my lth::mqueue module and just did >>> the cpan calls in my main. Same behavior. >>> More experimentation to come... >>> >>> On 2/24/09, Stevan Little <stevan.lit...@iinteractive.com> wrote: >>>> It would be much easier if we could see the actual DEMOLISH sub. Also >>>> I would recommend upgrading Moose as recent fixes may have solved >>>> this. >>>> >>>> But the two destroy sequences could easily be because something is >>>> being called inside DEMOLISH that causes it to create another copy of >>>> the object, perhaps the object is stored in a lazy attribute and >>>> somehow it is being clearer first then later in the destruction >>>> process is reinitialized. Perl global destruction can produce some >>>> really weird things. >>>> >>>> - Stevan >>>> >>>> On Feb 24, 2009, at 9:56 AM, Matthew Persico wrote: >>>> >>>>> I have run some tests. In the end, I have a die() in one of my Moose >>>>> object's attribute builder function. As I trace the destruct >>>>> sequence, >>>>> it appears that ALL of my objects are being destroyed twice. >>>>> I think I will pull the die() in favor of a return undef and force >>>>> the >>>>> caller to check validity. die() in a constructor is probably bad >>>>> news. >>>>> But does anyone have any idea about running two destroy sequences? >>>>> >>>>> On 2/23/09, Stevan Little <stevan.lit...@iinteractive.com> wrote: >>>>>> Thomas, >>>>>> >>>>>> Matthew forwarded your mail, here is what I responded to him with: >>>>>> >>>>>> Try updating Moose, I think this might have been fixed recently. >>>>>> >>>>>> Perl's destruction order is essentially random, which can >>>>>> complicate >>>>>> things a lot. If you can provide a stack trace we might be able to >>>>>> provide some more insight. >>>>>> >>>>>> - Stevan >>>>>> >>>>>> On Feb 20, 2009, at 12:50 PM, Thomas, Terry L wrote: >>>>>> >>>>>>> Sorry for the possibly empty prior email with this subject. >>>>>>> Limited >>>>>>> connectivity here. >>>>>>> >>>>>>> I am working with Moose v0.65 and I am getting messages in my logs >>>>>>> that >>>>>>> look like: >>>>>>> >>>>>>> DESTROY created new reference to dead object Foo::Bar during >>>>>>> global >>>>>>> destruction. >>>>>>> >>>>>>> In broad terms, what am I looking for? Badly defined DEMOLISH >>>>>>> sequences? >>>>>>> Missing or present explicit destroys? >>>>>>> >>>>>>> Any help would be appreciated. Sorry about the terseness - limited >>>>>>> connectivity at this time. >>>>>>> >>>>>>> Thanks >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Sent from my mobile device >>>>> >>>>> Matthew O. Persico >>>> >>>> >>> >>> -- >>> Sent from my mobile device >>> >>> Matthew O. Persico >> >> > > -- > Sent from my mobile device > > Matthew O. Persico > -- Matthew O. Persico
