[Libreoffice] cppunit test fails in lotuswordpro / breaks the build on Mac/PPC

Christian Lohmaier lohmaier+libreoffice at googlemail.com
Tue May 10 14:25:09 PDT 2011


Hi Rafael, *,

On Sun, May 8, 2011 at 1:50 PM, Rafael Dominguez <venccsralph at gmail.com> wrote:
> On Sun, May 8, 2011 at 6:10 AM, Christian Lohmaier
> <lohmaier+libreoffice at googlemail.com> wrote:
>> On Tue, Apr 26, 2011 at 11:15 PM, Christian Lohmaier
>> <lohmaier+libreoffice at googlemail.com> wrote:
>> >
>> > does anyone have an idea on what goes wrong here?
>> > [...]
>> > Assertion
>> > Test name: (anonymous namespace)::LotusWordProTest::test
>> > assertion failed
>> > - Expression: bRes == bExpected
>> > -
>> > file:///Users/buildslave/compile/libreoffice/clone/filters/lotuswordpro/qa/cp
>> > punit/data/pass/A14.lwp
>> > [...]
>
> export GDBCPPUNITTRACE="gdb --args" and then get a backtrace of the issue

That won't work - as some of the arguments it uses are not supported
by the version of gdb that is installed - and even then: there is no
crash, so I would need to manually set breakpoints, but I can only do
that when running it manuall,y, right?

But all that aside, I did some "printf" debugging to get a start /
check whether it is an endianess issue... And yes, it is.

It uses SvStream, and also has the stream set to little endian, but
then doesn't make use of the SvStream's read operations (that would
take care of bigendian → littleendian conversion, but manually reads
the data. First place where this hits when trying to load the A14.lwp
is in
lwpfilter.cxx

sal_Bool GetLwpSvStream(SvStream *pStream, LwpSvStream * & pLwpSvStream)
{
    SvStream * pDecompressed = NULL;

    sal_uInt32 nTag;
    pStream->Seek(0x10);
    // wrong - you'll read it to big-endian machine, so
    pStream->Read(&nTag, sizeof(nTag));
    if (nTag != 0x3750574c) // "LWP7"
    //...this doesn't match (well, it does match, but it should not),
because nTag is 0x4c575037 on PPC at this point.

If the code used
   *pStream >> nTag;
instead, the comparison would result in the correct result.

But unfortunately this is not the only case where the endianness kicks
in. So any volunteers who could fix that quickly? :-)

ciao
Christian


More information about the LibreOffice mailing list