Re: [Rlib-devel] Postgre -> Postgres rename RPM SPEC fix, 64-bit breakage(?) in 1.3.6

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

Hi,

Zoltan Boszormenyi =EDrta:

> Bob Doan =EDrta:
>
>> On Sat, 2005-12-17 at 16:46 +0100, Zoltan Boszormenyi wrote:
>> =20
>>
>>> Hi,
>>>
>>> long time no see, erm, write? :-)
>>>  =20
>>
>>
>> Hey!
>>
>> =20
>>
>>> I tried the latest CVS version of RLIB and I noticed two things.
>>>
>>> First, it didn't build by running rpmbuild because the rlib.spec.in=20
>>> wasn't
>>> updated when the postgre -> posgres renaming was done.
>>>  =20
>>
>>
>> Applied thanks!
>> =20
>>
>
> You're welcome. :-)
>
>>> Second, it crashes on reports that worked earlier. I tried to track=20
>>> it down,
>>> what I found out is that 1.3.5 works but 1.3.6 doesn't. I don't have=20
>>> a 32 bit
>>> machine at hand, so I don't know whether it's just a 64-bit=20
>>> uncleanliness or
>>> something else. Still hunting...
>>>  =20
>>
>>
>> Yea.. I changed things around quite a bit in order to support the "mem=
o"
>> fields.  Valgrind??  It's clean for me on 32 bit
>>
>> - Bob
>

Please, disregard my previous analysis and patch. Here's a better one.

It's still stands that g_iconv() doesn't allocate the output buffer but
g_convert() and g_convert_with_iconv() do. As a converter is already
initialized with g_iconv_open() it's better to use g_convert_with_iconv()=
.
In libsrc/charencoder.c::rlib_charencoder_convert() there are three
possible paths, two allocates the result string with g_strdup() but
the third that uses g_iconv doesn't. Using g_convert_with_iconv()
in the third path makes this function behave consistently and closes
one crasher bug. Deleting the memset() in this function avoids another
crash, as the pointer passed here is mostly NULL.

There is another crasher bug in libsrc/layout.c, the loop starting
at line 606 extends the string with spaces and the loop condition goes
to the very end of the allocated string. The variable assignment
after the loop "*ptr =3D '\0';" writes one byte after the allocated space=
.
Changing the loop condition from (lim-- > 0) to (--lim > 0) closes this b=
ug.

OK, RLIB now doesn't crash when it's compiled using GCC 4.0
but the fields in the report PDF is empty. When I compile it with gcc-3.4=
.4
it still crashes but even valgrind doesn't show anything. I just get a
"NUTS we crashed" message. :-(
Going back to 1.3.5 makes my crashes go away.

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