miniperl 5.8.7 fails building DynaLoader

[p5pRT]

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

Searchable as RT36309$

[p5pRT]

From alanh@fairlite.demon.co.uk

Created by alanh@fairlite.demon.co.uk

This is a bug report for perl from alanh@fairlite.demon.co.uk,
generated with the help of perlbug 1.35 running under perl v5.8.5.

---

When building perl 5.8.7 with the -fstack-protector patches for GCC,
miniperl fails to build DynaLoader and segfaults. This didn't happen
with 5.8.6.

Here's a backtrace of the crash in miniperl.

Starting program: /usr/src/perl-5.8.7/miniperl "-I../../lib"
"-I../../lib" ../../lib/ExtUtils/xsubpp -noprototypes -typemap
../../lib/ExtUtils/typemap DynaLoader.xs > DynaLoader.xsc && mv
DynaLoader.xsc DynaLoader.c

Program received signal SIGSEGV, Segmentation fault.
0x080d5a45 in S_regmatch (prog=0x8) at regexec.c:2886
2886 PL_op = (OP_4tree*)PL_regdata->data[n];
(gdb) bt
#0 0x080d5a45 in S_regmatch (prog=0x8) at regexec.c:2886
#1 0x080d67fb in S_regmatch (prog=0x8) at regexec.c:3323
#2 0x080d67fb in S_regmatch (prog=0x8) at regexec.c:3323
#3 0x080d80e2 in S_regmatch (prog=0x8) at regexec.c:3845
#4 0x081b2c98 in ?? ()
#5 0x00000091 in ?? ()
#6 0x00000091 in ?? ()
#7 0x0824032c in ?? ()
#8 0x0000007f in ?? ()
#9 0xbfffe4b8 in ?? ()
#10 0x080d697e in S_regmatch (prog=0x8) at regexec.c:3348
#11 0x080d6153 in S_regmatch (prog=0x8) at regexec.c:3151
#12 0x080d5dbb in S_regmatch (prog=0x8) at regexec.c:2978
#13 0x080d67fb in S_regmatch (prog=0x8) at regexec.c:3323
#14 0x080d67fb in S_regmatch (prog=0x8) at regexec.c:3323
#15 0x080d6153 in S_regmatch (prog=0x8) at regexec.c:3151
#16 0x080d5dbb in S_regmatch (prog=0x8) at regexec.c:2978
#17 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c:3818
#18 0x08240313 in ?? ()
#19 0x0823f3dc in ?? ()
#20 0x0000002c in ?? ()
#21 0x08240317 in ?? ()
#22 0x00000023 in ?? ()
#23 0x00000000 in ?? ()
#24 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c:3818
#25 0x0814adc8 in ?? ()
#26 0x0815f558 in ?? ()
#27 0x00000029 in ?? ()
#28 0x08240313 in ?? ()
#29 0x00000023 in ?? ()
#30 0xbfffeff8 in ?? ()
#31 0x080d697e in S_regmatch (prog=0x8) at regexec.c:3348
#32 0x080d6153 in S_regmatch (prog=0x8) at regexec.c:3151
#33 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c:3818
#34 0x00000000 in ?? ()
#35 0x0823f438 in ?? ()
#36 0x00000028 in ?? ()
#37 0x08240312 in ?? ()
#38 0x00000023 in ?? ()
#39 0x00000000 in ?? ()
#40 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c:3818
#41 0x3931895a in ?? ()
#42 0x0823f2fc in ?? ()
#43 0x0823f9e0 in ?? ()
#44 0x08240312 in ?? ()
#45 0x00000023 in ?? ()
#46 0x00000002 in ?? ()
#47 0x080d7e7e in S_regmatch (prog=0x8) at regexec.c:3795
#48 0xb7fc93f4 in mylock () from /lib/libc.so.0
#49 0x0005021c in ?? ()
#50 0x00000073 in ?? ()
#51 0x08240309 in ?? ()
#52 0x00000023 in ?? ()
#53 0x00000000 in ?? ()
#54 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c:3818
#55 0x0823ab4c in ?? ()
#56 0x00000067 in ?? ()
#57 0x0823f2a8 in ?? ()
#58 0x00000000 in ?? ()
#59 0x00000023 in ?? ()
#60 0x08240308 in ?? ()
#61 0x080d88db in S_regtry (prog=0x8240308,
startpos=0x3931895a <Address 0x3931895a out of bounds>) at
regexec.c:2196
#62 0x080dc03b in Perl_regexec_flags (prog=0x823f2a8,
stringarg=0x8240308 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var.context.value().size());\n",
strend=0x8240355 "",
strbeg=0x8240308 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var.context.value().size());\n",
minend=0, sv=0x823ab4c, data=0x0, flags=3)
at regexec.c:1750
---Type <return> to continue, or q <return> to quit---
#63 0x08097e3e in Perl_pp_match () at pp_hot.c:1340
#64 0x0808713f in Perl_runops_debug () at dump.c:1452
#65 0x0805cbfe in perl_run (my_perl=0x8114100) at perl.c:2000
#66 0x0804b34a in main (argc=-1073743736, argv=0xbffff864, env=0x8049ccd)
at miniperlmain.c:98

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=high
---
Site configuration information for perl v5.8.5:

