Summary: | Crash when scrolling to a file with auto-updated links in it | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Thomas Hackert <thackert> |
Component: | Libreoffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | critical | ||
Priority: | high | CC: | michael.meeks, serval2412 |
Version: | 4.1.0.1 rc | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=66288 https://bugs.freedesktop.org/show_bug.cgi?id=66227 |
||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 60270 | ||
Attachments: |
console + bt with symbols on master sources
Valgrind logs valgrind bt console logs during opening zipped backtrace, as original is 28K in size bzipped strace |
Description
Thomas Hackert
2013-06-23 16:59:23 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.
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 *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.