hash elem ref in @_ disappears

[p5pRT]

Migrated from rt.perl.org#119977 (status was 'open')

Searchable as RT119977$

[p5pRT]

From zefram@fysh.org

Created by zefram@fysh.org

$ cat t0
my $iter;
my %llll;
sub bbbb { }
sub aaaa {
  \@​_ if $iter & 1;
  bbbb($_[1]) if $iter & 2;
  delete $llll{p};
  print $_[0] // "undef", "\n";
}
for(0..3) {
  $iter = $_;
  %llll = (p => "oooo");
  aaaa($llll{p}, undef);
}
$ perl5.18.1 t0
undef
oooo
oooo
oooo
$ perl5.19.4 t0
undef
oooo
undef
oooo

It's surprising that $_[0] ever fails to retain the defined value.
Even if the deleted element becoming undef is somehow correct, the
two expressions controlled by $iter look as if they shouldn't make any
difference to the behaviour. Class-MethodMaker on CPAN is (in a very
roundabout way) depending on the old behaviour of the case that changed
in 5.19.4, and so is now failing its tests.

Devel​::Peek says that the undefs that appear with 5.19.4 are actually
&PL_sv_undef, whereas the undef that appeared previously was a refcnt=1
writable scalar. So the recent change looks to be related to the
undef-in-array change.

Suspect that the lack of refcounting on the stack is involved.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.19.4:

Configured by root at Mon Sep 23 11:12:36 UTC 2013.

Summary of my perl5 (revision 5 version 19 subversion 4) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-5-686, archname=i686-linux-64int-ld
    uname='linux beryllium.photobox.priv 2.6.32-5-686 #1 smp mon feb 25 01:04:36 utc 2013 i686 gnulinux '
    config_args='-des -Dusedevel -Uversiononly -Duseshrplib -Duse64bitint -Duselongdouble -Uusethreads -Uusemultiplicity -Dprefix=/opt/perl-5.19.4 -Dsiteprefix=/opt/perl-5.19.4 -Dvendorprefix=/opt/perl-5.19.4/vendor -Doptimize=-ggdb -O2 -Dcccdlflags=-fPIC -O2 -pipe'
    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=define
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-ggdb -O2',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.7.2', 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='long double', nvsize=12, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.13'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/opt/perl-5.19.4/lib/5.19.4/i686-linux-64int-ld/CORE'
    cccdlflags='-fPIC -O2 -pipe', lddlflags='-shared -ggdb -O2 -L/usr/local/lib -fstack-protector'



@INC for perl 5.19.4:
    /opt/perl-5.19.4/lib/site_perl/5.19.4/i686-linux-64int-ld
    /opt/perl-5.19.4/lib/site_perl/5.19.4
    /opt/perl-5.19.4/vendor/lib/vendor_perl/5.19.4/i686-linux-64int-ld
    /opt/perl-5.19.4/vendor/lib/vendor_perl/5.19.4
    /opt/perl-5.19.4/lib/5.19.4/i686-linux-64int-ld
    /opt/perl-5.19.4/lib/5.19.4
    .


Environment for perl 5.19.4:
    HOME=/root
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/opt/perl-5.19.4/bin:/root/pub/i686-pc-linux-gnu/bin:/root/pub/common/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/local/bin:/usr/local/sbin:/usr/games:/opt/geoip/bin:/opt/httpd/bin:/opt/perl/bin
    PERL5LIB=
    PERL5OPT=
    PERL5_CPANPLUS_IS_RUNNING=5158
    PERL5_CPAN_IS_RUNNING=5158
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

[p5pRT]

From zefram@fysh.org

Bisect for the change between 5.19.3 and 5.19.4 says

ce0d59f is the first bad commit
commit ce0d59f
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Tue Jul 2 13​:07​:45 2013 -0700

  [perl #7508] Use NULL for nonexistent array elems

-zefram

[p5pRT]

From @jkeenan

On Tue, 24 Sep 2013 13​:07​:50 GMT, zefram@​fysh.org wrote​:

This is a bug report for perl from zefram@​fysh.org,
generated with the help of perlbug 1.39 running under perl 5.19.4.

-----------------------------------------------------------------
[Please describe your issue here]

$ cat t0
my $iter;
my %llll;
sub bbbb { }
sub aaaa {
\@​_ if $iter & 1;
bbbb($_[1]) if $iter & 2;
delete $llll{p};
print $_[0] // "undef", "\n";
}
for(0..3) {
$iter = $_;
%llll = (p => "oooo");
aaaa($llll{p}, undef);
}
$ perl5.18.1 t0
undef
oooo
oooo
oooo
$ perl5.19.4 t0
undef
oooo
undef
oooo

It's surprising that $_[0] ever fails to retain the defined value.
Even if the deleted element becoming undef is somehow correct, the
two expressions controlled by $iter look as if they shouldn't make any
difference to the behaviour. Class-MethodMaker on CPAN is (in a very
roundabout way) depending on the old behaviour of the case that
changed
in 5.19.4, and so is now failing its tests.

Class-MethodMaker appears to have recovered. Almost all PASS at http​://matrix.cpantesters.org/?dist=Class-MethodMaker

Devel​::Peek says that the undefs that appear with 5.19.4 are actually
&PL_sv_undef, whereas the undef that appeared previously was a
refcnt=1
writable scalar. So the recent change looks to be related to the
undef-in-array change.

Suspect that the lack of refcounting on the stack is involved.

On Tue, 24 Sep 2013 21​:41​:45 GMT, zefram@​fysh.org wrote​:

Bisect for the change between 5.19.3 and 5.19.4 says

ce0d59f is the first bad commit
commit ce0d59f
Author​: Father Chrysostomos <sprout@​cpan.org>
Date​: Tue Jul 2 13​:07​:45 2013 -0700

\[perl \#7508\] Use NULL for nonexistent array elems

-zefram

I can confirm that that is the commit where the behavior of the test program changed.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[tonycoz]

Suspect that the lack of refcounting on the stack is involved.

This appears to be the case. Testing the example with -Accflags=-DPERL_RC_STACK produces four lines of oooo which seems like the most reasonable result.