Segfault in re_string_reconstruct()

Rob Landley rob at landley.net
Thu Oct 30 18:01:08 UTC 2008


On Wednesday 29 October 2008 17:05:54 Bernhard Reutner-Fischer wrote:
> On Thu, Oct 30, 2008 at 10:06:45AM +1300, Jeremy Bowen wrote:
> >On Monday 20 October 2008 5:54:14 pm Rob Landley wrote:
> >> You need to figure out what actual line is segfaulting.  I'd stick
> >> dprintf(2,"here\n") calls into the busybox source to track down exactly
> >> where the segfault happens.  (You can of course use gdb or some such, if
> >> you're feeling posh. :)
> >>
> >> If you can figure out what line is causing the segfault, and what the
> >> values of the variables used on that line are, it'd help a lot.  Right
> >> now we don't know if it's a busybox problem or a uClibc problem.
> >
> >OK after a lot of effort re-validating my toolchain, I'm now certain
> >the problem occurs within uClibc and not busybox.
> >
> >Specifically ./libc/misc/regex/regex_internal.c on line 703/4 >> <<
> >==============================================
> >#endif /* RE_ENABLE_I18N */
> >	    {
> >	      int c = pstr->raw_mbs[pstr->raw_mbs_idx + offset - 1];
> >	      if (pstr->trans)
> >        	c = pstr->trans[c];
> >==============================================
> >
> >However I'm now very nervous about my C compiler....
> >
> >I don't believe uClibc is actually broken because changing the above code
> > to
> >
> >	      if (pstr->trans)
> >+	      {
> >+		dprintf(2, "Hello");
> >        	c = pstr->trans[c];
> >+	      }
> >
> >eliminates the segfault behaviour even though "Hello" is never printed.
> >
> >The fact that the expression evaluates to false and the code continues on
> > OK makes me believe there is a problem with compiler optimisation or
> > something else, which I'm at a loss to explain at the moment.
> >
> >The code looks perfectly legal and simply bracketing the statement in the
> > 'if' doesn't help (but adding dprintf does).
> >
> >It has to be a compiler bug right ??
>
> Sounds a bit like it is.
> sprinkle some __asm__("# 1"); round the spot to see what the compiler
> generates there. Build this file with -O0 (either via
> __attribute__((optimize(0))) or by setting e.g. CFLAGS-regex_internal.os)
> if that works then reduce the spot that is miscompiled as described
> somewhere in http://gcc.gnu.org/bugs.html and report it in bugzilla.

If you understand avr32 assembly, look at the assembly output via "objdump -d" 
or in gdb.

(Sometimes adding dprintf() will fix something when the stack is getting 
stomped somewhere, but that doesn't look like it's the case here...)

Rob



More information about the uClibc mailing list