Configured by Gentoo at Mon Mar 21 19:34:07 GMT 2005.

Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=linux, osvers=2.6.10-gentoo-r6, archname=i686-linux
uname='linux server 2.6.10-gentoo-r6 #1 smp sun feb 20 23:27:37 gmt 2005 i686 pentium iii (katmai) genuineintel gnulinux '
config_args='-des -Darchname=i686-linux -Dcccdlflags=-fPIC -Dccdlflags=-rdynamic -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dlocincpth= -Doptimize=-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe -Duselargefiles -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dinstallman1dir=/usr/share/man/man1 -Dinstallman3dir=/var/tmp/portage/perl-5.8.5-r5/image//usr/share/man/man3 -Dman1ext=1 -Dman3ext=3pm -Dinc_version_list=5.8.0 5.8.0/i686-linux 5.8.2 5.8.2/i686-linux 5.8.4 5.8.4/i686-linux -Dcf_by=Gentoo -Ud_csh -Di_ndbm -Di_gdbm -Di_db'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe',
cppflags='-DPERL5 -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)', 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='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lpthread -lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.3.4.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.3.4'
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.8.5:
/etc/perl
/usr/lib/perl5/site_perl/5.8.5/i686-linux
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.2/i686-linux
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.4/i686-linux
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.5/i686-linux
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl/5.8.0/i686-linux
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.2/i686-linux
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.4/i686-linux
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.5/i686-linux
/usr/lib/perl5/5.8.5
/usr/local/lib/site_perl
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i686-linux
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.2/i686-linux
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.4/i686-linux
.

---
Environment for perl v5.8.5:
HOME=/root
LANG (unset)
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3.5-20050130:/opt/blackdown-jdk-1.4.2.01/bin:/opt/blackdown-jdk-1.4.2.01/jre/bin:/usr/qt/3/bin:/usr/kde/3.2/sbin:/usr/kde/3.2/bin
PERL_BADLANG (unset)
SHELL=/bin/bash

[p5pRT]

From @nwc10

On Thu, Jun 16, 2005 at 11​:13​:28AM -0000, alanh @​ fairlite. demon. co. uk wrote​:

When building perl 5.8.7 with the -fstack-protector patches for GCC,
miniperl fails to build DynaLoader and segfaults. This didn't happen
with 5.8.6.

I was unaware that these patches exist. Is the output of the debugging trace
consistent with what you would expect from a stack smashing attack?
(ie is perl inadvertently overflowing a buffer)

As you have line numbers in your stack backtrace, you must have compiled
with debuging, which means that you're not using the same compiler flags as
the perl that perlbug ran with.

Could you run ./myconfig and send the output?

I don't have any guesses as to what changed in 5.8.7, but I'm hoping someone
will spot something in that output and figure out why.

Nicholas Clark

[p5pRT]

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

[p5pRT]

From alanh@fairlite.demon.co.uk

