Core dump on simple instruction

[p5pRT]

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

Searchable as RT33003$

[p5pRT]

From jk@smartguide.com.au

Created by jkt@smartguide.com.au

The following line makes Perl dump core​:

  $#a>>=1;

if @​a is empty (or undefined). This seemed to me a legimiate way to halve the length of a list. Obviously $#a/=2 has the same effect and does not dump core when the list is empty and of course the list can always be tested first for non-emptiness\, so this is not at all critical\, but it has been this way since 5.0 so I thought I would report it.

Perl Info

``` Flags: category=core severity=low Site configuration information for perl v5.8.3: Configured by bhcompile at Thu Apr 15 13:08:28 EDT 2004. Summary of my perl5 (revision 5.0 version 8 subversion 3) configuration: Platform: osname=linux, osvers=2.4.21-4.elsmp, archname=i386-linux-thread-multi uname='linux tweety.devel.redhat.com 2.4.21-4.elsmp #1 smp fri oct 3 17:52:5 6 edt 2003 i686 i686 i386 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dversion=5 .8.3 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/u sr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd _dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ex t=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr /bin/less -isr -Dinc_version_list=5.8.2 5.8.1 5.8.0' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=de fine 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 -DTHREADS_HAVE_PIDS -DDEBUGGI NG -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_ BITS=64 -I/usr/include/gdbm', optimize='-O2 -g -pipe -march=i386 -mcpu=i686', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-st rict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='3.3.3 20040412 (Red Hat Linux 3.3.3-7)', gccosandv ers='' 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=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.3.3' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpa th,/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Locally applied patches: @INC for perl v5.8.3: /usr/lib/perl5/5.8.3/i386-linux-thread-multi /usr/lib/perl5/5.8.3 /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . Environment for perl v5.8.3: HOME=/home/sg LANG=en_GB.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/X11R 6/bin:/usr/local/j2sdk1.4.2_05/bin PERL_BADLANG (unset) SHELL=/bin/tcsh ```

[p5pRT]

From @schwern

Thank you for your report.

