This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
[2 BUGs] posix/regcomp.c (2.3.2 and 2.3.3-2003-12-18)
- From: Rene Rebe <rene dot rebe at gmx dot net>
- To: libc-alpha at sources dot redhat dot com
- Cc: bug-glibc at gnu dot org, "Tobias C. Rittweiler" <tcr at freebits dot de>,rock-linux at rocklinux dot org
- Date: Sun, 21 Dec 2003 02:07:59 +0100 (CET)
- Subject: [2 BUGs] posix/regcomp.c (2.3.2 and 2.3.3-2003-12-18)
Hi,
I have to report two bugs in glibc's regex code as used by grep when
linked against the libc's regex code.
The first is a seg-fault while parsing, e.g. s.th. like:
grep -e 'typeof.*;\{0\}*'
Program received signal SIGSEGV, Segmentation fault.
0x0ff5cd90 in calc_epsdest (dfa=0x10024230, node=0x1002465c) at regcomp.c:1264
1264 if (node->left && node->left->first == -1)
(gdb) bt
#0 0x0ff5cd90 in calc_epsdest (dfa=0x10024230, node=0x1002465c)
at regcomp.c:1264
#1 0x0ff5cb0c in analyze_tree (dfa=0x10024230, node=0x1002465c)
at regcomp.c:1118
#2 0x0ff5cb3c in analyze_tree (dfa=0x10024230, node=0x10024684)
at regcomp.c:1129
#3 0x0ff5cb20 in analyze_tree (dfa=0x10024230, node=0x100246d4)
at regcomp.c:1122
#4 0x0ff5ca5c in analyze (dfa=0x10024230) at regcomp.c:1093
#5 0x0ff5c088 in re_compile_internal (preg=0x10024200,
pattern=0x100241e8 "typeof.*;\\{0\\}*\n", length=15, syntax=2822)
at regcomp.c:789
#6 0x0ff5b120 in __re_compile_pattern (pattern=0x0, length=268584944,
bufp=0x21520) at regcomp.c:244
#7 0x1000d120 in ?? ()
(gdb) p node->left
$26 = (struct bin_tree_t *) 0x0
This happens with both glibc-2.3.2 and glibc-2.3.3-2003-12-18 on x86
and PowerPC ... This one was already reported a while ago:
http://sources.redhat.com/ml/bug-glibc/2003-08/msg00178.html
The second is simillar but happening at a different place:
grep -E -q '^[^#]*\bflistdel'
Program received signal SIGSEGV, Segmentation fault.
0x0ff5d69c in calc_eclosure_iter (new_set=0x7ffff528, dfa=0x10024218, node=20,
root=0) at regcomp.c:1578
1578 if (constraint && dfa->nodes[dfa->edests[node].elems[0]].duplicated)
(gdb) bt
#0 0x0ff5d69c in calc_eclosure_iter (new_set=0x7ffff528, dfa=0x10024218,
node=20, root=0) at regcomp.c:1578
#1 0x0ff5d770 in calc_eclosure_iter (new_set=0x7ffff578, dfa=0x10024218,
node=17, root=0) at regcomp.c:1604
#2 0x0ff5d770 in calc_eclosure_iter (new_set=0x7ffff5c8, dfa=0x10024218,
node=15, root=0) at regcomp.c:1604
#3 0x0ff5d770 in calc_eclosure_iter (new_set=0x7ffff608, dfa=0x10024218,
node=0, root=1) at regcomp.c:1604
#4 0x0ff5d58c in calc_eclosure (dfa=0x10024218) at regcomp.c:1540
#5 0x0ff5ca70 in analyze (dfa=0x10024218) at regcomp.c:1096
#6 0x0ff5c088 in re_compile_internal (preg=0x100241e8,
pattern=0x7ffff926 "^[^#]*\\bflistdel", length=16, syntax=2145052)
at regcomp.c:789
#7 0x0ff5b120 in __re_compile_pattern (pattern=0x0, length=160, bufp=0x50)
at regcomp.c:244
#8 0x1000d3f0 in ?? ()
(gdb) p dfa->edests[node].elems
$27 = (int *) 0x0
This bug is new in glibc-2.3.3-2003-12-18 - and does not happen with
glibc-2.3.2.
I try to add some workarounds - but since I'm not familiar with
glibc's regex code it would be nice if some author could take a look
...
Sincerely yours,
René Rebe
- ROCK Linux stable release maintainer
--
René Rebe - Europe/Germany/Berlin
rene@rocklinux.org rene@rocklinux-consulting.de
http://www.rocklinux.org http://www.rocklinux-consulting.de
http://gsmp.tfh-berlin.de/gsmp http://gsmp.tfh-berlin.de/rene