Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sort with custom subname and prototype ($$) segfaults intermittently #8478

Closed
p5pRT opened this issue Jun 9, 2006 · 33 comments
Closed

sort with custom subname and prototype ($$) segfaults intermittently #8478

p5pRT opened this issue Jun 9, 2006 · 33 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Jun 9, 2006

Migrated from rt.perl.org#39358 (status was 'resolved')

Searchable as RT39358$

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From johnh@isi.edu

Created by johnh@isi.edu

For a long time (more than a year), perl has segfaulted for me in a
program that does some nasty sorting. Recently I finally narrowed it
down to a modest-size test case​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
  '0000.0000.00039​:0000.0008.0031.',
  '0000.0000.00032​:0000.0008.0024.',
  '0002.0002.00033​:0002.0011.0020.',
  '0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
  my($A,$B) = @​_;
  return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.

Here's the backtrace on 5.8.8 built with debugging​:

(gdb) run -Ilib /tmp/t.pl
Starting program​: /usr/src/redhat/BUILD/perl-5.8.8/perl -Ilib
/tmp/t.pl
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xd88000
[Thread debugging using libthread_db enabled]
[New Thread -1208506688 (LWP 31509)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208506688 (LWP 31509)]
0x0069c8f0 in Perl_pp_aelem (my_perl=0x89b1008) at pp_hot.c​:3007
3007 IV elem = SvIV(elemsv);
(gdb) bt
#0 0x0069c8f0 in Perl_pp_aelem (my_perl=0x89b1008) at pp_hot.c​:3007
#1 0x00697937 in Perl_runops_standard (my_perl=0x89b1008)
  at run.c​:37
#2 0x00712860 in sortcv_stacked (my_perl=0x89b1008, a=0x89cd5c0,
  b=0x89cd5cc) at pp_sort.c​:1791
#3 0x0071065e in S_mergesortsv (my_perl=0x89b1008, base=Variable
"base" is not available.
)
  at pp_sort.c​:429
#4 0x007119d2 in Perl_sortsv (my_perl=0x89b1008, array=0x89d1a10,
  nmemb=4, cmp=0x7127f1 <sortcv_stacked>) at pp_sort.c​:1458
#5 0x007120b7 in Perl_pp_sort (my_perl=0x89b1008) at pp_sort.c​:1685
#6 0x00697937 in Perl_runops_standard (my_perl=0x89b1008)
  at run.c​:37
#7 0x0063d989 in perl_run (my_perl=0x89b1008) at perl.c​:2367
#8 0x080492f4 in main (argc=3, argv=0xbfe9a544, env=0xbfe9a554)
  at perlmain.c​:99
(gdb) q

The test program is 100% repeatable. I extracted it from a larger
program where I get intermittent problems depending on the input (but
always in the sort routine).

For a different input I got a different traceback​:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208793408 (LWP 31157)]
0x008c6ccd in Perl_mg_get (my_perl=0x81f7008, sv=0x8506ac0)
  at mg.c​:164
164 newmg = cur = head = mg = SvMAGIC(sv);
(gdb) bt
#0 0x008c6ccd in Perl_mg_get (my_perl=0x81f7008, sv=0x8506ac0)
  at mg.c​:164
#1 0x008e8695 in Perl_sv_setsv_flags (my_perl=0x81f7008,
  dstr=0x821e200, sstr=Variable "sstr" is not available.
) at sv.c​:3856
#2 0x008e9d2b in Perl_sv_mortalcopy (my_perl=0x81f7008,
  oldstr=0x8506ac0) at sv.c​:6814
#3 0x008d8b81 in Perl_pp_aelem (my_perl=0x81f7008) at pp_hot.c​:3055
#4 0x008d3937 in Perl_runops_standard (my_perl=0x81f7008)
  at run.c​:37
#5 0x0094e860 in sortcv_stacked (my_perl=0x81f7008, a=0x876a934,
  b=0x876a868) at pp_sort.c​:1791
#6 0x0094c65e in S_mergesortsv (my_perl=0x81f7008, base=Variable
"base" is not available.
)
  at pp_sort.c​:429
#7 0x0094d9d2 in Perl_sortsv (my_perl=0x81f7008, array=0x8506ab0,
  nmemb=4, cmp=0x94e7f1 <sortcv_stacked>) at pp_sort.c​:1458
#8 0x0094e0b7 in Perl_pp_sort (my_perl=0x81f7008) at pp_sort.c​:1685
#9 0x008d3937 in Perl_runops_standard (my_perl=0x81f7008)
  at run.c​:37
#10 0x00879989 in perl_run (my_perl=0x81f7008) at perl.c​:2367
#11 0x080492f4 in main (argc=6, argv=0xbfe54dd4, env=0xbfe54df0)
  at perlmain.c​:99

