Description: 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 Verze: 6.4.4.2 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
Created attachment 161876 [details] Docx file to crash Writer
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: 6.4.4.2 (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: 7.1.0.0.alpha0+ (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
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
Opens with Version: 7.1.0.0.alpha0+ (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
Created attachment 161893 [details] The ODT
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 https://dev-builds.libreoffice.org/daily/master/current.html 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.
no hang no crash reproduced in Version: 7.1.0.0.alpha0+ 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 http://dev-builds.libreoffice.org/daily/master/ ? 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
Xisco, please rebisect (reverse bibisect).
Bibisect 7.0: commit bacb366e04523bba8dc4762dbea52cd5d3bce5e1 Date: Wed Jan 29 11:29:14 2020 +0100 source 8b13da71aedd094de0d351a4bd5ad43fdb4bddde previous source 16cb51aedf38d2f9e10d4398665417ef922eb9fb author László Németh <nemeth@numbertext.org> 2020-01-28 14:32:54 +0100 committer László Németh <nemeth@numbertext.org> 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 ***