Bug 168404

*** Bug 168408 has been marked as a duplicate of this bug. ***

*** Bug 167686 has been marked as a duplicate of this bug. ***

it'd be great if you could 

yum install openoffice.org-debuginfo

and launch ooo again to get a more detailed stack report, it is a huge package
though

anything slightly different about your setup, home dirs on nfs ? or anything
like that.

another possibility is to 

> tar cvzf ~/userconfig.tar.gz ~/.openoffice* 

and attach that tar.gz to this issue to see if there is something in the config
which causes this

Ok, I'm installing the debuginfo now.  I'll post the results later today. 
Nothing is irregular about the setup, that I can tell.  In fact, I've blown away
the ~/.openoffice* directories and can still reproduct the error.

Here's the updated backtrace using the debuginfo:

#0  0x008d5402 in __kernel_vsyscall ()
#1  0x00798118 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#2  0x00799888 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#3  0x005bfd18 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#4  0x005bda31 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#5  0x005bda66 in std::terminate () from /usr/lib/libstdc++.so.6
#6  0x005bdbf4 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#7  0x005bfce9 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#8  0x005bda31 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6
#9  0x005bda66 in std::terminate () from /usr/lib/libstdc++.so.6
#10 0x005bdb9a in __cxa_throw () from /usr/lib/libstdc++.so.6
#11 0x059fab03 in gcc3::raiseException (pUnoExc=0xbf896930,
    pUno2Cpp=0x377a364)
    at
/usr/src/debug/SRC680_m125/bridges/source/cpp_uno/gcc3_linux_intel/except.cxx:308
#12 0x059fc8ab in (anonymous namespace)::cpp2uno_call (pThis=0x377a758,
    pMemberTypeDescr=0x377a9e8, pReturnTypeRef=0x3350ab8, nParams=1,
    pParams=0x377a610, pCallStack=0xbf8969e4, pReturnValue=0x0)
    at
/usr/src/debug/SRC680_m125/bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx:216
#13 0x059fcc32 in cpp_vtable_call (nFunctionIndex=3, nVtableOffset=0,
    pCallStack=0xbf8969e4, pReturnValue=0x0)
    at
/usr/src/debug/SRC680_m125/bridges/source/cpp_uno/gcc3_linux_intel/cpp2uno.cxx:371
#14 0x059fd6be in privateSnippetExecutorVoid ()
    at
/usr/src/debug/SRC680_m125/solver/680/unxlngi6.pro/inc/stl/stl/_algobase.h:326
#15 0x00905512 in cppu::throwException (exc=@0xbf896a50)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/exc_thrower.cxx:266
#16 0x004d2860 in ucbhelper::cancelCommandExecution (
    eError=com::sun::star::ucb::IOErrorCode_NOT_EXISTING,
    rArgs=@0xbf896b84, xEnv=@0xbf896c74, rMessage=@0xbf896b80,
    xContext=@0xbf896b7c)
    at
/usr/src/debug/SRC680_m125/ucbhelper/source/provider/cancelcommandexecution.cxx:251
#17 0x0156f57e in fileaccess::throw_handler (pShell=0x7104b10,
    errorCode=16, minorCode=2, xEnv=@0xbf896c74, aUncPath=@0x1c4aa84,
    pContent=0x1c4aa40, isHandled=true)
    at /usr/src/debug/SRC680_m125/ucb/source/ucp/file/filglob.cxx:537
#18 0x015615d6 in fileaccess::TaskManager::endTask (this=0x7104bac,
    pShell=0x7104b10, CommandId=1, aUncPath=@0x1c4aa84, pContent=0x1c4aa40)
    at /usr/src/debug/SRC680_m125/ucb/source/ucp/file/filtask.cxx:139
#19 0x0154dfc5 in fileaccess::BaseContent::endTask (this=0x0, CommandId=1)
    at /usr/src/debug/SRC680_m125/ucb/source/ucp/file/bc.cxx:1382
#20 0x01550d73 in fileaccess::BaseContent::execute (this=0x1c4aa40,
    aCommand=@0xbf896d60, CommandId=1, Environment=@0x1c50c98)
    at /usr/src/debug/SRC680_m125/ucb/source/ucp/file/bc.cxx:519
