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.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
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.
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
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
Problem is in SfxShell::SetContextName(vcl::EnumContext::GetContextName(vcl::EnumContext::Context::Printpreview));
@Caolán, I thought you might be interested in this issue
Created attachment 160939 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
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
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.
(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)...
(In reply to Mike Kaganski from comment #10) > The options are: 4. Modify SfxFrameLoader_Impl::load to handle preview shell separately ... also bad.
https://gerrit.libreoffice.org/c/core/+/99441
Patch mentioned in comment 12 does not prevent crash opening a file with view data for "view2". That should IMO be handled, too.
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.
https://gerrit.libreoffice.org/c/core/+/99442
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.
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.
I don't reproduce this after having update my local repo (so with your patch) Thank you Mike!
(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.
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!!
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.
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.
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.