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

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

Hi!

Bob Doan =C3=ADrta:
> Can you send a stack trace or is it really nasty?
>=20
> On Mon, 2005-06-13 at 00:25 +0200, Zoltan Boszormenyi wrote:
>=20
>>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

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:

	gchar	left_holding[20];
	gchar	right_holding[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.

It was a tough one to find without valgrind. :-D

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.

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