Segfault in re_string_reconstruct()

Jeremy Bowen jeremy.bowen at pertronic.co.nz
Wed Oct 29 21:06:45 UTC 2008


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 ??

--
Cheers
JeremyB



More information about the uClibc mailing list