(I didn't isolate this to a test kernel.)

Any suggestions?

Thanks,
  -John Heidemann

Perl Info

Flags:
    category=core
    severity=high

This perlbug was built using Perl v5.8.8 in the Red Hat build system.
It is being executed now by Perl v5.8.8 - Wed Mar  1 18:29:13 EST 2006.

Site configuration information for perl v5.8.8:

Configured by Red Hat, Inc. at Wed Mar  1 18:29:13 EST 2006.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.9-22.18.bz155725.elsmp, archname=i386-linux-thread-multi
    uname='linux hs20-bc1-6.build.redhat.com 2.6.9-22.18.bz155725.elsmp #1 smp thu nov 17 15:34:08 est 2005 i686 i686 i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 5.8.4 5.8.3 -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='4.1.0 20060228 (Red Hat 4.1.0-1)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.3.90.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.90'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.8:
    /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.8
    /usr/lib/perl5/site_perl/5.8.7
    /usr/lib/perl5/site_perl/5.8.6
    /usr/lib/perl5/site_perl/5.8.5
    /usr/lib/perl5/site_perl/5.8.4
    /usr/lib/perl5/site_perl/5.8.3
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.8
    /usr/lib/perl5/vendor_perl/5.8.7
    /usr/lib/perl5/vendor_perl/5.8.6
    /usr/lib/perl5/vendor_perl/5.8.5
    /usr/lib/perl5/vendor_perl/5.8.4
    /usr/lib/perl5/vendor_perl/5.8.3
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/5.8.8
    .


Environment for perl v5.8.8:
    HOME=/home/johnh
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/local/lib
    LOGDIR (unset)
    PATH=/home/johnh/BIN:/home/johnh/BIN/LINUX:/usr/local/bin:/bin:/usr/bin:/home/johnh/BIN/WP:/home/johnh/BIN/HOSTS:/home/johnh/BIN/DB:/usr/X11R6/bin:/usr/local/etc:/usr/local/sbin:/etc:/usr/etc:/sbin:/usr/sbin:/usr/hosts:/usr/local/games:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From @Tux

On Thu, 08 Jun 2006 21​:23​:41 -0700, "johnh@​isi.edu (via RT)"
<perlbug-followup@​perl.org> wrote​:

# New Ticket Created by johnh@​isi.edu
# Please include the string​: [perl #39358]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=39358 >

This is a bug report for perl from johnh@​isi.edu,
generated with the help of perlbug 1.35 running under perl v5.8.8.

-----------------------------------------------------------------
[Please enter your report here]

For a long time (more than a year), perl has segfaulted for me in a
program that does some nasty sorting. Recently I finally narrowed it
down to a modest-size test case​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It has changed in devel​:

pc09​:/pro/3gl/CPAN/perl-current 105 > ./perl -Ilib ~/test.pl
Bizarre copy of UNKNOWN in aelem at /home/merijn/test.pl line 16.

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.

Here's the backtrace on 5.8.8 built with debugging​:

(gdb) run -Ilib /tmp/t.pl
Starting program​: /usr/src/redhat/BUILD/perl-5.8.8/perl -Ilib
/tmp/t.pl
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xd88000
[Thread debugging using libthread_db enabled]
[New Thread -1208506688 (LWP 31509)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208506688 (LWP 31509)]
0x0069c8f0 in Perl_pp_aelem (my_perl=0x89b1008) at pp_hot.c​:3007
3007 IV elem = SvIV(elemsv);
(gdb) bt
#0 0x0069c8f0 in Perl_pp_aelem (my_perl=0x89b1008) at pp_hot.c​:3007
#1 0x00697937 in Perl_runops_standard (my_perl=0x89b1008)
at run.c​:37
#2 0x00712860 in sortcv_stacked (my_perl=0x89b1008, a=0x89cd5c0,
b=0x89cd5cc) at pp_sort.c​:1791
#3 0x0071065e in S_mergesortsv (my_perl=0x89b1008, base=Variable
"base" is not available.
)
at pp_sort.c​:429
#4 0x007119d2 in Perl_sortsv (my_perl=0x89b1008, array=0x89d1a10,
nmemb=4, cmp=0x7127f1 <sortcv_stacked>) at pp_sort.c​:1458
#5 0x007120b7 in Perl_pp_sort (my_perl=0x89b1008) at pp_sort.c​:1685
#6 0x00697937 in Perl_runops_standard (my_perl=0x89b1008)
at run.c​:37
#7 0x0063d989 in perl_run (my_perl=0x89b1008) at perl.c​:2367
#8 0x080492f4 in main (argc=3, argv=0xbfe9a544, env=0xbfe9a554)
at perlmain.c​:99
(gdb) q

The test program is 100% repeatable. I extracted it from a larger
program where I get intermittent problems depending on the input (but
always in the sort routine).

For a different input I got a different traceback​:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208793408 (LWP 31157)]
0x008c6ccd in Perl_mg_get (my_perl=0x81f7008, sv=0x8506ac0)
at mg.c​:164
164 newmg = cur = head = mg = SvMAGIC(sv);
(gdb) bt
#0 0x008c6ccd in Perl_mg_get (my_perl=0x81f7008, sv=0x8506ac0)
at mg.c​:164
#1 0x008e8695 in Perl_sv_setsv_flags (my_perl=0x81f7008,
dstr=0x821e200, sstr=Variable "sstr" is not available.
) at sv.c​:3856
#2 0x008e9d2b in Perl_sv_mortalcopy (my_perl=0x81f7008,
oldstr=0x8506ac0) at sv.c​:6814
#3 0x008d8b81 in Perl_pp_aelem (my_perl=0x81f7008) at pp_hot.c​:3055
#4 0x008d3937 in Perl_runops_standard (my_perl=0x81f7008)
at run.c​:37
#5 0x0094e860 in sortcv_stacked (my_perl=0x81f7008, a=0x876a934,
b=0x876a868) at pp_sort.c​:1791
#6 0x0094c65e in S_mergesortsv (my_perl=0x81f7008, base=Variable
"base" is not available.
)
at pp_sort.c​:429
#7 0x0094d9d2 in Perl_sortsv (my_perl=0x81f7008, array=0x8506ab0,
nmemb=4, cmp=0x94e7f1 <sortcv_stacked>) at pp_sort.c​:1458
#8 0x0094e0b7 in Perl_pp_sort (my_perl=0x81f7008) at pp_sort.c​:1685
#9 0x008d3937 in Perl_runops_standard (my_perl=0x81f7008)
at run.c​:37
#10 0x00879989 in perl_run (my_perl=0x81f7008) at perl.c​:2367
#11 0x080492f4 in main (argc=6, argv=0xbfe54dd4, env=0xbfe54df0)
at perlmain.c​:99