On Thu, Jun 16, 2005 at 01​:23​:37PM -0000, Nicholas Clark via RT wrote​:

On Thu, Jun 16, 2005 at 11​:13​:28AM -0000, alanh @​ fairlite. demon. co. uk wrote​:

When building perl 5.8.7 with the -fstack-protector patches for GCC,
miniperl fails to build DynaLoader and segfaults. This didn't happen
with 5.8.6.

I was unaware that these patches exist. Is the output of the debugging trace
consistent with what you would expect from a stack smashing attack?
(ie is perl inadvertently overflowing a buffer)

I'm not sure as I haven't dug that deeply, but using -fno-stack-protector
fixes the problem, so I'm assuming so.

Here's a backtrace of the crash in miniperl.

Starting program​: /usr/src/perl-5.8.7/miniperl "-I../../lib"
"-I../../lib" ../../lib/ExtUtils/xsubpp -noprototypes -typemap
../../lib/ExtUtils/typemap DynaLoader.xs > DynaLoader.xsc && mv
DynaLoader.xsc DynaLoader.c

Program received signal SIGSEGV, Segmentation fault.
0x080d5a45 in S_regmatch (prog=0x8) at regexec.c​:2886
2886 PL_op = (OP_4tree*)PL_regdata->data[n];
(gdb) bt
#0 0x080d5a45 in S_regmatch (prog=0x8) at regexec.c​:2886
#1 0x080d67fb in S_regmatch (prog=0x8) at regexec.c​:3323
#2 0x080d67fb in S_regmatch (prog=0x8) at regexec.c​:3323
#3 0x080d80e2 in S_regmatch (prog=0x8) at regexec.c​:3845
#4 0x081b2c98 in ?? ()
#5 0x00000091 in ?? ()
#6 0x00000091 in ?? ()
#7 0x0824032c in ?? ()
#8 0x0000007f in ?? ()
#9 0xbfffe4b8 in ?? ()
#10 0x080d697e in S_regmatch (prog=0x8) at regexec.c​:3348
#11 0x080d6153 in S_regmatch (prog=0x8) at regexec.c​:3151
#12 0x080d5dbb in S_regmatch (prog=0x8) at regexec.c​:2978
#13 0x080d67fb in S_regmatch (prog=0x8) at regexec.c​:3323
#14 0x080d67fb in S_regmatch (prog=0x8) at regexec.c​:3323
#15 0x080d6153 in S_regmatch (prog=0x8) at regexec.c​:3151
#16 0x080d5dbb in S_regmatch (prog=0x8) at regexec.c​:2978
#17 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c​:3818
#18 0x08240313 in ?? ()
#19 0x0823f3dc in ?? ()
#20 0x0000002c in ?? ()
#21 0x08240317 in ?? ()
#22 0x00000023 in ?? ()
#23 0x00000000 in ?? ()
#24 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c​:3818
#25 0x0814adc8 in ?? ()
#26 0x0815f558 in ?? ()
#27 0x00000029 in ?? ()
#28 0x08240313 in ?? ()
#29 0x00000023 in ?? ()
#30 0xbfffeff8 in ?? ()
#31 0x080d697e in S_regmatch (prog=0x8) at regexec.c​:3348
#32 0x080d6153 in S_regmatch (prog=0x8) at regexec.c​:3151
#33 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c​:3818
#34 0x00000000 in ?? ()
#35 0x0823f438 in ?? ()
#36 0x00000028 in ?? ()
#37 0x08240312 in ?? ()
#38 0x00000023 in ?? ()
#39 0x00000000 in ?? ()
#40 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c​:3818
#41 0x3931895a in ?? ()
#42 0x0823f2fc in ?? ()
#43 0x0823f9e0 in ?? ()
#44 0x08240312 in ?? ()
#45 0x00000023 in ?? ()
#46 0x00000002 in ?? ()
#47 0x080d7e7e in S_regmatch (prog=0x8) at regexec.c​:3795
#48 0xb7fc93f4 in mylock () from /lib/libc.so.0
#49 0x0005021c in ?? ()
#50 0x00000073 in ?? ()
#51 0x08240309 in ?? ()
#52 0x00000023 in ?? ()
#53 0x00000000 in ?? ()
#54 0x080d7fd0 in S_regmatch (prog=0x8) at regexec.c​:3818
#55 0x0823ab4c in ?? ()
#56 0x00000067 in ?? ()
#57 0x0823f2a8 in ?? ()
#58 0x00000000 in ?? ()
#59 0x00000023 in ?? ()
#60 0x08240308 in ?? ()
#61 0x080d88db in S_regtry (prog=0x8240308,
startpos=0x3931895a <Address 0x3931895a out of bounds>) at
regexec.c​:2196
#62 0x080dc03b in Perl_regexec_flags (prog=0x823f2a8,
stringarg=0x8240308 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var.context.value().size());\n",
strend=0x8240355 "",
strbeg=0x8240308 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var.context.value().size());\n",
minend=0, sv=0x823ab4c, data=0x0, flags=3)
at regexec.c​:1750
---Type <return> to continue, or q <return> to quit---
#63 0x08097e3e in Perl_pp_match () at pp_hot.c​:1340
#64 0x0808713f in Perl_runops_debug () at dump.c​:1452
#65 0x0805cbfe in perl_run (my_perl=0x8114100) at perl.c​:2000
#66 0x0804b34a in main (argc=-1073743736, argv=0xbffff864, env=0x8049ccd)
at miniperlmain.c​:98