I can confirm this bug in 5.8.1 RC3 (I don't have a 5.8.3 handy to check). This bug appears to have been fixed in 5.8.5 and the latest development perl.

Test patch attached.

[p5pRT]

From @schwern

bop.patch

```diff Index: t/op/bop.t =================================================================== --- t/op/bop.t (revision 18132) +++ t/op/bop.t (working copy) @@ -14,7 +14,7 @@ # If you find tests are failing, please try adding names to tests to track # down where the failure is, and supply your new names as a patch. # (Just-in-time test naming) -plan tests => 145; +plan tests => 146; # numerics ok ((0xdead & 0xbeef) == 0x9ead); @@ -321,3 +321,8 @@ ok(utf8::is_utf8($a)); # make sure UTF8 flag is still there $a = ~$a; is($a, "\xFF", "~ works with utf-8"); + + +# [rt.perl.org 33003] +# This would cause a segfault +is( runperl(prog => '$#a>>=1; print 1'), 1 ); ```

[p5pRT]

@schwern - Status changed from 'new' to 'resolved'

[p5pRT]

From rmgiroux@hotmail.com

John Krivitsky wrote​:

The following line makes Perl dump core​:

  $\#a>>=1;

if @​a is empty (or undefined).

Cute...

I see you're using 5.8.3. Using my 5.8.6 build\, I get

./perl -e'$#x>>=1' Out of memory during array extend at -e line 1.

That's a bit better :)

What's happening\, I think\, is that $#a for an empty array is -1. So left shifting it _still_ gives -1\, leaving perl to try to create a 2^32 (or 64) element array.

I think the only answer if you want to use that trick to shrink your array is to explicitly check if you're already done. -- Mike rmgiroux@​acm.org

[p5pRT]

From rmgiroux@hotmail.com

I wrote​:

What's happening\, I think\, is that $#a for an empty array is -1. So left shifting it _still_ gives -1\, leaving perl to try to create a 2^32 (or 64) element array.

2^31\, looks like the shift is done unsigned\, but that's not the problem.

I think the only answer if you want to use that trick to shrink your array is to explicitly check if you're already done.

Hmm\, I take that back...

perl -e'$#a=-1'

doesn't core dump\, or warn.

Neither do most other numeric ops on $#a when uninitialized.

So it looks like there's already a sanity check somewhere\, and $#a>>=1 bypasses it? -- Mike rmgiroux@​acm.org

[p5pRT]

From @tamias

On Mon\, Dec 13\, 2004 at 09​:21​:48AM -0500\, Mike Giroux wrote​:

I wrote​:

What's happening\, I think\, is that $#a for an empty array is -1. So left shifting it _still_ gives -1\, leaving perl to try to create a 2^32 (or 64) element array.

2^31\, looks like the shift is done unsigned\, but that's not the problem.

I think that is the problem. -1 >> 1 is MAXINT\, which is 2147483647 on a 32 bit architecture. It's not too surprising that trying to create an array of that many elements is problematic.

I think the only answer if you want to use that trick to shrink your array is to explicitly check if you're already done.

Hmm\, I take that back...

perl -e'$#a=-1'

doesn't core dump\, or warn.

Why would it? $#a=-1 just makes the array empty.

Neither do most other numeric ops on $#a when uninitialized.

$#a can't be uninitialized. For an empty array\, $#a == -1.

Your first suggestion was good; check to make sure the array isn't empty before doing the shift.

Ronald

[p5pRT]

From @schwern

On Mon\, Dec 13\, 2004 at 10​:27​:16AM -0500\, Ronald J Kimball wrote​:

I think the only answer if you want to use that trick to shrink your array is to explicitly check if you're already done.

Hmm\, I take that back...

perl -e'$#a=-1'

doesn't core dump\, or warn.

Why would it? $#a=-1 just makes the array empty.

Here's my first reaction​:

  For the same reason $#a>>=1 shouldn't. This isn't C. -1 shouldn't   wrap around to MAXINT no matter what the user does.

Then I thought about it a little more. I don't know so much about bit shifting\, but isn't it pretty much asking for exactly this sort of problem?

-- Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern/ Sometimes you eat the path\, sometimes the path eats you.

[p5pRT]

From rmgiroux@hotmail.com

Here's my first reaction​:

For the same reason $#a>>=1 shouldn't. This isn't C. -1 shouldn't wrap around to MAXINT no matter what the user does.

Then I thought about it a little more. I don't know so much about bit shifting\, but isn't it pretty much asking for exactly this sort of problem?

Probably. perldoc perlop actually specifies what the behaviour should be (hoping this doesn't get horribly mis-wrapped)​:

  Note that both "\<\<" and ">>" in Perl are implemented directly using   "\<\<" and ">>" in C. If "use integer" (see "Integer Arithmetic") is in   force then signed C integers are used\, else unsigned C integers are   used. Either way\, the implementation isn't going to generate results   larger than the size of the integer type Perl was built with (32 bits   or 64 bits).

So $#a>>=1 is correctly shifting down to MAXINT\, unless use integer is in scope.

perl -Minteger -e'$#a>>=1' doesn't core or warn. -- Mike

[p5pRT]

From rmgiroux@hotmail.com

From​: jk@​smartguide.com.au

Hi Guys! Pardon me for saying so\, but the reason I posted this in the first place was because I didn't think that any instruction should actually make perl dump core.

I don't think you're going to find anyone on p5p who disagrees with that\, unless you're playing with unpack in odd ways.

Well\, as I found out the hard way back in 2001\, there's a perl instruction that dumps core by design :)

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-12/msg01547.html -- Mike

[p5pRT]

From rmgiroux@hotmail.com

Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Mon\, Dec 13\, 2004 at 09​:21​:48AM -0500\, Mike Giroux wrote​:

I wrote​:

What's happening\, I think\, is that $#a for an empty array is -1. So left shifting it _still_ gives -1\, leaving perl to try to create a 2^32 (or 64) element array.

2^31\, looks like the shift is done unsigned\, but that's not the problem.

I think that is the problem. -1 >> 1 is MAXINT\, which is 2147483647 on a 32 bit architecture. It's not too surprising that trying to create an array of that many elements is problematic.

D'oh! Of course\, you're right.

I was insufficiently caffeinated when I didn't notice that\, that's my excuse and I'm sticking to it :) -- Mike

[p5pRT]

From jk@smartguide.com.au

Hi Guys! Pardon me for saying so\, but the reason I posted this in the first place was because I didn't think that any instruction should actually make perl dump core. If you do​:

  perl -e 'print -1>>1;'

This prints '2147483647' (on 32 bit)\, so it's definitely the problem as you suggest. I should have stated in my original posting that this is what I thought was happening. It's just that I thought this should produce an error rather than a core dump. If version 5.8.6 now does produce an error\, then I would now consider this issue resolved. It hadn't been between versions 5.0 and 5.8.3\, so naturally I came to the conclusion that it kept being overlooked\, hence my posting. Please accept my apologies for not installing the very latest version before submitting the bug (I got a bit confused and actually thought I did have the latest version). Thank you for all your help.

  Kindest regards\,

  jk

Quoting Mike Giroux \rmgiroux@&#8203;hotmail\.com​:

Ronald J Kimball \rjk\-perl\-p5p@&#8203;tamias\.net wrote​:

On Mon\, Dec 13\, 2004 at 09​:21​:48AM -0500\, Mike Giroux wrote​:

I wrote​:

What's happening\, I think\, is that $#a for an empty array is -1. So left shifting it _still_ gives -1\, leaving perl to try to create a 2^32 (or 64) element array.

2^31\, looks like the shift is done unsigned\, but that's not the problem.

I think that is the problem. -1 >> 1 is MAXINT\, which is 2147483647 on a 32 bit architecture. It's not too surprising that trying to create an array of that many elements is problematic.

D'oh! Of course\, you're right.

I was insufficiently caffeinated when I didn't notice that\, that's my excuse and I'm sticking to it :) -- Mike

[p5pRT]

From @schwern

On Tue\, Dec 14\, 2004 at 01​:15​:52AM +0800\, jk@​smartguide.com.au wrote​:

It's just that I thought this should produce an error rather than a core dump. If version 5.8.6 now does produce an error\, then I would now consider this issue resolved. naturally I came to the conclusion that it kept being overlooked\, hence my posting. Please accept my apologies for not installing the very latest version before submitting the bug (I got a bit confused and actually thought I did have the latest version). Thank you for all your help.

It appears to no longer be coring on 5.8.6.

You were correct in reporting the bug\, nothing should make Perl dump core (unless\, of course\, you ask it to). And as seen from all the discussion on this bug it probably was fixed incidentally as opposed to explicitly.

Just want to remind folks there is a test patch attached to this bug.

-- Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern/ Not king yet

[p5pRT]

From @rgs

Michael G Schwern wrote​:

You were correct in reporting the bug\, nothing should make Perl dump core (unless\, of course\, you ask it to). And as seen from all the discussion on this bug it probably was fixed incidentally as opposed to explicitly.

Just want to remind folks there is a test patch attached to this bug.

Thanks\, applied as #23645. I didn't notice it at first since it wasn't posted to the mailing list.

-- Mr Leopold Bloom ate with relish the inner organs of beasts and fowls.   -- Ulysses

[p5pRT]

From @steve-m-hay

Michael G Schwern wrote​:

It appears to no longer be coring on 5.8.6.

It is still crashing for me on Win32 :(

Produces an Access Violation error (more or less the Win32 equivalent of coring). Here's the call stack at the crash (using 5.8.6)​:

Perl_av_extend(av * 0x01830f5c\, long 2147483647) line 165 + 15 bytes Perl_av_store(av * 0x01830f5c\, long 2147483647\, sv * 0x28175070 _PL_sv_undef) line 322 + 13 bytes Perl_av_fill(av * 0x01830f5c\, long 2147483647) line 783 + 18 bytes Perl_magic_setarylen(sv * 0x01830f80\, magic * 0x01835648) line 1670 + 68 bytes Perl_mg_set(sv * 0x01830f80) line 237 + 14 bytes Perl_pp_right_shift() line 1667 + 46 bytes Perl_runops_debug() line 1449 + 9 bytes S_run_body(long 1) line 1937 perl_run(interpreter * 0x00233e90) line 1853 + 9 bytes RunPerl(int 2\, char * * 0x00232430\, char * * 0x00232c68) line 217 + 12 bytes main(int 2\, char * * 0x00232430\, char * * 0x00232c68) line 18 + 18 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e814c7()

At this point\, the debugger shows "newmax" is 2147483647 and "tmp" is 2147482080.

It crashes with bleadperl too.

- Steve

---

Radan Computational Ltd.

We would like to take this opportunity to wish all our customers\, suppliers and colleagues seasons greetings. We will not be sending corporate greetings cards this year. Instead\, we will be making a donation to charity.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems\, please notify the sender immediately. The unauthorized use\, disclosure\, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

[p5pRT]

@steve-m-hay - Status changed from 'resolved' to 'open'

[p5pRT]

From @smpeters

[shay - Wed Dec 15 03​:19​:13 2004]​:

Michael G Schwern wrote​:

It appears to no longer be coring on 5.8.6.

It is still crashing for me on Win32 :(

Produces an Access Violation error (more or less the Win32 equivalent of coring). Here's the call stack at the crash (using 5.8.6)​:

Perl_av_extend(av * 0x01830f5c\, long 2147483647) line 165 + 15 bytes Perl_av_store(av * 0x01830f5c\, long 2147483647\, sv * 0x28175070 _PL_sv_undef) line 322 + 13 bytes Perl_av_fill(av * 0x01830f5c\, long 2147483647) line 783 + 18 bytes Perl_magic_setarylen(sv * 0x01830f80\, magic * 0x01835648) line 1670 + 68 bytes Perl_mg_set(sv * 0x01830f80) line 237 + 14 bytes Perl_pp_right_shift() line 1667 + 46 bytes Perl_runops_debug() line 1449 + 9 bytes S_run_body(long 1) line 1937 perl_run(interpreter * 0x00233e90) line 1853 + 9 bytes RunPerl(int 2\, char * * 0x00232430\, char * * 0x00232c68) line 217 + 12 bytes main(int 2\, char * * 0x00232430\, char * * 0x00232c68) line 18 + 18 bytes PERL! mainCRTStartup + 227 bytes KERNEL32! 77e814c7()

At this point\, the debugger shows "newmax" is 2147483647 and "tmp" is 2147482080.

It crashes with bleadperl too.

- Steve

Perl_av_extend() has a lot of different paths depending on several #define's. Can you please look up to see what you have for the following #defines?

PERL_MALLOC_WRAP STRANGE_MALLOC MYMALLOC

Thanks!

[p5pRT]

From @cpansprout

Fixed in 5.8.4.

[p5pRT]

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