regexp: unicode char causes a 'double free corruption' #9139

p5pRT · 2007-12-05T09:01:38Z

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

Searchable as RT48156$

p5pRT · 2007-12-05T09:01:39Z

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 · 2007-12-05T16:32:14Z

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 · 2007-12-05T16:32:15Z

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

p5pRT · 2007-12-06T01:37:58Z

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 · 2007-12-06T02:02:14Z

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 · 2007-12-06T03:41:36Z

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 · 2007-12-06T15:06:09Z

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 · 2007-12-06T17:26:43Z

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 · 2007-12-07T07:51:57Z

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 · 2007-12-07T18:45:23Z

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 · 2007-12-07T19:39:31Z

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 · 2008-04-07T18:48:42Z

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 · 2008-05-09T20:28:53Z

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

p5pRT closed this as completed May 9, 2008

p5pRT added Severity Medium distro-Linux type-regex labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

regexp: unicode char causes a 'double free corruption' #9139

regexp: unicode char causes a 'double free corruption' #9139

p5pRT commented Dec 5, 2007

p5pRT commented Dec 5, 2007

p5pRT commented Dec 5, 2007

p5pRT commented Dec 5, 2007

p5pRT commented Dec 6, 2007

p5pRT commented Dec 6, 2007

p5pRT commented Dec 6, 2007

p5pRT commented Dec 6, 2007

p5pRT commented Dec 6, 2007

p5pRT commented Dec 7, 2007

p5pRT commented Dec 7, 2007

p5pRT commented Dec 7, 2007

p5pRT commented Apr 7, 2008

p5pRT commented May 9, 2008

regexp: unicode char causes a 'double free corruption' #9139

regexp: unicode char causes a 'double free corruption' #9139

Comments

p5pRT commented Dec 5, 2007

p5pRT commented Dec 5, 2007

From steev@hot.pl

Created by steev@hot.pl

p5pRT commented Dec 5, 2007

From perl5-porters@perl.org

p5pRT commented Dec 5, 2007

p5pRT commented Dec 6, 2007

From @moritz

p5pRT commented Dec 6, 2007

From @smpeters

p5pRT commented Dec 6, 2007

From ben@morrow.me.uk

p5pRT commented Dec 6, 2007

From jns@gellyfish.com

p5pRT commented Dec 6, 2007

From david@landgren.net

p5pRT commented Dec 7, 2007

From ben@morrow.me.uk

p5pRT commented Dec 7, 2007

From david@landgren.net

p5pRT commented Dec 7, 2007

From @eserte

p5pRT commented Apr 7, 2008

From @ntyni

p5pRT commented May 9, 2008