Bug 114111 - FILEOPEN: Hang/Crash loading many tables in table .doc
Summary: FILEOPEN: Hang/Crash loading many tables in table .doc
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:7.6.0
Keywords: bibisected, bisected, filter:doc
Depends on:
Blocks: DOC-Opening
  Show dependency treegraph
 
Reported: 2017-11-28 07:56 UTC by VViktor
Modified: 2024-02-16 22:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example file (399.50 KB, application/msword)
2017-11-28 07:57 UTC, VViktor
Details
example minimized in MSO (292.50 KB, application/msword)
2020-10-16 09:48 UTC, Timur
Details
example minimized and saved in MSO as DOCX (140.34 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-16 09:50 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description VViktor 2017-11-28 07:56:41 UTC
Description:
I have a document produced by one of the Polish institutions, which contains a complex arrangement. Any attempt to open this document causes the program to be crashed.

Steps to Reproduce:
1. try to open document
2. program crash every time


Actual Results:  
crash

Expected Results:
open


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 VViktor 2017-11-28 07:57:38 UTC
Created attachment 138033 [details]
example file
Comment 2 Xisco Faulí 2017-11-28 09:12:06 UTC
Regression introduced by:

author	Michael Stahl <mstahl@redhat.com>	2016-06-09 13:52:16 (GMT)
committer	Michael Stahl <mstahl@redhat.com>	2016-06-09 13:59:19 (GMT)
commit c488214817516c13603deb1c180fef02f4c700bf (patch)
tree f139da3173a9bf65a67d7d575af5d1ddc6a9d07a
parent 6a5cb3dae1760283c2c9156de666964ea4794f0f (diff)
tdf#96089 sw: fix scope of bBreakAfter in InsertCnt_()
The problem is that bBreakAfter is passed by reference to SwLayHelper
and stored as a reference member there, so it has to live at least as
long as pPageMaker.  (Unfortunately C++ can't statically check that.)

This then somehow caused the number of pages created after initial load
to be 812 instead of the correct 396 determined from the layout-cache in
the bugdoc, and that then caused Drawing objects to move backward during
the following re-pagination, and then SwDrawContact::Changed_() calls
SetFlyFrmAttr() and that sets the document to modified, which triggers the
AutoSave that was reported in the bug.

(regression from b4b7703e4335460cf48bfd6440f116359994c8ff)

Bisected with: bibisect-linux-64-5.3

Adding Cc: to Michael Stahl
Comment 3 tommy27 2017-11-28 09:15:00 UTC
tested under Win7 x64 using LibO 5.3.6.1
LibO hangs tryng to open the file... had to kill the process.

status NEW.
Comment 4 Michael Stahl (allotropia) 2017-11-28 13:00:49 UTC
not a regression
Comment 5 Julien Nabet 2017-11-28 20:29:24 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

However, I'm not sure it's hanging at the same location since I use enable-dbgutil and gdb shows I'm stuck (or I didn't have the patience to wait for the end of outer loop) here:
See https://opengrok.libreoffice.org/xref/core/sw/source/core/bastyp/swcache.cxx#40
Comment 6 QA Administrators 2019-03-01 03:49:53 UTC Comment hidden (obsolete)
Comment 7 VViktor 2019-03-01 05:41:03 UTC
LO version 6.2.0.3 (x64) Windows 10 x64 error still occurs
Comment 8 Timur 2020-10-16 09:48:28 UTC
Created attachment 166406 [details]
example minimized in MSO

Repro 7.1+.
Comment 9 Timur 2020-10-16 09:50:20 UTC
Created attachment 166407 [details]
example minimized and saved in MSO as DOCX

DOCX opens, but not the same as in MSO.
Comment 10 Silvestr VS 2022-05-04 18:56:55 UTC
Reproducible in 

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 465c3ad95059f0efa13c8027f7383c4d20a5b2ff
CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

Both the original document and the test file in comment #8 still cause the application to hang. 

Example from comment #9 opens, I can fill in some fields, save as docx and quit the application.
Comment 11 Commit Notification 2023-04-28 07:24:37 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1795d5183d5371a24e8dcb15f8671c78b2c94665

sw floattable, crashtesting: fix PDF export of tdf114111-3.docx

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Tex2002ans 2024-02-16 22:35:03 UTC
I was able to open comment 1 + comment 8 + comment 9 fine.

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

- - -

I suspect Miklos's patch back in April 2023 fixed it? :)