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