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

p /x in debugger yields memory fault #13526

Closed
p5pRT opened this issue Jan 14, 2014 · 20 comments
Closed

p /x in debugger yields memory fault #13526

p5pRT opened this issue Jan 14, 2014 · 20 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 14, 2014

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

Searchable as RT120998$

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

From @khwilliamson

This is a bug report for perl from khw@​karl.(none),
generated with the help of perlbug 1.39 running under perl 5.19.8.


Typing
  p /x
in the Perl debugger causes an immediate memory fault.



Flags​:
  category=utilities
  severity=low


Site configuration information for perl 5.19.8​:

Configured by khw at Mon Jan 13 18​:01​:27 MST 2014.

Summary of my perl5 (revision 5 version 19 subversion 8) configuration​:
  Commit id​: c1b88ea101cdecdcdb22aa017d4320dc65f53b7f
  Platform​:
  osname=linux, osvers=2.6.35-32-generic-pae,
archname=i686-linux-thread-multi-64int-ld
  uname='linux karl 2.6.35-32-generic-pae #67-ubuntu smp mon mar 5
21​:23​:19 utc 2012 i686 gnulinux '
  config_args='-des -Dprefix=/home/khw/devel -Dusedevel
-D'optimize=-ggdb3' -A'optimize=-ggdb3' -A'optimize=-O0'
-Accflags='-DPERL_BOOL_AS_CHAR' -Dman1dir=none -Dman3dir=none
-DDEBUGGING -Dcc=g++ -Dusemorebits -Dusethreads'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=undef, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='g++', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_BOOL_AS_CHAR
-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize=' -ggdb3 -O0',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_BOOL_AS_CHAR
-DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include'
  ccversion='', gccversion='4.4.5', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long long', ivsize=8, nvtype='long double', nvsize=12,
Off_t='off_t', lseeksize=8
  alignbytes=4, prototype=define
  Linker and Libraries​:
  ld='g++', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib
/usr/lib/i686-linux-gnu
  libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=/lib/libc-2.12.1.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.12'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -ggdb3 -ggdb3 -O0
-L/usr/local/lib -fstack-protector'


@​INC for perl 5.19.8​:
  /home/khw/perl/locale/lib

/home/khw/devel/lib/perl5/site_perl/5.19.8/i686-linux-thread-multi-64int-ld
  /home/khw/devel/lib/perl5/site_perl/5.19.8
  /home/khw/devel/lib/perl5/5.19.8/i686-linux-thread-multi-64int-ld
  /home/khw/devel/lib/perl5/5.19.8
  /home/khw/devel/lib/perl5/site_perl
  .


Environment for perl 5.19.8​:
  HOME=/home/khw
  LANG=en_US.UTF-8
  LANGUAGE=en_US​:en
  LC_ALL=de_DE.utf8
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)

PATH=/home/khw/bin​:/home/khw/perl5/perlbrew/bin​:/home/khw/print/bin​:/bin​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/usr/bin​:/sbin​:/usr/games​:/home/khw/cxoffice/bin
  PERL5OPT=-w
  PERL_BADLANG (unset)
  PERL_POD_PEDANTIC=1
  SHELL=/bin/ksh

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

From perl5-porters@perl.org

Karl Williamson wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I get "Search pattern not terminated."

Is this a regression?

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

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

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

From @khwilliamson

On 01/13/2014 10​:21 PM, Father Chrysostomos wrote​:

Karl Williamson wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I get "Search pattern not terminated."

Is this a regression?

It turns out it is. Fails in blead; works in 5.18.0

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

From @khwilliamson

On 01/13/2014 10​:48 PM, Karl Williamson wrote​:

On 01/13/2014 10​:21 PM, Father Chrysostomos wrote​:

Karl Williamson wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I get "Search pattern not terminated."

Is this a regression?

It turns out it is. Fails in blead; works in 5.18.0

I ran this​:

valgrind ./perl -Ilib -d utils/perlbug

then typed

p /x