(I didn't isolate this to a test kernel.)

Any suggestions?

Thanks,
-John Heidemann

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags​:
category=core
severity=high
---
This perlbug was built using Perl v5.8.8 in the Red Hat build system.
It is being executed now by Perl v5.8.8 - Wed Mar 1 18​:29​:13 EST 2006.

Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Wed Mar 1 18​:29​:13 EST 2006.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration​:
Platform​:
osname=linux, osvers=2.6.9-22.18.bz155725.elsmp, archname=i386-linux-thread-multi
uname='linux hs20-bc1-6.build.redhat.com 2.6.9-22.18.bz155725.elsmp #1 smp thu nov 17 15​:34​:08 est 2005 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 5.8.4 5.8.3 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler​:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.1.0 20060228 (Red Hat 4.1.0-1)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries​:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.90.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.90'
Dynamic Linking​:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches​:

---
@​INC for perl v5.8.8​:
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl/5.8.7
/usr/lib/perl5/site_perl/5.8.6
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8
/usr/lib/perl5/vendor_perl/5.8.7
/usr/lib/perl5/vendor_perl/5.8.6
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/5.8.8
.

---
Environment for perl v5.8.8​:
HOME=/home/johnh
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH=/usr/local/lib
LOGDIR (unset)
PATH=/home/johnh/BIN​:/home/johnh/BIN/LINUX​:/usr/local/bin​:/bin​:/usr/bin​:/home/johnh/BIN/WP​:/home/johnh/BIN/HOSTS​:/home/johnh/BIN/DB​:/usr/X11R6/bin​:/usr/local/etc​:/usr/local/sbin​:/etc​:/usr/etc​:/sbin​:/usr/sbin​:/usr/hosts​:/usr/local/games​:/usr/games
PERL_BADLANG (unset)
SHELL=/bin/bash

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.9.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.0, AIX 4.3 & 5.2, and Cygwin. http​://qa.perl.org
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org
  http​://www.goldmark.org/jeff/stupid-disclaimers/

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

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

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From @tamias

On Thu, Jun 08, 2006 at 09​:23​:41PM -0700, johnh @​ isi. edu wrote​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.

I get a segfault in 5.8.7, but it works fine in 5.8.3.

Ronald

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From @rgs

johnh@​isi.edu (via RT) wrote​:

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

I don't understand the algorithm, but making a copy of @​match_indices
and using that in sort_by_index() solves the problem.

Also, the $$ is necessary for this problem. Might be related to some
unclean things perl does to pass arguments to the sort routine
rapidly...
--

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From johnh@isi.edu

On Fri, 09 Jun 2006 08​:59​:10 PDT, "Rafael Garcia-Suarez via RT" wrote​:

johnh@​isi.edu (via RT) wrote​:

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

I don't understand the algorithm, but making a copy of @​match_indices
and using that in sort_by_index() solves the problem.

Also, the $$ is necessary for this problem. Might be related to some
unclean things perl does to pass arguments to the sort routine
rapidly...
--

the ($$) is not required. I get the same segfault with​:

sub sort_by_index {
  return $scores[$match_indices[$a]] cmp $scores[$match_indices[$b]];
}

(on perl-5.8.8 / fedora core 5).

  -John

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From johnh@isi.edu

On Fri, 09 Jun 2006 08​:49​:56 PDT, "Ronald J Kimball via RT" wrote​:

On Thu, Jun 08, 2006 at 09​:23​:41PM -0700, johnh @​ isi. edu wrote​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.

I get a segfault in 5.8.7, but it works fine in 5.8.3.

For me, the bug was inconsistent. Depending on the arguments passed
to the larger program, sometimes it was triggered and sometimes not.

A colleague of mine pointed out that there are two bugs here​:
1. perl shouldn't (ever) segfault
2. the code doesn't do quite what I thought it should

It actually has a mistaken double indirection. The subroutine should
just be​:

sub sort_by_index($$) {
  my($A,$B) = @​_;
  return $scores[$A] cmp $scores[$B];
}

Fixing bug #2, which conincidently makes the segfault go away for me.

I'll leave the original code and bug #1 to you folks, since I don't
know perl internals :-)

  -John

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2006

From @gbarr

On Fri, June 9, 2006 10​:59 am, Rafael Garcia-Suarez wrote​:

johnh@​isi.edu (via RT) wrote​:

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

I don't understand the algorithm, but making a copy of @​match_indices
and using that in sort_by_index() solves the problem.

That because sort is modifying @​match_indices as it goes because it
detected that the result is being assigned to the same array being sorted.

Simply assigning to a different array also solves it.

Try adding warn join(",",@​match_indices); into sort_by_index and see what
you get.

It would seem that when doing sort in-place that the array is at times in
a non-consistent state.

Graham.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 10, 2006

From @salva

Rafael Garcia-Suarez wrote​:

johnh@​isi.edu (via RT) wrote​:

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

I don't understand the algorithm, but making a copy of @​match_indices
and using that in sort_by_index() solves the problem.

Also, the $$ is necessary for this problem. Might be related to some
unclean things perl does to pass arguments to the sort routine
rapidly...

This is probably related to

  @​data = sort compare @​data;

being optimized into

  sort_inplace compare @​data;

that causes @​data to be in an inconsistent state when accessed from
&compare.

The solution may be to remove the optimization or to disallow access to
@​data from inside the sort in some way (using magic or localizing it to
something that croaks when accessed).

Cheers,

  - Salva

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 11, 2006

From @iabyn

On Sat, Jun 10, 2006 at 09​:33​:08AM +0200, Salvador Fandiño wrote​:

This is probably related to

@​data = sort compare @​data;

being optimized into

sort_inplace compare @​data;

that causes @​data to be in an inconsistent state when accessed from
&compare.

The solution may be to remove the optimization or to disallow access to
@​data from inside the sort in some way (using magic or localizing it to
something that croaks when accessed).

Yes, the mergesort stores temporary (non-SV) pointers in the SV** array
while sorting. (Hmm, that should nicely mess up -Dsv output too).

I think the fix is to, in the presence of a sort function, memcopy the
AvARRAY onto the stack and then sort that, then copy back to AvARRAY.

Note that this is still a lot more efficient than the unoptimised
@​a = sort @​a, which created a copy of every element, then deleted each
original element.

I'll fix this when I get some time.

--
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 11, 2006

From david@landgren.net

John Heidemann wrote​:

On Fri, 09 Jun 2006 08​:49​:56 PDT, "Ronald J Kimball via RT" wrote​:

On Thu, Jun 08, 2006 at 09​:23​:41PM -0700, johnh @​ isi. edu wrote​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.
I get a segfault in 5.8.7, but it works fine in 5.8.3.

For me, the bug was inconsistent. Depending on the arguments passed
to the larger program, sometimes it was triggered and sometimes not.

A colleague of mine pointed out that there are two bugs here​:
1. perl shouldn't (ever) segfault

Agreed.

2. the code doesn't do quite what I thought it should

It actually has a mistaken double indirection. The subroutine should
just be​:

sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$A] cmp $scores[$B];
}

I would also lose the prototypes, and the assignment from @​_ to $A and
$B. You are introducing an unnecessary slowdown, since a sort comparator
is considered to be so expensive that perl already arranges to have an
$a and $b set up when the routine is called, to lessen the cost.

I can't think of any reason off-hand why one would want to remove this
optimisation.

David
--
hope still, a little resistance always maybe stubborn tiny lights vs.
clustering darkness forever ok?

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 12, 2006

From @ysth

On Sun, Jun 11, 2006 at 10​:26​:23PM +0200, David Landgren wrote​:

John Heidemann wrote​:

On Fri, 09 Jun 2006 08​:49​:56 PDT, "Ronald J Kimball via RT" wrote​:

On Thu, Jun 08, 2006 at 09​:23​:41PM -0700, johnh @​ isi. edu wrote​:

----------------------------------------
#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.
I get a segfault in 5.8.7, but it works fine in 5.8.3.

For me, the bug was inconsistent. Depending on the arguments passed
to the larger program, sometimes it was triggered and sometimes not.

A colleague of mine pointed out that there are two bugs here​:
1. perl shouldn't (ever) segfault

Agreed.

2. the code doesn't do quite what I thought it should

