Setting $0 in eval_pv causes core dump #8977

p5pRT · 2007-07-24T13:15:50Z

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

Searchable as RT44129$

p5pRT · 2007-07-24T13:15:51Z

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;
}
---

Perl Info


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

p5pRT · 2012-06-22T16:30:19Z

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.

p5pRT · 2012-06-22T16:30:20Z

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

p5pRT · 2014-11-06T10:44:04Z

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

p5pRT · 2014-12-14T01:16:15Z

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

p5pRT · 2014-12-15T02:09:53Z

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

p5pRT · 2015-03-15T21:03:37Z

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/

p5pRT · 2018-01-17T21:49:52Z

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

p5pRT · 2018-01-17T22:45:16Z

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

p5pRT · 2018-06-23T15:27:51Z

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.

p5pRT · 2018-06-23T15:27:52Z

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

p5pRT closed this as completed Jun 23, 2018

p5pRT added Severity Low distro-Linux type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Setting $0 in eval_pv causes core dump #8977

Setting $0 in eval_pv causes core dump #8977

p5pRT commented Jul 24, 2007

p5pRT commented Jul 24, 2007

p5pRT commented Jun 22, 2012

p5pRT commented Jun 22, 2012

p5pRT commented Nov 6, 2014

p5pRT commented Dec 14, 2014

p5pRT commented Dec 15, 2014

p5pRT commented Mar 15, 2015

p5pRT commented Jan 17, 2018

p5pRT commented Jan 17, 2018

p5pRT commented Jun 23, 2018

p5pRT commented Jun 23, 2018

Setting $0 in eval_pv causes core dump #8977

Setting $0 in eval_pv causes core dump #8977

Comments

p5pRT commented Jul 24, 2007

p5pRT commented Jul 24, 2007

From perlbug@daveola.com

Created by perlbug@daveola.com

p5pRT commented Jun 22, 2012

From @doy

p5pRT commented Jun 22, 2012

p5pRT commented Nov 6, 2014

From hans@freitag-consulting.de

p5pRT commented Dec 14, 2014

From @wolfsage

p5pRT commented Dec 15, 2014

From @Leont

p5pRT commented Mar 15, 2015

From perlbug@daveola.com

p5pRT commented Jan 17, 2018

From zefram@fysh.org

p5pRT commented Jan 17, 2018

p5pRT commented Jun 23, 2018

From @khwilliamson

p5pRT commented Jun 23, 2018