develooper Front page | perl.perl5.porters | Postings from September 2010

[perl #37640] Shared hash destroyed too soon

Thread Previous
From:
Father Chrysostomos via RT
Date:
September 26, 2010 17:32
Subject:
[perl #37640] Shared hash destroyed too soon
Message ID:
rt-3.6.HEAD-24759-1285547554-1603.37640-15-0@perl.org
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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About