It actually has a mistaken double indirection. The subroutine should
just be​:

sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$A] cmp $scores[$B];
}

I would also lose the prototypes, and the assignment from @​_ to $A and
$B. You are introducing an unnecessary slowdown, since a sort comparator
is considered to be so expensive that perl already arranges to have an
$a and $b set up when the routine is called, to lessen the cost.

I can't think of any reason off-hand why one would want to remove this
optimisation.

Where the sort_by_index resides in a different package.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 12, 2006

From jpl@research.att.com

David Landgren <david@​landgren.net> replied to John Heidemann <johnh@​isi.edu>​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

It segfaults for me on the last line, both with perl 5.8.8 on fedora
core 5, and with perl 5.8.6 on fedora core 4. I believe the bug goes
back to at least perl 5.6, but I don't have good notes.
I get a segfault in 5.8.7, but it works fine in 5.8.3.

For me, the bug was inconsistent. Depending on the arguments passed
to the larger program, sometimes it was triggered and sometimes not.

A colleague of mine pointed out that there are two bugs here​:
1. perl shouldn't (ever) segfault

Agreed.

2. the code doesn't do quite what I thought it should

It actually has a mistaken double indirection. The subroutine should
just be​:

sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$A] cmp $scores[$B];
}

Bug 1 trumps bug 2. During the sort, there's a second,
parallel, array allocated for the merge sort. The
original array and the parallel array swap roles as
the merging takes place. The array that doesn't
currently hold pointers to the original array elements
holds pointers into the other array, delimiting the
runs of sorted elements. Any attempt to use these
pointers to runs as pointers to array elements is
likely to come to grief. Grief will be intermittent​:
if you go into the original array when it is holding
the sorted runs, you'll be ok. If you go into it
when it holds pointers to the runs, Segfault City
(although even this will be intermittent, since there's
only one pointer per run, with other pointers still
referring to original array elements).

This may have crept in with the in-place optimization,
although it would be possible any time the comparison
routine had access to the original array. Such a
comparison routine is almost certainly in error,
because it violates the mandate that the comparison
routine be consistent, and, as elements move around
in the array during the sort, maintaining consistent
results would be nearly impossible.

It might be possible to fix this by keeping the
array pointer pointing to the "correct array",
but changing the identity of the array
(as might be seen by stringifying it)
during the sort operation seems wrong.

If possible, it would seem best to disallow references
to the array while the sort was ongoing, particularly
since they are almost certainly in error as above, but I don't
know if this is possible. Otherwise, the merge sort
implementation would need some major changes. -- jpl

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 12, 2006

From jpl@research.att.com

Dave Mitchell <davem@​iabyn.com> offered

Yes, the mergesort stores temporary (non-SV) pointers in the SV** array
while sorting. (Hmm, that should nicely mess up -Dsv output too).

I think the fix is to, in the presence of a sort function, memcopy the
AvARRAY onto the stack and then sort that, then copy back to AvARRAY.

Note that this is still a lot more efficient than the unoptimised
@​a = sort @​a, which created a copy of every element, then deleted each
original element.

Would it be possible to use magic to disable access to the array
(as opposed to elements of the array, which will obviously be
needed for all comparisons) while the sort is in progress?
It's hard to imagine a valid (in the sense of consistent
results) comparison routine referring to the array itself.
If true, we'd be doing people a favor to alert them to what
is almost certainly an error (as was the case in the original
bug report). -- jpl

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 12, 2006

From @hvds

"John P. Linderman" <jpl@​research.att.com> wrote​:
:This may have crept in with the in-place optimization,
:although it would be possible any time the comparison
:routine had access to the original array. Such a
:comparison routine is almost certainly in error,
:because it violates the mandate that the comparison
:routine be consistent, and, as elements move around
:in the array during the sort, maintaining consistent
:results would be nearly impossible.

But "in-place sorting with @​x = sort @​x" is an optimisation, and as such
it is surely our responsibility to ensure it acts the same way as without
the optimisation, ie to act as if the assignment to @​x happens atomically
after the sort has completed?

:It might be possible to fix this by keeping the
:array pointer pointing to the "correct array",
:but changing the identity of the array
:(as might be seen by stringifying it)
:during the sort operation seems wrong.
:
:If possible, it would seem best to disallow references
:to the array while the sort was ongoing, particularly
:since they are almost certainly in error as above, but I don't
:know if this is possible. Otherwise, the merge sort
:implementation would need some major changes. -- jpl

I doubt we can detect them (since they may occur via aliasing etc),
but if we can it would be better to disable the in-place optimisation
in that case rather than complain.

Hugo

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 12, 2006

From @iabyn

On Mon, Jun 12, 2006 at 05​:38​:31PM +0100, hv@​crypt.org wrote​:

I doubt we can detect them (since they may occur via aliasing etc),
but if we can it would be better to disable the in-place optimisation
in that case rather than complain.

I think my suggestion of the partial pessimistion of memcopying AvARRAY
onto the stack then back again should fix this. During the course of the
sort, any sort sub sees the original array.

--
"There's something wrong with our bloody ships today, Chatfield."
  -- Admiral Beatty at the Battle of Jutland, 31st May 1916.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented May 12, 2008

p5p@spam.wizbit.be - Status changed from 'open' to 'stalled'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 26, 2010

From @cpansprout

On Thu Jun 08 21​:23​:40 2006, johnh@​isi.edu wrote​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

This gives me​:
Bizarre copy of UNKNOWN in aelem at - line 12.
in commit 42bd538

d963bf0, three commits later (the
intervening commits affecting only documentation), gives
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[0] in array element at - line 12.

but I can’t see how it fixes it.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Sep 26, 2010

From [Unknown Contact. See original ticket]

On Thu Jun 08 21​:23​:40 2006, johnh@​isi.edu wrote​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

This gives me​:
Bizarre copy of UNKNOWN in aelem at - line 12.
in commit 42bd538

d963bf0, three commits later (the
intervening commits affecting only documentation), gives
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[0] in array element at - line 12.

but I can’t see how it fixes it.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented May 1, 2011

@cpansprout - Status changed from 'stalled' to 'open'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 12, 2016

From @dcollinsn

Some research into the history of this testcase​: Until 5.11.5, this was fine on the perls I'm able to build. In 5.11.5, it started throwing a segfault, in 5.13.4 this became a libc "aborted", in 5.17.10, it segfaulted again, and in 5.19.1, 5.19.3, and all later versions, it is fine EXCEPT for -thread-multi-debug builds, which still amazingly manage to kill libc​:

  *** Error in `perl5.25.2-thread-multi-debug'​: free()​: invalid next size (fast)​: 0x0000000000b1cd80 ***
  ======= Backtrace​: =========
  /lib/x86_64-linux-gnu/libc.so.6(+0x71fc5)[0x7fa577634fc5]
  /lib/x86_64-linux-gnu/libc.so.6(+0x77966)[0x7fa57763a966]
  /lib/x86_64-linux-gnu/libc.so.6(+0x7814e)[0x7fa57763b14e]
  perl5.25.2-thread-multi-debug(perl_free+0x59)[0x4503e9]
  perl5.25.2-thread-multi-debug(main+0x101)[0x41dbd1]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa5775e35f0]
  perl5.25.2-thread-multi-debug(_start+0x29)[0x41dc49]

Valgrind is very disappointed​:

  ==37049== Invalid read of size 4
  ==37049== at 0x542901​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x568C31​: Perl_sv_2iv_flags (sv.c​:2415)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x567457​: S_sv_2iuv_common (sv.c​:2128)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[2] in array element at 39358.pl line 10.
  ==37049== Invalid read of size 4
  ==37049== at 0x567A9D​: S_sv_2iuv_common (sv.c​:2389)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x55AF00​: Perl_sv_upgrade (sv.c​:1204)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 8
  ==37049== at 0x55AF3F​: Perl_sv_upgrade (sv.c​:1228)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891c8 is 0 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x55AFD9​: Perl_sv_upgrade (sv.c​:1316)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 4
  ==37049== at 0x55AFF3​: Perl_sv_upgrade (sv.c​:1317)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 8
  ==37049== at 0x55B0CD​: Perl_sv_upgrade (sv.c​:1325)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891c8 is 0 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 8
  ==37049== at 0x55B0F7​: Perl_sv_upgrade (sv.c​:1326)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d8 is 16 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x542952​: Perl_pp_aelem (pp_hot.c​:4031)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x542901​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x668926​: S_mergesortsv (pp_sort.c​:450)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[2] in array element at 39358.pl line 10.
  ==37049== Invalid read of size 4
  ==37049== at 0x542952​: Perl_pp_aelem (pp_hot.c​:4031)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x668926​: S_mergesortsv (pp_sort.c​:450)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[0] in array element at 39358.pl line 10.
  ==37049==
  ==37049== HEAP SUMMARY​:
  ==37049== in use at exit​: 3,778 bytes in 9 blocks
  ==37049== total heap usage​: 799 allocs, 790 frees, 221,967 bytes allocated
  ==37049==
  ==37049== LEAK SUMMARY​:
  ==37049== definitely lost​: 512 bytes in 1 blocks
  ==37049== indirectly lost​: 3,266 bytes in 8 blocks
  ==37049== possibly lost​: 0 bytes in 0 blocks
  ==37049== still reachable​: 0 bytes in 0 blocks
  ==37049== suppressed​: 0 bytes in 0 blocks
  ==37049== Rerun with --leak-check=full to see details of leaked memory
  ==37049==
  ==37049== For counts of detected and suppressed errors, rerun with​: -v
  ==37049== ERROR SUMMARY​: 17 errors from 13 contexts (suppressed​: 0 from 0)

Valgrind is equally disappointed for normal builds of 5.25.2, but they manage to avoid crashing through some stroke of luck. The valgrind errors are the same.

This looks to me like a sign of either modifying a value that is on the context stack, or modifying an array that is in the process of being sort()ed in-place. If the former, then this is a dependency of 77706. If the latter - I vaguely remember another ticket about modifying an array while it is being sorted, this is probably similar. There's some discussion at RT #127759 on that topic.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Jul 12, 2016

From [Unknown Contact. See original ticket]

Some research into the history of this testcase​: Until 5.11.5, this was fine on the perls I'm able to build. In 5.11.5, it started throwing a segfault, in 5.13.4 this became a libc "aborted", in 5.17.10, it segfaulted again, and in 5.19.1, 5.19.3, and all later versions, it is fine EXCEPT for -thread-multi-debug builds, which still amazingly manage to kill libc​:

  *** Error in `perl5.25.2-thread-multi-debug'​: free()​: invalid next size (fast)​: 0x0000000000b1cd80 ***
  ======= Backtrace​: =========
  /lib/x86_64-linux-gnu/libc.so.6(+0x71fc5)[0x7fa577634fc5]
  /lib/x86_64-linux-gnu/libc.so.6(+0x77966)[0x7fa57763a966]
  /lib/x86_64-linux-gnu/libc.so.6(+0x7814e)[0x7fa57763b14e]
  perl5.25.2-thread-multi-debug(perl_free+0x59)[0x4503e9]
  perl5.25.2-thread-multi-debug(main+0x101)[0x41dbd1]
  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa5775e35f0]
  perl5.25.2-thread-multi-debug(_start+0x29)[0x41dc49]

