Download it now!
Bug 58480 - Temporarily unresponding when FILEOPEN .ods with cell with hundreds of linefeeds
Summary: Temporarily unresponding when FILEOPEN .ods with cell with hundreds of linefeeds
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta1
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: bibisected40
Keywords: regression
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-12-18 20:59 UTC by Brian
Modified: 2013-05-02 13:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document. (27.71 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-12-18 20:59 UTC, Brian
Details
File without the bug. (25.57 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-12-19 00:33 UTC, m.a.riosv
Details
Simple Sample (7.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-01-25 06:47 UTC, Rainer Bielefeld Retired
Details
bibisect40 log (3.00 KB, text/plain)
2013-01-25 09:09 UTC, Jorendc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian 2012-12-18 20:59:10 UTC
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.
Comment 1 Brian 2012-12-18 21:00:54 UTC
CORRECTION: 3.6.3.2 and NEWER to deadlock.
Comment 2 m.a.riosv 2012-12-19 00:33:33 UTC
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
Comment 3 m.a.riosv 2012-12-19 00:40:14 UTC
Do not seem high and critical.
Resetted to medium - normal.
Comment 4 john.pratt 2012-12-21 16:58:28 UTC
Comment on attachment 71751 [details]
Example document.

correct mime type
Comment 5 john.pratt 2012-12-21 17:09:51 UTC
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.
Comment 6 Jorendc 2013-01-25 00:35:26 UTC
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!
Comment 7 Jorendc 2013-01-25 00:41:25 UTC
(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.
Comment 8 Rainer Bielefeld Retired 2013-01-25 06:29:46 UTC
[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!
Comment 9 Rainer Bielefeld Retired 2013-01-25 06:47:03 UTC
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!
Comment 10 Rainer Bielefeld Retired 2013-01-25 07:05:41 UTC
Forgot to mention: bibisect by Joren De Cuyper, not by me.
Comment 11 Jorendc 2013-01-25 09:09:50 UTC
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;
Comment 12 Jorendc 2013-01-25 09:16:04 UTC
Due errors [1] I can't bibisect with version 3.6.

[1] terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'
Comment 13 Michael Meeks 2013-02-25 11:43:16 UTC
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 !
Comment 14 Michael Meeks 2013-02-25 14:14:12 UTC
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 ;-)
Comment 15 Michael Meeks 2013-02-25 14:34:35 UTC
So the problem somewhere in this range:

git log --numstat 33f5acad371bcf838011b3629450e6dcd405a4e9..1aa91a2d8e7db5cebff5b47f3005f1acff64d25e

reading through it ...
Comment 16 Michael Meeks 2013-02-25 14:50:34 UTC
Interestingly, this appears to import ~instantly on master but -4-0 is still afflicted with the problem.
Comment 17 Markus Mohrhard 2013-03-09 15:56:30 UTC
(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.
Comment 18 Björn Michaelsen 2013-04-15 14:55:43 UTC
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)
Comment 19 Michael Meeks 2013-05-02 13:20:01 UTC
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.