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

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

Zoltan Boszormenyi =C3=ADrta:
> Hi!
>=20
> Bob Doan =C3=ADrta:
>=20
>> Can you send a stack trace or is it really nasty?
>>
>> On Mon, 2005-06-13 at 00:25 +0200, Zoltan Boszormenyi wrote:
>>
>>> Hi,
>>>
>>> I created a two-query report with <Part> tag.
>>> There is a bug somewhere in RLIB that overwrites the stack
>>> and I get a "** NUTS.. WE CRASHED" message.
>>> If I filter the report's queries to return no rows,
>>> it doesn't crash. But if I filter the queries to return
>>> something and execute the report twice with the same
>>> result sets, I get a crash. Executing the query the first
>>> time I get the correct PDF. I try to track it down.
>>> Finally, the developers put x86-64 support into valgrind,
>>> maybe it will work for me, too.
>>>
>>> Best regards,
>>> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi
>=20
>=20
> Finally here's the fix for the crash I was experienced. It was not a
> 64-bitness issue, it crashed because the number conversion
> str(field,N,M) interpreted N and M backwards, e.g. str(field,18,2)
> was actually converted as "%81.2f" and the space used for
> converting both the integer and decimal parts of the number
> were statically allocated as:
>=20
>     gchar    left_holding[20];
>     gchar    right_holding[20];
>=20
> If one used two digit size for the integer part immediately
> exceeded the allocated space and caused stack corruption.
> I fixed rlib_number_sprintf() and rlib_pcode_operator_str()
> to allocate their strings dinamically and rlib_number_sprintf()
> to interpret the numbers correctly.
>=20
> It was a tough one to find without valgrind. :-D
>=20
> The patch also removes a bad cast, the macro changed isn't used
> in RLIB yet, but it would cause a memory corruption, too, on 64-bit
> systems. (long long) is 128 bits here and number_value member of
> struct rlib_value is gint64. The compiler can at least warn us
> this way.

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... :-)

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi