From wolfgang.laun@alcatel.at

Created by Wolfgang.Laun@alcatel.at

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

Interesting​: The value assigned to $_ for a value that got spliced
away equals undef(). Using the (seemingly redundant) expression

  defined( $_ ) ? $_ : undef()

to define the map block return value avoids the segmentation fault.

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by root at Sat Mar 25 17:46:37 CET 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.12-20, archname=i586-linux
    uname='linux localhost.localdomain 2.2.12-20 #1 mon sep 27 10:25:54 edt 1999 i586 unknown '
    config_args='-de'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define 
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    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, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.2.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.0:
    /usr/local/lib/perl5/5.6.0/i586-linux
    /usr/local/lib/perl5/5.6.0
    /usr/local/lib/perl5/site_perl/5.6.0/i586-linux
    /usr/local/lib/perl5/site_perl/5.6.0
    /usr/local/lib/perl5/site_perl/5.5.670/i586-linux
    /usr/local/lib/perl5/site_perl/5.5.670
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.6.0:
    HOME=/home/laune
    LANG=en
    LANGUAGE (unset)
    LC_ALL=en_US
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin:/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/usr/X11R6/bin:/home/laune/bin:/usr/X11R6/bin:/home/laune/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

From @gsar

On Fri, 30 Jun 2000 17​:50​:58 +0200, Wolfgang Laun wrote​:

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

The array that's being iterated over in grep/map/foreach should
probably be marked readonly for the duration of the iteration.

Patch welcome.

Sarathy
gsar@​ActiveState.com

From @smpeters

[RT_System - Tue Jul 04 01​:44​:33 2000]​:

On Fri, 30 Jun 2000 17​:50​:58 +0200, Wolfgang Laun wrote​:

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

The array that's being iterated over in grep/map/foreach should
probably be marked readonly for the duration of the iteration.

Patch welcome.

Sarathy
gsar@​ActiveState.com

Cool! The new panic recently added caught this case.

steve@​kirk​:~/perl-fix$ ./perl rt_3451.pl
panic​: sv_upgrade to unknown type 255 at rt_3451.pl line 2.

From @rgarcia

On 5 Jul 2005 10​:22​:53 -0000, Steve Peters via RT
<perlbug-followup@​perl.org> wrote​:

Cool! The new panic recently added caught this case.

steve@​kirk​:~/perl-fix$ ./perl rt_3451.pl
panic​: sv_upgrade to unknown type 255 at rt_3451.pl line 2.

That's not a fix. This bad upgrade really shouldn't happen, and
probably indicates access to corrupted memory or something. So the
risk of segfault is probably still there.

From @smpeters

On Tue, Jul 05, 2005 at 06​:28​:49PM +0200, Rafael Garcia-Suarez wrote​:

On 5 Jul 2005 10​:22​:53 -0000, Steve Peters via RT
<perlbug-followup@​perl.org> wrote​:

Cool! The new panic recently added caught this case.

steve@​kirk​:~/perl-fix$ ./perl rt_3451.pl
panic​: sv_upgrade to unknown type 255 at rt_3451.pl line 2.

That's not a fix. This bad upgrade really shouldn't happen, and
probably indicates access to corrupted memory or something. So the
risk of segfault is probably still there.

Sorry, I should have been more clear. Its not a fix, but we do have a
good idea as to why the segfault did occur. A little more detective
work is needed to fix the actual problem.

From @gannett-ggreer

On Tue Jul 05 09​:57​:36 2005, stmpeters wrote​:

On Tue, Jul 05, 2005 at 06​:28​:49PM +0200, Rafael Garcia-Suarez wrote​:

On 5 Jul 2005 10​:22​:53 -0000, Steve Peters via RT
<perlbug-followup@​perl.org> wrote​:

Cool! The new panic recently added caught this case.

steve@​kirk​:~/perl-fix$ ./perl rt_3451.pl
panic​: sv_upgrade to unknown type 255 at rt_3451.pl line 2.

That's not a fix. This bad upgrade really shouldn't happen, and
probably indicates access to corrupted memory or something. So the
risk of segfault is probably still there.

Sorry, I should have been more clear. Its not a fix, but we do have a
good idea as to why the segfault did occur. A little more detective
work is needed to fix the actual problem.

On the upside, in the 5 years since it now results in​:

panic​: attempt to copy freed scalar 1018d48 to 1018b98 at /tmp/rt3451
line 4.

Given v5.13.2-306-gce1e4fd, I get​:

Breakpoint 1, Perl_sv_setsv_flags (dstr=0x9f2a40, sstr=0x9dc0e0,
flags=1538) at sv.c​:3817
3817 Perl_croak(aTHX_ "panic​: attempt to copy freed scalar %p to %p",
(gdb) bt
#0 Perl_sv_setsv_flags (dstr=0x9f2a40, sstr=0x9dc0e0, flags=1538) at
sv.c​:3817
#1 0x00000000005a7ede in Perl_sv_mortalcopy (oldstr=0x9dc0e0) at sv.c​:7762
#2 0x0000000000555be3 in Perl_pp_leave () at pp_hot.c​:1903
#3 0x0000000000508320 in Perl_runops_debug () at dump.c​:2106
#4 0x000000000044d815 in S_run_body (oldscope=1) at perl.c​:2309
#5 0x000000000044cc75 in perl_run (my_perl=0x9d9010) at perl.c​:2233
#6 0x0000000000420c74 in main (argc=4, argv=0x7fffffffe278,
  env=0x7fffffffe2a0) at perlmain.c​:117

(at #2) p **mark
$4 = {sv_any = 0x9f2a58, sv_refcnt = 0, sv_flags = 255, sv_u = {
  svu_pv = 0x9edb20 "\020e\240", svu_iv = 10410784, svu_uv = 10410784,
  svu_rv = 0x9edb20, svu_array = 0x9edb20, svu_hash = 0x9edb20,
  svu_gp = 0x9edb20, svu_fp = 0x9edb20}}

Skipping freed SVs during leave seems too easy and not 'completely
correct', so I may investigate more.

--
George Greer

From @cpansprout

On Fri Jun 30 02​:51​:35 2000, laune wrote​:

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

Is this another symptom of the stack’s failure to count references?

From [Unknown Contact. See original ticket]

On Fri Jun 30 02​:51​:35 2000, laune wrote​:

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

Is this another symptom of the stack’s failure to count references?

From @ikegami

On Sun, Oct 10, 2010 at 7​:54 PM, Father Chrysostomos via RT <
perlbug-comment@​perl.org> wrote​:

On Fri Jun 30 02​:51​:35 2000, laune wrote​:

I know that modifying the list from a map of foreach is a no-no,
but​: The following program crashes with a segmentation fault,
and this is something that should not happen, right?

#! /usr/bin/perl -w
use strict;
my @​a = ( 'abc', 'def', 'ghi' );
@​a = map { splice( @​a, 0 ); $_ } ( @​a );
print "done​: @​a\n";

Is this another symptom of the stack’s failure to count references?

Yes.

I get "panic​: attempt to copy freed scalar", which means something was freed
prematurely, and Dump($a[0]) shows a refcnt of 1 before the splice, meaning
it would be freed by the splice and not available via $_.