gen_wctype segfaults with gcc 4

[Peter S. Mazinger]

On Mon, 12 Dec 2005, Michael Troß wrote:

> Peter S. Mazinger wrote:
> >>>>>gen_wctype segfaults on my system when optimized with -O2. It does work 
> >>>>>without optimization, even -O1 does not cause the segfault.
> >>>>>
> >>>>>Problem is in newopt, at gen_wctype.c:865,
> >>>>>  memcpy(tbl->ti + i * blocksize, ti[uniqblock[i]], blocksize);
> >>>>
> >>>>The segfault is caused by the uninitialized variable uniqblock when
> >>>>newopt is called recursively. The attached patch fixes this.
> >>>>Filling uniqblock with 0's should be the right initialization. At least
> >>>>the generated file is equal.
> >>>>
> >>>>Can someone else reproduce this error?
> >>>
> >>>
> >>>Haven't reproduced it, but I know that compiling this file on mips w/ 
> >>>stack-protection fails, also it segfaulted earlier and the *limit had to 
> >>>be raised (search for ifdef __linux__\n *rlimit). Maybe your patch could 
> >>>allow removing the rlimit hack.
> >>
> >>Yes, the missing initialization of uniqblock seems to cause all this 
> >>trouble. Now gen_wctype works without the rlimit stack hack, rediffed 
> >>patch attached.
> >>When linked against gcc's stack protector mudflap gen_wctype runs 
> >>without complaints. I am using gcc 4.0.2 on an i686 machine.
> > 
> > 
> > gcc-4.0.2 does not have ssp (mudflap != ssp), only 4.1 will probably
> > have it, have you built on mips?
> 
> Sorry, no mips system around here :-(  You're right, mudflap is not a 
> stack protector, but it helpfully checks for invalid pointer operations, 
> which are likely to happen with uninitialized stack variables.
> 
> Michael

only mips needed that change, both x86 and ppc do not fail here (w/ 
gcc-3.4.4)

You mentioned some comparison.
Have you compared the files from uClibc-locale-<date>.tgz with what the 
resulting ones after your change?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2