and got this​:
==18675== Invalid write of size 1
==18675== at 0x4027F79​: memmove (mc_replace_strmem.c​:629)
==18675== by 0x820D562​: Perl_sv_setpvn (sv.c​:4645)
==18675== by 0x8228772​: Perl_newSVpvn_flags (sv.c​:8691)
==18675== by 0x828BC37​: Perl_pp_caller (pp_ctl.c​:1846)
==18675== by 0x8184747​: Perl_runops_debug (dump.c​:2372)
==18675== by 0x8296419​: S_docatch (pp_ctl.c​:3213)
==18675== by 0x82A2039​: Perl_pp_entertry (pp_ctl.c​:4385)
==18675== by 0x8184747​: Perl_runops_debug (dump.c​:2372)
==18675== by 0x809AF6C​: Perl_call_sv (perl.c​:2745)
==18675== by 0x8189AA6​: S_invoke_exception_hook (util.c​:1409)
==18675== by 0x8189FE1​: Perl_vcroak (util.c​:1530)
==18675== by 0x818A04D​: Perl_croak (util.c​:1576)
==18675== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18675==
==18675==
==18675== Process terminating with default action of signal 11 (SIGSEGV)
==18675== Access not within mapped region at address 0x0
==18675== at 0x4027F79​: memmove (mc_replace_strmem.c​:629)
==18675== by 0x820D562​: Perl_sv_setpvn (sv.c​:4645)
==18675== by 0x8228772​: Perl_newSVpvn_flags (sv.c​:8691)
==18675== by 0x828BC37​: Perl_pp_caller (pp_ctl.c​:1846)
==18675== by 0x8184747​: Perl_runops_debug (dump.c​:2372)
==18675== by 0x809B170​: Perl_call_sv (perl.c​:2760)
==18675== by 0x81AB46F​: Perl_sighandler (mg.c​:3194)
==18675== by 0x819FD57​: Perl_csighandler (mg.c​:1387)
==18675== by 0x409CAD7​: ??? (in /lib/libpthread-2.12.1.so)
==18675== by 0x820D562​: Perl_sv_setpvn (sv.c​:4645)
==18675== by 0x8228772​: Perl_newSVpvn_flags (sv.c​:8691)
==18675== by 0x828BC37​: Perl_pp_caller (pp_ctl.c​:1846)
==18675== If you believe this happened as a result of a stack
==18675== overflow in your program's main thread (unlikely but
==18675== possible), you can try to increase the size of the
==18675== main thread stack using the --main-stacksize= flag.
==18675== The main thread stack size used in this run was 8388608.

@p5pRT
Copy link
Author

p5pRT commented Jan 14, 2014

From @shlomif

Hi all,

On Mon, 13 Jan 2014 22​:55​:29 -0700
Karl Williamson <public@​khwilliamson.com> wrote​:

On 01/13/2014 10​:48 PM, Karl Williamson wrote​:

On 01/13/2014 10​:21 PM, Father Chrysostomos wrote​:

Karl Williamson wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I get "Search pattern not terminated."

Is this a regression?

It turns out it is. Fails in blead; works in 5.18.0

I ran this​:

valgrind ./perl -Ilib -d utils/perlbug

then typed

p /x

Just for the record, perl -d on blead does not crash here (Mageia Linux x86-64
4/Cauldron)​:

shlomif@​telaviv1​:~/Download/unpack/perl/p5/git/perl$ ./perl -Ilib -d
utils/perlbug

Loading DB routines from perl5db.pl version 1.43
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main​::(utils/perlbug​:2)​: eval
'exec /home/shlomif/apps/perl/bleadperl/bin/perl5.19.8 -S $0 ${1+"$@​"}'
main​::(utils/perlbug​:3)​: if $running_under_some_shell; DB<570>
p /x Search pattern not terminated at (eval 12)[lib/perl5db.pl​:732] line 2.

  DB<571> p 5+6
11
  DB<572> p 100*3
300
  DB<573> q