Valgrind is very disappointed​:

  ==37049== Invalid read of size 4
  ==37049== at 0x542901​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x568C31​: Perl_sv_2iv_flags (sv.c​:2415)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x567457​: S_sv_2iuv_common (sv.c​:2128)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[2] in array element at 39358.pl line 10.
  ==37049== Invalid read of size 4
  ==37049== at 0x567A9D​: S_sv_2iuv_common (sv.c​:2389)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x55AF00​: Perl_sv_upgrade (sv.c​:1204)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 8
  ==37049== at 0x55AF3F​: Perl_sv_upgrade (sv.c​:1228)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891c8 is 0 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x55AFD9​: Perl_sv_upgrade (sv.c​:1316)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 4
  ==37049== at 0x55AFF3​: Perl_sv_upgrade (sv.c​:1317)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 8
  ==37049== at 0x55B0CD​: Perl_sv_upgrade (sv.c​:1325)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891c8 is 0 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid write of size 8
  ==37049== at 0x55B0F7​: Perl_sv_upgrade (sv.c​:1326)
  ==37049== by 0x56796D​: S_sv_2iuv_common (sv.c​:2393)
  ==37049== by 0x56924A​: Perl_sv_2iv_flags (sv.c​:2487)
  ==37049== by 0x542925​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d8 is 16 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x542952​: Perl_pp_aelem (pp_hot.c​:4031)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x6688D4​: S_mergesortsv (pp_sort.c​:427)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  ==37049== Invalid read of size 4
  ==37049== at 0x542901​: Perl_pp_aelem (pp_hot.c​:4023)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x668926​: S_mergesortsv (pp_sort.c​:450)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[2] in array element at 39358.pl line 10.
  ==37049== Invalid read of size 4
  ==37049== at 0x542952​: Perl_pp_aelem (pp_hot.c​:4031)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x66A8B5​: S_sortcv_stacked (pp_sort.c​:1830)
  ==37049== by 0x668926​: S_mergesortsv (pp_sort.c​:450)
  ==37049== by 0x66DF43​: Perl_sortsv_flags (pp_sort.c​:1464)
  ==37049== by 0x66DF43​: Perl_pp_sort (pp_sort.c​:1694)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049== Address 0x5f891d4 is 12 bytes after a block of size 56 alloc'd
  ==37049== at 0x4C28C0F​: malloc (vg_replace_malloc.c​:299)
  ==37049== by 0x4FE7F8​: Perl_safesysmalloc (util.c​:153)
  ==37049== by 0x52EC85​: Perl_av_extend_guts (av.c​:186)
  ==37049== by 0x536617​: Perl_pp_aassign (pp_hot.c​:1375)
  ==37049== by 0x4FC479​: Perl_runops_debug (dump.c​:2239)
  ==37049== by 0x45BC43​: S_run_body (perl.c​:2521)
  ==37049== by 0x45BC43​: perl_run (perl.c​:2444)
  ==37049== by 0x41DC06​: main (perlmain.c​:123)
  ==37049==
  Use of uninitialized value $match_indices[0] in array element at 39358.pl line 10.
  ==37049==
  ==37049== HEAP SUMMARY​:
  ==37049== in use at exit​: 3,778 bytes in 9 blocks
  ==37049== total heap usage​: 799 allocs, 790 frees, 221,967 bytes allocated
  ==37049==
  ==37049== LEAK SUMMARY​:
  ==37049== definitely lost​: 512 bytes in 1 blocks
  ==37049== indirectly lost​: 3,266 bytes in 8 blocks
  ==37049== possibly lost​: 0 bytes in 0 blocks
  ==37049== still reachable​: 0 bytes in 0 blocks
  ==37049== suppressed​: 0 bytes in 0 blocks
  ==37049== Rerun with --leak-check=full to see details of leaked memory
  ==37049==
  ==37049== For counts of detected and suppressed errors, rerun with​: -v
  ==37049== ERROR SUMMARY​: 17 errors from 13 contexts (suppressed​: 0 from 0)

Valgrind is equally disappointed for normal builds of 5.25.2, but they manage to avoid crashing through some stroke of luck. The valgrind errors are the same.

This looks to me like a sign of either modifying a value that is on the context stack, or modifying an array that is in the process of being sort()ed in-place. If the former, then this is a dependency of 77706. If the latter - I vaguely remember another ticket about modifying an array while it is being sorted, this is probably similar. There's some discussion at RT #127759 on that topic.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @iabyn

On Sun, Sep 26, 2010 at 02​:39​:49PM -0700, Father Chrysostomos via RT wrote​:

On Thu Jun 08 21​:23​:40 2006, johnh@​isi.edu wrote​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

This gives me​:
Bizarre copy of UNKNOWN in aelem at - line 12.
in commit 42bd538

d963bf0, three commits later (the
intervening commits affecting only documentation), gives
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[0] in array element at - line 12.

but I can’t see how it fixes it.

Fixed now in blead by the following. The issue was as the bit below about
mergesort leaving random pointers lying about.

commit 84721d6
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Aug 10 15​:12​:56 2016 +0100
Commit​: David Mitchell <davem@​iabyn.com>
CommitDate​: Wed Aug 10 16​:34​:04 2016 +0100

  Partially pessimise in-place sorting
 
  There's currently an optimisation that converts at compile-time
 
  @​a = sort { .... } @​a
 
  into (approximately)
 
  sort { ... } \@​a
 
  Then at run time, rather than passing an svp pointer to the appropriate
  sort routine which points to a list of SV*'s on the stack, pp_sort()
  passes a pointer to @​a's AvARRAY. This allows the array to be sorted
  in-place, which is more efficient.
 
  However, it has some issues. First, the @​a visible to the sort routine
  will be varying, whereas logically it should still hold the original list
  of values until after the '@​a = ...' assignment.
 
  Secondly, the mergesort algorithm cureently used internally, when in
  mid-sort, temporarily stores pointers in the array which aren't pointers
  to SVs - this means that if @​a elements are accessed mid-sort, it can
  crash.
 
  The solution to both these problems is for pp_sort() to push the elements
  of @​a onto the stack at the beginning, sort the stack (like normal sorts
  do), then copy back to @​a at the end. This is less efficient than before,
  but is still a lot more efficient than executing separate padav and
  aassign ops.
 
  Here are benchmark results in raw instruction counts etc (lower is better)
  for the sort line in this code block​:
 
  my (@​a, @​b);
  @​a = reverse 1..10;
  @​b = sort { $a <=> $b } @​a;
 
  A is for a non-in-place sort, i.e. @​b = sort ... @​a;
  B and C are for an inline sort, i.e. as above, but @​a = sort ... @​a;
  where B is blead before this commit and C is this commit.
 
  A B C
  ------ ------ ------
  Ir 5238.0 2324.0 2772.0
  Dr 1464.0 649.0 765.0
  Dw 919.0 298.0 370.0
  COND 782.0 320.0 405.0
  IND 25.0 25.0 26.0
 
  COND_m 14.9 13.0 17.0
  IND_m 8.0 5.0 5.0
 
  As can be seen, this partial pessimisation slows down in-place sorting by
  round 20%, but overall in-place is still nearly twice the speed as without
  the optimisation.
 
  These are the figures for a plain numeric sort (which is optimised to use
  a C comparison function); for other types of sort, the cost of the
  comparator dominates, and so the slowdown is much less marked.

--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @khwilliamson

On 08/10/2016 09​:36 AM, Dave Mitchell wrote​:

On Sun, Sep 26, 2010 at 02​:39​:49PM -0700, Father Chrysostomos via RT wrote​:

On Thu Jun 08 21​:23​:40 2006, johnh@​isi.edu wrote​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

This gives me​:
Bizarre copy of UNKNOWN in aelem at - line 12.
in commit 42bd538

d963bf0, three commits later (the
intervening commits affecting only documentation), gives
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[2] in array element at - line 12.
Use of uninitialized value $match_indices[0] in array element at - line 12.

but I can’t see how it fixes it.

Fixed now in blead by the following. The issue was as the bit below about
mergesort leaving random pointers lying about.

commit 84721d6
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Aug 10 15​:12​:56 2016 +0100
Commit​: David Mitchell <davem@​iabyn.com>

blead is failing to compile for me unless I revert this, with the message​:

