Bug 167130 - OOo crashes when closing presentations, if multiple are open
Summary: OOo crashes when closing presentations, if multiple are open
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org   
(Show other bugs)
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
: 168308 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-30 18:28 UTC by Phil Estes
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 05:24:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 51969 None None None Never

Description Phil Estes 2005-08-30 18:28:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
I tried to see if this was related to 162935, but it appears to have a different stack trace, although I'm still unsure if this is an exposure of the same issue.  In this case, I cannot reproduce all the time, and from reading the 19664 bug in gcc and several bugs in FC bugzilla if that problem could be intermittent.  Also, I have 1.9.117-3.1.0.fc4 which should, if I understand correctly, have the workaround for 162935.  The OOo backtrace output for my issue is below:

0xb20b96: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1db96
0xb213e4: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e3e4
0x763420:  + 0x420 (__kernel_sigreturn + 0x0)
0x4b83f74: /usr/lib/openoffice.org2.0/program/libsd680li.so + 0x296f74
0x4b837ce: /usr/lib/openoffice.org2.0/program/libsd680li.so + 0x2967ce
0x5a180ea: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1960ea
0x5a15d80: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x193d80 (SfxDispatcher::_FillState(SfxSlotServer const&, SfxItemSet&, SfxSlot const*) + 0x54)
0x5a22034: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a0034
0x5a22288: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a0288
0x5a22432: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a0432
0x4dba5a2: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x825a2
0x4dc613e: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8e13e (Timer::Timeout() + 0x10)
0x4dc64b8: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8e4b8
0x6fddfe5: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x3efe5
0x6fddfd0: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x3efd0 (SalData::Timeout() const + 0x24)
0x3db352: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xa352
0x739bf06: /usr/lib/libglib-2.0.so.0 + 0x24f06
0x739a3ee: /usr/lib/libglib-2.0.so.0 + 0x233ee (g_main_context_dispatch + 0x1dc)0x739d3f6: /usr/lib/libglib-2.0.so.0 + 0x263f6
0x739d8d8: /usr/lib/libglib-2.0.so.0 + 0x268d8 (g_main_context_iteration + 0x66)0x3db535: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xa535
0x6fe4da1: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x45da1 (X11SalInstance::Yield(unsigned char) + 0x29)
0x4dc091c: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8891c (Application::Yield() + 0x50)
0x4dc095a: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8895a (Application::Execute() + 0x26)
0x8065670: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x1d670 (desktop::Desktop::Main() + 0x149a)
0x4dc5d49: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8dd49 (SVMain() + 0x45)
0x8060723: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x18723 (sal_main + 0x47)
0x445de6: /lib/libc.so.6 + 0x14de6 (__libc_start_main + 0xc6)
0x8060659: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x18659 (Window::RequestHelp(HelpEvent const&) + 0x31)

Again, this only happens on close, and may involved several instances of OOo apps (a doc, a spreadsheet, a couple presentations), but only happens when a presentation is closed.  Most of the times I have seen it, I have several presentations open, referencing one while I write another one, and upon closing the referenced presentation, which I have not modified or saved, I hit the above stack trace and every OOo doc instance goes away.  This was catastrophic the first couple of times, but now I know to save my work before I close any other OOo windows :(

As mentioned, I do *not* have a perfectly reproducible issue.  There are times when I have multiple OOo instances where the crash does not happen upon exit of one or more OOo doc instances.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. open more than one OOo instance--it appears to be related to presentations, however
2. close one OOo presentation instance (in my case, I'm clicking the "X" in the window manager UI to close these instances)

Actual Results:  not every time, but sometimes, the above mentioned stack trace will be displayed and all OOo instance windows will close

Expected Results:  should never crash on closing a presentation instance when multiple are open

Additional info:

I'm setting it high since it is a crash, and loss of data does occur if you don't realize this can happen and have not saved data in other OOo instances which are open at the time of the crash.

Comment 1 Caolan McNamara 2005-08-31 06:57:01 UTC
there's a 1.9.125 update for fc4, give that a whirl

Comment 2 Caolan McNamara 2005-08-31 07:33:16 UTC
if you could install the (huge) debuginfo package that gives a better stack trace

Comment 3 Caolan McNamara 2005-08-31 13:36:30 UTC
btw, do you run under kde or gnome ?

Comment 4 Phil Estes 2005-08-31 13:57:16 UTC
(In reply to comment #3)
> btw, do you run under kde or gnome ?

under gnome

Comment 5 Caolan McNamara 2005-08-31 14:04:40 UTC
my money is on http://www.openoffice.org/issues/show_bug.cgi?id=51969 being the
problem, I'll backport that patch

Comment 6 Phil Estes 2005-08-31 16:32:04 UTC
I've got 1.9.125 + debuginfo (did you say "huge"?--what an understatement :)
..at least I've got access to an internal mirror on my intranet at work)

I noticed all the non-stripped .so's are in /usr/lib/debug/usr/lib/openoffice...
is there some magic that loads those up for symbols as necessary or do I need to
do something else to get them where the loader sees them?  I haven't looked into
debuginfo that much other than knowing that in the spec file you can get it
created with a special macro that strips the non-debuginfo libs and binaries.

And of course, the clincher--I can't reproduce right now.  Of course I'm trying
all these contrived things since I'm not actually working on a presentation
today, and as usual in these situations, I can't reproduce at all.  I'll keep
trying and hopefully do some real work with some real presentations and see if I
can hit it.  Otherwise, maybe -1.9.125 had some fix that worked around or helped
my issue?

Comment 7 Caolan McNamara 2005-08-31 18:46:30 UTC
yeah it's a biggy :-), nothing needs to be done. But if it crashes again we
should hopefully get more info. 

Comment 8 Caolan McNamara 2005-09-15 08:22:15 UTC
*** Bug 168308 has been marked as a duplicate of this bug. ***

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