Red Hat Bugzilla – Bug 167130
OOo crashes when closing presentations, if multiple are open
Last modified: 2007-11-30 17:11:12 EST
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): openoffice.org-core-1.9.117-3.1.0.fc4 How reproducible: Sometimes 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.
there's a 1.9.125 update for fc4, give that a whirl
if you could install the (huge) debuginfo package that gives a better stack trace
btw, do you run under kde or gnome ?
(In reply to comment #3) > btw, do you run under kde or gnome ? under gnome
my money is on http://www.openoffice.org/issues/show_bug.cgi?id=51969 being the problem, I'll backport that patch
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?
yeah it's a biggy :-), nothing needs to be done. But if it crashes again we should hopefully get more info.
*** Bug 168308 has been marked as a duplicate of this bug. ***