Bug#557771: *** stack smashing detected ***: /usr/bin/perl terminated
Thomas Schwinge
Version: 5.10.1-8
Severity: important
Hello!
I have a case where perl reproducibly crashed like this:
[...]
scanning tag/open_issue_viengoos.mdwn
scanning tag/open_issue_xen.mdwn
building render_locally
building colophon.mdwn
*** stack smashing detected ***: /usr/bin/perl terminated
This is when using ikiwiki, <http://packages.debian.org/ikiwiki>, for
rendering a set of web pages.
I have this sitting in GDB at the moment, but without debugging symbols
the backtrace is probably not to helpful for you:
(gdb) bt
#0 abort () at abort.c:55
#1 0x0112c71c in __libc_message (do_abort=2, fmt=0x1214956 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:138
#2 0x011dc7db in __fortify_fail (msg=0x121493e "stack smashing detected") at fortify_fail.c:32
#3 0x011dc790 in __stack_chk_fail () at stack_chk_fail.c:29
#4 0x08070018 in Perl_newATTRSUB ()
#5 0x0806ed90 in Perl_utilize ()
#6 0x080a5d15 in Perl_yyparse ()
#7 0x0811e93b in ?? ()
#8 0x0811f4fc in Perl_pp_entereval ()
#9 0x080dce79 in Perl_runops_standard ()
#10 0x080770ee in perl_run ()
#11 0x0806093d in main ()
How do you suggest to proceed with debugging this?
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: hurd-i386 (i386-AT386)
Kernel: GNU-Mach 1.3.99/Hurd-0.3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages perl depends on:
ii hurd 20090404-2 The GNU Hurd
ii libbz2-1.0 1.0.5-3 high-quality block-sorting file co
ii libc0.3 2.10.1-7 GNU C Library: Shared libraries
ii libdb4.7 4.7.25-8 Berkeley v4.7 Database Libraries [
ii libgdbm3 1.8.3-9 GNU dbm database routines (runtime
ii perl-base 5.10.1-8 minimal Perl system
ii perl-modules 5.10.1-8 Core Perl modules
ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime
Versions of packages perl recommends:
ii make 3.81-7 An utility for Directing compilati
ii netbase 4.37 Basic TCP/IP networking system
Versions of packages perl suggests:
pn libterm-readline-gnu-perl | l <none> (no description available)
pn perl-doc <none> (no description available)
-- no debconf information
Regards,
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Schwinge
Here is a more useful backtrace, thanks to installing the perl-debug
package:
#0 abort () at abort.c:55
act = {__sigaction_handler = {sa_handler = 0x3a, sa_sigaction = 0x3a}, sa_mask = 23067476, sa_flags = 85024}
sigs = <value optimized out>
#1 0x0112c71c in __libc_message (do_abort=2, fmt=0x1214956 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:138
ap = 0x15ffb6c "\364\177\"\001\310\352\031\b\001>\036\b\210\373_\001\220\307\035\001>I!\001\310\352\031\b8\374_\001\030"
fd = 4
on_2 = <value optimized out>
list = <value optimized out>
nlist = 5
cp = <value optimized out>
#2 0x011dc7db in __fortify_fail (msg=0x121493e "stack smashing detected") at fortify_fail.c:32
No locals.
#3 0x011dc790 in __stack_chk_fail () at stack_chk_fail.c:29
No locals.
#4 0x08070018 in Perl_newATTRSUB (my_perl=0x819eac8, floor=322, o=0x88b2f28, proto=0x0, attrs=0x0, block=0x889e828) at op.c:5843
aname = 0x0
gv = 0x81e9404
ps = 0x0
ps_len = 150752024
cv = 0x8fa3614
const_sv = <value optimized out>
gv_fetch_flags = 2
name = 0x81e3eb4 "BEGIN"
__PRETTY_FUNCTION__ = "Perl_newATTRSUB"
#5 0x0806ed90 in Perl_utilize (my_perl=0x819eac8, aver=1, floor=322, version=0x0, idop=0x88abbd8, arg=0x0) at op.c:3878
pack = 0x88b5810
imop = <value optimized out>
veop = 0x0
#6 0x080a5d15 in Perl_yyparse (my_perl=0x819eac8) at perly.y:659
yystate = <value optimized out>
yyn = 80
yyresult = <value optimized out>
yytoken = <value optimized out>
parser = 0x8d68e04
ps = 0x8d74094
yyval = {ival = 0, pval = 0x0, opval = 0x0, gvval = 0x0, p_tkval = 0x0, i_tkval = 0}
#7 0x0811e93b in S_doeval (my_perl=0x819eac8, gimme=128, startop=0x0, outside=0x85bd834, seq=4264) at pp_ctl.c:2981
sp = <value optimized out>
saveop = 0x85a0f60
__PRETTY_FUNCTION__ = "S_doeval"
#8 0x0811f4fc in Perl_pp_entereval (my_perl=0x819eac8) at pp_ctl.c:3671
sp = 0x8bdf044
cx = <value optimized out>
sv = <value optimized out>
gimme = <value optimized out>
was = 2603
tbuf = "_<(eval 1066)\000@\324\031\b\340,\002"
tmpbuf = 0x15ffd82 "_<(eval 1066)"
safestr = 0x8d50760 "_<(eval 1066)"
len = 13
ok = <value optimized out>
runcv = 0x85bd834
seq = 4264
saved_hh = 0x0
#9 0x080dce79 in Perl_runops_standard (my_perl=0x819eac8) at run.c:40
No locals.
#10 0x080770ee in S_run_body (my_perl=0x819eac8) at perl.c:2431
__PRETTY_FUNCTION__ = "S_run_body"
#11 perl_run (my_perl=0x819eac8) at perl.c:2349
oldscope = 1
ret = <value optimized out>
cur_env = {je_prev = 0x819ec7c, je_buf = {{__jmpbuf = {23068240, 135910464, 142560, 23068168, 23068096, 134704751},
__mask_was_saved = 0, __saved_mask = 0}}, je_ret = 0, je_mustcatch = 0 '\000'}
#12 0x0806093d in main (argc=2, argv=0x15ffea8, env=0x15ffeb4) at perlmain.c:117
exitstatus = <value optimized out>
Regards,
Thomas
Niko Tyni
> Here is a more useful backtrace, thanks to installing the perl-debug
> package:
Thanks. Is it reproducible with #!/usr/bin/debugperl ?
That's compiled with extra debugging info and without optimizations,
so the trace should be better.
Could you put together a testcase so others can reproduce it?
Is this specific to the hurd port? I wasn't aware libc is
compiled with fortifying options, is that the case elsewhere too?
--
Niko Tyni nt...@debian.org
Thomas Schwinge
Sorry for being late with answering.
On Wed, Nov 25, 2009 at 01:30:56PM +0200, Niko Tyni wrote:
> On Wed, Nov 25, 2009 at 09:45:52AM +0100, Thomas Schwinge wrote:
> > Here is a more useful backtrace, thanks to installing the perl-debug
> > package:
>
> Thanks. Is it reproducible with #!/usr/bin/debugperl ?
Yes. Here is the backtrace, from ``break abort'':
#0 abort () at abort.c:55
act = {__sigaction_handler = {sa_handler = 0x3f, sa_sigaction = 0x3f}, sa_mask = 23067412, sa_flags = 85024}
sigs = <value optimized out>
#1 0x0112c71c in __libc_message (do_abort=2, fmt=0x1214956 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:138
ap = 0x15ffb2c "\364\177\"\001\003"
fd = 4
on_2 = <value optimized out>
list = <value optimized out>
nlist = 5
cp = <value optimized out>
#2 0x011dc7db in __fortify_fail (msg=0x121493e "stack smashing detected") at fortify_fail.c:32
No locals.
#3 0x011dc790 in __stack_chk_fail () at stack_chk_fail.c:29
No locals.
#4 0x08073e11 in Perl_newATTRSUB (my_perl=0x82b7fe8, floor=322, o=0x8aa56c8, proto=0x0, attrs=0x0, block=0x8aa7680) at op.c:5843
aname = 0x0
gv = 0x872d498
ps = 0x0
ps_len = 153893344
cv = 0x91a6d98
const_sv = <value optimized out>
gv_fetch_flags = 2
name = 0x82ff9dc "BEGIN"
__PRETTY_FUNCTION__ = "Perl_newATTRSUB"
#5 0x08072e90 in Perl_utilize (my_perl=0x82b7fe8, aver=1, floor=322, version=0x0, idop=0x8aade80, arg=0x0) at op.c:3878
pack = 0x8a9d198
imop = <value optimized out>
veop = 0x0
#6 0x080c0ed4 in Perl_yyparse (my_perl=0x82b7fe8) at perly.y:659
yystate = 375
yyn = 80
yyresult = <value optimized out>
yytoken = 14
parser = 0x9296608
ps = 0x91a58bc
yyval = {ival = 1, pval = 0x1 <Address 0x1 out of bounds>, opval = 0x1, gvval = 0x1, p_tkval = 0x1 <Address 0x1 out of bounds>,
i_tkval = 1}
#7 0x0819ba68 in S_doeval (my_perl=0x82b7fe8, gimme=128, startop=0x0, outside=0x872d8a8, seq=4264) at pp_ctl.c:2981
sp = <value optimized out>
saveop = 0x8744538
__PRETTY_FUNCTION__ = "S_doeval"
#8 0x0819cba4 in Perl_pp_entereval (my_perl=0x82b7fe8) at pp_ctl.c:3671
sp = 0x8e6e048
cx = 0x82dee08
sv = <value optimized out>
gimme = <value optimized out>
was = 2712
tbuf = "_<(eval 1175)\000\350\177+\b\340,\002"
tmpbuf = <value optimized out>
safestr = 0x8ebaec8 "_<(eval 1175)"
len = 13
ok = <value optimized out>
runcv = 0x872d8a8
seq = 4264
saved_hh = 0x0
__PRETTY_FUNCTION__ = "Perl_pp_entereval"
#9 0x080ed3a7 in Perl_runops_debug (my_perl=0x82b7fe8) at dump.c:1968
No locals.
#10 0x0807ea20 in S_run_body (my_perl=0x82b7fe8) at perl.c:2431
__PRETTY_FUNCTION__ = "S_run_body"
#11 perl_run (my_perl=0x82b7fe8) at perl.c:2349
oldscope = 1
ret = <value optimized out>
cur_env = {je_prev = 0x82b819c, je_buf = {{__jmpbuf = {19038196, 23068240, 142560, 23068168, 23068080, 134735376},
__mask_was_saved = 0, __saved_mask = 0}}, je_ret = 0, je_mustcatch = 0 '\000'}
__PRETTY_FUNCTION__ = "perl_run"
#12 0x08060a85 in main (argc=2, argv=0x15ffea8, env=0x15ffeb4) at perlmain.c:117
exitstatus = <value optimized out>
> Could you put together a testcase so others can reproduce it?
I will try to reduce this to a suitable testcase.
> Is this specific to the hurd port?
A quick attempt to reproduce this on GNU/Linux with mostly similar
packages installed didn't reveal this Perl bug, but I'll try some more to
make this reproducible on Linux-based systems. Of course, you (or
everyone else interested) could also get an account on this Hurd machine.
> I wasn't aware libc is
> compiled with fortifying options, is that the case elsewhere too?
Isn't it rather that Perl is being compiled with fortifying options (I
didn't check)? glibc / GCC only provide the infrastructure and print out
the error message.
Regards,
Thomas
Thomas Schwinge
Joey, cf. <http://bugs.debian.org/557771>.
On Tue, Dec 22, 2009 at 11:55:58PM +0100, I wrote:
> On Wed, Nov 25, 2009 at 01:30:56PM +0200, Niko Tyni wrote:
> > Could you put together a testcase so others can reproduce it?
>
> I will try to reduce this to a suitable testcase.
Still on GNU/Hurd:
hurd-web@foobar:~$ ikiwiki -setup hurd-web.setup --render hurd-web/colophon.mdwn
*** stack smashing detected ***: /usr/bin/debugperl terminated
Aborted
hurd-web@foobar:~$ mv hurd-web/.ikiwiki/indexdb{,.}
hurd-web@foobar:~$ ikiwiki -setup hurd-web.setup --render hurd-web/colophon.mdwn
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
[...]
</body>
</html>
hurd-web@foobar:~$ mv hurd-web/.ikiwiki/indexdb{.,}
hurd-web@foobar:~$ ikiwiki -setup hurd-web.setup --render hurd-web/colophon.mdwn
*** stack smashing detected ***: /usr/bin/debugperl terminated
Aborted
So, the indexdb got corrupted in a way that would make Perl go bonkers.
Is someone interested in debugging this? Otherwise I'll simply have
ikiwiki regenerate this file, and hope that it doesn't get corrupted
again.
> > Is this specific to the hurd port?
>
> A quick attempt to reproduce this on GNU/Linux with mostly similar
> packages installed didn't reveal this Perl bug, but I'll try some more to
> make this reproducible on Linux-based systems. Of course, you (or
> everyone else interested) could also get an account on this Hurd machine.
The offer for an account still holds, too.
Regards,
Thomas
Thomas Schwinge
Uh, removing the indexdb does fix it when rendering that one file
manually, but not when rebuilding the whole set of page -- even rm -rf
.ikiwiki doesn't help:
[...]
scanning ikiwiki/pagespec/sorting.mdwn
scanning ikiwiki/pagespec/po.mdwn
scanning ikiwiki/subpage/linkingrules.mdwn
building render_locally
building abac.mdwn
*** stack smashing detected ***: /usr/bin/debugperl terminated
Aborted
render_locally is simply copied, and abac.mdwn is the first page to be
built.
Regards,
Thomas
Niko Tyni
You're right of course, sorry. It must be the -fstack-protector compile
flag added with 5.10.1. That would explain why I haven't seen reports
with this failure mode earlier.
Niko Tyni
> On Wed, Dec 23, 2009 at 12:30:27AM +0100, I wrote:
> > So, the indexdb got corrupted in a way that would make Perl go bonkers.
> > Is someone interested in debugging this? Otherwise I'll simply have
> > ikiwiki regenerate this file, and hope that it doesn't get corrupted
> > again.
>
> Uh, removing the indexdb does fix it when rendering that one file
> manually, but not when rebuilding the whole set of page -- even rm -rf
> .ikiwiki doesn't help:
Looks rather like a problem with the Storable module, but it's hard to say
more without a test case.
Please note that the perl test suite doesn't pass on hurd yet AFAIK, so
it's possible this is just a consequence of unimplemented or unfinished
functionality. Reproducing the bug on another port would eliminate that.
Thomas Schwinge
On Fri, Dec 25, 2009 at 03:26:05PM +0200, Niko Tyni wrote:
> Looks rather like a problem with the Storable module, but it's hard to say
> more without a test case.
That's what I thought, too, but I now bisected this down to perlmagick
being installed vs. not being installed. Involving Pino Toscano who
recently did some imagemagick patching
(cf. <http://bugs.debian.org/551017>) -- Pino, please note that I'm not
saying that you're responsible for this perlmagick breakage which we're
discussing in <http://bugs.debian.org/557771>, but perhaps you have an
idea / know how to run some testing / etc.
Unfortunately I can't locate an installable older version of perlmagick
et al. on snapshot.debian.net, but installed vs. not installed is
confirmed on three different (Hurd) systems.
> Please note that the perl test suite doesn't pass on hurd yet AFAIK, so
> it's possible this is just a consequence of unimplemented or unfinished
> functionality. Reproducing the bug on another port would eliminate that.
Regards,
Thomas
Thomas Schwinge
On Sun, Dec 27, 2009 at 11:44:43PM +0100, I wrote:
> On Fri, Dec 25, 2009 at 03:26:05PM +0200, Niko Tyni wrote:
> > Looks rather like a problem with the Storable module, but it's hard to say
> > more without a test case.
>
> That's what I thought, too, but I now bisected this down to perlmagick
> being installed vs. not being installed. Involving Pino Toscano who
> recently did some imagemagick patching
> (cf. <http://bugs.debian.org/551017>) -- Pino, please note that I'm not
> saying that you're responsible for this perlmagick breakage which we're
> discussing in <http://bugs.debian.org/557771>, but perhaps you have an
> idea / know how to run some testing / etc.
>
> Unfortunately I can't locate an installable older version of perlmagick
> et al. on snapshot.debian.net, but installed vs. not installed is
> confirmed on three different (Hurd) systems.
I'm currently building imagemagick 6.2.4.5.dfsg1-2 (which I think was the
latest version built for GNU/Hurd?) in the current Perl environment.
> > Please note that the perl test suite doesn't pass on hurd yet AFAIK, so
> > it's possible this is just a consequence of unimplemented or unfinished
> > functionality. Reproducing the bug on another port would eliminate that.
Trying to run the perlmagick demos:
$ rsync -a /usr/share/doc/perlmagick/examples/demo/ perlmagick-demos/
$ cd perlmagick-demos/
$ gunzip demo.pl
$ make
perl demo.pl
*** stack smashing detected ***: perl terminated
make: *** [all] Aborted
This is not reproducible on i386 Linux.
Reducing further:
$ perl -e 'use Image::Magick;'
*** stack smashing detected ***: perl terminated
Aborted
#0 __stack_chk_fail () at stack_chk_fail.c:29
No locals.
#1 0x08073e11 in Perl_newATTRSUB (my_perl=0x82b7fe8, floor=27, o=0x82b8940, proto=0x0, attrs=0x0, block=0x82b8920) at op.c:5843
aname = 0x0
gv = 0x82fdca8
ps = 0x0
ps_len = 24
cv = 0x82fdc28
const_sv = <value optimized out>
gv_fetch_flags = 2
name = 0x830171c "BEGIN"
__PRETTY_FUNCTION__ = "Perl_newATTRSUB"
#2 0x08072e90 in Perl_utilize (my_perl=0x82b7fe8, aver=1, floor=27, version=0x0, idop=0x82b8740, arg=0x0) at op.c:3878
pack = 0x82b8760
imop = <value optimized out>
veop = 0x0
#3 0x080c0ed4 in Perl_yyparse (my_perl=0x82b7fe8) at perly.y:659
yystate = 375
yyn = 80
yyresult = <value optimized out>
yytoken = 14
parser = 0x82f8608
ps = 0x83018bc
yyval = {ival = 1, pval = 0x1 <Address 0x1 out of bounds>, opval = 0x1, gvval = 0x1, p_tkval = 0x1 <Address 0x1 out of bounds>,
i_tkval = 1}
#4 0x08080cc4 in S_parse_body (my_perl=0x82b7fe8, env=0x0, xsinit=0x8060aa0 <xs_init>) at perl.c:2274
rsfp = 0x82f8018
argc = 1
argv = 0x15ffc10
scriptname = 0x823616f "/dev/null"
dosearch = 0 '\000'
sv = 0x82db8d8
c = <value optimized out>
cddir = 0x0
linestr_sv = 0x82db8c8
add_read_e_script = 1 '\001'
__PRETTY_FUNCTION__ = "S_parse_body"
#5 0x08082914 in perl_parse (my_perl=0x82b7fe8, xsinit=0x8060aa0 <xs_init>, argc=3, argv=0x15ffc08, env=0x0) at perl.c:1687
oldscope = 1
ret = 0
cur_env = {je_prev = 0x82b819c, je_buf = {{__jmpbuf = {40, 1, 3, 23067496, 23067408, 134751448}, __mask_was_saved = 0,
__saved_mask = 137063936}}, je_ret = 0, je_mustcatch = 0 '\000'}
__PRETTY_FUNCTION__ = "perl_parse"
#6 0x08060a42 in main (argc=3, argv=0x15ffc08, env=0x15ffc18) at perlmain.c:115
exitstatus = <value optimized out>
Enough for today; good night.
Regards,
Thomas
Pino Toscano
Alle domenica 27 dicembre 2009, Thomas Schwinge ha scritto:
> On Fri, Dec 25, 2009 at 03:26:05PM +0200, Niko Tyni wrote:
> > Looks rather like a problem with the Storable module, but it's hard to
> > say more without a test case.
>
> That's what I thought, too, but I now bisected this down to perlmagick
> being installed vs. not being installed. Involving Pino Toscano who
> recently did some imagemagick patching
> (cf. <http://bugs.debian.org/551017>) -- Pino, please note that I'm not
> saying that you're responsible for this perlmagick breakage which we're
> discussing in <http://bugs.debian.org/557771>, but perhaps you have an
> idea / know how to run some testing / etc.
The only change needed was patching GetExecutionPath() (defined in
magick/utility.c); note that the released version is slightly different from
the one I sent.
Knowing whether that function is the actual issue should be matter of taking
the current implementation in the "#if defined(__GNU__) ... #endif" block out
of there, put only a "return (MagickFalse);" in its place, recompile and test.
If it still doesn't work with the above change, another option would be adding
1 to the calculation of "extent" (always in the __GNU__ block said above).
A further option would be asking upstream to provide more unit test for that
function, in case the current unit tests (which all pass on Hurd) do not
covert it yet/fully.
--
Pino Toscano
Dominic Hargreaves
thanks
dom@hurdtest:~/perlmagick-demos$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for i486-gnu-thread-multi-64int
(with 59 registered patches, see perl -V for more detail)
...
dom@hurdtest:~$ perl -e 'use Image::Magick;'
dom@hurdtest:~$
I think bisecting to find out where the bug went away is going to be a
lot of work for not much gain, so I propose to just close this off with
no further work. Any objections?
Thanks,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
Thomas Schwinge
First, thanks for handling this old issue!
On Tue, 20 Mar 2012 22:58:37 +0000, Dominic Hargreaves <d...@earth.li> wrote:
> On Mon, Dec 28, 2009 at 12:43:43AM +0100, Thomas Schwinge wrote:
> > $ perl -e 'use Image::Magick;'
> > *** stack smashing detected ***: perl terminated
> > Aborted
>
> I can't reproduce this on an up to date sid system:
>
> dom@hurdtest:~/perlmagick-demos$ perl -v
>
> This is perl 5, version 14, subversion 2 (v5.14.2) built for i486-gnu-thread-multi-64int
> (with 59 registered patches, see perl -V for more detail)
> ...
>
> dom@hurdtest:~$ perl -e 'use Image::Magick;'
> dom@hurdtest:~$
>
> I think bisecting to find out where the bug went away is going to be a
> lot of work for not much gain, so I propose to just close this off with
> no further work. Any objections?
We had been doing some further triage at
<http://www.gnu.org/software/hurd/open_issues/perlmagick.html>
(<http://git.savannah.gnu.org/cgit/hurd/web.git/tree/open_issues/perlmagick.mdwn>
for posterity), but apparently that information never found its way into
this bug report, which I apologize for.
Grüße,
Thomas