Description: LibreOffice crashes whenever an attempt is made to use "Export to PDF..." functionality. I've verified this in Calc and Writer using both the icon and the File menu entry. Steps to Reproduce: 1. Open a document 2. Try to export the document to a PDF file. 3. Observe crash, followed by document recovery process. Actual Results: Application crashes, potentially losing data. Expected Results: Properly exports the contents to PDF Reproducible: Always User Profile Reset: Yes Additional Info: I noticed this immediately after today's release update in the Ubuntu repositories. I was using it before the updates and everything was working fine. I restarted the application after the repository updates and the export functionality was broken. After the update had completed, I also rebooted the PC as recommended by the updater. This made no difference. I tried restarting in safe mode, including using the option to reset my profile to factory defaults. Again, this made no difference. The Build ID reported by the updated package(s) is: 1:5.4.5-0ubuntu0.17.10.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.167 Chrome/64.0.3282.167 Safari/537.36
I'd change the severity to a minimum of "major", but I don't have permissions to do so.
Actually, I just observed that the application also crashes in the same way if I choose the option "Save as...", which would be done if you're trying to save a document in a different format (e.g. LibreOffice Calc to Microsoft Excel). This is _not limited_ to PDF exports.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. (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.) I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
Created attachment 140048 [details] A sample document for the bug report. The issue is present regardless of document I use. I've created a new sample document as requested.
(In reply to Xisco Faulí from comment #3) > Thank you for reporting the bug. Please attach a sample document, as this > makes it easier for us to verify the bug. > (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.) > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' once the requested document is provided. To be explicit, I'm observing the bug regardless of which LibreOffice version (pre/post update) is used to create and/or modify the document(s) and regardless of which document and/or content I use. I've also changed it back to unconfirmed.
Are you sure your reset your user profile? Could you please try Help - Restart in Safe Mode as explained here https://wiki.documentfoundation.org/UserProfile#Resolving_corruption ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
(In reply to Xisco Faulí from comment #6) > Are you sure your reset your user profile? > > Could you please try Help - Restart in Safe Mode as explained here > https://wiki.documentfoundation.org/UserProfile#Resolving_corruption ? > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the issue is still present Yes, I'm sure I did. And yes, those are the exact instructions I followed when resetting my profile. The only way for the profile to not be reset back to its initial state is if the LibreOffice option that claims to be resetting the profile is not working either.
Could you also check it's not related to OpenGL (see https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28OpenGL.29) If you still reproduce this, would it be possible you attach a backtrace? (see https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace)
Created attachment 140049 [details] gdbtrace.log file Trace of crash after reproducing issue.
(In reply to Julien Nabet from comment #8) > Could you also check it's not related to OpenGL (see > https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_. > 28OpenGL.29) Mine says "UI render: default", so according to the document, this is not an OpenGL-related issue and the rest doesn't apply. > If you still reproduce this, would it be possible you attach a backtrace? > (see > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux:_How_to_get_a_backtrace) I've attached the trace to this report.
Created attachment 140050 [details] Trace for "
Created attachment 140051 [details] gdbtrace.log for "Save as..." option While the first trace posted was generated by clicking the "Export to PDF" icon, this second trace attachment was generated by clicking the File > "Save as..." entry in the menu. Posted both in case there's a difference.
Thank you for your quick feedback. According to the bt, it seems related to kde rendering. For the test could you try other renderings, ie: export SAL_USE_VCLPLUGIN=gtk3 then launch LO from console. You can also try these: SAL_USE_VCLPLUGIN=gen SAL_USE_VCLPLUGIN=gtk
Created attachment 140052 [details] gdbtrace-vlcplugin-gtk-crash.log Test Case: export SAL_USE_VCLPLUGIN=gtk3 Result : Good Test Case: export SAL_USE_VCLPLUGIN=gen Result : Good Test Case: export SAL_USE_VCLPLUGIN=gtk Result : Crash (gdbtrace-vlcplugin-gtk-crash.log attached) A new/independent terminal was spawned for each test case.
According to your last bt, since it seems there's no gtk libs present on your env (only gtk3), LO used kde rendering for your test with gtk. Let's put this one to NEW given the bts.
(In reply to Julien Nabet from comment #15) > According to your last bt, since it seems there's no gtk libs present on > your env (only gtk3), LO used kde rendering for your test with gtk. > > Let's put this one to NEW given the bts. Did something change internally in LO? I've been using Kubuntu (currently 17.10) and LO had been working fine for months without crashes. The only thing I did prior to running into the crashes was to apply a LO update that showed up in the repositories today. Nothing else was changed. And since I was using LO before the update and had to resume using it afterwards, it was pretty easy to realize that the issues arrived b/c of the update. Is there at least a way to specify rendering to gtk3 when launching LO from the K Application Launcher -at least while a proper fix is released? This is very disrupting.
(In reply to xghost from comment #16) > ... > Is there at least a way to specify rendering to gtk3 when launching LO from > the K Application Launcher -at least while a proper fix is released? > > ... Sorry I don't know. Katarina: thought you might be interested in this one since it concerns kde rendering.
*** Bug 115920 has been marked as a duplicate of this bug. ***
Workaround to use a different rendering, see https://bugs.documentfoundation.org/show_bug.cgi?id=115920#c6
I guess we can close this as a duplicate of bug 98776 *** This bug has been marked as a duplicate of bug 98776 ***