Bug 657394

Summary: [abrt] SwXTextDocument::getRenderer after closing right after launching print
Product: [Fedora] Fedora Reporter: Paulius Zaleckas <paulius.zaleckas>
Component: openoffice.orgAssignee: Michael Stahl <mstahl>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: caolanm, mstahl, nobodie0, tobyknudsen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:158094ac133166a0c87c7a7266ab06f73230fab9
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-02 21:21:58 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
close listener experiment none

Description Paulius Zaleckas 2010-11-25 17:41:31 UTC
abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: /usr/lib64/openoffice.org3/program/swriter.bin -writer file:///home/paulius/Download/Daugyba.doc
component: openoffice.org
crash_function: SwXTextDocument::getRenderer
executable: /usr/lib64/openoffice.org3/program/swriter.bin
kernel: 2.6.35.6-48.fc14.x86_64
package: openoffice.org-writer-1:3.3.0-15.2.fc14
rating: 4
reason: Process /usr/lib64/openoffice.org3/program/swriter.bin was killed by signal 6 (SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1290703798
uid: 500

How to reproduce
-----
1. Open some document with OO.o Writer
2. press Print
3. quickly close OO.o Writer

Comment 1 Paulius Zaleckas 2010-11-25 17:41:34 UTC
Created attachment 462951 [details]
File: backtrace

Comment 2 Caolan McNamara 2010-11-25 20:19:47 UTC
Looks like the print doesn't block OOo from shutting down while its still pulling pages from writer. In theory should be relatively easy to reproduce this with a big document. In theory at least.

Comment 3 Caolan McNamara 2011-06-17 14:56:01 UTC
*** Bug 714181 has been marked as a duplicate of this bug. ***

Comment 4 Caolan McNamara 2011-06-17 14:58:01 UTC
*** Bug 661967 has been marked as a duplicate of this bug. ***

Comment 5 Michael Stahl 2011-10-31 15:16:07 UTC
the SwXTextDocument printing implementation throws a
RuntimeException if the instance has been disposed.

nobody catches it, hence the crash.

Calc crashes in the same way, but strangely Impress does not.

have put in some exception handling logic that is ugly and makes it not crash.

but now i wonder:
should it be possible to close the document while it is being printed?

there is apparently some way to prevent closing with a CloseVetoException,
perhaps that could be used to keep the doc alive until it is printed.

so should the document be printed fully in this case or not?

Comment 6 Michael Stahl 2011-11-02 21:11:22 UTC
have fixed the crash in Writer and Calc on upstream master:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=17f1adc78adf3b8b943dc36882855b901259d4c1

Impress also crashes, but for a different reason:
its XRenderable implementation owns a view that has SfxItemSets,
but it does not own the document and when that dies its SfxItemPool is destroyed.
also fixed:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b2254d5d6fde8c28501e99e29bc824e935a25247

Comment 7 Michael Stahl 2011-11-02 21:17:19 UTC
Created attachment 531454 [details]
close listener experiment

have experimented with attaching a CloseListener that throws
CloseVetoExceptions so that the document can be printed in full.

adding that is easy enough, however, it turns out that this
only works for Calc currently.

both Writer and Impress depend on having an SfxView and a
ViewShell for printing and all that stuff goes away when the doc
is closed in the UI, so they print a lot of empty pages
which isn't so useful.

Comment 8 Michael Stahl 2011-11-02 21:21:58 UTC
this seems to be a rather obscure crash, and there is an easy work around of 'don't do that then' available, so currently i don't see a reason to backport the fix.

new upstream release with the fix will likely go into F17.

if some more crash reports/duplicates turn up then backport may be considered.