On Thu, 6 Nov 2008 10:33:37 +1300 Jeremy Bowen <[EMAIL PROTECTED]> 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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
