Bug 1144939 - [abrt] libreoffice-core: SwEnhancedPDFExportHelper::EnhancedPDFExport()(): soffice.bin killed by SIGSEGV
Summary: [abrt] libreoffice-core: SwEnhancedPDFExportHelper::EnhancedPDFExport()(): so...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:2f5fe146edbf85f156ba27ad300...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-22 05:37 UTC by Paul DeStefano
Modified: 2015-01-21 12:17 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-01-21 12:17:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (174.68 KB, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: cgroup (181 bytes, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: core_backtrace (39.32 KB, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: dso_list (27.51 KB, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: exploitable (82 bytes, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: limits (1.29 KB, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: maps (124.67 KB, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: open_fds (563 bytes, text/plain)
2014-09-22 05:37 UTC, Paul DeStefano
no flags Details
File: proc_pid_status (971 bytes, text/plain)
2014-09-22 05:38 UTC, Paul DeStefano
no flags Details
PDF 1 (6.87 MB, application/pdf)
2014-09-22 18:06 UTC, Paul DeStefano
no flags Details
PDF 2 (616.54 KB, application/pdf)
2014-09-22 18:08 UTC, Paul DeStefano
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.