Compiler​:
cc='gcc', ccflags ='-fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O3 -march=pentium3 -fprefetch-loop-arrays -funroll-loops -pipe',
cppflags='-DPERL5 -fno-strict-aliasing -pipe'
ccversion='', gccversion='3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)', 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

As you have line numbers in your stack backtrace, you must have compiled
with debuging, which means that you're not using the same compiler flags as
the perl that perlbug ran with.

Could you run ./myconfig and send the output?

I don't have any guesses as to what changed in 5.8.7, but I'm hoping someone
will spot something in that output and figure out why.

Attached the output of ./myconfig below. Note that -fstack-protector
is implicitly enabled by default and doesn't show it in this log.

Alan.

Summary of my perl5 (revision 5 version 8 subversion 7) configuration​:
  Platform​:
  osname=linux, osvers=2.6.11-gentoo-r4, archname=i486-linux
  uname='linux ipcop 2.6.11-gentoo-r4 #1 smp wed mar 30 16​:12​:54 bst 2005 i486 pentium3 i486 gnulinux '
  config_args='-ds -e -Dprefix=/usr -Dpager=/bin/less -isR -Dd_dosuid -Ui_db -Ui_gdbm -Ui_ndbm -Ui_dbm -Dmyhostname=localhost -Doptimize=-g -Dccflags= -Os -fomit-frame-pointer -march=i486 -mtune=pentium -pipe'
  hint=recommended, useposix=true, d_sigaction=define
  usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
  useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
  use64bitint=undef use64bitall=undef uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-Os -fomit-frame-pointer -march=i486 -mtune=pentium -pipe -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-g',
  cppflags='-Os -fomit-frame-pointer -march=i486 -mtune=pentium -pipe -DDEBUGGING -fno-strict-aliasing'
  ccversion='', gccversion='3.4.3', 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 =''
  libpth=/usr/lib
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=/usr/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fpic', lddlflags='-shared'

[p5pRT]

From @smpeters

From my experimenting and daily smokes, this coredump occurs only with a
-g and -fstack-protector-all. Below is the backtrace.