pp_sort.c​: In function ‘OP* Perl_pp_sort(PerlInterpreter*)’​:
pp_sort.c​:1599​:26​: error​: invalid conversion from ‘OP* {aka op*}’ to
‘char’ [-fpermissive]
  copytmps = PL_sortcop;

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @khwilliamson

On 08/10/2016 11​:48 AM, Karl Williamson wrote​:

On 08/10/2016 09​:36 AM, Dave Mitchell wrote​:

On Sun, Sep 26, 2010 at 02​:39​:49PM -0700, Father Chrysostomos via RT
wrote​:

On Thu Jun 08 21​:23​:40 2006, johnh@​isi.edu wrote​:

#!/usr/bin/perl -w

@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');

@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;
----------------------------------------

This gives me​:
Bizarre copy of UNKNOWN in aelem at - line 12.
in commit 42bd538

d963bf0, three commits later (the
intervening commits affecting only documentation), gives
Use of uninitialized value $match_indices[2] in array element at -
line 12.
Use of uninitialized value $match_indices[2] in array element at -
line 12.
Use of uninitialized value $match_indices[0] in array element at -
line 12.

but I can’t see how it fixes it.

Fixed now in blead by the following. The issue was as the bit below about
mergesort leaving random pointers lying about.

commit 84721d6
Author​: David Mitchell <davem@​iabyn.com>
AuthorDate​: Wed Aug 10 15​:12​:56 2016 +0100
Commit​: David Mitchell <davem@​iabyn.com>

blead is failing to compile for me unless I revert this, with the message​:

pp_sort.c​: In function ‘OP* Perl_pp_sort(PerlInterpreter*)’​:
pp_sort.c​:1599​:26​: error​: invalid conversion from ‘OP* {aka op*}’ to
‘char’ [-fpermissive]
copytmps = PL_sortcop;

It does compile with some options. Attached is a diff with, the options
it works with marked by '<', and those it doesn't, by '>'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @khwilliamson

6c6
< archname=x86_64-linux


archname=x86\_64\-linux\-thread\-multi\-ld

8c8
< config_args='-des -Uversiononly -Dprefix=/home/khw/devel -Dusedevel -Accflags='-DPERL_BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none -Accflags='-Werror=declaration-after-statement' -Accflags='-DNO_MATHOMS''


config\_args='\-des \-Uversiononly \-Dprefix=/home/khw/devel \-Dusedevel \-D'optimize=\-ggdb3' \-A'optimize=\-ggdb3' \-A'optimize=\-O0' \-Accflags='\-DPERL\_BOOL\_AS\_CHAR' \-Accflags='\-DPERL\_EXTERNAL\_GLOB' \-Dman1dir=none \-Dman3dir=none \-DDEBUGGING \-Dcc=g\+\+ \-Dusemorebits \-Dusethreads'

12,13c12,13
< useithreads=undef
< usemultiplicity=undef


useithreads=define
usemultiplicity=define

16c16
< uselongdouble=undef


uselongdouble=define

20,23c20,23
< cc='cc'
< ccflags ='-DPERL_BOOL_AS_CHAR -Werror=declaration-after-statement -DNO_MATHOMS -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
< optimize='-O2'
< cppflags='-DPERL_BOOL_AS_CHAR -Werror=declaration-after-statement -DNO_MATHOMS -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'


cc='g\+\+'
ccflags ='\-D\_REENTRANT \-D\_GNU\_SOURCE \-DPERL\_BOOL\_AS\_CHAR \-DPERL\_EXTERNAL\_GLOB \-fwrapv \-DDEBUGGING \-fno\-strict\-aliasing \-pipe \-fstack\-protector\-strong \-I/usr/local/include \-D\_LARGEFILE\_SOURCE \-D\_FILE\_OFFSET\_BITS=64 \-D\_FORTIFY\_SOURCE=2'
optimize=' \-ggdb3 \-O0'
cppflags='\-D\_REENTRANT \-D\_GNU\_SOURCE \-DPERL\_BOOL\_AS\_CHAR \-DPERL\_EXTERNAL\_GLOB \-fwrapv \-DDEBUGGING \-fno\-strict\-aliasing \-pipe \-fstack\-protector\-strong \-I/usr/local/include'

40,41c40,41
< nvtype='double'
< nvsize=8


nvtype='long double'
nvsize=16

44c44
< alignbytes=8


alignbytes=16

47c47
< ld='cc'


ld='g\+\+'

49c49
< libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib


libpth=/usr/include/c\+\+/5 /usr/include/x86\_64\-linux\-gnu/c\+\+/5 /usr/include/c\+\+/5/backward /usr/local/lib /usr/lib/gcc/x86\_64\-linux\-gnu/5/include\-fixed /usr/include/x86\_64\-linux\-gnu /usr/lib /lib/x86\_64\-linux\-gnu /lib/\.\./lib /usr/lib/x86\_64\-linux\-gnu /usr/lib/\.\./lib /lib

63c63
< lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'


lddlflags='\-shared \-ggdb3 \-ggdb3 \-O0 \-L/usr/local/lib \-fstack\-protector\-strong'

67a68

DEBUGGING

69c70
< NO_MATHOMS


MULTIPLICITY

73a75

PERL\_EXTERNAL\_GLOB

74a77

PERL\_IMPLICIT\_CONTEXT

77a81

PERL\_TRACK\_MEMPOOL

80a85

USE\_ITHREADS

86a92

USE\_LONG\_DOUBLE

88a95

USE\_REENTRANT\_API
@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @cpansprout

On Wed Aug 10 10​:49​:29 2016, public@​khwilliamson.com wrote​:

blead is failing to compile for me unless I revert this, with the
message​:

pp_sort.c​: In function ‘OP* Perl_pp_sort(PerlInterpreter*)’​:
pp_sort.c​:1599​:26​: error​: invalid conversion from ‘OP* {aka op*}’ to
‘char’ [-fpermissive]
copytmps = PL_sortcop;

Fixed in ff859a7.

--

Father Chrysostomos

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

@cpansprout - Status changed from 'open' to 'pending release'

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 10, 2016

From @jplinderman

#!/usr/bin/perl -w
@​scores = (
  '0000.0000.00039​:0000.0008.0031.',
  '0000.0000.00032​:0000.0008.0024.',
  '0002.0002.00033​:0002.0011.0020.',
  '0028.0028.00190​:0077.0085.0028.');
@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
  my($A,$B) = @​_;
  return $scores[$match_indices[$A]] cmp
  $scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

