Created attachment 106348 [details] Sample crasher document, many more at URL listed http://cbs-ext2014.wmo.int/documents-english 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 (Attached) 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 4.2.6.3 (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 4.2.6.3 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 SwTxtFrm::_Format. These observations are on master commit f74a633, fetched 2014-08-23, configured: --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --enable-online-update built and running on debian-wheezy 64-bit.
I can confirm the bug on current LO on Fedora 22. (4.4.3.2) 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 frmform.cxx:1484 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 version: 4.4.2.2 build ID: 40m0(Build:2) locale: cs_CZ
I still see the loop in daily dbgutil bibisect repo version 2015-07-10. On Windows Vista, LibreOffice ... Version: 5.1.0.0.alpha1+ 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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=20538f233fe120b33a23d594458d4639b0c9670e 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I guest it's fixed, I can open the document.