#0 0x1c0fdcd7 in S_cache_re (prog=0x2eca7efb) at regexec.c​:347
347 PL_regprecomp = prog->precomp; /* Needed for
FAIL. */
(gdb) bt
#0 0x1c0fdcd7 in S_cache_re (prog=0x2eca7efb) at regexec.c​:347
#1 0x1c10d0a2 in S_regmatch (prog=0x7edb80b8) at regexec.c​:4167
#2 0x1c10a96f in S_regmatch (prog=0x7edb80b4) at regexec.c​:3672
#3 0x1c1098d1 in S_regmatch (prog=0x7edb8044) at regexec.c​:3475
#4 0x1c1093ad in S_regmatch (prog=0x7edb804c) at regexec.c​:3302
#5 0x1c10a6ab in S_regmatch (prog=0x7edb804c) at regexec.c​:3647
#6 0x1c10a6ab in S_regmatch (prog=0x7edb80b4) at regexec.c​:3647
#7 0x1c1098d1 in S_regmatch (prog=0x7edb8044) at regexec.c​:3475
#8 0x1c1093ad in S_regmatch (prog=0x84ce5f50) at regexec.c​:3302
#9 0x1c10cea8 in S_regmatch (prog=0x84ce5f40) at regexec.c​:4143
#10 0x1c10cea8 in S_regmatch (prog=0x84ce5f2c) at regexec.c​:4143
#11 0x1c10a96f in S_regmatch (prog=0x84ce5f28) at regexec.c​:3672
#12 0x1c1098d1 in S_regmatch (prog=0x84ce5ee0) at regexec.c​:3475
#13 0x1c10cea8 in S_regmatch (prog=0x84ce5ed0) at regexec.c​:4143
#14 0x1c10cea8 in S_regmatch (prog=0x84ce5ec8) at regexec.c​:4143
#15 0x1c10cbde in S_regmatch (prog=0x84ce5e50) at regexec.c​:4120
#16 0x1c10cea8 in S_regmatch (prog=0x84ce5e44) at regexec.c​:4143
#17 0x1c1052c3 in S_regtry (prog=0x84ce5e00,
  startpos=0x7e870d80 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var
.context.value().size());\n") at regexec.c​:2223
#18 0x1c1038ad in Perl_regexec_flags (prog=0x84ce5e00,
  stringarg=0x7e870d80 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$va
r.context.value().size());\n", strend=0x7e870dcd "",
  strbeg=0x7e870d80 "\tsv_setpvn($arg,
$var.context.value().chp(),\n\t\t$var.context.value().size());\n",
minend=0, sv=0x7cb76f90, data=0x0, flags=3)
  at regexec.c​:1764
#19 0x1c0986a6 in Perl_pp_match () at pp_hot.c​:1279
#20 0x1c07b6ac in Perl_runops_debug () at dump.c​:1600
#21 0x1c02d858 in S_run_body (oldscope=1) at perl.c​:1922
#22 0x1c02d3b1 in perl_run (my_perl=0x86d35030) at perl.c​:1851
#23 0x1c015783 in main (argc=8, argv=0xcfbc7074, env=0xcfbc7098)
  at miniperlmain.c​:103

[p5pRT]

From spoke@neuraldisruption.com

Possibly the catalyst?

"The internal pointer mapping hash used during ithreads cloning now uses
an arena for memory allocation. In tests this reduced ithreads cloning
time by about 10%."

If this change results in miniperl using memory in an "illegal" or
otherwise dangerous way, stack protector will terminate the process with
extreme prejudice.

[p5pRT]

From spoke@neuraldisruption.com

Duplicated the error, and this is what grsec had to say about it (ips,
gids, pids & uids replaced by '?')

grsec​: From ?.?.?.?​: denied hardlink of
/usr/lib/perl5/5.8.7/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
(owned by 0.0) to .libs/back_perl.lax/lt1-DynaLo for /bin/ln[ln​:?]
uid/euid​:?/? gid/egid​:?/?, parent /bin/bash[sh​:?] uid/euid​:?/? gid/egid​:?/?

[p5pRT]

From @jkeenan

On Fri Feb 03 02​:52​:24 2006, target wrote​:

Duplicated the error, and this is what grsec had to say about it (ips,
gids, pids & uids replaced by '?')

grsec​: From ?.?.?.?​: denied hardlink of
/usr/lib/perl5/5.8.7/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
(owned by 0.0) to .libs/back_perl.lax/lt1-DynaLo for /bin/ln[ln​:?]
uid/euid​:?/? gid/egid​:?/?, parent /bin/bash[sh​:?] uid/euid​:?/?
gid/egid​:?/?

Is there anyone who could evaluate the status of the issues in this RT?

