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
[205693.323969] soffice.bin: segfault at 0 ip 00007fc893dc0b72 sp 00007fc8ceaeb580 error 4 in libucpdav1.so[7fc893d9b000+62000]
, 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: 18.104.22.168 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
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]
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;
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:
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.
Created attachment 81372 [details]
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: 22.214.171.124.0 Build ID: 103a942746cfe346e87daab62acbd4268c38097
OS: Debian Testing AMD64
Sorry for the inconvenience
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.
> 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
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
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
Created attachment 82115 [details]
zipped backtrace, as original is 28K in size
Created attachment 82116 [details]
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 ***