regexp: unicode char causes a 'double free corruption'

[p5pRT]

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

Searchable as RT48156$

[p5pRT]

From steev@hot.pl

Created by steev@hot.pl

Perl Info

Flags:
    category=core
    severity=medium

This perlbug was built using Perl v5.8.8 in the Red Hat build system.
It is being executed now by Perl v5.8.8 - Mon Nov 12 14:45:10 EST 2007.

Site configuration information for perl v5.8.8:

Configured by Red Hat, Inc. at Mon Nov 12 14:45:10 EST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=linux, osvers=2.6.20-1.2952.fc6, archname=i386-linux-thread-multi
    uname='linux hammer2.fedora.redhat.com 2.6.20-1.2952.fc6 #1 smp wed may 16 18:18:22 edt 2007 i686 athlon i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    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 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='4.1.2 20070925 (Red Hat 4.1.2-33)', 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=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.8:
    /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.8
    /usr/lib/perl5/site_perl/5.8.7
    /usr/lib/perl5/site_perl/5.8.6
    /usr/lib/perl5/site_perl/5.8.5
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.8
    /usr/lib/perl5/vendor_perl/5.8.7
    /usr/lib/perl5/vendor_perl/5.8.6
    /usr/lib/perl5/vendor_perl/5.8.5
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.8/i386-linux-thread-multi
    /usr/lib/perl5/5.8.8
    .


Environment for perl v5.8.8:
    HOME=/home/steev
    LANG=pl_PL.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/steev/bin:/usr/java/jre/bin:/usr/java/sdk/bin:/home/steev/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From perl5-porters@perl.org

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​: 0x0977adf8 ***

<snip>

'ó' is latin letter 'o acute'

Bug ocurs usually when 'ans' contains one or more 'ó' characters (low -or uppercase)
(althought phrase 'Ó ' works, 'Ó ' dumps the core)
Words with more, different unicode characters works fine.

<snip>

Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Mon Nov 12 14​:45​:10 EST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration​:
Platform​:
osname=linux, osvers=2.6.20-1.2952.fc6, archname=i386-linux-thread-multi
uname='linux hammer2.fedora.redhat.com 2.6.20-1.2952.fc6 #1 smp wed may 16 18​:18​:22 edt 2007 i686 athlon i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
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 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.1.2 20070925 (Red Hat 4.1.2-33)', 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

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

/J\

[p5pRT]

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

[p5pRT]

From @moritz

Jonathan Stowe wrote​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​: 0x0977adf8 ***
...
Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Mon Nov 12 14​:45​:10 EST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration​:
Platform​:
osname=linux, osvers=2.6.20-1.2952.fc6, archname=i386-linux-thread-multi
uname='linux hammer2.fedora.redhat.com 2.6.20-1.2952.fc6 #1 smp wed may 16 18​:18​:22 edt 2007 i686 athlon i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
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 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.1.2 20070925 (Red Hat 4.1.2-33)', 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

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

Just to provide additional data​: it fails with Debian Etch's perl 5.8.8
with the same error as in the original report, so it's not Red Hat's
blame. (no -D_FORTIFY_SOURCE here)

BTW it runs fine on a (self built) 5.10.0 (r32579).

Moritz

[p5pRT]

From @smpeters

On Dec 5, 2007 10​:31 AM, Jonathan Stowe <jns@​gellyfish.com> wrote​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​: 0x0977adf8 ***

<snip>

'ó' is latin letter 'o acute'

Bug ocurs usually when 'ans' contains one or more 'ó' characters (low -or uppercase)
(althought phrase 'Ó ' works, 'Ó ' dumps the core)
Words with more, different unicode characters works fine.

<snip>

Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Mon Nov 12 14​:45​:10 EST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration​:
Platform​:
osname=linux, osvers=2.6.20-1.2952.fc6, archname=i386-linux-thread-multi
uname='linux hammer2.fedora.redhat.com 2.6.20-1.2952.fc6 #1 smp wed may 16 18​:18​:22 edt 2007 i686 athlon i386 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Dversion=5.8.8 -Dmyhostname=localhost -Dperladmin=root@​localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dinc_version_list=5.8.7 5.8.6 5.8.5 -Dscriptdir=/usr/bin'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
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 -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='4.1.2 20070925 (Red Hat 4.1.2-33)', 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

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

It might have been that particular build. Fedora just updated Perl a
couple of days ago, and my version runs without failing.

Steve Peters
steve@​fisharerojo.org

[p5pRT]

From ben@morrow.me.uk

Quoth perl5-porters@​perl.org​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​: 0x0977adf8 ***

<snip>

'ó' is latin letter 'o acute'

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

It doesn't segfault here (FreeBSD) either, but valgrind finds a whole
lot of

==24404== Invalid read of size 1
==24404== at 0x812A23B​: S_regmatch (regexec.c​:3994)
==24404== by 0x8124435​: S_regtry (regexec.c​:2202)
==24404== by 0x8123E1B​: Perl_regexec_flags (regexec.c​:2020)
==24404== by 0x80C7816​: Perl_pp_match (pp_hot.c​:1340)
==24404== Address 0x3C392829 is 1 bytes after a block of size 108 alloc'd
==24404== at 0x3C038183​: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==24404== by 0x80B07D2​: Perl_safesysmalloc (util.c​:78)
==24404== by 0x80A1A4C​: Perl_pregcomp (regcomp.c​:1798)
==24404== by 0x80F6F92​: Perl_pp_regcomp (pp_ctl.c​:126)

so this is the regex utf8 buffer overrun, isn't it?

Ben

[p5pRT]

From jns@gellyfish.com

On Wed, 2007-12-05 at 18​:31 +0100, Moritz Lenz wrote​:

Jonathan Stowe wrote​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​: 0x0977adf8 ***
...
Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Mon Nov 12 14​:45​:10 EST 2007.

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

Just to provide additional data​: it fails with Debian Etch's perl 5.8.8
with the same error as in the original report, so it's not Red Hat's
blame. (no -D_FORTIFY_SOURCE here)

BTW it runs fine on a (self built) 5.10.0 (r32579).

Yeah I realized after I posted this that infact that the perl here has "
"Mandriva Linux patches" which may well fix the problem for all I know
what's in them.

/J\

[p5pRT]

From david@landgren.net

Ben Morrow wrote​:

Quoth perl5-porters@​perl.org​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

[...]

Is this something to do with the way the Red Hat have compiled either
perl (I'm looking at some of those options like -Wp,-D_FORTIFY_SOURCE=2)
or the way they have compiled glibc? The test program runs fine here
with a Mandriva packaged 5.8.8.

It doesn't segfault here (FreeBSD) either, but valgrind finds a whole
lot of

==24404== Invalid read of size 1
==24404== at 0x812A23B​: S_regmatch (regexec.c​:3994)
==24404== by 0x8124435​: S_regtry (regexec.c​:2202)
==24404== by 0x8123E1B​: Perl_regexec_flags (regexec.c​:2020)
==24404== by 0x80C7816​: Perl_pp_match (pp_hot.c​:1340)
==24404== Address 0x3C392829 is 1 bytes after a block of size 108 alloc'd
==24404== at 0x3C038183​: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck.so)
==24404== by 0x80B07D2​: Perl_safesysmalloc (util.c​:78)
==24404== by 0x80A1A4C​: Perl_pregcomp (regcomp.c​:1798)
==24404== by 0x80F6F92​: Perl_pp_regcomp (pp_ctl.c​:126)

so this is the regex utf8 buffer overrun, isn't it?

Wow! you managed to get valgrind running on FreeBSD? What's your secret?

David

[p5pRT]

From ben@morrow.me.uk

