Segfault in re_search_internal() - [Was: Segfault in re_string_reconstruct()]

Jeremy Bowen jeremy.bowen at pertronic.co.nz
Wed Nov 5 21:33:37 UTC 2008


> On Mon, 3 Nov 2008 10:09:51 +1300
>
> > I know this isn't a real solution but I have other issues (in my
> > application) which are show-stoppers that I need to work on first.
> > Finding & fixing the root cause of this bug can come later.

OK so now I'm playing whack-a-mole with this :-)

It looks like I have triggered another segfault in regexec.c in the 
re_search_internal() function.
This one looks less like a compiler bug however.

I'm using the svn checkout of uClibc 0.9.30-rc3-svn compiling with my gcc
avr32-linux-gcc (GCC) 4.2.2-atmel.1.0.8 and patched with the additional 
patches listed on:
http://avr32linux.org/twiki/bin/view/Main/GccPatches
#'s 901, 902, 903, 904 & 905

The segfault is triggered in case 6 of the switch (match_kind) somewhere 
around line ~760 of libc/misc/regex/regexec.c from a call to mdev (busybox)
[ + my debug code]
====================
        forward_match_found_start_or_reached_end:
            if (BE (match_first == right_lim, 0))
            {
                ch = match_first >= length
                    ? 0 : (unsigned char) string[match_first];
+               assert(ch != 0);
+               dprintf(2, "File: %s - Line %d\n", __FILE__, __LINE__);
                if (!fastmap[t ? t[ch] : ch])
                    goto free_return;
=====================

In this instance, ch is 0. t is also NULL and the attempt to reference t[ch] 
results in a segfault.

I have no idea what this code is trying to do and it's particularly cryptic so 
difficult to determine what the intent is so I don't know which bit is 
faulty. Someone with more knowledge of the regex engine may be able to shed 
some light on what is going on here.

-- 
Cheers
JeremyB



More information about the uClibc mailing list