Bug 123196 - Writer hangs if you Try to Open a Specific DOCX with check box form fields
Summary: Writer hangs if you Try to Open a Specific DOCX with check box form fields
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: high major
Assignee: Not Assigned
Keywords: filter:docx, implementationError, perf
: 123233 (view as bug list)
Depends on:
Blocks: DOCX-Opening DOCX-ActiveX-Legacy
  Show dependency treegraph
Reported: 2019-02-05 19:48 UTC by Harald Koester
Modified: 2024-01-19 08:23 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Document that causes the crash (62.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-02-05 19:48 UTC, Harald Koester
WinDBG from procdump (7.89 KB, text/plain)
2019-02-11 13:22 UTC, Timur
Document compared MSO OO LO3.4.jpg (141.46 KB, image/jpeg)
2019-02-11 13:42 UTC, Timur
Minimized sample (25.98 KB, application/vnd.openxmlformats-officedocument.wordprocessingml)
2019-02-11 14:37 UTC, Timur
perf flamegraph (44.43 KB, application/x-bzip)
2019-11-12 19:48 UTC, Julien Nabet
strace log (396.99 KB, application/x-bzip)
2019-11-20 22:08 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Koester 2019-02-05 19:48:40 UTC
Created attachment 148932 [details]
Document that causes the crash

In order to reproduce the bug:
[1] Open the attached document in docx format. The document is displayed but the mouse pointer indicates, that the system is working. Expected: Document should be ready for editing.
[2] Click into document. The whole window is greyed. The mouse pointer still indicates, that the system is working. It's only possible to close LibreOffice.

A data loss is possible if you do this:
[1] Open an existing document and change this document a bit.
[2] Open the attached document.
[3] Now you can only close LibreOffice via the cross of the title bar. Then Windows informs you, that you can either close LibreOffice or you can still wait.
[4] Close LibreOffice.
[5] Start LibreOffice again. The recovery dialogue is opened. Both documents are listed in the recovery dialogue.
[6] Start recovery. Both documents are recovered. Then 'Finish'. The mouse pointer indicates again, that the system is working. You can only close LibreOffice again. 

A saving of the first document is not possible. The change of step 1 is lost.
In order to avoid a data loss, it should be possible to select the documents that you want to recover at step 5.
Comment 1 Durgapriyanka 2019-02-06 17:21:09 UTC
Thank you for reporting the bug. I confirm the bug is present in

Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 2 Timur 2019-02-11 13:22:30 UTC
Created attachment 149124 [details]
WinDBG from procdump

5c3992de 8b5e0c          mov     ebx,dword ptr [esi+0Ch]
SYMBOL_NAME:  swlo!SwPosition::operator<+e
Comment 3 Timur 2019-02-11 13:42:29 UTC Comment hidden (obsolete)
Comment 4 Timur 2019-02-11 14:37:11 UTC
Created attachment 149139 [details]
Minimized sample

While it's true that attached document was Restricted Editing DOCX and saved with pass and 14 pages long, that all obscured the root cause which is check box form fields on page 13. 
I attach the minimized sample. 

Harald, since you're long-time bug reporter, please try to pinpoint the cause and to create a minimal sample document. Dividing by half is a simple method. 

Durgapriyanka, while confirming the bug is useful, more useful is to test different versions and as written, to minimize the sample.
Comment 5 Harald Koester 2019-02-28 22:46:10 UTC
(In reply to Timur from comment #4)
> Harald, since you're long-time bug reporter, please try to pinpoint the
> cause and to create a minimal sample document. Dividing by half is a simple
> method. 

The document, that I attached to the original report, is provided by the public administration in order to list candidates for general elections. Myself I did not made any changes to this document and due to this bug I am not able to make any changes with LibreOffice. I also tried it with version 3.3.0. This version did not hang, but if you save the document under a different name the file is corrupted. Furthermore on my system I have not installed MSO, so I am sorry that I can't provide a minimal sample document.
Comment 6 Xisco Faulí 2019-11-12 10:01:11 UTC Comment hidden (obsolete)
Comment 7 Julien Nabet 2019-11-12 10:17:41 UTC Comment hidden (obsolete)
Comment 8 Julien Nabet 2019-11-12 19:48:22 UTC
Created attachment 155757 [details]
perf flamegraph

Here's a Flamegraph on pc Debian x86-64 with master sources updated today (63c5a1e2aa9e39633c3e644df0d8d9f8cedfc10e)
Comment 9 Xisco Faulí 2019-11-12 23:43:35 UTC Comment hidden (obsolete)
Comment 10 Noel Grandin 2019-11-19 12:46:13 UTC
This not strictly a speed issue, it's some kind of layout hang. Sorry, I don't do those.
Comment 11 Julien Nabet 2019-11-20 22:08:06 UTC
Created attachment 155989 [details]
strace log

On pc Debian x86-64 with master sources updated today +enable-symbols (not enable-dbgutil), I retrieved a strace.

I'm a beginner about interpreting it but it seems that the pb is just after:
line 37240:
459287 23:03:33.841129 close(24)        = 0
37241 459287 23:03:33.841297 brk(0x55e2085c4000) = 0x55e2085c4000
  37242 459310 23:03:34.263558 <... futex resumed> ) = -1 ETIMEDOUT (Connexion terminée par expiration du délai d'attente)
  37243 459310 23:03:34.263623 futex(0x55e204be5e20, FUTEX_WAIT_PRIVATE, 1, {tv_sec=14, tv_nsec=999998708}) = -1 ETIMEDOUT (Connexion terminée par expiration du délai d'attente)
  37244 459310 23:03:49.263957 futex(0x7f204c785c40, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
  37245 459287 23:03:49.263987 futex(0x7f204c785c40, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
  37246 459310 23:03:49.264000 <... futex resumed> ) = 0
  37247 459287 23:03:49.264010 <... futex resumed> ) = -1 EAGAIN (Ressource temporairement non disponible)
  37248 459310 23:03:49.264021 madvise(0x7f203b3a4000, 8368128, MADV_DONTNEED <unfinished ...>
  37249 459287 23:03:49.264031 futex(0x7f204c785c40, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
  37250 459310 23:03:49.264052 <... madvise resumed> ) = 0
  37251 459287 23:03:49.264062 <... futex resumed> ) = 0
Comment 12 Xisco Faulí 2020-03-24 10:17:03 UTC
*** Bug 123233 has been marked as a duplicate of this bug. ***
Comment 13 Roman Kuznetsov 2021-09-25 15:01:38 UTC
still repro in

Version: (x64) / LibreOffice Community
Build ID: 1516711eb7861a08cc9fd19ec867360737a6d070
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded
Comment 14 QA Administrators 2023-09-26 03:14:21 UTC Comment hidden (obsolete)
Comment 15 Matt K 2024-01-18 04:13:36 UTC
I repro the hang on latest master.  I took an ETW trace on Windows and got the following results:

Most time spent underneath: swlo.dll!SwTextFrame::FormatImpl (about 35 secs)

Breakdowns from underneath that frame show the following frames with significant activity:
- swlo.dll!SwTextFormatter::NewPortion (about 22 secs)
- swlo.dll!SwTextFormatter::Underflow (about 12 secs - underneath NewPortion)
- swlo.dll!SwTextIter::SeekAndChg (about 10 secs)
- swlo.dll!SwTextSizeInfo::GetMultiCreator (about 5 secs)