Bug 236899 - OpenOffice.org doesn't start due to an XError on nvidia_drv.so
Summary: OpenOffice.org doesn't start due to an XError on nvidia_drv.so
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org   
(Show other bugs)
Version: 6
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Keywords: Desktop
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-18 11:24 UTC by Haakon Riiser
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version: NVIDIA driver 1.0-9755
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-27 11:14:51 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from ldd (4.83 KB, text/plain)
2007-04-18 12:09 UTC, Haakon Riiser
no flags Details
Output from strace (285.64 KB, text/plain)
2007-04-18 12:10 UTC, Haakon Riiser
no flags Details
Single thread backtrace (3.59 KB, text/plain)
2007-04-25 10:23 UTC, Haakon Riiser
no flags Details
Multi thread backtrace (5.70 KB, text/plain)
2007-04-25 10:25 UTC, Haakon Riiser
no flags Details

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

Description Haakon Riiser 2007-04-18 11:24:56 UTC
After installing FC6 (clean install, not an upgrade), I am unable
to run OpenOffice.  When running soffice, no error message is displayed
and not even an error code is returned to the shell.  To find out what
was happening, I tried running the soffice script with tracing enabled
(sh -x soffice).  This revealed the following (the last five commands):

+ /usr/lib/openoffice.org2.0/program/soffice.bin
+ trap 'kill -9 $!' TERM
+ wait 12020
+ '[' 78 -eq 79 ']'
+ exit

Versions of OpenOffice:
The above problem affects every version of OpenOffice I've tried.
That includes 2.0.4-5.5.21 from Fedora updates, and the official
versions from www.openoffice.org (2.0, 2.1, and 2.2).

How reproducible:

Additional info:
It seems highly unlikely that this problem would affect everyone,
or even a large number of users, since such an obvious bug would
be detected and fixed immediately.  Therefore, I supsect that the
problem lies in the dependencies.  Could the above error be caused
by me not having installed some prerequisite packages?

Comment 1 Caolan McNamara 2007-04-18 11:31:56 UTC
every single version that you try. 

well is there anything ususual about your setup in any way, 

what desktop environment are you running, 

a) GNOME/KDE anything else
b) do a ldd /usr/lib/openoffice.org/program/libsw680li.so and a ldd
/usr/lib/openoffice.org2.0/program/soffice.bin and paste the output here, to see
if you have e.g. some library in /usr/local/bin or elsewhere which is not
c) then strace -f /usr/lib/openoffice.org2.0/program/soffice.bin -writer >
/tmp/logging 2>&1 and see if there is anything in that output file /tmp/logging.
Attach it here if there's nothing obviously wrong with it.

Does it show the splash screen, or just immediately exit. It might think that
you have OOo already running, rm -rf /tmp/OSL* as root to remove any stale pipes
and make sure with ps auxw that there are no office instances already running
displaying to another display, or in a stuck state

Comment 2 Haakon Riiser 2007-04-18 12:09:33 UTC
Created attachment 152892 [details]
Output from ldd

Comment 3 Haakon Riiser 2007-04-18 12:10:36 UTC
Created attachment 152893 [details]
Output from strace

Comment 4 Haakon Riiser 2007-04-18 12:11:07 UTC
a) GNOME is installed, but I don't use it.  (Running fvwm2 directly
from ~/.xinitrc). KDE is not installed.

b) See the attachment for the ldd output.  All libraries are found, and are
located in /usr/lib and /lib.

c) Already tried that, and found nothing obvious.  See the attachment.

Nothing is displayed on startup, not even the splash screen.
Removing leftover junk in /tmp does not work, and no instances
of OpenOffice is running in the background.

Comment 5 Caolan McNamara 2007-04-23 09:57:22 UTC
not run in a xen guest os or anything like that I guess either ?

Comment 6 Haakon Riiser 2007-04-23 10:14:31 UTC
No, nothing like that.  There's nothing out of the ordinary about my

Comment 7 Caolan McNamara 2007-04-23 15:05:01 UTC
heh :-), I don't know what the problem is. But there has to be *something* odd,
if no OOos regardless of version or where they come from will start.