#21 0x004a877c in ucb::Content_Impl::executeCommand (this=0x1c50c80,
    rCommand=@0xbf896d60)
    at /usr/src/debug/SRC680_m125/ucbhelper/source/client/content.cxx:1864
#22 0x004a96b7 in ucb::Content::executeCommand (this=0x0,
    rCommandName=@0xbf896f9c, rCommandArgument=@0xbf896fa4)
    at /usr/src/debug/SRC680_m125/ucbhelper/source/client/content.cxx:935
#23 0x0045c0ab in UCBOpenContentSync (xLockBytes=@0xbf89700c,
    xContent=@0xbf897008, rArg=@0xbf896f9c, xSink=@0xbf897000,
    xInteract=@0xbf896ffc, xProgress=@0xbf896ff8, xHandler=@0xbf896ff4)
    at /usr/src/debug/SRC680_m125/unotools/source/ucbhelper/ucblockbytes.cxx:1301
#24 0x0045d7bc in utl::UcbLockBytes::CreateLockBytes (xContent=@0xbf89714c,
    rProps=@0xbf897148, eOpenMode=261, xInteractionHandler=@0xbf897178,
    pHandler=0x0)
    at /usr/src/debug/SRC680_m125/unotools/source/ucbhelper/ucblockbytes.cxx:1852
#25 0x00466b4c in lcl_CreateStream (rFileName=@0xbf897284, eOpenMode=261,
    xInteractionHandler=@0xbf897178, pHandler=0x0, bForceSynchron=1 '\001',
    bEnsureFileExists=1 '\001')
    at /usr/src/debug/SRC680_m125/unotools/source/ucbhelper/ucbstreamhelper.cxx:168
#26 0x00466ded in utl::UcbStreamHelper::CreateStream (
    rFileName=@0xbf897284, eOpenMode=261, pHandler=0x0,
    bForceSynchron=1 '\001')
    at /usr/src/debug/SRC680_m125/unotools/source/ucbhelper/ucbstreamhelper.cxx:198
#27 0x02ac2744 in SfxApplication::GetDisabledSlotList_Impl (this=0x4e0a568)
    at /usr/src/debug/SRC680_m125/sfx2/source/appl/appmisc.cxx:430
#28 0x02bb6374 in SfxDispatcher::Construct_Impl (this=0x70fb3d0,
    pParent=0x0)
    at /usr/src/debug/SRC680_m125/sfx2/source/control/dispatch.cxx:440
#29 0x02bb64e7 in SfxDispatcher (this=0x70fb3d0, pParent=0x0)
    at /usr/src/debug/SRC680_m125/sfx2/source/control/dispatch.cxx:461
#30 0x02abfe51 in SfxApplication::Initialize_Impl (this=0x4e0a568)
    at /usr/src/debug/SRC680_m125/sfx2/source/appl/appinit.cxx:330
#31 0x02accafd in SfxApplication::SetApp (pSfxApp=0x4e0a568)
    at /usr/src/debug/SRC680_m125/sfx2/source/appl/app.cxx:433
#32 0x02acce16 in SfxApplication::GetOrCreate ()
    at /usr/src/debug/SRC680_m125/sfx2/source/appl/app.cxx:397
#33 0x02aa999e in SfxGetpApp () at ../../inc/app.hxx:702
#34 0x02bced31 in SfxGlobalEvents_Impl (this=0x2e67438, xSMGR=@0xbf897728)
    at /usr/src/debug/SRC680_m125/sfx2/source/notify/eventsupplier.cxx:660
#35 0x02bceea5 in SfxGlobalEvents_Impl::impl_createInstance (
    xServiceManager=@0xbf897728)
    at /usr/src/debug/SRC680_m125/sfx2/source/notify/eventsupplier.cxx:649
#36 0x0091694f in cppu::OSingleFactoryHelper::createInstanceEveryTime (
    this=0x71096d4, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:232
#37 0x0091620b in cppu::OSingleFactoryHelper::createInstanceWithContext (
    this=0x0, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:264
#38 0x00916272 in cppu::OFactoryComponentHelper::createInstanceWithContext (
    this=0x71096a0, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:536
