Bug Hunting Session
Bug 66094 - Crash when scrolling to a file with auto-updated links in it
Summary: Crash when scrolling to a file with auto-updated links in it
Status: RESOLVED DUPLICATE of bug 66009
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-06-23 16:59 UTC by Thomas Hackert
Modified: 2013-11-13 20:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
console + bt with symbols on master sources (30.24 KB, text/plain)
2013-06-23 20:47 UTC, Julien Nabet
Details
Valgrind logs (35.66 KB, application/x-bzip)
2013-06-23 21:23 UTC, Julien Nabet
Details
valgrind bt (4.71 KB, text/plain)
2013-06-24 21:15 UTC, Julien Nabet
Details
console logs during opening (12.78 KB, text/plain)
2013-07-02 20:33 UTC, Julien Nabet
Details
zipped backtrace, as original is 28K in size (3.92 KB, application/zip)
2013-07-06 05:43 UTC, Thomas Hackert
Details
bzipped strace (505.24 KB, application/x-bzip2)
2013-07-06 05:44 UTC, Thomas Hackert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hackert 2013-06-23 16:59:23 UTC
Hello @ll,
I hope, I have chosen the right component. If not, feel free to change it ... :(

Because of bug #47603, I downloaded https://wiki.documentfoundation.org/images/1/1e/Regressions.odt and clicked on "Edit File" in the Toolbar Standard. Then I scrolled down with my mouse wheel (maybe this could depend on the scroll speed used?) to go to the table, mentioned in #47603. LO first slowed down scrolling and then crashed without any error message ... :(

If I do a "dmesg | tail" afterwards, I get
<quote>
[205693.323969] soffice.bin[25753]: segfault at 0 ip 00007fc893dc0b72 sp 00007fc8ceaeb580 error 4 in libucpdav1.so[7fc893d9b000+62000]
</quote>
, but that's all ... :(

Watched behaviour: LO slows down, before it crashes
Expected behaviour: LO should scroll to the side, where I want to go ... ;)

LO: Version: 4.1.0.1 Build ID: 1b3956717a60d6ac35b133d7b0a0f5eb55e9155 with Germanophone lang- as well helppack installed, and installed in parallel as instructed in the wiki (so own, new profile ... ;) )
OS: Debian Testing AMD64
Reproducible: On my system, yes ... :(

Sorry for the inconvenience
Thomas.
Comment 1 Julien Nabet 2013-06-23 20:47:21 UTC
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.
Comment 2 Julien Nabet 2013-06-23 21:23:25 UTC
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)
Comment 3 Julien Nabet 2013-06-23 21:24:27 UTC
Michael: I collected bt+valgrind logs, I thought you might be interested in the feedback.
Comment 4 Michael Meeks 2013-06-24 11:30:34 UTC
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.
Comment 5 Michael Meeks 2013-06-24 12:09:35 UTC
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 :-)
Comment 6 Julien Nabet 2013-06-24 12:21:15 UTC
Michael: perhaps I misunderstand but I've already attached Valgrind logs.
Comment 7 Michael Meeks 2013-06-24 12:26:53 UTC
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 !
Comment 8 Julien Nabet 2013-06-24 21:15:55 UTC
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 :-)
Comment 9 Caolán McNamara 2013-07-02 19:58:58 UTC
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 ?
Comment 10 Julien Nabet 2013-07-02 20:33:30 UTC
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.
Comment 11 Thomas Hackert 2013-07-05 16:47:29 UTC
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.
Comment 12 Julien Nabet 2013-07-05 18:24:44 UTC
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)
Comment 13 Thomas Hackert 2013-07-06 05:41:43 UTC
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.
Comment 14 Thomas Hackert 2013-07-06 05:43:35 UTC
Created attachment 82115 [details]
zipped backtrace, as original is 28K in size
Comment 15 Thomas Hackert 2013-07-06 05:44:09 UTC
Created attachment 82116 [details]
bzipped strace
Comment 16 Julien Nabet 2013-07-07 11:11:39 UTC
Sorry Thomas, i'm in vacation and away from any computer for 2 weeks. I can just answer quickly from an iPhone
Comment 17 Caolán McNamara 2013-07-09 15:51:32 UTC
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 ***