Comment 8 Caolan McNamara 2007-04-25 08:42:30 UTC
doing the following might give some useful hints as to the problem...

gdb /usr/lib/openoffice.org2.0/program/soffice.bin
(gdb) break main
(gdb) run -writer
(gdb) break exit
(gdb) break _exit
(gdb) cont

wait for it to exit/crash

(gdb) bt
(gdb) thread apply all bt

Comment 9 Haakon Riiser 2007-04-25 10:23:56 UTC
Created attachment 153405 [details]
Single thread backtrace

Comment 10 Haakon Riiser 2007-04-25 10:25:02 UTC
Created attachment 153406 [details]
Multi thread backtrace

Comment 11 Caolan McNamara 2007-04-25 10:30:15 UTC
ah!, now we're getting there. I see SalXLib::XError so we have an XError causing
this problem. 


a) what's your XServer, i.e. the output of

grep drivers `(xset -q || echo "  Log file:     /var/log/Xorg.0.log") | grep
"Log file:" | cut -c 17-`

b) and what's your screen depth, i.e. the output of

xdpyinfo | grep "depth of root window:"

and finally 

c) if you export SAL_IGNOREXERRORS=TRUE and the run office from the terminal
does this change things, either by actually working, or by spitting out some
more verbose error.

Comment 12 Haakon Riiser 2007-04-25 10:34:21 UTC
This revealed something very interesting -- the error is related to the
X display.  Knowing this, I logged into the FC6 remotely via ssh
(from a Slackware 11.0 system), and ran OpenOffice so that it's display
was forwarded to the Slackware box.  This actually worked!  This means
that I was mistaken in my assumption that this was a dependency issue.
Have you ever seen something like this before?

Thanks for the suggestion, btw; I didn't know there even were debugging symbols
in Fedora's binary packages. :-)

Comment 13 Haakon Riiser 2007-04-25 10:41:56 UTC
a) (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so

I should perhaps have mentioned that I was using NVIDIA's drivers before,
but it seemed so unlikely that this could make a regular X application like
OpenOffice fail that it never occured to me. :-)

b)   depth of root window:    24 planes

c) It seems to be working, actually!  I can't say this with 100 % certainty
since I don't have physical access to the FC6 system, but when I run soffice
with DISPLAY=:0.0 via ssh, it doesn't crash like it did before.

Comment 14 Caolan McNamara 2007-04-25 10:58:19 UTC
Well, you need to get debuginfo to get the full symbols, but I know that there's
enough in them even stripped to get some basic traces. No need to install
debuginfo to do that.

So... I strongly suspect that the problem is related to the nvidia drivers. When
you get access to the original display where it always crashes you can try using
the nv drivers and see if doing that enables OOo to display to the local display.

We don't ship the nvidia drivers ourselves, so 
a) ensure that it's up to date, 
b) and the version of the nVidia card, i.e. /sbin/lspci | grep VGA
c) the version of the nVidia driver
c) and you might as well attach the xorg.conf you're using for it

If it's trivial to reproduce the problem on one my boxes here with an nvidia
card then I might have a look to see if there's anything we can do about it
inside OOo, but otherwise you may have to live with a SAL_IGNOREXERRORS=TRUE
workaround given their closed source nature :-(

Comment 15 Haakon Riiser 2007-04-27 11:07:02 UTC
I was running NVIDIA driver 1.0-9746 and have now updated to 9755.  This seems
to have resolved the issue completely.  SAL_IGNOREXERRORS=TRUE is no longer needed.

Seems safe to close this bug now.  Anyway, for future reference:

$ /sbin/lspci | grep VGA
02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS] (rev a1)

Comment 16 Haakon Riiser 2007-04-27 11:11:55 UTC
Also, I'd like to thank you for not giving up on this bug, even when you learned
that it was caused by NVIDIA's drivers, which is not even your responsibility!

Comment 17 Caolan McNamara 2007-04-27 11:14:51 UTC

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