From perlbug@daveola.com

Created by perlbug@daveola.com

Setting $0 in an embedded perl script (such as with eval_pv) causes
a segfault.

Example case​:

---
#include <EXTERN.h>
#include <perl.h>

int
main(int argc, char **argv, char **env) {
  PerlInterpreter *my_perl;
  char *arg[] = { "", "-e", "" };

  my_perl = perl_alloc();
  perl_construct(my_perl);
  if (perl_parse(my_perl, NULL, 3, arg, (char **)NULL)) {
  fprintf(stderr,"Trouble opening perl parser\n");
  return -1;
  }

  eval_pv( "$0='fubar'" , G_VOID);

  perl_destruct(my_perl);
  perl_free(my_perl);
  return 0;
}
---

Flags:
    category=core
    severity=low

Site configuration information for perl v5.8.4:

Configured by Debian Project at Wed May 10 04:14:05 UTC 2006.

Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
  Platform:
    osname=linux, osvers=2.6.15.6, archname=i386-linux-thread-multi
    uname='linux ernie 2.6.15.6 #1 thu mar 16 13:11:55 est 2006 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.4 -Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des'
    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='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-13)', 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='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.4
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.4:
    /etc/perl
    /usr/local/lib/perl/5.8.4
    /usr/local/share/perl/5.8.4
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.8
    /usr/share/perl/5.8
    /usr/local/lib/site_perl
    .


Environment for perl v5.8.4:
    HOME=/home/dave
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=.:/home/dave/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/sbin:/WWW/web/MarginalHacks.com/bin
    PERL_BADLANG (unset)
    SHELL=/usr/bin/tcsh

From @doy

This is still true in blead. The segfault happens at the memcpy call here​:

  Copy(s, PL_origargv[0], PL_origalen-1, char);

which is currently mg.c​:3011 (as of revision 83f29af). According to gdb,
PL_origargv[0] is "", but PL_origalen is 4.

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

From hans@freitag-consulting.de

Hello together,

I am on the look why two well probed Perl script are either coredumping,crashing,producing unforseeable errors, since we
patched AIX 6.1 to a recent verstion.

After tracing back the calls (which is difficult because you never know which of the good calls is the bad one) we came about a line of
perl code​:

my $obj=eval "someclass->new(\$someparam)";

which has some similaritys to the eval that is reported in this bug.

eval_pv( "$0='fubar'" , G_VOID);

We are still trying to get the problem reproduced, because the Application is a bit bigger, and it also does not fail always. But we have tried different Perl versions, from the 5.8 os version up to a self compiled 5.20.1.
However the same program is running fine for years now on AIX as well as on Linux/Solaris and even Windows.

regards

  Hans

From @wolfsage

On Fri, Jun 22, 2012 at 12​:30 PM, Jesse Luehrs via RT
<perlbug-followup@​perl.org> wrote​:

This is still true in blead. The segfault happens at the memcpy call here​:

Copy(s, PL_origargv[0], PL_origalen-1, char);

which is currently mg.c​:3011 (as of revision 83f29af). According to gdb,
PL_origargv[0] is "", but PL_origalen is 4.

I think this is because arg is declared as​:

  char *arg[] = { "", "-e", "" };

And the code in perl_parse says​: (
http​://perl5.git.perl.org/perl.git/blob/HEAD​:/perl.c#l1489 )

  1489 /* Set PL_origalen be the sum of the contiguous argv[]
  1490 * elements plus the size of the env in case that it is
  1491 * contiguous with the argv[]. This is used in
mg.c​:Perl_magic_set()
  1492 * as the maximum modifiable length of $0.

I *think* the real issue here is that declaring​:

  char *arg[] = { "", "-e", ""};

seems to make arg[0] a const string, and so unwritable. But how can we
solve for that?

Here's example of similar behaviour​:

  mhorsfall@​tworivers​:~$ cat uh.c
  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>

  int main(void) {
  char *arg[] = { "hello\0" };
  printf("%s\n", arg[0]);

  strcpy(arg[0], "h\0");

  printf("%s\n", arg[0]);

  return 0;
  }

  mhorsfall@​tworivers​:~$ gcc uh.c
  mhorsfall@​tworivers​:~$ ./a.out
  hello
  Segmentation fault (core dumped)

If I turn on -Wwrite-strings, we get some info that seems to verify my theory​:

  mhorsfall@​tworivers​:~$ gcc -Wwrite-strings uh.c
  uh.c​: In function ‘main’​:
  uh.c​:6​:3​: warning​: initialization discards ‘const’ qualifier from
pointer target type [enabled by default]
  char *arg[] = { "hello\0" };

Likewise for the test code in the bug​:

  mhorsfall@​tworivers​:~$ cc -Wwrite-strings -o break break.c
`./blead-debug/bin/perl5.21.5 -MExtUtils​::Embed -e ccopts -eldopts`
  break.c​: In function ‘main’​:
  break.c​:12​:3​: warning​: initialization discards ‘const’ qualifier
from pointer target type [enabled by default]
  char *arg[] = { "", "-e", "" };
  ^
  break.c​:12​:3​: warning​: initialization discards ‘const’ qualifier
from pointer target type [enabled by default]
  break.c​:12​:3​: warning​: initialization discards ‘const’ qualifier
from pointer target type [enabled by default]

-- Matthew Horsfall (alh

From @Leont

On Sun, Dec 14, 2014 at 2​:15 AM, Matthew Horsfall (alh) <wolfsage@​gmail.com>
wrote​:

I think this is because arg is declared as​:

char *arg[] = { "", "-e", "" };

And the code in perl_parse says​: (
http​://perl5.git.perl.org/perl.git/blob/HEAD​:/perl.c#l1489 )

1489 /* Set PL_origalen be the sum of the contiguous argv[]
1490 * elements plus the size of the env in case that it is
1491 * contiguous with the argv[]. This is used in
mg.c​:Perl_magic_set()
1492 * as the maximum modifiable length of $0.

I *think* the real issue here is that declaring​:

char *arg[] = { "", "-e", ""};

seems to make arg[0] a const string, and so unwritable.

arg[0] is a non-const pointer to a value that should be non-const but isn't
in this case.

But how can we
solve for that?

char *arg[] = { argv[0], "-e", ""};

would be a pretty good start probably. Possibly we should update perlembed
to that effect.

Leon

From perlbug@daveola.com

Yes, this is the reason, a strdup takes the segfault away and all is right in the world.

I can use a non-const string in my code (such as through strdup), but one could argue that either the docs need to specify this, the code needs to require a non-const string, or else the perl code should strdup in perl_parse.

--
David Ljung Madison
http​://GetDave.com/ http​://MarginalHacks.com/ http​://DaveSource.com/

From zefram@fysh.org

In addition to the string constant writability issue, the requestor's
usage is erroneous in not terminating the argv array with a null pointer.

I've documented the need for writable argv strings in commit
a3e261d. This ticket can be closed.

-zefram

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

From @khwilliamson

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

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

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

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

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