Quoth david@​landgren.net (David Landgren)​:

Wow! you managed to get valgrind running on FreeBSD? What's your secret?

Do you mean at all, or with perl? perl with -Dusemymalloc seems to
segfault immediately if run under valgrind, and the ports perl is build
with -Dusemymalloc by default, but otherwise it Just Worked...

Am I missing something?

Ben

[p5pRT]

From david@landgren.net

Ben Morrow wrote​:

Quoth david@​landgren.net (David Landgren)​:

Wow! you managed to get valgrind running on FreeBSD? What's your secret?

Do you mean at all, or with perl? perl with -Dusemymalloc seems to

yes, running valgrind on perl.

segfault immediately if run under valgrind, and the ports perl is build
with -Dusemymalloc by default, but otherwise it Just Worked...

Yes, that was my experience too.

Am I missing something?

No, I was. I'll try again some time without -Dusemymalloc.

Thanks,
David

[p5pRT]

From @eserte

David Landgren <david@​landgren.net> writes​:

Ben Morrow wrote​:

Quoth david@​landgren.net (David Landgren)​:

Wow! you managed to get valgrind running on FreeBSD? What's your secret?
Do you mean at all, or with perl? perl with -Dusemymalloc seems to

yes, running valgrind on perl.

segfault immediately if run under valgrind, and the ports perl is build
with -Dusemymalloc by default, but otherwise it Just Worked...

Yes, that was my experience too.

Am I missing something?

No, I was. I'll try again some time without -Dusemymalloc.

I think it's also necessary to have a debugging perl. A perl with
-Dusemymalloc and with DEBUGGING does not dump core immediately, but
does not show any results, probably because valgrind is looking at
calls to system's malloc. Without -Dusemymalloc and with DEBUGGING it
works fine. Unfortunately it's available only for i386-freebsd, not
for amd64-freebsd, so it means for me​: reboot :-(

Regards,
  Slaven

--
Slaven Rezic - slaven <at> rezic <dot> de

  tkruler - Perl/Tk program for measuring screen distances
  http​://ptktools.sourceforge.net/#tkruler

[p5pRT]

From @ntyni

On Wed Dec 05 17​:37​:58 2007, moritz@​casella.verplant.org wrote​:

Jonathan Stowe wrote​:

On Wed, 2007-12-05 at 01​:01 -0800, steev@​hot.pl (via RT) wrote​:

This little program causes a core dump :

######################################################

#!/usr/bin/perl -w -CSDA
use strict;
use utf8;
use encoding 'utf8';
use locale;

my $ans='Ostrów';
$_="whatever...";
if (/^$ans| $ans/) { print "I was wrong, sorry...\n" }

######################################################

*** glibc detected *** perl​: double free or corruption (!prev)​:
0x0977adf8 ***
...
Site configuration information for perl v5.8.8​:

Configured by Red Hat, Inc. at Mon Nov 12 14​:45​:10 EST 2007.

Just to provide additional data​: it fails with Debian Etch's perl
5.8.8
with the same error as in the original report, so it's not Red Hat's
blame. (no -D_FORTIFY_SOURCE here)

This is also Debian bug #454792, and fully reproducible on x86 (but not
on amd64, FWIW.)

Bisecting the maint-5.8 branch shows it's fixed by change 32364, which
integrates change 29204 from blead. So it looks like this is a duplicate
of ticket #40641.

In the Debian bug report, Don Armstrong is concerned about possible
security aspects​:

I've set the severity to serious and tagged with security as there is
(apparently) a possibility that this could result in execution of
arbitrary code. [I don't have any proof of concept for this or a CVE
though, so feel free to detag and lower severity.]

Informed opinions would be welcome, as the bug is present in the current
Debian stable distribution.

Cheers,
--
Niko Tyni
ntyni@​debian.org

[p5pRT]

p5p@spam.wizbit.be - Status changed from 'open' to 'resolved'