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

Using ARGV can cause core dump #2664

Closed
p5pRT opened this issue Sep 29, 2000 · 5 comments
Closed

Using ARGV can cause core dump #2664

p5pRT opened this issue Sep 29, 2000 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 29, 2000

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

Searchable as RT4356$

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2000

From jlawrenc@infonium.com

Created by jlawrenc@infonium.com

By assigning $ARGV[1] to a variable​:
$lang=$ARGV[1] || "e";
and then later using it in hash references​:
$blort{'e'}="Happy day"
print $blort{$lang}
I sometimes core dump.

Work around by creating new string from value of $ARGV[1] thus
breaking reference?​:
$lang="$ARGV[1]" || "e";
core dump goes away.

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.6.0:

Configured by root at Wed Jul 26 11:45:39 EDT 2000.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.2.16-3, archname=i586-linux
    uname='linux infonium.com 2.2.16-3 #1 mon jun 19 18:10:14 edt 2000 i586 unknown '
    config_args='-de -Dprefix=/usr -Duselargefiles=undef'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=undef 
    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'
    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=4
    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 -ldl -lm -lc -lposix -lcrypt
    libc=/lib/libc-2.1.3.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/lib/perl5/5.6.0/i586-linux
    /usr/lib/perl5/5.6.0
    /usr/lib/perl5/site_perl/5.6.0/i586-linux
    /usr/lib/perl5/site_perl/5.6.0
    /usr/lib/perl5/site_perl
    .


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


@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2000

From @vanstyn

In <20000930070622.3588.qmail@​infonium.com>, jlawrenc@​infonium.com writes​:
:By assigning $ARGV[1] to a variable​:
: $lang=$ARGV[1] || "e";
:and then later using it in hash references​:
: $blort{'e'}="Happy day"
: print $blort{$lang}
:I sometimes core dump.

That seems very strange. If you can find a way of making it reliably
reproducible and then cut it down to a small test case it would be
very helpful. It initially sounds as if the original system memory
for the arguments is being moved out from under you, but as far as I
can see the arguments are _copied_ into newly acquired memory when
setting up the ARGV array. (In 5.6.0 this should be done by the code​:
  SV *sv = newSVpv(argv[0],0);
at line 3180 of perl.c).

If that is the case, it sounds likely to be a more random corruption
that just happens to be hitting this variable. If so, I'd expect
you to see other variables causing a coredump from time to time as
well. This shouldn't be happening. :)

Hugo

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2000

From [Unknown Contact. See original ticket]

My initial comment about ARGV is wrong - I must have hit something magical
*somewhere* else! Alas, I don't think you're gonna be able to repeat it.

This is most odd. I have a program that can cause dump in question but if
I make the slightest code change then it works fine.

- Adding a print statement to beginning of code make it work
- commenting out some statement makes it work
- renaming program makes it work (!!!)
- running on difference machine works - basically same perl build
  except faulty is on i586 Linux 2.2.16 and successful is on i686 2.2.14
- running under debug works

- reording statements - same problem - core dump
- changing text of a variable assignment - same problem - core dump
- renaming its directory - same problem

If you want me to try any other sort of diagnostics I'll hold on to it.

Cheers,
Jay

On Fri, 29 Sep 2000, Hugo wrote​:

In <20000930070622.3588.qmail@​infonium.com>, jlawrenc@​infonium.com writes​:
:By assigning $ARGV[1] to a variable​:
: $lang=$ARGV[1] || "e";
:and then later using it in hash references​:
: $blort{'e'}="Happy day"
: print $blort{$lang}
:I sometimes core dump.

That seems very strange. If you can find a way of making it reliably
reproducible and then cut it down to a small test case it would be
very helpful. It initially sounds as if the original system memory
for the arguments is being moved out from under you, but as far as I
can see the arguments are _copied_ into newly acquired memory when
setting up the ARGV array. (In 5.6.0 this should be done by the code​:
SV *sv = newSVpv(argv[0],0);
at line 3180 of perl.c).

If that is the case, it sounds likely to be a more random corruption
that just happens to be hitting this variable. If so, I'd expect
you to see other variables causing a coredump from time to time as
well. This shouldn't be happening. :)

Hugo

@p5pRT
Copy link
Author

p5pRT commented Dec 31, 2004

From @smpeters

[RT_System - Fri Sep 29 07​:23​:11 2000]​:

My initial comment about ARGV is wrong - I must have hit something magical
*somewhere* else! Alas, I don't think you're gonna be able to repeat it.

This is most odd. I have a program that can cause dump in question but if
I make the slightest code change then it works fine.

- Adding a print statement to beginning of code make it work
- commenting out some statement makes it work
- renaming program makes it work (!!!)
- running on difference machine works - basically same perl build
except faulty is on i586 Linux 2.2.16 and successful is on i686 2.2.14
- running under debug works

- reording statements - same problem - core dump
- changing text of a variable assignment - same problem - core dump
- renaming its directory - same problem

If you want me to try any other sort of diagnostics I'll hold on to it.

Cheers,
Jay

On Fri, 29 Sep 2000, Hugo wrote​:

In <20000930070622.3588.qmail@​infonium.com>, jlawrenc@​infonium.com
writes​:
:By assigning $ARGV[1] to a variable​:
: $lang=$ARGV[1] || "e";
:and then later using it in hash references​:
: $blort{'e'}="Happy day"
: print $blort{$lang}
:I sometimes core dump.

That seems very strange. If you can find a way of making it reliably
reproducible and then cut it down to a small test case it would be
very helpful. It initially sounds as if the original system memory
for the arguments is being moved out from under you, but as far as I
can see the arguments are _copied_ into newly acquired memory when
setting up the ARGV array. (In 5.6.0 this should be done by the code​:
SV *sv = newSVpv(argv[0],0);
at line 3180 of perl.c).

If that is the case, it sounds likely to be a more random corruption
that just happens to be hitting this variable. If so, I'd expect
you to see other variables causing a coredump from time to time as
well. This shouldn't be happening. :)

Hugo

Requestor is unable to reproduce the core dump.

@p5pRT
Copy link
Author

p5pRT commented Dec 31, 2004

@smpeters - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant