Bug 657394 - [abrt] SwXTextDocument::getRenderer after closing right after launching print
Summary: [abrt] SwXTextDocument::getRenderer after closing right after launching print
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: 14
Hardware: x86_64
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Michael Stahl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:158094ac133166a0c87c7a7266a...
: 661967 714181 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-25 17:41 UTC by Paulius Zaleckas
Modified: 2011-11-02 21:21 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-11-02 21:21:58 UTC
Type: ---
Embargoed:


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

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.


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