Re: Fribidi not 64-bit friendly?

Hi Mark,

Ok, seems like you are right.  You can temporarily solve the
problem by putting some preprocessor stuff to find the correct
32bit integer.  In the new FriBidi code (available in CVS
accessible from http://freedesktop.org/Software/FriBidi) I've put
enough stuff to solve the problem.

behdad


On Sat, 17 Jul 2004, Mark Gilbert wrote:

> We have a bit of a problem here in AbiWord.  It is manifesting several
> ways, including footnote fields (see assert log below).  It is starting
> to look as though it may originate or at least be related to fribidi not
> being 64-bit friendly (I don't know, the bug is beyond my expertise,
> seeking your help).  Following is excerpts from a conversation on irc,
> after I asked plam if I could paste an assert to see if it was relevant:
>
> <mgF> DEBUG: !!!Populate:InsertObject:Field: BlockOffset 104
> <mgF> **** (92) Assert ****
> <mgF> **** (92) sizeof(UT_UCS4Char) == sizeof(FriBidiChar) at
> ../../../../../abi/src/af/util/xp/ut_string.cpp:1601 ****
> <mgF> **** (92) Continue ? (y/n) [y] :
> <mgF> DEBUG: fl_DocListener::populateStrux for 'SectionFootnote'
> <plam> yes, it's relevant.  however, i don't get it.
> <mgF> plam: there's about 60-80 like that, plus others with slightly
> different context but same assert
> <mgF> plam: what should I do from here to track down the problem, if you
> can't repro it?
> <plam> why don't you md5sum the file?
> <plam> the rtf
> <plam> 49ca69ed1073245c96a3aa7e9b5cc271  bug7081.rtf
> <mgF> it matches
> <plam>  // if this assert fails, we have a serious problem ...
> <plam>  UT_ASSERT_HARMLESS( sizeof(UT_UCS4Char) == sizeof(FriBidiChar)
> );
> * mgF gets that weird premonition in the back of his head of martin
> telling him yet again that it's one of Tomas' unsafe 0xffffffff values
> or something causing problems on 64bit archs
> <mgF> plam: eep
> <plam> are you running on a 64bit arch?
> <mgF> yes
> <plam> that would probably do it, i bet.
> <mgF> one of those two is probably a 4byte like my int (UCS4Char?),
> while the other is 8byte like my long and pointer
> <plam> uhhhh...
> <plam> long is 64 bit, huh.
> <plam> fribidi says that an in32 is long.
> <mgF> plam: so, any ideas on how to fix it?  I have about 8 large
> serious sets of regressions pending for tomas when he gets back, I'd
> like to not count on waiting for him to fix the 9th as well /-:
> <plam> is fribidi 64-bit friendly?  it seems to not be.
> <mgF> wouldnt surprise me, but I couldn't tell you for sure not being at
> all familiar with the code
> <mgF> .oO(I wonder if that guy...the guy...damn what's his name from
> fribidi, if he could provide some insight)
> [Referring to you]
> <mgF> plam: suggestion(s) on how to proceed?
> * plam is looking up google and fribidi and 64 bits.
> <plam> why don't i delegate that to you?
> <mgF> heh, sure thing
> * mgF is pretty good at googling
> <plam> yeah, i suspect the rest of the problem may have to do with
> fribidi not being 64-bit friendly.  you might want to mail the fribidi
> devs or something.
> <plam> #define FRIBIDI_INT32   long
> <plam> doesn't quite seem correct.
>
> Naturally it does not, long being 64 bits over here.
>
> Anyway, I was wondering if you could help me out.  I am running 0.10.4,
> willing to test patches, we think (for the moment) that fribidi + x86_64
> == disaster and would like to fix that.
>
> Regards
> -MG
>
> (feel free to drop in on #abiword again, we've talked in there before,
> which is how I remembered you)
>
>
>

--behdad
  behdad.org