Download it now!
Bug 133897 - Fileopen: 271 pages Docx with large single table hangs Writer during open
Summary: Fileopen: 271 pages Docx with large single table hangs Writer during open
Status: RESOLVED DUPLICATE of bug 128959
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: bibisected, bisected
Depends on:
Reported: 2020-06-11 12:44 UTC by michal
Modified: 2020-09-30 10:44 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Docx file to crash Writer (544.59 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-11 12:44 UTC, michal
The ODT (300.94 KB, application/vnd.oasis.opendocument.text)
2020-06-11 18:03 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description michal 2020-06-11 12:44:12 UTC
While opening the attached docx file, writer hangs and slowly consumes more and more memory resources up to the OOM condition.

Steps to Reproduce:
1. Launch Writer
2. Open attached docx file

Actual Results:
Writer hangs.

Expected Results:
Writer opens the file correctly.

Reproducible: Always

User Profile Reset: Yes

OpenGL enabled: Yes

Additional Info:
[Information automatically included from LibreOffice]
Locale: cs
Module: TextDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes

ID sestavení: 6.4.4-1
Vlákna CPU: 4; OS: Linux 5.6; Vykreslování UI: výchozí; VCL: gtk3; 
Národní prostředí: cs-CZ (cs_CZ.UTF-8); Jazyk UI: cs-CZ
Calc: threaded
Comment 1 michal 2020-06-11 12:44:57 UTC
Created attachment 161876 [details]
Docx file to crash Writer
Comment 2 ian 2020-06-11 13:39:21 UTC
Thanks for reporting this bug.

I can see other bugs like bug 120351, bug 92433 are similar to this. Not sure whether to mark this as a duplicate.

I can replicate it in Windows:

Version: (x64)
Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL

And with:

Version: (x64)
Build ID: 83c4f86f22dc37269ac6a038fe7de053c42aad6e
CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 3 michal 2020-06-11 13:45:05 UTC
Just tried to launch Writer from console to see if it spits any error messages. And it does before it hangs and latter dies.

$ lowriter crashfile.docx
E: lt_string_value: assertion `string != ((void *)0)' failed
E: lt_string_value: assertion `string != ((void *)0)' failed
E: lt_string_value: assertion `string != ((void *)0)' failed
E: lt_string_value: assertion `string != ((void *)0)' failed
Comment 4 Telesto 2020-06-11 17:59:54 UTC
Opens with
Version: (x64)
Build ID: a201ab6f47c2d5a7ba4c5f998b0aa231cae82010
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Not really fast.. but no crash/hang
Comment 5 Telesto 2020-06-11 18:03:33 UTC
Created attachment 161893 [details]
Comment 6 Timur 2020-06-18 14:28:18 UTC
I reproduce long hang and eventually OOM in windows with Lo 6.4. So I set New and All.
I don't reproduce with master Lo 7.1+, it's slow and not responding shortly, but after a while it's ok.
DOCS is MSO created (important to note).
It's 270 pages of single table, but I don't see images or merged cells. 

So we have more issues here: 
1. to confirm that hang is no more with 7.1+: michal please do with daily master from
2. to find out where it was done (important for easily reproducible bug like this one): I set bibisectRequest, 
3. LO 7.1+ is still slow to open and that could remain a bug, but I'm afraid we already have these reported: AFAIK LO builds table row by row and it's many rows, MSO is also somwwhat slow to open,
4. MSO opens 271 page and LO 299 pages: to be seen why with minimum test case, but that's not this bug.  
5. Telesto didn't write how ODT was created, seems save in 7.1+, but my LO 7.1+ crashes finally on fast scrolling: also another issue, maybe a duplicate.
Comment 7 Xisco Faulí 2020-06-25 10:51:18 UTC
no hang no crash reproduced in

Build ID: 42bf9bdf3d551eb59604f952204c49f7d7a1e913
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

for me it takes

real	0m41,440s
user	0m38,599s
sys	0m2,163s

to open the file and the a minute or so load all the pages and be 100% responsive.

Could you please try to reproduce it with a master build from ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 8 Timur 2020-06-25 11:31:08 UTC
Xisco, please rebisect (reverse bibisect).
Comment 9 Timur 2020-09-30 10:44:47 UTC
Bibisect 7.0:

commit bacb366e04523bba8dc4762dbea52cd5d3bce5e1
Date:   Wed Jan 29 11:29:14 2020 +0100
    source sha:8b13da71aedd094de0d351a4bd5ad43fdb4bddde
    previous source sha:16cb51aedf38d2f9e10d4398665417ef922eb9fb

author	László Németh <>	2020-01-28 14:32:54 +0100
committer	László Németh <>	2020-01-29 11:00:34 +0100
commit	8b13da71aedd094de0d351a4bd5ad43fdb4bddde (patch)
tree	a8674ca240b084a4220e8b5c38930fb47ecc046c
parent	16cb51aedf38d2f9e10d4398665417ef922eb9fb (diff)
tdf#128959 DOCX import: fix missing text lines in tables

I'll mark duplicate.

*** This bug has been marked as a duplicate of bug 128959 ***