Skip Menu |
Report information
Id: 122556
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: felipe [at] felipegasper.com
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: medium
Type: core
Perl Version: 5.14.4
Fixed In: 5.22.0



From: felipe [...] felipegasper.com
Subject: DESTROY handler not firing until after function return.
To: perlbug [...] perl.org
Date: Mon, 18 Aug 2014 13:58:22 -0500
Download (untitled) / with headers
text/plain 7.3k
This is a bug report for perl from felipe@felipegasper.com, generated with the help of perlbug 1.39 running under perl 5.14.4. ----------------------------------------------------------------- [Please describe your issue here] Consider the following: ============================== #!/usr/bin/perl package Thingie; use Carp; sub DESTROY { print Carp::longmess() } package main; use strict; use warnings; sub body { sub { my $t = bless [], 'Thingie'; undef $t; #When the below is commented out, $t isn't garbage-collected until #body()'s return. When it's uncommented, $t is garbage-collected #right here. # #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. }->(); return; } body(); ==================== When the "undef $t" is the last statement in the anonymous sub, Perl is waiting until after that scope is finished to do the GC. This runs counter to expectation since the last reference to the Thingie is removed by setting $t to undef. Moreover, this can produce errors if Thingie references a global in its DESTROY and the anonsub did a "local" on that global. The proper course would seem to be to do GC within the scope. The fact that Perl doesn't behave this way currently looks to me like a bug. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.14.4: Configured by cPanel at Thu Jul 10 15:51:11 CDT 2014. Summary of my perl5 (revision 5 version 14 subversion 4) configuration: Platform: osname=linux, osvers=2.6.32-358.23.2.el6.i686, archname=i386-linux-64int uname='linux rpmb-32-centos-6 2.6.32-358.23.2.el6.i686 #1 smp wed oct 16 17:21:31 utc 2013 i686 i686 i386 gnulinux ' config_args='-des -Dusedevel -Darchname=i386-linux-64int -Dcc=/usr/bin/gcc -Dcpp=/usr/bin/cpp -DDEBUGGING=none -Doptimize=-Os -Dusemymalloc=n -Duseshrplib -Duselargefiles=yes -Duseposix=true -Dhint=recommended -Duseperlio=yes -Dccflags=-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -Dcppflags=-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -Dldflags=-Wl,-rpath -Wl,/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -Dprefix=/usr/local/cpanel/3rdparty/perl/514 -Dsiteprefix=/opt/cpanel/perl5/514 -Dsitebin=/opt/cpanel/perl5/514/bin -Dsitelib=/opt/cpanel/perl5/514/site_lib -Dusevendorprefix=true -Dvendorbin=/usr/local/cpanel/3rdparty/perl/514/bin -Dvendorprefix=/usr/local/cpanel/3rdparty/perl/514/lib/perl5 -Dvendorlib=/usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib -Dprivlib=/usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4 -Dman1dir=none -Dman3dir=none -Dscriptdir=/usr/local/cpanel/3rdparty/perl/514/bin -Dscriptdirexp=/usr/local/cpanel/3rdparty/perl/514/bin -Dsiteman1dir=none -Dsiteman3dir=none -Dinstallman1dir=none -Dversiononly=no -Dinstallusrbinperl=no -Dcf_by=cPanel -Dmyhostname=localhost -Dperladmin=root@localhost -Dcf_email=support@cpanel.net -Di_dbm=/usr/local/cpanel/3rdparty/include -Di_gdbm=/usr/local/cpanel/3rdparty/include -Di_ndbm=/usr/local/cpanel/3rdparty/include -Ud_dosuid -Uuserelocatableinc -Umad -Uusethreads -Uusemultiplicity -Uusesocks -Uuselongdouble -Ui_db -Aldflags=-L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -lgdbm -Dlocincpth=/usr/local/cpanel/3rdparty/perl/514/include /usr/local/cpanel/3rdparty/include /usr/local/include -Duse64bitint -Uuse64bitall -Acflags=-fPIC -DPIC -m32 -I/usr/local/cpanel/3rdparty/perl/514/include -I/usr/local/cpanel/3rdparty/include -Dlibpth=/usr/local/cpanel/3rdparty/perl/514/lib /usr/local/cpanel/3rdparty/lib /usr/local/lib /lib /usr/lib ' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='/usr/bin/gcc', ccflags ='-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-Os', cppflags='-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.4.7 20120313 (Red Hat 4.4.7-3)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='/usr/bin/gcc', ldflags ='-Wl,-rpath -Wl,/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -lgdbm -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.12.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.12' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4/i386-linux-64int/CORE' cccdlflags='-fPIC', lddlflags='-shared -Os -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -L/usr/local/lib -fstack-protector' Locally applied patches: cPanel patches cPanel INC path changes Disabled some unstable tests on a kvm build server Cherry pick of 49498ca from p5p (RT 113514) Remove improper use of each() in B::walksymtable (5cc8528c90) --- @INC for perl 5.14.4: /usr/local/cpanel /usr/local/cpanel /usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib/i386-linux-64int /usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib /usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4/i386-linux-64int /usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4 /opt/cpanel/perl5/514/site_lib/i386-linux-64int /opt/cpanel/perl5/514/site_lib . --- Environment for perl 5.14.4: HOME=/root LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/root/.opt/bin:/usr/local/cpanel/3rdparty/perl/514/bin:/usr/local/cpanel/3rdparty/bin:/usr/local/cpanel/3rdparty/node/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin PERL5LIB=/usr/local/cpanel PERL_BADLANG (unset) SHELL=/bin/bash
Date: Thu, 21 Aug 2014 14:32:23 +0100
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #122556] DESTROY handler not firing until after function return.
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Mon, Aug 18, 2014 at 11:59:00AM -0700, felipe@felipegasper.com wrote: Show quoted text
> ============================== > #!/usr/bin/perl > > package Thingie; > > use Carp; > > sub DESTROY { print Carp::longmess() } > > package main; > > use strict; > use warnings; > > sub body { > sub { > my $t = bless [], 'Thingie'; > undef $t; > > #When the below is commented out, $t isn't garbage-collected until > #body()'s return. When it's uncommented, $t is garbage-collected > #right here. > # > #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. > }->(); > > return; > } > > body(); > ==================== > > When the "undef $t" is the last statement in the anonymous sub, Perl is > waiting until after that scope is finished to do the GC. This runs > counter to expectation since the last reference to the Thingie is > removed by setting $t to undef. > > Moreover, this can produce errors if Thingie references a global in its > DESTROY and the anonsub did a "local" on that global. > > The proper course would seem to be to do GC within the scope. The fact > that Perl doesn't behave this way currently looks to me like a bug.
Well, the actual behaviour is that 'undef $ref' defers decrementing the reference on on the referent until the boundary between the end of the current statement and the start of the next statement. This deferring is part of a general mechanism when converting a scalar ref into something else, so that things like '$a = $a->[0]' work. When there is a 'return' statement (or any other statement following the undef), the destructor is called just before executing the next statement (e.g. the return). When the undef is the last statement, the destructor is called after exit from the anon sub, but *before* any further statements within the 'body' sub are executed. From a technical viewpoint, the exit from a sub (pp_leavesub) can't free the current frame's worth of temporaries (of which $$t is one) because that frame may contain one or more of the return values; e.g. if the value of the last statement is a temporary value, then freeing temporaries during return would free the return value. So temporaries can't be freed until the start of the next statement in the caller. -- No matter how many dust sheets you use, you will get paint on the carpet.
From: felipe [...] felipegasper.com
Date: Thu, 21 Aug 2014 09:40:34 -0500
Subject: Re: [perl #122556] DESTROY handler not firing until after function return.
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 2.7k
Hm. It sounds like this should be documented, then? It seems a pretty conspicuous exception to how one would normally think that this works. -FG Sent from my android device. Show quoted text
-----Original Message----- From: Dave Mitchell via RT <perlbug-followup@perl.org> To: felipe@felipegasper.com Sent: Thu, 21 Aug 2014 8:32 AM Subject: Re: [perl #122556] DESTROY handler not firing until after function return. On Mon, Aug 18, 2014 at 11:59:00AM -0700, felipe@felipegasper.com wrote:
> ============================== > #!/usr/bin/perl > > package Thingie; > > use Carp; > > sub DESTROY { print Carp::longmess() } > > package main; > > use strict; > use warnings; > > sub body { > sub { > my $t = bless [], 'Thingie'; > undef $t; > > #When the below is commented out, $t isn't garbage-collected until > #body()'s return. When it's uncommented, $t is garbage-collected > #right here. > # > #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. > }->(); > > return; > } > > body(); > ==================== > > When the "undef $t" is the last statement in the anonymous sub, Perl is > waiting until after that scope is finished to do the GC. This runs > counter to expectation since the last reference to the Thingie is > removed by setting $t to undef. > > Moreover, this can produce errors if Thingie references a global in its > DESTROY and the anonsub did a "local" on that global. > > The proper course would seem to be to do GC within the scope. The fact > that Perl doesn't behave this way currently looks to me like a bug.
Well, the actual behaviour is that 'undef $ref' defers decrementing the reference on on the referent until the boundary between the end of the current statement and the start of the next statement. This deferring is part of a general mechanism when converting a scalar ref into something else, so that things like '$a = $a->[0]' work. When there is a 'return' statement (or any other statement following the undef), the destructor is called just before executing the next statement (e.g. the return). When the undef is the last statement, the destructor is called after exit from the anon sub, but *before* any further statements within the 'body' sub are executed. From a technical viewpoint, the exit from a sub (pp_leavesub) can't free the current frame's worth of temporaries (of which $$t is one) because that frame may contain one or more of the return values; e.g. if the value of the last statement is a temporary value, then freeing temporaries during return would free the return value. So temporaries can't be freed until the start of the next statement in the caller. -- No matter how many dust sheets you use, you will get paint on the carpet.
Date: Thu, 21 Aug 2014 16:58:17 +0200
To: Perl5 Porters <perl5-porters [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #122556] DESTROY handler not firing until after function return.
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Download (untitled) / with headers
text/plain 1.4k
On Mon, Aug 18, 2014 at 8:59 PM, felipe@felipegasper.com <perlbug-followup@perl.org> wrote:
Show quoted text
Consider the following:

==============================
#!/usr/bin/perl

package Thingie;

use Carp;

sub DESTROY { print Carp::longmess() }

package main;

use strict;
use warnings;

sub body {
    sub {
        my $t = bless [], 'Thingie';
        undef $t;

        #When the below is commented out, $t isn't garbage-collected until
        #body()'s return. When it's uncommented, $t is garbage-collected
        #right here.
        #
        #return;    #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT.
    }->();

    return;
}

body();
====================

When the "undef $t" is the last statement in the anonymous sub, Perl is waiting until after that scope is finished to do the GC. This runs counter to expectation since the last reference to the Thingie is removed by setting $t to undef.

Moreover, this can produce errors if Thingie references a global in its DESTROY and the anonsub did a "local" on that global.

The proper course would seem to be to do GC within the scope. The fact that Perl doesn't behave this way currently looks to me like a bug.

I can see why this happens (it mortalized the referenced SV, instead of destroying it immediately). The obvious fix breaks assignment under some circumstances. I think this can be fixed, but it needs to be thought out well.

Leon
From: Dave Mitchell <davem [...] iabyn.com>
Date: Thu, 21 Aug 2014 16:11:15 +0100
Subject: Re: [perl #122556] DESTROY handler not firing until after function return.
To: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>, "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Download (untitled) / with headers
text/plain 686b
On Thu, Aug 21, 2014 at 04:58:17PM +0200, Leon Timmermans wrote: Show quoted text
> I can see why this happens (it mortalized the referenced SV, instead of > destroying it immediately). The obvious fix breaks assignment under some > circumstances. I think this can be fixed, but it needs to be thought out > well.
The real fix of course is to make the stack refcounted. The sv_2mortal() hack in sv_unref_flags() is just one of many of workarounds for this design flaw. (A "grep -c mortal *.c" shows almost 500 lines; I wonder how mnay of those are just compensating for unrefcounted stack.) -- In England there is a special word which means the last sunshine of the summer. That word is "spring".
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Thu Aug 21 07:59:10 2014, LeonT wrote: Show quoted text
> On Mon, Aug 18, 2014 at 8:59 PM, felipe@felipegasper.com < > perlbug-followup@perl.org> wrote: >
> > Consider the following: > > > > ============================== > > #!/usr/bin/perl > > > > package Thingie; > > > > use Carp; > > > > sub DESTROY { print Carp::longmess() } > > > > package main; > > > > use strict; > > use warnings; > > > > sub body { > > sub { > > my $t = bless [], 'Thingie'; > > undef $t; > > > > #When the below is commented out, $t isn't garbage-collected until > > #body()'s return. When it's uncommented, $t is garbage-collected > > #right here. > > # > > #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. > > }->(); > > > > return; > > } > > > > body(); > > ==================== > > > > When the "undef $t" is the last statement in the anonymous sub, Perl is > > waiting until after that scope is finished to do the GC. This runs counter > > to expectation since the last reference to the Thingie is removed by > > setting $t to undef. > > > > Moreover, this can produce errors if Thingie references a global in its > > DESTROY and the anonsub did a "local" on that global. > > > > The proper course would seem to be to do GC within the scope. The fact > > that Perl doesn't behave this way currently looks to me like a bug. > >
> > I can see why this happens (it mortalized the referenced SV, instead of > destroying it immediately). The obvious fix breaks assignment under some > circumstances. I think this can be fixed, but it needs to be thought out > well.
undef is distinct from assignment. We can fix this case by having pp_undef pass the SV_IMMEDIATE_UNREF flag, no? (I am testing a patch right now.) Would that cause any unforeseen problems? -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
On Wed Aug 27 22:24:22 2014, sprout wrote: Show quoted text
> On Thu Aug 21 07:59:10 2014, LeonT wrote:
> > On Mon, Aug 18, 2014 at 8:59 PM, felipe@felipegasper.com < > > perlbug-followup@perl.org> wrote: > >
> > > Consider the following: > > > > > > ============================== > > > #!/usr/bin/perl > > > > > > package Thingie; > > > > > > use Carp; > > > > > > sub DESTROY { print Carp::longmess() } > > > > > > package main; > > > > > > use strict; > > > use warnings; > > > > > > sub body { > > > sub { > > > my $t = bless [], 'Thingie'; > > > undef $t; > > > > > > #When the below is commented out, $t isn't garbage-collected until > > > #body()'s return. When it's uncommented, $t is garbage-collected > > > #right here. > > > # > > > #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. > > > }->(); > > > > > > return; > > > } > > > > > > body(); > > > ==================== > > > > > > When the "undef $t" is the last statement in the anonymous sub, > > > Perl is > > > waiting until after that scope is finished to do the GC. This runs > > > counter > > > to expectation since the last reference to the Thingie is removed > > > by > > > setting $t to undef. > > > > > > Moreover, this can produce errors if Thingie references a global in > > > its > > > DESTROY and the anonsub did a "local" on that global. > > > > > > The proper course would seem to be to do GC within the scope. The > > > fact > > > that Perl doesn't behave this way currently looks to me like a bug. > > >
> > > > I can see why this happens (it mortalized the referenced SV, instead > > of > > destroying it immediately). The obvious fix breaks assignment under > > some > > circumstances. I think this can be fixed, but it needs to be thought > > out > > well.
> > undef is distinct from assignment. We can fix this case by having > pp_undef pass the SV_IMMEDIATE_UNREF flag, no? (I am testing a patch > right now.) Would that cause any unforeseen problems?
I have gone ahead and applied my patch as 4dda930, fixing ‘undef $scalar’. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 957b
On Wed Aug 27 22:24:22 2014, sprout wrote: Show quoted text
> undef is distinct from assignment. We can fix this case by having > pp_undef pass the SV_IMMEDIATE_UNREF flag, no? (I am testing a patch > right now.) Would that cause any unforeseen problems?
a perl object constructor (new()), that uses a global error var like errno or package var/C library equivelent, if the new call fails, and the undef is assigned to an existing object ref of the same class, triggers a DESTROY on the existing object, and wiping the global error var. So you dont know why, or its a totally different uninitialized (since the DESTROY was successful) error code, the new() failed. Changing when DESTROY is called can cause subtle bugs like that. The solution is DESTROY has to save and restore global state, but in a complex app its very difficult to know when DESTROYs will run and what classes they are from, and the code behind those classes, etc. -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #122556] DESTROY handler not firing until after function return.
Date: Tue, 09 Sep 2014 13:05:24 -0500
To: perlbug-followup [...] perl.org
From: Felipe Gasper <felipe [...] felipegasper.com>
Thank you to everyone who has looked at this! :) On 8/28/14 8:23 AM, Father Chrysostomos via RT wrote: Show quoted text
> On Wed Aug 27 22:24:22 2014, sprout wrote:
>> On Thu Aug 21 07:59:10 2014, LeonT wrote:
>>> On Mon, Aug 18, 2014 at 8:59 PM, felipe@felipegasper.com < >>> perlbug-followup@perl.org> wrote: >>>
>>>> Consider the following: >>>> >>>> ============================== >>>> #!/usr/bin/perl >>>> >>>> package Thingie; >>>> >>>> use Carp; >>>> >>>> sub DESTROY { print Carp::longmess() } >>>> >>>> package main; >>>> >>>> use strict; >>>> use warnings; >>>> >>>> sub body { >>>> sub { >>>> my $t = bless [], 'Thingie'; >>>> undef $t; >>>> >>>> #When the below is commented out, $t isn't garbage-collected until >>>> #body()'s return. When it's uncommented, $t is garbage-collected >>>> #right here. >>>> # >>>> #return; #<== UNCOMMENT, AND COMPARE Carp::longmess OUTPUT. >>>> }->(); >>>> >>>> return; >>>> } >>>> >>>> body(); >>>> ==================== >>>> >>>> When the "undef $t" is the last statement in the anonymous sub, >>>> Perl is >>>> waiting until after that scope is finished to do the GC. This runs >>>> counter >>>> to expectation since the last reference to the Thingie is removed >>>> by >>>> setting $t to undef. >>>> >>>> Moreover, this can produce errors if Thingie references a global in >>>> its >>>> DESTROY and the anonsub did a "local" on that global. >>>> >>>> The proper course would seem to be to do GC within the scope. The >>>> fact >>>> that Perl doesn't behave this way currently looks to me like a bug. >>>>
>>> >>> I can see why this happens (it mortalized the referenced SV, instead >>> of >>> destroying it immediately). The obvious fix breaks assignment under >>> some >>> circumstances. I think this can be fixed, but it needs to be thought >>> out >>> well.
>> >> undef is distinct from assignment. We can fix this case by having >> pp_undef pass the SV_IMMEDIATE_UNREF flag, no? (I am testing a patch >> right now.) Would that cause any unforeseen problems?
> > I have gone ahead and applied my patch as 4dda930, fixing ‘undef $scalar’. >
Subject: Your ticket against Perl 5 has been resolved
Download (untitled) / with headers
text/plain 222b
Thanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket -- Karl Williamson for the Perl 5 porters team


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org