Bug 145743 - Embedded file crash master document
Summary: Embedded file crash master document
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.1 rc
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:24.2.0 target:7.6.1 target:7.5.6
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Writer-Master-Doc Crash
  Show dependency treegraph
 
Reported: 2021-11-17 18:03 UTC by Olivier Hallot
Modified: 2023-10-06 10:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SwFrame::DestroyFrame(SwFrame * const)"]


Attachments
File to be inserted in blank master document (2.93 MB, application/vnd.oasis.opendocument.text)
2021-11-17 18:03 UTC, Olivier Hallot
Details
Bibisect log (4.36 KB, text/plain)
2022-05-23 07:36 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2021-11-17 18:03:38 UTC
Created attachment 176320 [details]
File to be inserted in blank master document

The attached file causes a crash or a permanent freeze when inserted in a master document.

Step to reproduce:
1) create a new master document
2) insert (link) the sample document (insert > text from file or use the icons in the navigator)

Expected results: document is inserted

Actual results: Crash or freeze of LO

Notes:
1) The attached document opens, edits and saves with no problem in LO.

2) It may be that the attached document is ill formatted, somehow carrying garbage invisible when editing as individual file. However, the point here is that master document is unable to prevent the crash or inform user of contents issues.

Version: 7.2.2.2 / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: pt-BR
Calc: threaded
Comment 1 Julien Nabet 2021-11-17 19:36:33 UTC
Michael: on pc Debian x86-64 with master sources updated today + gtk3, I don't reproduce this and noticed this on console:
...
warn:sw.core:1131933:1131933:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:sw.core:1131933:1131933:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:sw.core:1131933:1131933:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:legacy.osl:1131933:1131933:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame?
warn:legacy.osl:1131933:1131933:sw/source/core/layout/layact.cxx:771: LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction
...

but I could reproduce this with kf5 rendering.
I got:
warn:sw.core:1132189:1132189:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:sw.core:1132189:1132189:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.

but no these:
warn:legacy.osl:1131933:1131933:sw/source/core/access/acccontext.cxx:445: fire event for disposed frame?
warn:legacy.osl:1131933:1131933:sw/source/core/layout/layact.cxx:771: LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction

It seems to loop in :
SwLayAction::InternalAction (this=0x7fffdd0737f0, pRenderContext=0x91a91b0) at sw/source/core/layout/layact.cxx:587

With gen rendering, I don't reproduce this and got this on console:
...
warn:sw.core:1132486:1132486:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:sw.core:1132486:1132486:sw/source/core/docnode/node.cxx:1983: Wrong cond collection, skipping check of Cond Colls.
warn:legacy.osl:1132486:1132486:sw/source/core/layout/layact.cxx:771: LoopControl_2 in Interrupt formatting in SwLayAction::InternalAction


Any thoughts here?
Comment 2 sdc.blanco 2022-05-17 22:32:46 UTC
Reproduce crash after inserting attachment 176320 [details] to new master document (also in Safe Mode).

Tested with:

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: cdf8e971d5d46df4bcab35a99c4254df9459213f
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: en-US
Calc: CL

Also tested with: 

Version: 7.2.6.2 (x64) / LibreOffice Community
Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: en-US
Calc: threaded

Here is the crash report:

https://crashreport.libreoffice.org/stats/crash_details/fc77cae3-1962-423c-bdb8-c776d07034d4

In the Document Recovery dialog for 7.2.6.2, there was a Confirmation popup:

   The document 0.odm contains one or more links to external data.

   Would you like to change the document, and update all links
   to get the most recent data?

I answered no.  And then the new master document opened, with the file listed in the Navigator. 

In the master document, now with the attachment included, I did Tools > Update > Update All.  Crash.

https://crashreport.libreoffice.org/stats/crash_details/187d708f-7400-405c-bb70-ed9e09afe9d4  (report looks similar/identical to the previous one).

This time, in the Document Recovery dialog, I answered "yes" to the confirmation message and now the master document opened with the attachment displayed in the master.

Finally, when I open the attachment 176320 [details], I get a message asking if I want to update links to external files.  

Have not tried to make a minimal test case, but is it possible that master documents have trouble inserting/updating files that have external links?
Comment 3 sdc.blanco 2022-05-18 09:47:35 UTC
In relation to comment 2, can restrict focus to updating links. 
Crash happens with: 
Tools > Update > Links  (but not with Update > Fields or Page Formatting).
Also can crash using Navigator and Update > Selection or Links
Comment 4 Telesto 2022-05-23 07:20:54 UTC
Still crashing
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: cdf8e971d5d46df4bcab35a99c4254df9459213f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: en-US (nl_NL); UI: en-GB
Calc: CL Jumbo
Comment 5 Telesto 2022-05-23 07:26:17 UTC
Fine with
Version: 7.0.7.0.0+ (x64)
Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

crashing with 
7.1
Comment 6 Telesto 2022-05-23 07:36:18 UTC
Created attachment 180309 [details]
Bibisect log

Bibisected to:
author	Michael Stahl <Michael.Stahl@cib.de>	2020-11-13 20:52:28 +0100
committer	Michael Stahl <michael.stahl@cib.de>	2020-11-16 16:51:19 +0100
commit b9ef71476fd70bc13f50ebe80390e0730d1b7afb (patch)
tree de2c044f51addf5a7ccc32f0d3289db919d5b19e
parent 094ee3955ee81e1bc631d50cc216cbb17a777839 (diff)
tdf#134298 sw: layout: remove left-over page frame without content
Once tdf#138039 is fixed, this bugdoc has an additional empty page 3.

This is because it first goes to 3 pages, and then the SwTextFrame
on page does a MoveBwd, leaving behind a page frame with just a body
frame and nothing else.

It turns out that SwRootFrame::RemoveSuperfluous() only removes
empty frames at the end of the document, but here there's a non-empty
frame following it.  Also, this function doesn't handle cases like
right/left page styles so it can't delete pages in the middle.

SwFrame::CheckPageDescs() doesn't remove page frames that don't have
content, it only removes those that have the intentionally-empty flag set.

Extend CheckPageDescs() to also remove page frames that don't have
content, and make sure it is called when SwContentFrame::Cut()
removes the last content from a page frame (it will be called after
all pages are valid in SwLayAction::InternalAction()).

(Alternatively it might be possible to prevent the problem from
 occurring in SwTextFly::ForEach() by ignoring the fly so that the first
 paragraph never leaves page 1, but we didn't explore that.)
Comment 7 Commit Notification 2023-08-03 07:54:27 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bd996a23bc4780579fc17e23d8f9f16e2af60289

tdf#145743 sw: don't delete empty page with ColLocked section

It will be available in 24.2.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 8 Michael Stahl (allotropia) 2023-08-03 09:35:10 UTC
fixed on master
Comment 9 Commit Notification 2023-08-03 12:03:34 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/4a69c103cd0a8f41c3c679bf9440c87974de933b

tdf#145743 sw: don't delete empty page with ColLocked section

It will be available in 7.6.1.

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 10 Commit Notification 2023-08-04 14:00:44 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/b308c3b3242d920e9ef054a0bf118623cf8d235c

tdf#145743 sw: don't delete empty page with ColLocked section

It will be available in 7.5.6.

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.