Download it now!
Bug 83910 - Loading DOCX causes hanging (loop in
Summary: Loading DOCX causes hanging (loop in
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: high critical
Assignee: Tobias Lippert
Whiteboard: target:5.1.0
Depends on:
Reported: 2014-09-16 00:15 UTC by Peter Silva
Modified: 2016-10-10 12:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Sample crasher document, many more at URL listed (179.13 KB, application/msword)
2014-09-16 00:15 UTC, Peter Silva

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Silva 2014-09-16 00:15:46 UTC
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.
Comment 1 Peter Silva 2014-09-16 00:19:27 UTC
libreoffice installed on ubuntu 14.04. claims to be (choice not offerred in pull-downs.)  reproduced all the time, on two different machines with multiple documents.
Comment 2 penttila 2014-09-16 14:22:22 UTC
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 Build id.: 420m0(Build:3)
Comment 3 Terrence Enger 2014-09-16 18:56:20 UTC
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
    --without-system-postgresql --without-myspell-dicts
    --with-extra-buildid --without-doxygen
built and running on debian-wheezy 64-bit.
Comment 4 Tobias Lippert 2015-06-17 19:08:15 UTC
I can confirm the bug on current LO on Fedora 22. (
I will look into it.
@Peter - Thanks for providing the test document.
Comment 5 Tobias Lippert 2015-06-17 19:10:46 UTC
The bug also exists on the current master
Comment 6 Tobias Lippert 2015-06-17 20:20:57 UTC
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.
Comment 7 Marek Dolezel 2015-07-12 20:13:45 UTC
Is this linux only? Repro on Ubuntu 15.04 x86-64 

build ID: 40m0(Build:2)
locale: cs_CZ
Comment 8 Terrence Enger 2015-07-12 21:51:55 UTC
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.
Comment 9 Tobias Lippert 2015-08-06 20:06:02 UTC
It seems as if the loop starting in 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.
Comment 10 Tobias Lippert 2015-09-27 19:35:27 UTC
I have added a fix which is currently waiting for review at
With the fix, the document loads correctly
Comment 11 Tobias Lippert 2015-11-02 20:12:13 UTC
The fix is still waiting for review. I will post an update when it has been merged.
Comment 12 Commit Notification 2015-11-04 14:31:05 UTC
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 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.
Comment 13 Timur 2015-11-12 17:08:06 UTC
I guest it's fixed, I can open the document.