[2 BUGs] posix/regcomp.c (2.3.2 and 2.3.3-2003-12-18)

[Rene Rebe <rene dot rebe at gmx dot net>]

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