Created attachment 106348 [details]
Sample crasher document, many more at URL listed
roughly two thirds of the documents there, when loaded, cause libreoffice to hang. For example, this one: CBS-Ext(2014)-d03-2(1)-WIS-Approved_en.docx
tested with abiword, and it hangs also. But Kingsoft WPS opens it OK, it gives an error message about font loading, but presents the document anyways.
libreoffice installed on ubuntu 14.04. claims to be 22.214.171.124 (choice not offerred in pull-downs.) reproduced all the time, on two different machines with multiple documents.
I can confirm this issue. When opening the attached file, the first page displays but writer doesn't response any more!
LinuxMint 17 Cinnamon (based on Ubuntu 14.04)
LO 126.96.36.199 Build id.: 420m0(Build:3)
Digging around in gdb, I see a pretty busy loop, possibly *the* busy
loop, in SwTxtFrm::_Format, source file
sw/source/core/text/frmform.cxx, from line 1427 to line 1526.
One point in one iteration of the loop is in SwTxtIter::GetLineNr,
source sw/source/core/text/itrtxt.hxx:87, where rLine.GetlineNr() is
1, which is less than nOrhpLines, which is 2, which makes the function
return false, which is the exit condition of the loop in
These observations are on master commit f74a633, fetched 2014-08-23, configured:
--enable-option-checking=fatal --enable-dbgutil --enable-crashdump
built and running on debian-wheezy 64-bit.
I can confirm the bug on current LO on Fedora 22. (188.8.131.52)
I will look into it.
@Peter - Thanks for providing the test document.
The bug also exists on the current master
I did a callgrind analysis.
The problem seems to be
SwTxtFrm::FormatLine which gets called quite often on line
I will try to find out what the code is supposed to do, and how to optimize this.
Is this linux only? Repro on Ubuntu 15.04 x86-64
build ID: 40m0(Build:2)
I still see the loop in daily dbgutil bibisect repo version
On Windows Vista, LibreOffice ...
Build ID: d3b6f3790953bdfeaeebcd3ba9ec370d94ca4ebf
TinderBox: Win-x86@39, Branch:master, Time: 2015-07-09_00:11:56
Locale: en-CA (en_CA)
renders the top windowful of the document then loops. I guess that
this is the same loop, so am setting O/S All.
It seems as if the loop starting in frmform.cc:1427 does not terminate.
(if I force to terminate it after, e.g., 100 iterations, the document loads correctly)
To fix the bug, I need to understand the logic of the aforementioned loop which used to identify line breaks. It is quite complicated, but I am working on it.
I have added a fix which is currently waiting for review at https://gerrit.libreoffice.org/18896
With the fix, the document loads correctly
The fix is still waiting for review. I will post an update when it has been merged.
Tobias Lippert committed a patch related to this issue.
It has been pushed to "master":
tdf#83910 Formatting of lines which consist of a single dummy line only
It will be available in 5.1.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
I guest it's fixed, I can open the document.