#39 0x00917d1f in cppu::ORegistryFactoryHelper::createInstanceEveryTime (
    this=0x4e09b38, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:802
#40 0x0091620b in cppu::OSingleFactoryHelper::createInstanceWithContext (
    this=0x0, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:264
#41 0x009162c3 in cppu::OFactoryComponentHelper::createInstanceWithContext (
    this=0x4e09b38, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/cppuhelper/source/factory.cxx:540
#42 0x0148f515 in stoc_smgr::OServiceManager::createInstanceWithContext (
    this=0x3351440, rServiceSpecifier=@0xbf897a34, xContext=@0x335148c)
    at /usr/src/debug/SRC680_m125/stoc/source/servicemanager/servicemanager.cxx:1330
#43 0x0148bee7 in stoc_smgr::OServiceManager::createInstance (this=0x6,
    rServiceSpecifier=@0xbf897a34)
    at /usr/src/debug/SRC680_m125/stoc/source/servicemanager/servicemanager.cxx:1436
#44 0x00e829d7 in desktop::Desktop::Main (this=0xbf897ad8)
    at /usr/src/debug/SRC680_m125/desktop/source/app/app.cxx:1413
#45 0x00196b41 in SVMain ()
    at /usr/src/debug/SRC680_m125/vcl/source/app/svmain.cxx:267
#46 0x00e7e6c7 in sal_main (argc=1, argv=0xbf897ba4)
    at /usr/src/debug/SRC680_m125/desktop/source/app/main.cxx:103
#47 0x00784d5f in __libc_start_main (main=0x8048474, argc=1,
    ubp_av=0xbf897ba4, init=0x8048548 <__libc_csu_init>,
    fini=0x8048598 <__libc_csu_fini>, rtld_fini=0x7601ad <_dl_fini>,
    stack_end=0xbf897b9c) at ../sysdeps/generic/libc-start.c:216
#48 0x080484c5 in _start ()

Created attachment 118915 [details]
all openoffice config files in home directory

Here's the contents of the ~/.openoffice.org2.0 directory just following the
last stacktrace.

that stacktrace says that OOo attempt to open
~/.openoffice.org2.0/user/config/slots.cfg, finds it doesn't exist (which is
normal) throws an exception, which blows up OOo. What should happen is that the
exception gets thrown, gets caught and the open fails normally and OOo continues
to execute. That exception is probably the first one during execution, i.e.
generic exception problem of some kind, rather that specific to the slots.cfg code.

what platform was this btw, normal i386 , x86_64 ? ppc ?

This is on an i386 system.

Is there any other information I can provide to help move this forward?

the backtrace and so forth show where the problem is occuring, except there is
no way that should cause a crash, 

I really suspect there's a miscompilation problem or something *very* odd going
on which isn't directly attributable to OOo. I hope to have a FC4 update within
the week which will hopefully clear this problem by vitue of being compiled with
latest gcc update

tentatively blamed on gcc, might go away on pending rebuild

How pending is this rebuild?  I haven't seen any updates with yum.

maybe this is the same error I reportet as bug 166434

It's not fixed. It still crashes after the splash screen.

The output is:

0x5feb8a: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1db8a
0x5ff3d8: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e3d8
0xffffe500:  + 0x500 (__kernel_sigreturn + 0x0)

Updated to version 2.0.0-3.2.1.  Removed existing ~/.openoffice.org2.0
directory.  Still crashing for me as well.  The only difference is that it
appears to be crashing faster than it did previously.

Currently downloading openoffice.org-debuginfo-2.0.0-3.2.1.  Expect to have a
stacktrace posted later today.

Created attachment 120514 [details]
stacktrace for version 2.0.0-3.2.1

Stacktrace attached.  It appears to be identical to the previous stacktrace.

Is your home dir an nfs mount, or any type of non ext2/ext3 local filesystem ?

the stacktrace is most odd, it says that a file being searched for does not
exist, which is true. So a "not found" exception is being thrown, which is ok.
But terminate is being called, rather than the exception getting progated to the
appropiate catch. I think all the interim code is compiled with exceptions
enabled and -fno-enforce-eh-specs is enabled. So it shouldn't go into the
terminate rabbit hole

I installed a clean fc4 machine and installed all the updates, and I'm still not
seeing this crash.