This could be "fixed" at the expense of allocating *two* extra arrays
instead of just one (which is already more than quicksort, which sorts "in
place"). But I wonder why people think that the contents of any array in
the process of being sorted can participate in any meaningful way in a
comparison. Must all sort implementations guarantee that the intermediate
contents of the array to be sorted are some permutation of the original
array? I don't like the idea of penalizing *all* users for the dubious
intent of *some* users. Segfaults are evil, of course. A better solution
would be to somehow mark an array as "off limits" while a sort is in
progress, but that's way beyond my pay grade.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 11, 2016

From @iabyn

On Wed, Aug 10, 2016 at 05​:03​:28PM -0400, John P. Linderman wrote​:

#!/usr/bin/perl -w
@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');
@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

This could be "fixed" at the expense of allocating *two* extra arrays
instead of just one (which is already more than quicksort, which sorts "in
place").

I don't understand any of the above sentence. Its just been fixed, so why
is it still "could be"? No extra arrays are created, and I don't
understand why creating an extra array would be of benefit.

But I wonder why people think that the contents of any array in
the process of being sorted can participate in any meaningful way in a
comparison. Must all sort implementations guarantee that the intermediate
contents of the array to be sorted are some permutation of the original
array?

In this code​:

  @​a = sort {...} @​a

at the logical perl level, a list is created from the contents of @​a,
sort returns a sorted version of that list, then that list is assigned
to @​a. If @​a gets modified during the sort itself (and before the
assignment), then that's internal optimisation details leaking out.

The internal quicksort and mergesort implementations sort a (C) array
of SV pointers - usually that array is just a chunk of perl's argument
stack. Before my commit, they someones also worked directly on an AvARRAY
array, which turned out to be a bad idea.

I don't like the idea of penalizing *all* users for the dubious
intent of *some* users. Segfaults are evil, of course. A better solution
would be to somehow mark an array as "off limits" while a sort is in
progress, but that's way beyond my pay grade.

The previous code temporarily marked the array as readonly, which stopped
modification, but didn't stop access. The only way to stop reading would
be to temporarily tie the array. But this wuld be semantically wrong​:
there's nothing to imply in the expression

  something = sort { ... } @​a

that accessing @​a during the sort would be an error.

--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented Aug 11, 2016

From @jplinderman

I think we are in violent agreement. As you noted, long ago the internal
sort worked directly on an AvARRAY, and, when the sort algorithm was
quicksort, that was not a bad idea. The contents of that array could be
rearranged, but they always contained SV pointers. When I ported Peter
McIlroy's mergesort to Perl, I allocated another array of the same size,
and, during the initial pass, it held pointers into the original array to
delimit runs. On subsequent passes, however, the roles of the two arrays
were reversed, one holding the original SV pointers, the other pointers
into that array. So in every other pass, the original array held pointers
to things that were most assuredly not SV's. Accessing them as though they
were SV pointers generally lead to segfaults.

What I meant to say is that changes could have been made to the sort
routine so that an AvARRAY could continue to be the argument. The sort
could have allocated two extra arrays, and copied the original into one of
the arrays, so the contents of the original would never be anything other
than SV pointers. This would have cost extra copying and extra space, but
this is arguably better than risking segfaults. It appears you have paid
the copying and allocating expenses at a higher level, and I certainly have
no problem with that. It has the effect of making the copy of the array
that is participating in the sort "off limits".

The other point I was trying to make is that access to the SV pointers that
are in the process of being rearranged (now impossible) was always asking
for trouble. In the code in question

$match_indices[$A]

is simply $A, and would have been better written as such. If that
expression referenced a partially rearranged version of the original array,
then the comparison routine would probably "violate the contract". For
example, if the first two elements of @​match_indices were reversed, then
the sense of the comparison for elements 0 and 1 would also be reversed,
and the contract demands that the comparison routine be consistent when the
same two elements are compared.

In (not so very) short, comparison routines that reference the array that
is being sorted are probably not doing what the user expects.

On Thu, Aug 11, 2016 at 4​:11 AM, Dave Mitchell <davem@​iabyn.com> wrote​:

On Wed, Aug 10, 2016 at 05​:03​:28PM -0400, John P. Linderman wrote​:

#!/usr/bin/perl -w
@​scores = (
'0000.0000.00039​:0000.0008.0031.',
'0000.0000.00032​:0000.0008.0024.',
'0002.0002.00033​:0002.0011.0020.',
'0028.0028.00190​:0077.0085.0028.');
@​match_indices = (0,1,2,3);
sub sort_by_index($$) {
my($A,$B) = @​_;
return $scores[$match_indices[$A]] cmp
$scores[$match_indices[$B]];
}
@​match_indices = sort sort_by_index @​match_indices;

This could be "fixed" at the expense of allocating *two* extra arrays
instead of just one (which is already more than quicksort, which sorts
"in
place").

I don't understand any of the above sentence. Its just been fixed, so why
is it still "could be"? No extra arrays are created, and I don't
understand why creating an extra array would be of benefit.

But I wonder why people think that the contents of any array in
the process of being sorted can participate in any meaningful way in a
comparison. Must all sort implementations guarantee that the intermediate
contents of the array to be sorted are some permutation of the original
array?

In this code​:

@&#8203;a = sort \{\.\.\.\} @&#8203;a

at the logical perl level, a list is created from the contents of @​a,
sort returns a sorted version of that list, then that list is assigned
to @​a. If @​a gets modified during the sort itself (and before the
assignment), then that's internal optimisation details leaking out.

The internal quicksort and mergesort implementations sort a (C) array
of SV pointers - usually that array is just a chunk of perl's argument
stack. Before my commit, they someones also worked directly on an AvARRAY
array, which turned out to be a bad idea.

I don't like the idea of penalizing *all* users for the dubious
intent of *some* users. Segfaults are evil, of course. A better solution
would be to somehow mark an array as "off limits" while a sort is in
progress, but that's way beyond my pay grade.

The previous code temporarily marked the array as readonly, which stopped
modification, but didn't stop access. The only way to stop reading would
be to temporarily tie the array. But this wuld be semantically wrong​:
there's nothing to imply in the expression

something = sort \{ \.\.\. \} @&#8203;a

that accessing @​a during the sort would be an error.

--
"But Sidley Park is already a picture, and a most amiable picture too.
The slopes are green and gentle. The trees are companionably grouped at
intervals that show them to advantage. The rill is a serpentine ribbon
unwound from the lake peaceably contained by meadows on which the right
amount of sheep are tastefully arranged." -- Lady Croom, "Arcadia"

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented May 30, 2017

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release today of Perl 5.26.0, this and 210 other issues have been
resolved.

Perl 5.26.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.26.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT

This comment has been minimized.

Copy link
Collaborator Author

@p5pRT p5pRT commented May 30, 2017

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.