Bug 117723 - Writer crashes every time with a certain large file FILEOPEN
Summary: Writer crashes every time with a certain large file FILEOPEN
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.4.2 release
Hardware: All All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0 target:6.0.6 target:6.1.0.1
Keywords: bibisected, bisected, filter:docx, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2018-05-21 13:59 UTC by konsultor
Modified: 2018-06-18 13:54 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["SwDoc::IsInHeaderFooter(SwNodeIndex const &)"]


Attachments
gdb + bt trace (43.70 KB, text/plain)
2018-05-21 20:56 UTC, Julien Nabet
Details
sample file (26.64 MB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-05-28 16:31 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description konsultor 2018-05-21 13:59:08 UTC
Description:
FILEOPEN
https://www.fbo.gov/utils/view?id=5899e6698a7163d1770a537fcacec0eb
is a public document, part of an RFP.  Attempting to open it has reliably crashed Writer more than a dozen times.  An associate reports that this file opens with no problem in MS Word.
The size of this file is about 26 MB.  I obtained it as a direct download and as part of a zip file.  Both versions crashed Writer.


Steps to Reproduce:
1. open Writer, 
2.open file menu and select "section J" doc
3.Writer crashes

1.  Follow link
2.  select "open with Writer" for the download
3.  Writer crashes

Actual Results:  
LO crashed and restarted with offer to restore documents, including the problem document.

Expected Results:
file should have opened


Reproducible: Always


User Profile Reset: No



Additional Info:
Associate who opened this file says it is about 200 pages.  He divided the file into two 100-page segments.  The second part still was 25 MB.


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Comment 1 konsultor 2018-05-21 14:00:55 UTC
OS is openSuse 42.3 with KDE
Comment 2 raal 2018-05-21 14:54:34 UTC
I can confirm crash with Version: 6.1.0.0.alpha1+
Build ID: db608e8e5e27cce8eeda26918bcab71222d342df
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3; 
I can open file in word2010. No crash in Version 4.1.0.0.alpha0+ -> regression
Comment 3 Telesto 2018-05-21 17:56:29 UTC
Repro with
Version: 6.1.0.0.alpha1+ (x64)
Build ID: e1a8338876bd161de4e9d9a4b22d4bc5335f7cee
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-18_23:55:37
Locale: nl-NL (nl_NL); Calc: CL

no repro with
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 4 raal 2018-05-21 19:56:35 UTC Comment hidden (obsolete)
Comment 5 Julien Nabet 2018-05-21 20:56:50 UTC
Created attachment 142234 [details]
gdb + bt trace

On pc Debian x86-64 with master sources updated today, I could reproduce this.

I attached gdb session which includes bt too.
Comment 6 Julien Nabet 2018-05-21 20:57:41 UTC
Regression+crash=> let's increase importance
Comment 7 Luke Deller 2018-05-22 12:48:01 UTC
To narrow this down a bit, this relates the rendering of an embedded document within an embedded document within this file.

Under the following heading there is an embedded document shown as an icon:

J.16.1	AcquServe Access Guide for EIS (FEB 2015)

This document may also be found by unzipping the referenced docx file, at:
word/embeddings/Microsoft_Word_Document3.docx

Now within this document there is another embedded document, this time shown as a preview of the content rather than an icon.  This is labelled:

Figure 1.  EIS Proposal Submission Process using AcquServe

This document may also be found by unzipping Microsoft_Word_Document3.docx mentioned above, and locating within that the file:
[Microsoft_Word_Document3.docx/]word/embeddings/Microsoft_Word_Document1.docx

I can reproduce essentially the same crash in LO master by opening Microsoft_Word_Document3.docx, but this last Microsoft_Word_Document1.docx opens fine.  From first glance at the gdb backtrace it looks like the crash is occurring when trying to render the preview image of Microsoft_Word_Document1.docx for showing within Microsoft_Word_Document3.docx.
Comment 8 Luke Deller 2018-05-22 13:44:41 UTC
Incidentally I can open this document in LibreOffice 5.1.6.2 (packaged with Ubuntu 16.04), which includes commit b4ccde72b8e2e45e7276d5b08b182495a1b1a617.

Can we double check the bisection?
Comment 9 raal 2018-05-22 14:40:14 UTC
(In reply to Luke Deller from comment #8)
> Incidentally I can open this document in LibreOffice 5.1.6.2 (packaged with
> Ubuntu 16.04), which includes commit
> b4ccde72b8e2e45e7276d5b08b182495a1b1a617.
> 

me too, Ubuntu 16.04 LO 5.1.6.2

> Can we double check the bisection?
I check bisection everytime - in this commit it hangs and in commit before (git checkout HEAD~1 it doesn't hang), but maybe it was fixed and got worse later or it's another crash. Removing keywords.
Comment 10 Xisco Faulí 2018-05-28 16:31:22 UTC
Created attachment 142353 [details]
sample file
Comment 11 Xisco Faulí 2018-05-28 17:11:45 UTC
The crash was recently introduced as the document is open in 6.0.0.0.alpha0+

Regression introduced by:

author	Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org>	2017-09-19 07:46:50 +0200
committer	Björn Michaelsen <bjoern.michaelsen@libreoffice.org>	2017-09-20 01:04:33 +0200
commit	e73961022d8efda407c3f5ed806f78bb7cc0e0b4 (patch)
tree	e1ee9fe8b61d945cefdfb8ddc88dab2d276e7378
parent	ce2fce9a41729774689080c8b5552b60c2e6ee2d (diff)
no need to queue formats in header and footer ...
- we can call MakeFrames on them right away
- as there had been performance issues on mail merge here before, this
  might a bit quicker for suoer large documents.

Bisected with: bibisect-linux64-6.0

Adding Cc: to Bjoern Michaelsen
Comment 12 Commit Notification 2018-06-15 06:54:39 UTC
Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8142da066b6ee80444694e0eb6b0da9375a89c7

tdf#117723: nullcheck the ContentAnchor before deref

It will be available in 6.2.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 13 Xisco Faulí 2018-06-17 15:42:15 UTC
Crash verified in

Version: 6.2.0.0.alpha0+
Build ID: d60d695fcc5064e1f16842387fdce23456a64694
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

@Bjoern, Should it be closed as RESOLVED FIXED?
Comment 14 Commit Notification 2018-06-18 09:49:27 UTC
Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1d679a1b06de087fe2a1af079e0c6c46473c0e3&h=libreoffice-6-0

tdf#117723: nullcheck the ContentAnchor before deref

It will be available in 6.0.6.

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

Affected users are encouraged to test the fix and report feedback.
Comment 15 Commit Notification 2018-06-18 09:49:39 UTC
Bjoern Michaelsen committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=009c36b0bf59adadc643dc94fe30c18485f89c6d&h=libreoffice-6-1

tdf#117723: nullcheck the ContentAnchor before deref

It will be available in 6.1.0.1.

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

Affected users are encouraged to test the fix and report feedback.