On Tue Nov 08 17:50:07 2005, davem@iabyn.com wrote: > On Tue, Nov 08, 2005 at 10:23:58AM -0800, Jerry D. Hedden wrote: > > ##### OUTPUT ##### > > > > Checking that the %SHARED hash still exists in thread 0 > > Here are its keys: My::Obj > > Checking that the %SHARED hash still exists in thread 1 > > (in cleanup) Can't call method "FIRSTKEY" on an undefined > value > > at bug.pl line 44 during global destruction. > > This happens because shared arrays and hashes (due to their > implementation) happen to be both an object and be tied. What is > happening > is that during global destruction, the tied object is getting freed > before > the hash object. Note that perl does indeed free objects before > ordinary > values, but in this case they are both objects, so which gets freed > first > is just down to luck. In your case it was only happening in the child > thread because of the order in which things happened to get copied > into > that child. > > The issue can be duplicated without threads in the following code: > > #!/usr/bin/perl > use warnings; > > sub T::TIEHASH: { bless [], 'T' } > sub X::DESTROY { my @x = keys %{$_[0]} } > > tie %h, 'T'; > eval q{$x = \%h; bless $x, 'X'}; > > which gives: > > Name "main::h" used only once: possible typo at /tmp/d1 line 7. > (in cleanup) Can't call method "FIRSTKEY" on an undefined value > at /tmp/d1 line 5 during global destruction. > > Note that the eval is used to ensure that the ref to the blessed hash > is > created *after* the ref to the blessed tie object, so that they get > freed in > the wrong order. > > I don't think there's anything we realistically can do to the perl > interpeter to fix this :-( Could we solve it with an extra refcount for the mg_obj, as there is for backref arrays?Thread Previous