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:
Keywords: bibisected, bisected, filter:doc
Depends on:
Blocks: DOC
  Show dependency treegraph
 
Reported: 2017-11-28 07:56 UTC by VViktor
Modified: 2020-10-16 09:50 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.