Bug 1144939

Summary: [abrt] libreoffice-core: SwEnhancedPDFExportHelper::EnhancedPDFExport()(): soffice.bin killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Paul DeStefano <prd-fedora>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: caolanm, dtardon, erack, ltinkl, mstahl, prd-fedora, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/da80c40cd744c60b160774983092ba7082ba2dd3
Whiteboard: abrt_hash:2f5fe146edbf85f156ba27ad30007bafc7fc1551
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-21 12:17:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
PDF 1
none
PDF 2 none

Description Paul DeStefano 2014-09-22 05:37:29 UTC
Version-Release number of selected component:
libreoffice-core-4.2.6.3-3.fc20

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        /usr/lib64/libreoffice/program/soffice.bin --impress --splash-pipe=5
crash_function: SwEnhancedPDFExportHelper::EnhancedPDFExport()
executable:     /usr/lib64/libreoffice/program/soffice.bin
kernel:         3.16.2-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            13013

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 SwEnhancedPDFExportHelper::EnhancedPDFExport() at /usr/lib64/libreoffice/program/../program/libswlo.so
 #1 SwEnhancedPDFExportHelper::SwEnhancedPDFExportHelper(SwEditShell&, OutputDevice&, rtl::OUString const&, bool, bool) at /usr/lib64/libreoffice/program/../program/libswlo.so
 #2 SwXTextDocument::render(int, com::sun::star::uno::Any const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at /usr/lib64/libreoffice/program/../program/libswlo.so
 #3 PDFExport::ExportSelection(vcl::PDFWriter&, com::sun::star::uno::Reference<com::sun::star::view::XRenderable>&, com::sun::star::uno::Any const&, StringRangeEnumerator const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>&, int) at /usr/lib64/libreoffice/program/../program/libpdffilterlo.so
 #4 PDFExport::Export(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at /usr/lib64/libreoffice/program/../program/libpdffilterlo.so
 #5 PDFFilter::implExport(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at /usr/lib64/libreoffice/program/../program/libpdffilterlo.so
 #6 PDFFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at /usr/lib64/libreoffice/program/../program/libpdffilterlo.so
 #7 SfxObjectShell::ExportTo(SfxMedium&) at /usr/lib64/libreoffice/program/libsfxlo.so
 #8 SfxObjectShell::SaveTo_Impl(SfxMedium&, SfxItemSet const*) at /usr/lib64/libreoffice/program/libsfxlo.so
 #9 SfxObjectShell::PreDoSaveAs_Impl(rtl::OUString const&, rtl::OUString const&, SfxItemSet*) at /usr/lib64/libreoffice/program/libsfxlo.so

Comment 1 Paul DeStefano 2014-09-22 05:37:35 UTC
Created attachment 939884 [details]
File: backtrace

Comment 2 Paul DeStefano 2014-09-22 05:37:39 UTC
Created attachment 939885 [details]
File: cgroup

Comment 3 Paul DeStefano 2014-09-22 05:37:40 UTC
Created attachment 939886 [details]
File: core_backtrace

Comment 4 Paul DeStefano 2014-09-22 05:37:44 UTC
Created attachment 939887 [details]
File: dso_list

Comment 5 Paul DeStefano 2014-09-22 05:37:45 UTC
Created attachment 939888 [details]
File: exploitable

Comment 6 Paul DeStefano 2014-09-22 05:37:49 UTC
Created attachment 939889 [details]
File: limits

Comment 7 Paul DeStefano 2014-09-22 05:37:55 UTC
Created attachment 939890 [details]
File: maps

Comment 8 Paul DeStefano 2014-09-22 05:37:59 UTC
Created attachment 939891 [details]
File: open_fds

Comment 9 Paul DeStefano 2014-09-22 05:38:01 UTC
Created attachment 939892 [details]
File: proc_pid_status

Comment 10 Caolan McNamara 2014-09-22 09:48:58 UTC
crashes on exporting/printing something to .pdf. Are you able to attach the document that crashes when exported to pdf ?

Comment 11 Paul DeStefano 2014-09-22 18:06:30 UTC
Created attachment 940110 [details]
PDF 1

Actually, I'm not sure which file I was exporting at the time.  When this crash happened, I had three documents open and I was working on two of them.  I don't remember which one I exported that caused this crash.

I'll attached PDF exports of both active documents, but there is no guarantee that these files will show any errors.  One looks like it could be old and was never updated because the crash occurred before the file was opened for writing.  That is this attachment, PDF 1.

The other one, PDF 2 (uploaded next), has been re-exported since the crash, so, for a different reason, it may not contain any data that expresses the problem.  But, maybe that's not what you are looking for, so I hope it helps.

Comment 12 Paul DeStefano 2014-09-22 18:08:37 UTC
Created attachment 940111 [details]
PDF 2

Second PDF.  This one has been exported since the crash.  I suspect it was actually this one that was exporting when the crash occurred, but I can't be sure.

Comment 13 Caolan McNamara 2014-09-23 08:44:07 UTC
These are the outputs, I was hoping for the input .odts

Comment 15 Caolan McNamara 2014-09-24 09:05:50 UTC
"You don't have permission to access /~pdestefa/tmp/tofHardware.Jan2014Work.odt on this server."

Comment 16 Paul DeStefano 2014-09-24 16:54:37 UTC
Damn it.  I forget every time.  Sorry.  Try now.

Comment 17 Michael Stahl 2015-01-20 17:29:48 UTC
downloaded the ODT file (which is huge...) and it does not crash for me when exporting it to PDF with default settings or with PDF/A, neither on LO master nor 4.2.7.

tried exporting with valgrind, master and current 4.2, no findings.

there is some debug output indicating linked images cannot be found.

does this still crash for you? the attached backtrace does not contain symbols so it's not even clear where it's crashing - can you try to get a better backtrace?

1. "yum install libreoffice-debuginfo"
2. "soffice --backtrace"
3. make it crash
4. attach generated file "gdbtrace.log"

Comment 18 Paul DeStefano 2015-01-21 03:52:32 UTC
There's no reason to believe this is related to the files, specifically, other than there large size, as you noted.  I exported both documents to PDF from 4.2.6.3 many times without problems before and after this crash.  If you're not getting what you need from the abrt report, I'm not sure what to do.  I will certainly remember your procedure if I get a reproducible crash in the future, though.

I'm more concerned now that the backtrace wasn't usable.  LibreOffice crashes on me regularly, though I wouldn't say frequently, but it's rarely a reproducible problem.  It's critical these reports are useful to the developers.  Did something go wrong with the retrace server?  That should have provided all the symbols you want, right?

Comment 19 Michael Stahl 2015-01-21 12:17:32 UTC
ok, pity it's not reproducible for you either.

we sometimes see unhelpful gdb backtraces without line numbers and variables and there are several ways how that could happen, and all of them are probably bugs in ABRT (if the backtrace is generated locally, ABRT should install the libreoffice-debuginfo package, and if the core dump is uploaded to the server, the server should install the debuginfo).

the retrace server also generates line numbers but it does not show values of local variables and in case of function inlining (like apparently happens in this bug) some parts may be missing.

but unfortunately even with a good gdb backtrace we have to close half of the bugs because it's impossible to figure out what went wrong.