Bug 130559 - LibreOffice crashes when opening a document in print preview
Summary: LibreOffice crashes when opening a document in print preview
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All All
: high critical
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.1.0 target:7.0.1 target:6.4....
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Crash
  Show dependency treegraph
 
Reported: 2020-02-10 13:48 UTC by Marqeaux
Modified: 2020-08-05 21:27 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (15.49 KB, text/plain)
2020-05-17 16:17 UTC, Julien Nabet
Details
bt from initial exception (16.12 KB, text/plain)
2020-07-25 08:45 UTC, Julien Nabet
Details
An ODS with print preview view data in settings.xml (7.58 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-07-25 11:43 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marqeaux 2020-02-10 13:48:50 UTC
Description:
When you open a document in Calc and has one of more charts, and you open that document in print preview, LibreOffice crashes. This behaviour is the same on Windows 10 and Linux (Manjaro in this case).

Steps to Reproduce:
1. Open LibreOffice Calc
2. Open an .ods-file which hold charts or create one
3. Go to "print preview" to see the result

Actual Results:
When closing print preview, LibreOffice crashes.

Expected Results:
When closing preview, everything should be fine and shouldn't crash at all.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
The thing I noticed is that a filed and resolved bug is reintroduced again: the rendering of lines in tables in Calc is incredibly slow in print preview, like it's never been solved.

Info about LibreOffice:
Versie: 6.4.0.3 (x86)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU-threads: 4; Besturingssysteem: Windows 10.0 Build 18363; UI-render: standaard; VCL: win; 
Locale: nl-NL (nl_NL); UI-taal: nl-NL
Calc: threaded

Same behaviour on LibreOffice 6.4.0. in Manjaro 18.1.5. And in both cases it doesn't matter if OpenGL is enabled or not.
Comment 1 Xisco Faulí 2020-02-10 14:21:19 UTC Comment hidden (obsolete)
Comment 2 Marqeaux 2020-02-10 15:49:37 UTC
LibreOffice 6.4.0. crashes at EVERY file. Without any exception.

Just a moment ago I discovered that Calc doesn't even need a chart or picture. It crashes even without any sort of graphics. Even just typing some random letters in a cell, and then show that page in print preview makes it crash immediately. Conclusion: no matter what the Calc-file holds, it crashes as soon as you press "print preview". In other words: It doesn't need an example file. You can reproduce it with ANY file and just typ some random characters.
Comment 3 Oliver Brinzing 2020-02-10 17:56:45 UTC
reproducible with:

Version: 7.0.0.0.alpha0+ (x64)
Build ID: e6341e0f613237020fef9e2028e123022ff2ce38
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

Version: 6.4.1.1 (x64)
Build-ID: 56f3c78975db08733f771c53643b5d1aa7c57567
CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

Version: 6.2.8.2 (x64)
Build-ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: 

but *not* reproducible with:

Version: 6.1.6.3 (x64)
Build-ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group threaded

steps to reproduce:

- new spreadsheet
- cell A1, enter "Hello"
- Menu File/Print Preview
- Menu File/Save a Copy...
- Close Print Preview
- Close file (don't save again)
- open file
-> crash
Comment 4 Xisco Faulí 2020-02-11 15:07:50 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=128ecffe53394c1f045521c2efb42ea03a319f4b

author	andreas kainz <kainz.a@gmail.com>	2018-10-17 21:41:25 +0200
committer	Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>	2018-10-29 08:23:23 +0100
commit	128ecffe53394c1f045521c2efb42ea03a319f4b (patch)
tree	40316dff3279e03624118cab271d1c1e19b75db4
parent	ac51f1dfb3c63f1d0a3e2577ba5a56c25bc0b94b (diff)
Notebookbar: add context-Printpreview to calc tabbed NB

Bisected with: bibisect-linux64-6.2

Adding Cc: to andreas kainz
Comment 5 Xisco Faulí 2020-02-11 16:00:59 UTC
Problem is in SfxShell::SetContextName(vcl::EnumContext::GetContextName(vcl::EnumContext::Context::Printpreview));
Comment 6 Xisco Faulí 2020-02-13 09:41:47 UTC
@Caolán, I thought you might be interested in this issue
Comment 7 Julien Nabet 2020-05-17 16:17:34 UTC
Created attachment 160939 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 8 Julien Nabet 2020-05-17 16:26:57 UTC
Just for the test, I tried the same thing on Writer.
Here are the steps with differences I noticed:
- open brand new odt file
- type "Hello"
- Menu File/Print Preview
- Menu File/Save a Copy...
- Close Print Preview
- Close file
=> LO closes the file with no dialog which proposes to save or not
(quite logical since we haven't changed anything since the Save a copy step
- open file
-> no crash

I suppose equivalent commit is:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d05b7b32d9ecb6fcb4a268eb68cdcee09bafa6dd
Comment 9 Julien Nabet 2020-07-25 08:45:47 UTC
Created attachment 163503 [details]
bt from initial exception

On pc Debian x86-64 with master sources updated today, I gave a new try and could still reproduce this.

I noticed this trace:
warn:sfx.view:12741:12741:sfx2/source/view/frmload.cxx:489: DBG_UNHANDLED_EXCEPTION in static void (anonymous namespace)::SfxFrameLoader_Impl::impl_handleCaughtError_nothrow(const com::sun::star::uno::Any &, const ::comphelper::NamedValueCollection &) exception: com.sun.star.uno.RuntimeException message: not supported /home/julien/lo/libreoffice/sfx2/source/dialog/backingcomp.cxx:583
[New Thread 0x7fffe54fc700 (LWP 12891)]
warn:sfx:12741:12741:sfx2/source/control/thumbnailviewacc.cxx:542: Calling disposed object. Throwing exception:
warn:sfx:12741:12741:sfx2/source/control/thumbnailviewacc.cxx:542: Calling disposed object. Throwing exception:
warn:legacy.osl:12741:12741:vcl/source/window/window.cxx:273: Window ( 19SfxFrameWindow_Impl()) with live children destroyed:  23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl()
Window ( 19SfxFrameWindow_Impl()) with live children destroyed:  23SfxFrameViewWindow_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl() 14SfxSplitWindow() 21SfxEmptySplitWin_Impl()

sfx2/source/dialog/backingcomp.cxx 583 contains:
    571 /** not supported.
    572 
    573     @param  xListener
    574                 not used.
    575 
    576     @throw  css::uno::RuntimeException
    577                 because the listener expect to be holded alive by this container.
    578                 We must inform it about this unsupported feature.
    579  */
    580 
    581 void SAL_CALL BackingComp::addEventListener( /*IN*/ const css::uno::Reference< css::lang::XEventListener >& )
    582 {
    583     throw css::uno::RuntimeException(
    584             "not supported",
    585             static_cast< ::cppu::OWeakObject* >(this));
    586 }

(see https://opengrok.libreoffice.org/xref/core/sfx2/source/dialog/backingcomp.cxx?r=27f4feab#583)

So I took a bt from this location.
Comment 10 Mike Kaganski 2020-07-25 10:37:44 UTC
(In reply to Julien Nabet from comment #8)
> Just for the test, I tried the same thing on Writer.
> ...
> -> no crash

The problem here is that preview data is exported into ODS' settings.xml (/office:document-settings/office:settings/config:config-item-set[1]/config:config-item-map-indexed/config:config-item-map-entry/config:config-item: ViewId = view2). Then on load, this ViewId is used in SfxBaseModel::createViewController called from impl_createDocumentView called from SfxFrameLoader_Impl::load, and an instance of preview is attempted to be created, which throws and crashes.

On the other hand, preview data is not exported into ODT. The difference is in implementation of ScPreviewShell::WriteUserDataSequence vs SfxViewShell::WriteUserDataSequence (i.e., ScPreviewShell overrides the WriteUserDataSequence method, while SwPagePreview does not, and uses base empty method).

The implementation of ScPreviewShell::WriteUserDataSequence was added in https://git.libreoffice.org/core/+/1f51730f3c5b05c3afaa35431c925482e8152783, without any explanation in commit message (the issue number in some internal tracker is unavailable).

The options are:

1. Remove the implementation - with possible unknown regression.
2. Pass an information to the implementation, so that it conditionally doesn't write information. As this is called through UNO interface during the export, the only method to pass the necessary data is using component context, like done in https://gerrit.libreoffice.org/c/core/+/81616 using SetFlagContext.
3. Process the result of getViewData() in SvXMLExport::GetViewSettingsAndViews, so that when aProps.hasElements, the elements are checked if ViewId gives a preview shell ... bad: needs to know modules' preview shell classes; needs to modify the XIndexAccess instance (re-create it "filtered" in case of multiple views, one of which should not be exported)...
Comment 11 Mike Kaganski 2020-07-25 11:02:16 UTC
(In reply to Mike Kaganski from comment #10)
> The options are:

4. Modify SfxFrameLoader_Impl::load to handle preview shell separately ... also bad.
Comment 12 Mike Kaganski 2020-07-25 11:32:18 UTC
https://gerrit.libreoffice.org/c/core/+/99441
Comment 13 Mike Kaganski 2020-07-25 11:40:42 UTC
Patch mentioned in comment 12 does not prevent crash opening a file with view data for "view2". That should IMO be handled, too.
Comment 14 Mike Kaganski 2020-07-25 11:43:02 UTC
Created attachment 163522 [details]
An ODS with print preview view data in settings.xml

This is a file created using steps from comment 3. This is a crasher.
Comment 15 Mike Kaganski 2020-07-25 12:32:20 UTC
https://gerrit.libreoffice.org/c/core/+/99442
Comment 16 Commit Notification 2020-07-25 12:37:57 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/592a02b2869aa04cb6d95cb3d491cd7c5455bd0a

tdf#130559: don't export preview view data to ODS

It will be available in 7.1.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 17 Commit Notification 2020-07-25 16:44:40 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#130559: don't fail creation of preview when BackingComp can't add...

It will be available in 7.1.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 18 Julien Nabet 2020-07-25 17:12:34 UTC
I don't reproduce this after having update my local repo (so with your patch)

Thank you Mike!
Comment 19 Mike Kaganski 2020-07-25 17:31:36 UTC
(In reply to Julien Nabet from comment #18)
> I don't reproduce this after having update my local repo (so with your patch)

Great! :-) Hope this is the correct fix.
Comment 20 Xisco Faulí 2020-07-30 10:27:43 UTC
Verified in

Version: 7.1.0.0.alpha0+
Build ID: 231e1e416c039d1f9724962a89cf0573a3db48a2
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Mike, thanks for fixing this issue!!
Comment 21 Commit Notification 2020-07-30 19:28:01 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

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

tdf#130559: don't fail creation of preview when BackingComp can't add...

It will be available in 7.0.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 22 Commit Notification 2020-08-03 09:25:27 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/810b9dabc0b91629b0aadadb999b396a7879b385

tdf#130559: don't fail creation of preview when BackingComp can't add...

It will be available in 6.4.7.

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 23 Commit Notification 2020-08-05 21:27:22 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-6":

https://git.libreoffice.org/core/commit/21184becd97392e142f61225cc7d45daa6cbe97b

tdf#130559: don't fail creation of preview when BackingComp can't add...

It will be available in 6.4.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.