Bug 657394 - [abrt] SwXTextDocument::getRenderer after closing right after launching print
[abrt] SwXTextDocument::getRenderer after closing right after launching print
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
14
x86_64 Unspecified
low Severity medium
: ---
: ---
Assigned To: Michael Stahl
Fedora Extras Quality Assurance
abrt_hash:158094ac133166a0c87c7a7266a...
:
: 661967 714181 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-25 12:41 EST by Paulius Zaleckas
Modified: 2011-11-02 17:21 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-02 17:21:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (47.02 KB, text/plain)
2010-11-25 12:41 EST, Paulius Zaleckas
no flags Details
close listener experiment (1.07 KB, patch)
2011-11-02 17:17 EDT, Michael Stahl
no flags Details | Diff

  None (edit)
Description Paulius Zaleckas 2010-11-25 12:41:31 EST
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 12:41:34 EST
Created attachment 462951 [details]
File: backtrace
Comment 2 Caolan McNamara 2010-11-25 15:19:47 EST
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 10:56:01 EDT
*** Bug 714181 has been marked as a duplicate of this bug. ***
Comment 4 Caolan McNamara 2011-06-17 10:58:01 EDT
*** Bug 661967 has been marked as a duplicate of this bug. ***
Comment 5 Michael Stahl 2011-10-31 11:16:07 EDT
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 17:11:22 EDT
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 17:17:19 EDT
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 17:21:58 EDT
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.

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