Bug 153674 - OOo fails at startup
Summary: OOo fails at startup
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: powerpc
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Depends On: 151955
Blocks: fedora-ppc
TreeView+ depends on / blocked
Reported: 2005-04-04 21:30 UTC by David Woodhouse
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-07 21:00:27 UTC
Type: ---

Attachments (Terms of Use)

Description David Woodhouse 2005-04-04 21:30:20 UTC
OOo fails at startup on PPC. This has happened since about 1.1.87-1 IIRC, which
had other problems (no suitable windowing system found).

$ oowriter
terminate called after throwing an instance of
/usr/lib/openoffice.org1.9.89/program/soffice: line 237:  5082 Aborted       
"$sd_prog/$sd_binary" "$@"

Breakpoint 2, 0x0e8482cc in std::terminate () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x0e8482cc in std::terminate () from /usr/lib/libstdc++.so.6
#1  0x0e8484c4 in __cxa_throw () from /usr/lib/libstdc++.so.6
#2  0x0f0dd0c8 in cppu::WeakAggComponentImplHelper_getTypes ()
   from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3
#3  0x0f0dd3f8 in cppu::WeakComponentImplHelper_query ()
   from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3
#4  0x0d7afa94 in
com::sun::star::lang::XInitialization>::queryInterface () from
#5  0x0d930cbc in stoc_tdmgr::ManagerImpl::insert ()
   from /usr/lib/openoffice.org1.9.89/program/typemgr.uno.so
#6  0x0f0d3840 in cppu::bootstrapInitialContext ()
   from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3
#7  0x0f0d80b0 in cppu::get_unorc ()
   from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3
#8  0x0f0d88a8 in cppu::defaultBootstrap_InitialComponentContext ()
   from /usr/lib/openoffice.org1.9.89/program/libuno_cppuhelpergcc3.so.3
#9  0x100337b8 in desktop::CommandLineArgs::ParseCommandLine_Impl ()
#10 0x10033cc8 in desktop::CommandLineArgs::CommandLineArgs ()
#11 0x1001afc8 in desktop::Desktop::GetCommandLineArgs ()
#12 0x1002e9b0 in desktop::Desktop::CreateApplicationServiceManager ()
#13 0x1001b44c in desktop::Desktop::Init ()
---Type <return> to continue, or q <return> to quit---
#14 0x0fd078cc in InitVCL ()
   from /usr/lib/openoffice.org1.9.89/program/libvcl680lp.so
#15 0x0fd07fc8 in SVMain ()
   from /usr/lib/openoffice.org1.9.89/program/libvcl680lp.so
#16 0x1001a89c in sal_main ()
#17 0x1001a930 in main ()

Comment 1 David Woodhouse 2005-04-04 21:35:00 UTC
The openoffice.org-debuginfo package is tiny. I assume it isn't functional so
didn't bother to install it. Am rebuilding for myself to get debugging info.

Comment 2 David Woodhouse 2005-04-05 13:00:53 UTC
This is probably a manifestation of bug #151955, and even if it isn't there's
little point in investigating until #151955 is fixed. 

Comment 3 Caolan McNamara 2005-04-05 13:12:31 UTC
Ack!, that would do it and totally destroy all the uno->c++ bridging. 

Comment 4 Caolan McNamara 2005-04-06 15:44:25 UTC
1.9.89-4 rebuilt with gcc 4.0.0-40 in fc4-HEAD. Does it work under ppc ?

Comment 5 David Woodhouse 2005-04-06 16:59:24 UTC
No. I see precisely the same failure mode.

Comment 6 David Woodhouse 2005-04-06 17:35:35 UTC
The exception seems to be raised from __queryDeepNoXInterface() in

Adding extra debugging shows:

cannot get type description for type "com.sun.star.lang.XServiceInfo"!

Comment 7 Caolan McNamara 2005-04-06 17:46:16 UTC
This is all deep in the arch/compiler specific uno bridging stuff walking
vtables I think. Seeing as OOo *did* work under ppc, something has changed. 

caolanm->jakub: I'm bewildered, any ideas ?

Comment 8 David Woodhouse 2005-04-06 20:41:14 UTC
If I understood aph correctly yesterday, the other thing that changed in this
timeframe is that we now compile everything to native code _during_ the build
process, rather than using gij throughout. Is it feasible to revert that change
to see if it helps?

Comment 9 Caolan McNamara 2005-04-07 08:09:31 UTC
Nah, if you're referring to the java components the only bits that are compiled
with native code in this rpm are the bits used during buildtime.

Comment 10 David Woodhouse 2005-04-07 08:24:42 UTC
I was trying to provoke aph into elaborating on precisely what he meant rather
than merely making do with my garbled rendition of it :)

Comment 12 David Woodhouse 2005-04-07 09:48:39 UTC
To recap:
1.9.85-1 works.
1.9.87-1 fails with a different problem (no suitable windowing system found).
1.9.87-2 has this problem.

Looking at the dates of gcc and OOo builds, it looks like the compilers used were:

1.9.85-1: gcc 4.0.0-34
1.9.87-1: gcc 4.0.0-35
1.9.87-2: gcc 4.0.0-35

Comment 13 Andrew Haley 2005-04-07 09:53:25 UTC
OK, so we need to see the patches applied to OOo between those releases.

I'll look at the gcc changes between -34 and -35.

Comment 14 David Woodhouse 2005-04-07 09:56:04 UTC
I'll set gcc-4.0.0-40 building 1.9.85-1 too, in case it sheds any light on the
matter (and because it's cold in here today so the extra heat will be nice :)

Comment 15 Caolan McNamara 2005-04-07 10:04:31 UTC
No suitable windowing system sounds like the missing 32bit startup-notification
under 64bit platforms and so should not be relevent (fixed in 1.9.89-4)

OOo makes extensive use of namespaces under C++ as well as java

I doubt that its a change to OOo that has caused this, though it's not impossible.

Comment 16 Caolan McNamara 2005-04-07 12:16:55 UTC
cvs diff -rSRC680_m85 -rSRC680_m87 solenv/inc/unxlngppc4.mk

Index: unxlngppc4.mk
RCS file: /cvs/tools/solenv/inc/unxlngppc4.mk,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- unxlngppc4.mk       24 Feb 2005 14:43:41 -0000      1.14
+++ unxlngppc4.mk       15 Mar 2005 09:57:17 -0000      1.15
@@ -150,9 +150,14 @@
 DYNAMIC                = -Wl,-Bdynamic

 # name of linker
 # default linker flags

 # linker flags for linking applications
 LINKFLAGSAPPGUI= -Wl,-export-dynamic -Wl,--noinhibit-exec

where adding -Wl,-export-dynamic to the link flags is a ppc specific change in
the relevent timeframe.

Comment 17 David Woodhouse 2005-04-07 12:23:26 UTC
Building a version with this patch now to make it match i386 and see if it helps...


Comment 23 David Woodhouse 2005-04-07 20:59:07 UTC
It fails on my shinybook with its puny 1GiB of RAM:

cc1plus: out of memory allocating 1643995136 bytes after a total of 94982144 bytes

The same file does compile fairly quickly with gcc 3.4 if you just comment out
the calls to __builtin_powi{f,l,}. 

Comment 25 David Woodhouse 2005-04-07 21:00:27 UTC
openoffice.org-core-1.9.89-5 works fine. Thanks.

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