core, calc, graphicfilter, math, xsltfilter, writer, impress and draw 
2.0.0-3.2.1 installed.

run from terminal as "oowriter"

Might have been related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25199.
2.0.1-143.2.1 is out today, does this affect this problem ?

2.0.1-143.2.1 segfaults on my FC4 x86_64 from the start. It works fine on my
i686 FC4 box

because I had to finish my presentation I installed last night's rawhide on the
x86_64 laptop. I was happy to see that 2.0.1-143.2.1 works fine in it :)

I now get the following error during startup with openoffice.org version 
2.0.1-143.2.1:

terminate called after throwing an instance of
'com::sun::star::configuration::InvalidBootstrapFileException'
terminate called recursively
/usr/lib/openoffice.org2.0/program/soffice: line 156:  8997 Aborted    
"$sd_prog/$sd_binary" "$@"

I do frequenctly get this error. But not always and it cannot be
reproduced 100%. 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. The bug never
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-2.0.1.1-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
(ucb::Content::Content(rtl::OUString const&,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&)
+ 0x50)
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
(desktop::DispatchWatcher::executeDispatchRequests(_STL::vector<desktop::DispatchWatcher::DispatchRequest,
_STL::allocator<desktop::DispatchWatcher::DispatchRequest> > const&) + 0x1027)
0x52316ff: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x316ff
(desktop::OfficeIPCThread::ExecuteCmdLineRequests(desktop::ProcessDocumentsRequest&)
+ 0x129)
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()
+ 0x29)
0x5220a37: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x20a37 (sal_main
+ 0x57)
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

Peter, your report sounds like bug #176664, perhaps you could attach it there?