Thank you very much.
Jim Keenan

[p5pRT]

From @nwc10

On Fri Mar 30 17​:54​:22 2012, jkeenan wrote​:

On Fri Feb 03 02​:52​:24 2006, target wrote​:

Duplicated the error, and this is what grsec had to say about it (ips,
gids, pids & uids replaced by '?')

grsec​: From ?.?.?.?​: denied hardlink of

/usr/lib/perl5/5.8.7/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a

(owned by 0.0) to .libs/back_perl.lax/lt1-DynaLo for /bin/ln[ln​:?]
uid/euid​:?/? gid/egid​:?/?, parent /bin/bash[sh​:?] uid/euid​:?/?
gid/egid​:?/?

That doesn't seem to be related to the original bug report about
backtraces from running code.

Is there anyone who could evaluate the status of the issues in this RT?

Somewhat less that satisfactory, but​:

5.8.7 and later build for me on the (newer) OpenBSD systems I have
access to. (As does blead). We also now enable -fstack-protector by
default on all systems where the probe for it passes.

So it *seems* that whatever the cause of this problem was, it is
resolved. On that basis I'm going to mark the ticket as resolved. But I
would have preferred a positive confirmation of which core change (or
gcc change) resolved it, to be sure that it wasn't just symptoms being
shuffled under the carpet.

Nicholas Clark

[p5pRT]

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

[p5pRT]

From @nwc10

[bother. There are now two copies of my comment on this in RT. Sorry.]

On Fri Mar 30 17​:54​:22 2012, jkeenan wrote​:

On Fri Feb 03 02​:52​:24 2006, target wrote​:

Duplicated the error, and this is what grsec had to say about it (ips,
gids, pids & uids replaced by '?')

grsec​: From ?.?.?.?​: denied hardlink of

/usr/lib/perl5/5.8.7/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a

(owned by 0.0) to .libs/back_perl.lax/lt1-DynaLo for /bin/ln[ln​:?]
uid/euid​:?/? gid/egid​:?/?, parent /bin/bash[sh​:?] uid/euid​:?/?
gid/egid​:?/?

That doesn't seem to be related to the original bug report about
backtraces from running code.

Is there anyone who could evaluate the status of the issues in this RT?

Somewhat less that satisfactory, but​:

5.8.7 and later build for me on the (newer) OpenBSD systems I have
access to. (As does blead). We also now enable -fstack-protector by
default on all systems where the probe for it passes.

So it *seems* that whatever the cause of this problem was, it is
resolved. On that basis I'm going to mark the ticket as resolved. But I
would have preferred a positive confirmation of which core change (or
gcc change) resolved it, to be sure that it wasn't just symptoms being
shuffled under the carpet.

Nicholas Clark

[p5pRT]

From [Unknown Contact. See original ticket]

[bother. There are now two copies of my comment on this in RT. Sorry.]

On Fri Mar 30 17​:54​:22 2012, jkeenan wrote​:

On Fri Feb 03 02​:52​:24 2006, target wrote​:

Duplicated the error, and this is what grsec had to say about it (ips,
gids, pids & uids replaced by '?')

grsec​: From ?.?.?.?​: denied hardlink of

/usr/lib/perl5/5.8.7/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a

(owned by 0.0) to .libs/back_perl.lax/lt1-DynaLo for /bin/ln[ln​:?]
uid/euid​:?/? gid/egid​:?/?, parent /bin/bash[sh​:?] uid/euid​:?/?
gid/egid​:?/?

That doesn't seem to be related to the original bug report about
backtraces from running code.

Is there anyone who could evaluate the status of the issues in this RT?

Somewhat less that satisfactory, but​:

5.8.7 and later build for me on the (newer) OpenBSD systems I have
access to. (As does blead). We also now enable -fstack-protector by
default on all systems where the probe for it passes.

So it *seems* that whatever the cause of this problem was, it is
resolved. On that basis I'm going to mark the ticket as resolved. But I
would have preferred a positive confirmation of which core change (or
gcc change) resolved it, to be sure that it wasn't just symptoms being
shuffled under the carpet.

Nicholas Clark