I've built my perl like this​:

#!/bin/sh
rm -f config.sh Policy.sh
sh Configure -de -Dprefix=$HOME/apps/perl/bleadperl -Dusedevel

Regards,

  Shlomi Fish

--


Shlomi Fish http​://www.shlomifish.org/
Why I Love Perl - http​://shlom.in/joy-of-perl

I figured wrong (with a capital R).
  — Harvey Danger​: “Wine, Women and Song”.

Please reply to list if it's a mailing list post - http​://shlom.in/reply .

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2014

From @tonycoz

On Mon Jan 13 21​:55​:44 2014, public@​khwilliamson.com wrote​:

On 01/13/2014 10​:48 PM, Karl Williamson wrote​:

On 01/13/2014 10​:21 PM, Father Chrysostomos wrote​:

Karl Williamson wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I get "Search pattern not terminated."

Is this a regression?

It turns out it is. Fails in blead; works in 5.18.0

I ran this​:

valgrind ./perl -Ilib -d utils/perlbug

I've reproduced this in a 32-bit VM, here's a more detailed stack trace (I used "o signalLevel=0" to avoid the debugger setting a signal handler, since we're getting twice the noise with it)​:

(gdb) bt
#0 0xb76a27a4 in __memmove_ssse3_rep () from /lib/libc.so.6
#1 0x081f756b in Perl_sv_setpvn (my_perl=0x8d29008, sv=0x8f29fb4,
  ptr=0x8f3e68c "", len=4294967294) at sv.c​:4698
#2 0x08211561 in Perl_newSVpvn_flags (my_perl=0x8d29008, s=0x8f3e68c "",
  len=4294967294, flags=524288) at sv.c​:8755
#3 0x0827144f in Perl_pp_caller (my_perl=0x8d29008) at pp_ctl.c​:1846
#4 0x08174ba5 in Perl_runops_debug (my_perl=0x8d29008) at dump.c​:2397
#5 0x0827b776 in S_docatch (my_perl=0x8d29008, o=0x9166428) at pp_ctl.c​:3215
#6 0x08286cd0 in Perl_pp_entertry (my_perl=0x8d29008) at pp_ctl.c​:4387
#7 0x08174ba5 in Perl_runops_debug (my_perl=0x8d29008) at dump.c​:2397
#8 0x0809963f in Perl_call_sv (my_perl=0x8d29008, sv=0x9142dd4, flags=6)
  at perl.c​:2746
#9 0x08179c76 in S_invoke_exception_hook (my_perl=0x8d29008, ex=0x8f3efcc,
  warn=false) at util.c​:1517
#10 0x0817a181 in Perl_vcroak (my_perl=0x8d29008,
  pat=0x83799c3 "Search pattern not terminated", args=0xbfd8e52c)
  at util.c​:1638
#11 0x0817a1ed in Perl_croak (my_perl=0x8d29008,
  pat=0x83799c3 "Search pattern not terminated") at util.c​:1684
#12 0x080f5cce in S_scan_pat (my_perl=0x8d29008, start=0x8f3e6fe "/x;\n\n;",
  type=31) at toke.c​:9716
#13 0x080e1750 in Perl_yylex (my_perl=0x8d29008) at toke.c​:6795
#14 0x08102e1e in Perl_yyparse (my_perl=0x8d29008, gramtype=258) at perly.c​:342
#15 0x0827d1e9 in S_doeval (my_perl=0x8d29008, gimme=3, outside=0x8d2bcdc,
  seq=2584, hh=0x8ee42f8) at pp_ctl.c​:3475
#16 0x08284c39 in Perl_pp_entereval (my_perl=0x8d29008) at pp_ctl.c​:4261
#17 0x08174ba5 in Perl_runops_debug (my_perl=0x8d29008) at dump.c​:2397
#18 0x0809839b in S_run_body (my_perl=0x8d29008, oldscope=1) at perl.c​:2441
#19 0x080979bc in perl_run (my_perl=0x8d29008) at perl.c​:2362
#20 0x0805df30 in main (argc=3, argv=0xbfd8f3f4, env=0xbfd8f404)
  at perlmain.c​:112

