Created attachment 71751 [details] Example document. Certain .ods files cause LibreOffice 3.6.3.2 and older to deadlock on FILEOPEN. These files were created in 3.5 and open without issue in 3.5. Attached is an example document.
CORRECTION: 3.6.3.2 and NEWER to deadlock.
Created attachment 71778 [details] File without the bug. Win7x64 Ultimate LibreOffice 3.6.4 and 4.0 beta1 No deadlock, near to a minute for open. The problem is with the content in cell Sheet1.B31, deleting the content of this cell clear the issue and open right in 3.6 and 4.0
Do not seem high and critical. Resetted to medium - normal.
Comment on attachment 71751 [details] Example document. correct mime type
I have tried opening the test file with 4.0 beta 2 on windows XP and it did open, but it took about 5 minutes. I cannot see any content in sheet1.B31, although the row is very tall.
I can reproduce a huge freeze/crash using Mac OSX 10.8.2 and latest master 4.1 version. No freeze using LO 3.5.7.2. I'll bibisect this tomorrow, and narrow it down further down. I add regression to the keywords and set bibisectrequest in the whiteboard. Following the flowchart (https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg) I mark this bug as 'highest' and 'blocker' + add it to the mab3.6. Thanks for reporting!
(In reply to comment #6) > Following the flowchart > (https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart. > jpg) I mark this bug as 'highest' and 'blocker' + add it to the mab3.6. Sorry 'major' 'high' is a better value for this.
[Reproducible] with "LibO 4.0.0.2 rc - GERMAN UI / German Locale [Build ID: 5991f37846fc3763493029c4958b57282c2597e)]" {tinderbox: @6, pull time 2013-01-24 07:20(?)} on German WIN7 Home Premium (64bit) with separate /40 User Profile for alphas etc. Hm, this seems to be a damaged document, or what might be the reason for hundreds of linefeeds within a cell making disappear the "real" contents? So I can't see any outstanding importance, but indeed, we should know why later versions need so much more time to open such a document. @mariosv Thx, great research!
Created attachment 73630 [details] Simple Sample This simple sample contains 2 Cells with several hundred linefeeds. Takes 1 second to open until LibO 3.5, 1 minute with LibO 4.0 Already [Reproducible] with * Server Installation of "LibreOffice 3.6.2.1 rc German UI/ German Locale [Build-ID: ba822cc] on German WIN7 Home Premium (64bit) * Server installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: a502549]" (tinderbox: Win-x86@6-fast, pull time 2012-05-31 Still worked fine with * Parallel unzipped 3.6.0.0.alpha+ 2012-04-26 own profile MinGW * Server installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 475d0c5-829fc92-39746e8-206648e-fefd87]" (2012-02-14) More Details with bibisect!
Forgot to mention: bibisect by Joren De Cuyper, not by me.
Created attachment 73634 [details] bibisect40 log This is the bibisect40 log; I'm now trying to bibisect also with bibisect36; Bibisected with Linux Mint 14 x64;
Due errors [1] I can't bibisect with version 3.6. [1] terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'
With such an obvious slow-down :-) almost better then bisection is to run: export OOO_EXIT_POST_STARTUP=1 export OOO_DISABLE_RECOVERY=1 valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin --splash-pipe=0 /path/to/slow.odt Then attaching the log of that should help us get to the piece of code causing the grief :-) I'm doing that now FWIW - thanks for the report !
Wow - Rainer that is a great test case :-) thanks for building it. I've up-loaded the callgrind profile here: http://users.freedesktop.org/~michael/callgrind-import-58480.txt.bz2 And it's quite interesting - it seems we excessively thrash the editeng for this case in some quite interesting ways; 225bn cycles - and the import did not (yet) complete - I killed it after an hour or so of grinding ;-)
So the problem somewhere in this range: git log --numstat 33f5acad371bcf838011b3629450e6dcd405a4e9..1aa91a2d8e7db5cebff5b47f3005f1acff64d25e reading through it ...
Interestingly, this appears to import ~instantly on master but -4-0 is still afflicted with the problem.
(In reply to comment #16) > Interestingly, this appears to import ~instantly on master but -4-0 is still > afflicted with the problem. Kohei fixed it in master but it will most likely not be backported. It required some larger refactoring in editeng.
bibisection points at a pre-branchoff commit, thus not a microrelease 3.6.0->3.6.x regression (earliest version thus at least 3.6beta)
I'm going to close this - we've agreed that the patch fixing this is too large and dangerous to back-port to 4.0 and even less likely to 3.6 - so it will be fixed in 4.1 - going into feature-freeze in the next couple of weeks. Sorry about that; thanks for reporting though. Master snapshots should be in reasonable shape, and run nicely for 4.1 so ... if you're desperate use them.