Segfault in re_search_internal() - [Was: Segfault in re_string_reconstruct()]
Hans-Christian Egtvedt
hans-christian.egtvedt at atmel.com
Thu Nov 6 09:10:16 UTC 2008
On Thu, 6 Nov 2008 10:33:37 +1300
Jeremy Bowen <jeremy.bowen at pertronic.co.nz> wrote:
> > 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 am still unable to reproduce this with gcc, binutils and uClibc built
by Buildroot for AVR32. Buildroot from uclibc.org should also generate
a working 4.2.2 compiler using the external source toolchain.
> 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
>
Seems correct, which binutils are you using?
http://avr32linux.org/twiki/bin/view/Main/BinutilsPatches ?
Is it possible that you could give Buildroot for AVR32 v2.2.1 a run to
generate a toolchain and use that to recompile the stuff you have?
> 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]
mdev works fine for me, do you do anything fancy in /etc/mdev.conf?
> ====================
> 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.
>
Unexpected 0's are a typical example of a missing
901-avr32-fix-no-cond-exec-before-reload.patch.
> 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.
>
--
Best regards,
Hans-Christian Egtvedt
More information about the uClibc
mailing list