Note the large len value passed to Perl_newSVpvn_flags.

I'll fiddle with this some more.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2014

From perl5-porters@perl.org

Tony Cook wrote​:

Note the large len value passed to Perl_newSVpvn_flags.

Somehow cx->blk_eval.cur_text is an SV containing an empty string. I
thought that could not happen. (I added the code in pp_caller that
is subtracting 2 from the string length.) Has something changed, or
is this bug as old as v5.17.3-150-g19bcb54e but was not apparent yet?

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2014

From @tonycoz

On Thu, Jan 23, 2014 at 04​:41​:23AM -0000, Father Chrysostomos wrote​:

Tony Cook wrote​:

Note the large len value passed to Perl_newSVpvn_flags.

Somehow cx->blk_eval.cur_text is an SV containing an empty string. I
thought that could not happen. (I added the code in pp_caller that
is subtracting 2 from the string length.) Has something changed, or
is this bug as old as v5.17.3-150-g19bcb54e but was not apparent yet?

cur_text is being initialized with the eval text, but line 1440 in
toke.c zeroes the length, and so it's zero length by the time caller
gets to see it (detected with "watch ((struct
xpv*)($1->sv_any))->xpv_cur" where $1 is cur_text).

Note that if I remove the subtraction, the output doesn't match my
machine that didn't crash​:

# 32-bit machine that was crashing​:
Search pattern not terminated at (eval 8)[lib/perl5db.pl​:732] line 2.
at (eval 8)[lib/perl5db.pl​:732] line 2.
  eval '' called at lib/perl5db.pl line 732
  DB​::eval called at lib/perl5db.pl line 3091
  DB​::DB called at -e line 1

# 64-bit machine that wasn't​:
Search pattern not terminated at (eval 8)[lib/perl5db.pl​:732] line 2.

Tony

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2014

From perl5-porters@perl.org

Tony cook wrote​:

line 1440 in
toke.c zeroes the length

What line is that? It is a closing brace in blead, and earlier it
is one of​:

  if (UTF8_IS_INVARIANT(head))

  len = UTF8SKIP(&head);

Did you get the number wrong?

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2014

From @tonycoz

On Thu, Jan 23, 2014 at 06​:08​:34AM -0000, Father Chrysostomos wrote​:

Tony cook wrote​:

line 1440 in
toke.c zeroes the length

What line is that? It is a closing brace in blead, and earlier it
is one of​:

    if \(UTF8\_IS\_INVARIANT\(head\)\)

        len = UTF8SKIP\(&head\);

Did you get the number wrong?

  if (!(flags & LEX_KEEP_PREVIOUS) &&
  PL_parser->bufptr == PL_parser->bufend) {
  old_bufend_pos = bufptr_pos = oldbufptr_pos = oldoldbufptr_pos = 0;
  linestart_pos = 0;
  if (PL_parser->last_uni != PL_parser->bufend)
  PL_parser->last_uni = NULL;
  if (PL_parser->last_lop != PL_parser->bufend)
  PL_parser->last_lop = NULL;
  last_uni_pos = last_lop_pos = 0;
  *buf = 0;

This line​:
  SvCUR(linestr) = 0;
  } else {
  old_bufend_pos = PL_parser->bufend - buf;
  bufptr_pos = PL_parser->bufptr - buf;
  oldbufptr_pos = PL_parser->oldbufptr - buf;
  oldoldbufptr_pos = PL_parser->oldoldbufptr - buf;
  linestart_pos = PL_parser->linestart - buf;
  last_uni_pos = PL_parser->last_uni ? PL_parser->last_uni - buf : 0;
  last_lop_pos = PL_parser->last_lop ? PL_parser->last_lop - buf : 0;
  }

@p5pRT
Copy link
Author

p5pRT commented Apr 4, 2014

From @tonycoz

