Bug 66094

Created attachment 81284 [details]
console + bt with symbols on master sources

On pc Debian x86-64 with master sources updated today (+ a brand new LO profile), I reproduced a crash just by opening the file!
I attached console and bt.

Created attachment 81287 [details]
Valgrind logs

Valgrind logs:
We can see this line
  11520 ==13105== Invalid read of size 8
  11521 ==13105==    at 0x98A5EAB: PolyPolygon::Count() const (poly2.cxx:382)
  11522 ==13105==    by 0xA70508F: GDIMetaFile::GetSizeBytes() const (gdimtf.cxx:2710)
(but after the bt, we could guess there was memory problem here:-))

But we've got some interesting parts:
  11461 ==13105== Use of uninitialised value of size 8
  11462 ==13105==    at 0xA746081: MetaAction::ReadMetaAction(SvStream&, ImplMetaReadData*) (metaact.cxx:161)
  11463 ==13105==    by 0xA7052E6: operator>>(SvStream&, GDIMetaFile&) (gdimtf.cxx:2770)
  11464 ==13105==    by 0xA72E307: operator>>(SvStream&, ImpGraphic&) (impgraph.cxx:1687)
  11465 ==13105==    by 0xA719DD5: operator>>(SvStream&, Graphic&) (graph.cxx:577)

or this one:
  11334 ==13105== Warning: set address range perms: large range [0x100000040, 0x20001896b) (undefined)
  11335 ==13105== Conditional jump or move depends on uninitialised value(s)
  11336 ==13105==    at 0xA74606A: MetaAction::ReadMetaAction(SvStream&, ImplMetaReadData*) (metaact.cxx:161)
  11337 ==13105==    by 0xA7052E6: operator>>(SvStream&, GDIMetaFile&) (gdimtf.cxx:2770)
  11338 ==13105==    by 0xA72E307: operator>>(SvStream&, ImpGraphic&) (impgraph.cxx:1687)
  11339 ==13105==    by 0xA719DD5: operator>>(SvStream&, Graphic&) (graph.cxx:577)

Michael: I collected bt+valgrind logs, I thought you might be interested in the feedback.

I had a look :-) I imagine that these operators:

void MetaPolyPolygonAction::Read( SvStream& rIStm, ImplMetaReadData* )
{
    COMPAT( rIStm );
    rIStm >> maPolyPoly;                // Version 1

    if ( aCompat.GetVersion() >= 2 )    // Version 2
    {
        sal_uInt16 i, nIndex, nNumberOfComplexPolygons;
        rIStm >> nNumberOfComplexPolygons;
        for ( i = 0; i < nNumberOfComplexPolygons; i++ )
        {
            rIStm >> nIndex;
            Polygon aPoly;
            aPoly.Read( rIStm );
            maPolyPoly.Replace( aPoly, nIndex );
        }
    }

Somehow are not working so well for some corner case.

I can't reproduce the problem, you prolly need valgrind.

I'm rather suspicious of this code though:

void PolyPolygon::Insert( const Polygon& rPoly, sal_uInt16 nPos )
{
    if ( nPos > mpImplPolyPolygon->mnCount )
        nPos = mpImplPolyPolygon->mnCount;

...

Which looks pretty ugly (to me) - why not use a std::vector - but I guess it's deadly old and must work.

Beyond that - I guess getting valgrind to kick us into gdb at that point, and examining what's going on with the outer loop:

sal_uLong GDIMetaFile::GetSizeBytes() const
{
    sal_uLong nSizeBytes = 0;

    for( size_t i = 0, nObjCount = GetActionSize(); i < nObjCount; ++i )
    {
        MetaAction* pAction = GetAction( i );

what pAction is, what GetActionSize() is etc. might help ...

But sorry no fix :-)

Michael: perhaps I misunderstand but I've already attached Valgrind logs.

sure the logs are useful but don't let us see what is going on for that failure. So - I would a) disable Java, and b) run under valgrind with:

http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

So we can inspect the state of the program at the point that we hit this problem that is highlighted in the logs :-)

Hopefully a) will stop that huge bus-load of false-positives.

HTH !

Created attachment 81372 [details]
valgrind bt

Michael: I disabled Jre in Advanced Options then I tried to follow the quickstart of the link. I didn't know where to put a breakpoint so I attached what I got.
I don't see anything new (except that there are no more Java parts) here.
I certainly missed something so if you have some idea :-)

The actual original crash with "libucpdav1.so" in it is presumably a dup of bug #66009 / bug #66324.

The remaining warnings are still interesting though. But do they still exist post the 36e42c0bc094231cb80157a871862c76d6a2d03a fix ? Or did that fix them ?

Created attachment 81911 [details]
console logs during opening

On pc Debian x86-64 with master sources updated today, no more crash indeed!

I tried to reproduce the problem (Edit file + scroll down) but I got no crash too.

I attached console logs for information.

Hello everybody :)
thank you in your interest so far :)

Has anybody forgotten to remove the status "NEEDINFO"? Or need someone an answer from me? The only one I see, was Caolán's comment 9, where Julien answered in comment 10, but which I cannot confirm ... :( I still get the crash, when I scroll faster or slower (it doesn't matter at all ... :( ) through the document ... :(

LO: Version: 4.1.0.2.0 Build ID: 103a942746cfe346e87daab62acbd4268c38097
OS: Debian Testing AMD64

Sorry for the inconvenience
Thomas.

thackert: I had let NEEDINFO because I had got another crash than yours. So I prefered you answered, what you've just done.
Apparently you still reproduce the problem after the commit quoted by Caolan.
I put it back to UNCONFIRMED.

You can use a brand new LO profile to confirm to be sure it's not a buggy remnant then if you can still reproduce the crash, try to retrieve a backtrace by using this link (https://wiki.documentfoundation.org/QA/BugReport#How_to_get_a_backtrace_on_Linux)

Good morning Julien, *,
(In reply to comment #12)
> thackert: I had let NEEDINFO because I had got another crash than yours. So
> I prefered you answered, what you've just done.

O.K.

> Apparently you still reproduce the problem after the commit quoted by Caolan.
> I put it back to UNCONFIRMED.

Thanks :)

> You can use a brand new LO profile to confirm to be sure it's not a buggy

I am using a parallel installed LO, following the instructions from https://wiki.documentfoundation.org/Installing_in_parallel. Isn't it enough to get a brand new profile? If you think, I should use a brand new profile, I will rename it again to reproduce this bug :)

> remnant then if you can still reproduce the crash, try to retrieve a
> backtrace by using this link
> (https://wiki.documentfoundation.org/QA/
> BugReport#How_to_get_a_backtrace_on_Linux)

I will attach it to this bug - as well as a strace log, which I produced with "soffice -strace" - to this bug afterwards ... ;)
Thank you for your answer
Thomas.

Created attachment 82115 [details]
zipped backtrace, as original is 28K in size

Created attachment 82116 [details]
bzipped strace

Sorry Thomas, i'm in vacation and away from any computer for 2 weeks. I can just answer quickly from an iPhone

I believe its substantially a duplicate of 66009 and fixed by b7cf9c7b933fdc2dcd61e59c0022a066a8717b27 (If anyone is encountering this on an incremental self-build, then cd openssl && make clean && make && cd ../neon && make clean && make && cd ../ucb && make clean && make)

The subpart of the valgrind warning I believe is addressed by 36e42c0bc094231cb80157a871862c76d6a2d03a. Its not warning for me anymore in latest 4-1 anyway.

*** This bug has been marked as a duplicate of bug 66009 ***