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.
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 ***