On Mon Jan 13 20​:22​:57 2014, public@​khwilliamson.com wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

I ran a bisect on this on a 32-bit VM using​:

#!/usr/bin/perl
use strict;

system "git clean -dxf";
system "./Configure -des -Dusedevel -Dusemorebits -Duseithreads"
  and exit 125;
system "make -j3 test-prep"
  and exit 125;

open my $db, ">", ".perldb";
print $db <<'EOF';
&parse_options("NonStop=0 TTY=db.out");
sub afterinit {
  push @​DB​::typeahead, "p /x", "q";
}
EOF
close $db;
chmod 0644, ".perldb";

my $rev = `git describe`;
chomp $rev;
my $res = system './perl -Ilib -de0';

system "git clean -dxf";

my $status = $res == 0 ? "good" : "bad";
open my $resfile, ">", "../bisect/$rev" or die;
print $resfile "$rev\nerrorlevel $res\n$status";
close $resfile;
print "** bisect $status $rev\n";
if ($res) {
  exit 1;
}
exit;

(which does a lot more work than necessary)

This bisected down to​:

cbcb2a1 is the first bad commit
commit cbcb2a1
Author​: David Mitchell <davem@​iabyn.com>
Date​: Sat Jun 8 18​:24​:51 2013 +0100

  add 1 to SvGROW under COW (and fix svleak.t)
 
  the new COW scheme uses SvPVX(sv)[SvLEN(sv)-1] (if spare)
  to store the COW reference count. If this byte isn't spare, the string is
  copied rather than COWed. So, when built under the new COW, allocate one
  more byte than asked for in sv_grow(), to make it likely this byte is
  always spare​: and thus make more strings COW-able. If the new size is a
  big power of two, don't bother​: we assume the caller wanted a nice 2^N
  sized block and will be annoyed at getting 2^N+1 or more.

