p5pRT
commented
7 years ago From victor.burns@bankofamerica.com
This issue is believed to exist in all 5.10.1+ Perl's and every older Perl as well. I have verified the issue in every Perl I have at my disposal from 5.10.1\, 5.12.0\, 5.22.0 and 5.24.0.
Description: If the last reference to an object is in thread shared memory the objects DESTROY method won't be called or highly unlikely to be called. This is a *huge* problem for applications that are OO and designed using composition of other classes (HAS-A). The last\, and possibly only reference will be in Perl's thread shared memory. I think the real issue only resembles my description and therefore it is not perfect. I have however included a small script that when used and modified as the comments suggest the related behaviors may be observed. The actual issue is a bit more unpredictable.
## PERL BUG Example
use 5.010001; use strict; use warnings; use threads; use threads::shared;
our $VERSION = 0.1;
say 'Hello World!\, - Perl shared memory failure to call ->DESTROY detector.';
LEAKER: { ## Using the "shared" attribute can play a role in this ## Best guess it means all references are shared. my $aa :shared = bless &share({})\, 'Lazy::Crazy'; my $bb :shared = bless &share({})\, 'Lazy::Crazy'; my $cc :shared = &share( bless {}\, 'Lazy::Crazy' );
## Placing an object into another makes it a sure bet its ## ->DESTROY won't be called $aa->{ has_c } = $cc; $bb->{ has_a } = $aa;
## It's strange that the order of the following assignments ## will allow the last one touched to call its ->DESTROY $cc->{ label } = 'c'; $aa->{ label } = 'a'; $bb->{ label } = 'b';
## If I'm able to control the order these are unwrapped (destroyed) ## things start working as expected. ## How likely can I always get this right\, not at all! ## (uncomment and things work as expected) # $bb = undef; # $aa = undef; # $cc = undef; }
package Lazy::Crazy;
sub DESTROY { my $self = shift; printf "# %s '%s' is destroyed\n"\, ref $self\, $self->{ label }; return; }
## END
Migrated from rt.perl.org#130649 (status was 'open')
Searchable as RT130649$