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
OS is openSuse 42.3 with KDE
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
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
This seems to have begun at the below commit. Adding Cc: to Luke Deller; Could you possibly take a look at this one? Thanks 17972dcd73482ba1cccbb3119ee3d9aa710da0f1 is the first bad commit commit 17972dcd73482ba1cccbb3119ee3d9aa710da0f1 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sat Mar 14 23:57:41 2015 +0800 source-hash-b4ccde72b8e2e45e7276d5b08b182495a1b1a617 commit b4ccde72b8e2e45e7276d5b08b182495a1b1a617 Author: Luke Deller <luke@deller.id.au> AuthorDate: Sat Jul 12 21:49:50 2014 +1000 Commit: Luboš Luňák <l.lunak@collabora.com> CommitDate: Mon Jul 28 13:01:08 2014 +0200 Copy first-header-footer test from ww8 to ooxml The test document was converted from doc to docx using MS Word 2010. Several fixes were required to make this test pass: - Do not clear the "FirstIsShared" property on page styles, as the code instead uses the old fashioned method of translating a Word section with "different first page header/footer": two page styles linked together, the first page style and the follow page style. (Also remove a wrong test case which checks the FirstIsShared property) - Do not clear the "HeaderIsShared"/"FooterIsShared" properties on the first page style, only on the follow page style. - Actually set the "FollowStyle" property on the first page style to link it to the follow page style. This didn't matter for the very first Word section because it was mapped to the default page styles "First Page" and "Standard" which are already linked, but it does matter for subsequent Word sections. - For some reason setting a new page style at a section break was excluded in the case where the following section had a title page. Remove this exclusion. - The exclusion mentioned in the last point was masking that bnc#751077 was not entirely fixed. To resolve that issue: When checking if the last paragraph of the section is empty, consider not just text content but also shapes. - Remove a workaround for bnc#780843 involving copying of headers and footers from the "Standard" (first section) page style in the case where the following section had a title page. This workaround is no longer needed as the test case passes without it.
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.
Regression+crash=> let's increase importance
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.
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?
(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.
Created attachment 142353 [details] sample file
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
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.
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?
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.
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.