which I had trouble believing, since the change is so trivial, but I confirmed it by manually building the commit before (which didn't fault) and the release after (which did fault).

I can only suspect this is a heisenbug of sorts - the size increase is pushing us over some boundary that moves something in memory.

Tony

@p5pRT
Copy link
Author

p5pRT commented Apr 7, 2014

From @tonycoz

On Wed Jan 22 20​:41​:45 2014, perl5-porters@​perl.org wrote​:

Tony Cook wrote​:

Note the large len value passed to Perl_newSVpvn_flags.

Somehow cx->blk_eval.cur_text is an SV containing an empty string. I
thought that could not happen. (I added the code in pp_caller that
is subtracting 2 from the string length.) Has something changed, or
is this bug as old as v5.17.3-150-g19bcb54e but was not apparent yet?

It looks like yes, this has been around since that commit​:

[tony@​localhost perl]$ git describe
v5.17.3-150-g19bcb54e
[tony@​localhost perl]$ gdb ./miniperl -Ilib -de0
gdb​: unrecognized option '-Ilib'
Use `gdb --help' for a complete list of options.
[tony@​localhost perl]$ gdb --args ./miniperl -Ilib -de0
GNU gdb (GDB) Fedora 7.7-4.fc21
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+​: GNU GPL version 3 or later <http​://gnu.org/licenses/gpl.html>
This is free software​: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see​:
<http​://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at​:
<http​://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./miniperl...done.
(gdb) b Perl_sv_grow if newlen > 0x80000000
Breakpoint 1 at 0x8151d80​: file sv.c, line 1473.
(gdb) r
Starting program​: /home/tony/dev/perl/git/perl/miniperl -Ilib -de0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Loading DB routines from perl5db.pl version 1.39_02
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main​::(-e​:1)​: 0
  DB<1> p /x

Breakpoint 1, Perl_sv_grow (my_perl=my_perl@​entry=0x82de008,
  sv=sv@​entry=0x85f1c40, newlen=newlen@​entry=4294967295) at sv.c​:1473
1473 {
Missing separate debuginfos, use​: debuginfo-install glibc-2.19.90-8.fc21.i686 n\
ss-softokn-freebl-3.16.0-1.fc21.i686
(gdb) bt
#0 Perl_sv_grow (my_perl=my_perl@​entry=0x82de008, sv=sv@​entry=0x85f1c40,
  newlen=newlen@​entry=4294967295) at sv.c​:1473
#1 0x08157e98 in Perl_sv_setpvn (my_perl=my_perl@​entry=0x82de008,
  sv=sv@​entry=0x85f1c40, ptr=ptr@​entry=0x84a618c "",
  len=len@​entry=4294967294) at sv.c​:4440
#2 0x08158717 in Perl_newSVpvn_flags (my_perl=my_perl@​entry=0x82de008,
  s=0x84a618c "", len=len@​entry=4294967294, flags=flags@​entry=524288)
  at sv.c​:8278
#3 0x081a5d1b in Perl_pp_caller (my_perl=0x82de008) at pp_ctl.c​:1860
#4 0x080fd7ec in Perl_runops_debug (my_perl=0x82de008) at dump.c​:2132
#5 0x08192fb8 in S_docatch (my_perl=my_perl@​entry=0x82de008, o=0x84aeb54)
  at pp_ctl.c​:3194
#6 0x081b054c in Perl_pp_entertry (my_perl=0x82de008) at pp_ctl.c​:4247
#7 0x080fd7ec in Perl_runops_debug (my_perl=0x82de008) at dump.c​:2132
#8 0x08051ba1 in Perl_call_sv (my_perl=my_perl@​entry=0x82de008,
  sv=sv@​entry=0x849affc, flags=<optimized out>) at perl.c​:2676
#9 0x080fe12e in S_invoke_exception_hook (my_perl=my_perl@​entry=0x82de008,
  ex=ex@​entry=0x8392a50, warn=warn@​entry=false) at util.c​:1437
#10 0x08100bae in Perl_vcroak (my_perl=my_perl@​entry=0x82de008,
  pat=pat@​entry=0x82402fd "Search pattern not terminated",
  args=args@​entry=0xbffff22c) at util.c​:1558
#11 0x08100d07 in Perl_croak (my_perl=my_perl@​entry=0x82de008,
  pat=0x82402fd "Search pattern not terminated") at util.c​:1604
#12 0x08094e11 in S_scan_pat (my_perl=my_perl@​entry=0x82de008,
  start=start@​entry=0x84a61f9 "/x;\n\n;", type=type@​entry=31) at toke.c​:9219
#13 0x0809e1b8 in Perl_yylex (my_perl=my_perl@​entry=0x82de008) at toke.c​:6453
#14 0x080b6f36 in Perl_yyparse (my_perl=my_perl@​entry=0x82de008,
  gramtype=gramtype@​entry=258) at perly.c​:334
#15 0x08199f5a in S_doeval (my_perl=my_perl@​entry=0x82de008,
  gimme=gimme@​entry=3, outside=outside@​entry=0x82e0b34, seq=1621,
  hh=hh@​entry=0x85a7928) at pp_ctl.c​:3434
#16 0x081aea06 in Perl_pp_entereval (my_perl=0x82de008) at pp_ctl.c​:4121
#17 0x080fd7ec in Perl_runops_debug (my_perl=0x82de008) at dump.c​:2132
#18 0x0805a8c7 in S_run_body (oldscope=1, my_perl=0x82de008) at perl.c​:2387
#19 perl_run (my_perl=0x82de008) at perl.c​:2309
#20 0x0804ceb7 in main (argc=3, argv=0xbffffb74, env=0xbffffb84)
  at miniperlmain.c​:113
(gdb) q
A debugging session is active.

  Inferior 1 [process 13743] will be killed.

Quit anyway? (y or n) y
[tony@​localhost perl]$ git checkout v5.17.3-150-g19bcb54e^
Previous HEAD position was 19bcb54... Stop (caller $n)[6] from including final\
"\n;"
HEAD is now at 1107659... Fix eval 'q;;'
[tony@​localhost perl]$ git describe
v5.17.3-149-g11076590
[tony@​localhost perl]$ gdb --args ./miniperl -Ilib -de0
GNU gdb (GDB) Fedora 7.7-4.fc21
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+​: GNU GPL version 3 or later <http​://gnu.org/licenses/gpl.html>
This is free software​: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see​:
<http​://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at​:
<http​://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./miniperl...done.
(gdb) b Perl_sv_grow if newlen > 0x80000000
Breakpoint 1 at 0x8151d80​: file sv.c, line 1473.
(gdb) r
Starting program​: /home/tony/dev/perl/git/perl/miniperl -Ilib -de0
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Loading DB routines from perl5db.pl version 1.39_02
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main​::(-e​:1)​: 0
  DB<1> p /x
Search pattern not terminated at (eval 4)[lib/perl5db.pl​:729] line 2.
at (eval 4)[lib/perl5db.pl​:729] line 2.
  eval '' called at lib/perl5db.pl line 729
  DB​::eval called at lib/perl5db.pl line 3368
  DB​::DB called at -e line 1

  DB<2> q
[Inferior 1 (process 22592) exited normally]
Missing separate debuginfos, use​: debuginfo-install glibc-2.19.90-8.fc21.i686 n\
ss-softokn-freebl-3.16.0-1.fc21.i686
(gdb) q
[tony@​localhost perl]$

Tony

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2014

From @tonycoz

On Mon Jan 13 20​:22​:57 2014, public@​khwilliamson.com wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

A simple reproducer​:

$SIG{__DIE__} = \&dbdie;
eval '/x';

sub dbdie {
  @​x = caller(1);
}

Tony

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2014

From @tonycoz

On Mon Apr 07 19​:04​:50 2014, tonyc wrote​:

On Mon Jan 13 20​:22​:57 2014, public@​khwilliamson.com wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

A simple reproducer​:

$SIG{__DIE__} = \&dbdie;
eval '/x';

sub dbdie {
@​x = caller(1);
}

Attached is a patch that fixes the problem and provides a test.

Backtraces from "p /x" in the debugger now match older versions of perl rather than being truncated on 64-bit builds, or causing a SEGV on 32-bit builds.

Please review.

Tony

@p5pRT
Copy link
Author

p5pRT commented Apr 8, 2014

From @tonycoz

0001-perl-120998-avoid-caller-crashing-on-eval-stack-fram.patch
From 76e7a9fe39549ab86e80cf93da9b638464dbe8f6 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Tue, 8 Apr 2014 11:12:38 +1000
Subject: [PATCH] [perl #120998] avoid caller() crashing on eval '' stack
 frames

Starting from v5.17.3-150-g19bcb54e caller() on an eval frame would
end up calling Perl_sv_grow() with newlen = 0xFFFFFFFF on 32-bit
systems.

This eventually started segfaulting with v5.19.0-442-gcbcb2a1 which
added code to round up allocations to the nearest 0x100, setting
newlen to 0, faulting when sv_setpvn() attempted to copy its source
string into the zero space provided.
---
 pp_ctl.c      |   13 ++++++++++---
 t/op/caller.t |   14 +++++++++++++-
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/pp_ctl.c b/pp_ctl.c
index e13e450..380a7fe 100644
--- a/pp_ctl.c
+++ b/pp_ctl.c
@@ -1847,9 +1847,16 @@ PP(pp_caller)
     if (CxTYPE(cx) == CXt_EVAL) {
 	/* eval STRING */
 	if (CxOLD_OP_TYPE(cx) == OP_ENTEREVAL) {
-	    PUSHs(newSVpvn_flags(SvPVX(cx->blk_eval.cur_text),
-				 SvCUR(cx->blk_eval.cur_text)-2,
-				 SvUTF8(cx->blk_eval.cur_text)|SVs_TEMP));
+            SV *cur_text = cx->blk_eval.cur_text;
+            if (SvCUR(cur_text) >= 2) {
+                PUSHs(newSVpvn_flags(SvPVX(cur_text), SvCUR(cur_text)-2,
+                                     SvUTF8(cur_text)|SVs_TEMP));
+            }
+            else {
+                /* I think this is will always be "", but be sure */
+                PUSHs(sv_2mortal(newSVsv(cur_text)));
+            }
+
 	    PUSHs(&PL_sv_no);
 	}
 	/* require */
diff --git a/t/op/caller.t b/t/op/caller.t
index 61a3816..54a6bac 100644
--- a/t/op/caller.t
+++ b/t/op/caller.t
@@ -5,7 +5,7 @@ BEGIN {
     chdir 't' if -d 't';
     @INC = '../lib';
     require './test.pl';
-    plan( tests => 94 );
+    plan( tests => 95 );
 }
 
 my @c;
@@ -318,6 +318,18 @@ sub doof { caller(0) }
 print +(doof())[3];
 END
     "caller should not SEGV when the current package is undefined";
+
+# caller should not SEGV when the eval entry has been cleared #120998
+fresh_perl_is <<'END', 'main', {},
+$SIG{__DIE__} = \&dbdie;
+eval '/x';
+sub dbdie {
+    @x = caller(1);
+    print $x[0];
+}
+END
+    "caller should not SEGV for eval '' stack frames";
+
 $::testing_caller = 1;
 
 do './op/caller.pl' or die $@;
-- 
1.7.10.4

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2014

From @shlomif

On Mon Apr 07 22​:58​:02 2014, tonyc wrote​:

On Mon Apr 07 19​:04​:50 2014, tonyc wrote​:

On Mon Jan 13 20​:22​:57 2014, public@​khwilliamson.com wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

A simple reproducer​:

$SIG{__DIE__} = \&dbdie;
eval '/x';

sub dbdie {
@​x = caller(1);
}

Attached is a patch that fixes the problem and provides a test.

Backtraces from "p /x" in the debugger now match older versions of
perl rather than being truncated on 64-bit builds, or causing a SEGV
on 32-bit builds.

Please review.

With this patch, all tests are successful on Mageia Linux x86-64 5/Cauldron both with a threaded build of Perl and a non-threaded build of it.

Thanks!

Regards,

-- Shlomi Fish

@p5pRT
Copy link
Author

p5pRT commented Apr 9, 2014

From @shlomif

On Wed Apr 09 00​:04​:43 2014, shlomif wrote​:

On Mon Apr 07 22​:58​:02 2014, tonyc wrote​:

On Mon Apr 07 19​:04​:50 2014, tonyc wrote​:

On Mon Jan 13 20​:22​:57 2014, public@​khwilliamson.com wrote​:

Typing
p /x
in the Perl debugger causes an immediate memory fault.

A simple reproducer​:

$SIG{__DIE__} = \&dbdie;
eval '/x';

sub dbdie {
@​x = caller(1);
}

Attached is a patch that fixes the problem and provides a test.

Backtraces from "p /x" in the debugger now match older versions of
perl rather than being truncated on 64-bit builds, or causing a SEGV
on 32-bit builds.

Please review.

With this patch, all tests are successful on Mageia Linux x86-64
5/Cauldron both with a threaded build of Perl and a non-threaded build
of it.

All tests with this patch are also successful on a Mageia Linux 4 32-bit (i586) VM in both threaded and non threaded builds.

-- Shlomi Fish

@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2014

From @tonycoz

On Mon Apr 07 22​:58​:02 2014, tonyc wrote​:

Attached is a patch that fixes the problem and provides a test.

Backtraces from "p /x" in the debugger now match older versions of
perl rather than being truncated on 64-bit builds, or causing a SEGV
on 32-bit builds.

Applied to blead as 78beb4c.

Tony

@p5pRT p5pRT closed this as completed Apr 13, 2014
@p5pRT
Copy link
Author

p5pRT commented Apr 13, 2014

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

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

No branches or pull requests

1 participant