(In reply to comment #29)
> Peter, your report sounds like bug #176664, perhaps you could attach it there?

OK, I will attach it there, however, I think it is not THAT bug, since for
me it never crashed during work (perhaps I'm not using enough features). Also,
seeing the comments here, I speculate that there is a problem with the java
backend (this kind of crash didn't happen before this change). Like in C++, when
 there is a memory problem in the constructor.

gcj shouldn't enter into affairs until something that uses java gets called,
e.g. the wizards and some other functionality. Almost certainly not just during
basic startup.

caolanm->peter: how many processors do you have ? Maybe we have a threading
issue not seen on my little 1 proc box. /usr/bin/getconf _NPROCESSORS_ONLN

I'm mostly using a single CPU PC (pentium without hyperthreading). The x86_64
was only mentioned, because I got the crash there too. But I cannot reproduce it
right now (on the 2 cpu x86_64 beast with 6 Gig Memory). 
The athlon is single core (32-bit anyway). I wrote about this, because some
comments seem to indicate architecture dependency (perhaps some of these bugs
are, I don't know). On the pentium, where I use oo mostly, it crashes randomly
at startup. Perhaps it is an upgrade issue? Some left over library from earlier
installs? Just guessing because of comment #23. All my machines have some
pre-fc4 history. Is there a stack safeguard in openoffice? Can it be build it?
Perhaps
this would help.

well re comment 23 you can try 

rpm --erase `rpm -qf /usr/lib/openoffice.org2.0 | xargs`

and see if there is anything left in /usr/lib/openoffice.org2.0

if there is, let me know what the contents are, perhaps tar them up and attach
if so. remove the directory totally and re-install

(In reply to comment #33)

I did right away and /usr/lib/openoffice.org2.0 is gone after removing
it this way. I noticed /usr/lib/openoffice.org1.9.104/share/readme existed
(an empty directory; I removed the *1.9.104 now as well (have a tar 
copy just in case - no hidden dot files either)
Reinstalled it, and running openoffice again and again I got the known random
error pattern. Nice try...

> well re comment 23 you can try 
> 
> rpm --erase `rpm -qf /usr/lib/openoffice.org2.0 | xargs`
> 
> and see if there is anything left in /usr/lib/openoffice.org2.0
> 
> if there is, let me know what the contents are, perhaps tar them up and attach
> if so. remove the directory totally and re-install

how about with 2.0.1.1-5.1 for fc4 updates ? 

(where RPM_OPT_FLAGS mtune is ignored in favour of -mpentiumpro)

for reference, similiar bugs are...

http://seclists.org/lists/linux-kernel/2005/Jan/8830.html
http://bugzilla.ximian.com/show_bug.cgi?id=48346
http://lists.debian.org/debian-openoffice/2005/11/msg00108.html

debugging help...

a) from a terminal export SAL_NOOPENGL=true and run oowriter, any difference ?
a) run glxgears, any crash or warning output ?
c) strace -f /usr/lib/openoffice.org2.0/program/soffice.bin -writer > /tmp/log 2>&1
and attach that log

Attempted to launch oowriter using version 2.0.1.1-5.1 on FC4.  I received the
following error on the terminal and no splash screen appeared:

terminate called after throwing an instance of
'com::sun::star::configuration::InvalidBootstrapFileException'
terminate called recursively
/usr/lib/openoffice.org2.0/program/soffice: line 156:  2201 Aborted    
"$sd_prog/$sd_binary" "$@"

Created attachment 123647 [details]
strace output using version 2.0.1.1-5.1 on FC4

Output from strace attached.  Setting SAL_NOOPENGL=true had no effect.	Running
glxgears went smoothly, with no errors or warnings.

Created attachment 123657 [details]
successful strace for comparison

I am very confused by this bug, the comments are not making any sense - seems
like they cover 10 different bugs. I want to confirm that I see a very similar
trace as in comment #7 - what's the status of that? 

This is on Athlon x86_64. I just finished upgrading from i386 -> x86_64 (very
dumb idea, significant pain to make it work). This is a rawhide system that's
fully up to date. 

Openoffice crashes on startup every time, so this is reproducible.
openoffice.org-core-2.0.1.1-8.2.

I can attach traces, and any other information required, but I don't know if you
need anything, or the problem is already known and being fixed? It's a similar
trace to #7.

The status is that the reason for this is unknown, it doesn't happen for me, or
for the majority of users, but it does happen reliably and consistently for
those that do get it. 

What is the output of /usr/sbin/sestatus ?

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          enforcing
Policy version:                 20
Policy from config file:        targeted

I can report that oowriter starts just fine through valgrind, however...
(although valgrind prints quite a lot of errors, let me know if you're
interested...)

Race condition? I read something about a threading issue with rebuild-gcj-db
earlier today, that was possibly caused by the kernel...

Created attachment 124037 [details]
replacement library

Lets try this replacement library, *only* if you are suffering from this
problem, and are on ix86 or x86_64.

cp /usr/lib/openoffice.org2.0/program/libgcc3_uno.so /tmp
cp the attachment to /usr/lib/openoffice.org2.0/program/libgcc3_uno.so
and restart oowriter from a terminal, if it still fails attach the output on
the terminal

Created attachment 124038 [details]
Crash output with modified libgcc3_uno.so

(In reply to comment #44)

I did it and noticed:
 - it runs rather slow (but still reasonable)
 - it still crashes randomly (as it used to)

If it does not crash, the output is:
PAGESIZE is 4096
mapping b5571000
createBlock of b5571000
making b5571000 executable
unmapping b5571000

The output for a crash is attached.

Created attachment 124039 [details]
update slightly

one more run with this attachment

Created attachment 124041 [details]
Crash output with modified libgcc3_uno.so (version 2)

again with the second version of libgcc3_uno.so.

Crash log attached, without crash I get:

PAGESIZE is 4096
mapping b54aa000
createBlock of b54aa000
before making b54aa000 executable
after making b54aa000 executable
unmapping b54aa000

(In reply to comment #44)
> Created an attachment (id=124037) [edit]
> replacement library
> 
> Lets try this replacement library, *only* if you are suffering from this
> problem, and are on ix86 or x86_64.
> 
> cp /usr/lib/openoffice.org2.0/program/libgcc3_uno.so /tmp
> cp the attachment to /usr/lib/openoffice.org2.0/program/libgcc3_uno.so
> and restart oowriter from a terminal, if it still fails attach the output on
> the terminal
> 

I've tried this workaround and it worked for me !
I'm using openoffice.org-core.i386 1:2.0.1.1-9.2 on FC5 test2 with last updates
applied ...

*** This bug has been marked as a duplicate of 179519 ***