Re: [Rlib-devel] Re: Crasher bug in RLIB

[Zoltan B. <zb...@du...>]

Zoltan Boszormenyi =EDrta:
> William K. Volkman =EDrta:
>=20
>> On Thu, 2005-06-23 at 23:25, Zoltan Boszormenyi wrote:
>>
>>> Bad news. Running the same report in a for() cycle, it still
>>> crashes on the second turn. There are more stack-destroying bugs
>>> in heaven and earth, Horatio... :-)
>>
>>
>>
>> I also ran into this last night, haven't had a chance to
>=20
>=20
> Phew. So it's not just my bad luck. :-)
>=20
>> investigate further.  Are you using your two patches
>> for the GCC 4 issues?  My RLIB version is skewed a bit
>=20
>=20
> Yes, I am using those two patches, and I also cleaned up
> "long long" usage replacing it with gint64 abstract type
> to further reduce the amount of warnings. It would be best
> to get rid of all the explicit casts so the compiler's
> type checking will work.
>=20
>> from latest CVS, 3 of the last 5 patches I made
>> are not in CVS yet.  I might get some time this weekend
>> to help you hunt the other bugs.
>=20
>=20
> I intend to install the final gcc-4.0.0 (the gcc4 update for FC3
> is based on a snapshot) and the bounds checking patch on top of it.
> This seems to be a highly useful feature, you can find it here:
>=20
> http://sourceforge.net/projects/boundschecking/
>=20
> The compiler will generate code that guards against itself
> if you use option -fbounds-checking.

After compiling GCC4 4 times, here's the RPM SPEC file if someone
is interested. It's based on the FC3 GCC4 errata release, you will need
gcc4-4.0.0-0.41.fc3.src.rpm, the patch from the above address for
GCC 4.0, bounds-checking-gcc-4.0.0-1.00.patch.bz2, and this specfile.

Using -fbounds-checking didn't reveal any real bugs in RLIB,
but here are fixes for two suspicious functions. They got suspicious
because of the bounds checking messages. One of the bugs was not
obvious, patch is also attached.

- gint64 tentothe(gint n) does not check whether the index into the
   local array is a correct index. Fix it by using pow(N, M).
   Two advantages: no more bad stack access and it gives correct answer
   for n=3D0...18, comparing with the previous n=3D0...11.

- gchar hextochar(gchar c) assigned an integer (32-bit) value
   internally to its character parameter, possibly overwriting
   something on the stack.

However, it didn't fix the bug where running the same report
the second time makes it crash.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi