Since upgrading to openoffice.org 2.0.1-143.2.1 (from the 1.9.x release included
in FC4), random crashes occur frequently.
For example, selecting in firefox to open this link with OOo makes it crash
It looks like bug #171873, I thought that's fixed.
I'll attach OOo crash report.
Created attachment 122618 [details]
ooo crash report
I have a testing 2.0.1-1-2.1 in the fc4 testing repositry, doesn't crash for me
in that version. I'll push it final soon.
try in fc4 update 18.104.22.168-4.1
Still happens with 22.214.171.124-4.1. Attaching crash report. This time happened again
on a powerpoint file with macros disabled, but I cannot reproduce it.
Created attachment 122938 [details]
ooo 2nd crash report
It also happened on a plain no-macros Excel file
Created attachment 122950 [details]
Another oocalc crash report
Also seeing frequent random crashes in oocalc (again) particularly since the
last update to openoffice.org-calc-126.96.36.199-4.1.i386. The previous version
didn't seem as bad.
This happens ~40% of the times when OOo is started. It also happened during
regular work (no file-related operations) on Draw. Increasing severity.
Caolan, what more info could we provide to help fix this?
Created attachment 122993 [details]
Crash dump number 4
Crashed in oowriter this time after a short period (~10 mins) of use. I've now
uninstalled openoffice 188.8.131.52-4.1 and reinstalled 2.0.1-143.2.1 which I don't
believe has crashed on me yet.
It crashes very often on a new drawing with an ellipse, when you open it or try
to edit the text inside the ellipse (try to replicate with this)
Created attachment 123033 [details]
Crash dump from loading logohelp.rtf
I have encountered a crash with a similar stack trace. It happens about 40% of
the time when I execute "oowriter logohelp.rtf". logohelp.rtf is a rich-text
file that was generated by DocBook. This has happened to me about 10 times.
Here are my openoffice package versions:
I was asked to attach my comment below to this bug, which I first submitted to
bug 168404. I added some more details.
I do frequenctly get oo crash dumps when starting office. But not always and it
cannot be reproduced 100%. Crashes (so far) happend only when starting
openoffice, never when opening additional files.
The problem started when openoffice moved to java (with 2.0beta?). NFS is not
used for any relevant files; all file systems are ext3. The error seems to
show up more easily when starting from the command line with some argument (file
name to open). The crash doesn't happen randomly: when it fails to load, it
continues to fail many times, until it suddenly works again (sometimes a
file recovery dialog starts; once even for an empty document 'Untitled1'). The
shows up during work, so it is limited to the initialization phase. I'm using
fedore core 4 which was upgraded from fedora core 2 (which was the first os).
Architecture: I have it running on i686, athon xp, x86_64 and find get this
error occationally on all three (all have a different upgrade history and
run fc4 now). The x86_64 box is running a i386 package (don't know if there
is a native x86_64 version). I do not see any difference in system status
between these events, nor do I think it is hardware related. BESIDES THIS
LITTLE PROBLEM ITS GREAT SOFTWARE!
I get the following crash report from oo:
Video Driver is probably nv
DESKTOP_SESSION is set to default
libgcj version is libgcj-4.0.2-8.fc4
OpenOffice.org core rpm version is openoffice.org-core-184.108.40.206-4.1
0x4f0007: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e007
0x4f07cc: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e7cc
0x1da420: + 0x420 (__kernel_sigreturn + 0x0)
0x7b0888: /lib/libc.so.6 + 0x29888 (abort + 0xf8)
0xbaa41e: /usr/lib/libstdc++.so.6 + 0xad41e
(__gnu_cxx::__verbose_terminate_handler() + 0x16e)
0xba8115: /usr/lib/libstdc++.so.6 + 0xab115
0xba814a: /usr/lib/libstdc++.so.6 + 0xab14a
0xba827e: /usr/lib/libstdc++.so.6 + 0xab27e (__cxa_rethrow + 0x0)
0x489f5a: /usr/lib/openoffice.org2.0/program/libucbhelper3gcc3.so + 0x1cf5a
0x48cbba: /usr/lib/openoffice.org2.0/program/libucbhelper3gcc3.so + 0x1fbba
0x48dba6: /usr/lib/openoffice.org2.0/program/libucbhelper3gcc3.so + 0x20ba6
0x1bff839: /usr/lib/openoffice.org2.0/program/fsstorage.uno.so + 0x5839
0x46c2946: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xfe946
0x46c3ea7: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xffea7
0x46a62c1: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xe22c1
0xa714ac: /usr/lib/openoffice.org2.0/program/libuno_cppuhelpergcc3.so.3 + 0x274ac
0xa715f4: /usr/lib/openoffice.org2.0/program/libuno_cppuhelpergcc3.so.3 + 0x275f4
0xa727fc: /usr/lib/openoffice.org2.0/program/libuno_cppuhelpergcc3.so.3 + 0x287fc
0x12f23c0: /usr/lib/openoffice.org2.0/program/servicemgr.uno.so + 0x73c0
0x12f1862: /usr/lib/openoffice.org2.0/program/servicemgr.uno.so + 0x6862
0x46a4166: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xe0166
0x46ad781: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xe9781
0x4688a48: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xc4a48
0x465eaca: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0x9aaca
0x4671765: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xad765
0x3f361bb: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1391bb
0x3f7d507: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x180507
0x3fab9b0: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1ae9b0
0x3facfbb: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1affbb
0x3ebc3f1: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0xbf3f1
(SfxApplication::SetViewFrame(SfxViewFrame*) + 0x239)
0x3f900da: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1930da
0x3f9d7dd: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1a07dd
(SfxTopFrame::InsertDocument(SfxObjectShell*) + 0x831)
0x3eac5d9: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0xaf5d9
0x3f80105: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x183105
0x46b2723: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xee723
0x46b2f15: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xeef15
0x46b34da: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0xef4da
0x4602ca5: /usr/lib/openoffice.org2.0/program/libfwk680li.so + 0x3eca5
0x52385c1: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x385c1
_STL::allocator<desktop::DispatchWatcher::DispatchRequest> > const&) + 0x1027)
0x52316ff: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x316ff
0x52212f1: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x212f1
(desktop::Desktop::OpenDefault() + 0x271)
0x5225fc9: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x25fc9
(desktop::Desktop::OpenClients() + 0xec1)
0x522600d: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x2600d
(desktop::Desktop::OpenClients_Impl(void*) + 0x33)
0x5226064: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x26064
(desktop::Desktop::LinkStubOpenClients_Impl(void*, void*) + 0x1a)
0x2ffdc64: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x83c64
0x31572de: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x1dd2de
0x1fafefe: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x1eefe
0x1fd6208: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x45208
(SalDisplay::DispatchInternalEvent() + 0xb0)
0xe18e2d: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x1ae2d
0x21cb730: /usr/lib/libglib-2.0.so.0 + 0x25730
0x21c94ce: /usr/lib/libglib-2.0.so.0 + 0x234ce (g_main_context_dispatch + 0x1dc)
0x21cc4d6: /usr/lib/libglib-2.0.so.0 + 0x264d6
0x21cc9b8: /usr/lib/libglib-2.0.so.0 + 0x269b8 (g_main_context_iteration + 0x66)
0xe18a53: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x1aa53
0x1fd7412: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x46412
(X11SalInstance::Yield(unsigned char) + 0x28)
0x3003ef8: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x89ef8
(Application::Yield() + 0x48)
0x3003f2e: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x89f2e
(Application::Execute() + 0x26)
0x5228fea: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x28fea
(desktop::Desktop::Main() + 0x15c6)
0x3009473: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8f473
0x3009523: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8f523 (SVMain()
0x5220a37: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x20a37 (sal_main
0x5220a83: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x20a83 (main + 0x27)
0x79bd5f: /lib/libc.so.6 + 0x14d5f (__libc_start_main + 0xdf)
0x80484e1: /usr/lib/openoffice.org2.0/program/swriter.bin + 0x4e1
This is something of a dogs dinner of a bug now, those a 4 different stack
caolanm->David: Comment #11: You sound like you have a reproducable .rtf which,
when loaded causes OOo to crash. Can you open a separate bug about that problem
with the rtf attached to it. That's almost certainly a different problem to the
rest of this anyway, and I can handle that one as a discrete issue
Pleased to say I've not had a crash since going back to 2.0.1-143.2.1 a couple
of days ago and I think by now that's more than luck.
perhaps the gcc bugfix needs to be revisited somewhat, e.g. rebuild with
removing the -mtune=pentium4 RPM_OPT_FLAG
how about with 220.127.116.11-5.1 for fc4 updates ?
Created attachment 123366 [details]
openoffice crash output
Still crashes for me.
A thought, there's a possibility that this is DRI permissions related somehow.
a) run glxgears, any crash or warning output ?
b) attach your /etc/X11/xorg.conf here as well
c) strace -f /usr/lib/openoffice.org2.0/program/soffice.bin -writer >& /tmp/log
and attach that /tmp/log
this might be like these bugs
a) no crash/warnings for me
b) will attach
c) I can't, as I moved to upstream OOo a few days ago (too many crashes).
Upstream doesn't crash. I will go back to Fedora's ooo on FC5. Peter?
Created attachment 123373 [details]
still get the crash with the new version
a) running glxgears: no crash only framerate reported.
b) will attach
c) very strange: I do not get the crash when running with strace. I tried
*many* times, but of course, this may just be bad luck.
When running it with:
I do sometimes get a crash with the message: "sh: crash_report: command
not found" and the program quitts without showing the crash report window.
When running it using the (kde) panel button, it seems to crash more often.
Finally, I tried also many times like this:
strace -f /usr/lib/openoffice.org2.0/program/soffice.bin "" >& /dev/null
strace -o /tmp/log -f /usr/lib/openoffice.org2.0/program/soffice.bin -writer
But it didn't crash this way.
Created attachment 123381 [details]
I've been running with 18.104.22.168-5.1 in and out of writer and calc all morning
and it hasn't crashed yet - I reckon it's definately worth sticking with the -
mtune option for now. For info., I think openoffice issue reports 60461 and
60599 are all pointing to the same problem.
Created attachment 123442 [details]
OpenOffice.org crash report
Comment on attachment 123442 [details]
OpenOffice.org crash report
> I have encountered a crash with a similar stack trace.
I also have random crahes in writer and calc, with no clear reason. Very
similar trace, I try to attach it here. FC4 with
Someone wrote here that "upstream" version does not crash. From testing I
suppose? That means "openoffice.org-base-22.214.171.124-5.2.i386.rpm". I'll give it a
try. This is quite annoying bug..
ok, messy bug
1. Peter's bug is on startup with "(ucb::Content::Content(rtl::OUString const&,"
in the stack, and is thus bug 168404, that's a discrete problem of its own.
Which I suspect is somehow DRI or permissions related.
2. David's bug is almost certainly a gcc bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199 and worked around in 2.0.1-5.1
3. Jonathan's bug is probably the same root cause as David's bug.
4. Marius's bug troubles me as it doesn't look like that gcc bug but I can't
reproduce it :-(
So I'll follow up on the Content::Content crash on startup problem with bug
168404. Given the gcc bug worked around in 2.0.1-5.1 any stacktraces pointing to
a OOo problem in < 2.0.1-5.1 have to be viewed with deep suspicion, so I'm going
to close this bug as WORKSFORME for 2.0.1-5.1. If anyone gets another crash with
2.0.1-5.1 which doesn't contain ucb::Content::Content in the stack trace then
open a new bug.