Bug 236899 - OpenOffice.org doesn't start due to an XError on nvidia_drv.so
OpenOffice.org doesn't start due to an XError on nvidia_drv.so
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
: Desktop
Depends On:
  Show dependency treegraph
Reported: 2007-04-18 07:24 EDT by Haakon Riiser
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: NVIDIA driver 1.0-9755
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-27 07:14:51 EDT
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 08:09 EDT, Haakon Riiser
no flags Details
Output from strace (285.64 KB, text/plain)
2007-04-18 08:10 EDT, Haakon Riiser
no flags Details
Single thread backtrace (3.59 KB, text/plain)
2007-04-25 06:23 EDT, Haakon Riiser
no flags Details
Multi thread backtrace (5.70 KB, text/plain)
2007-04-25 06:25 EDT, Haakon Riiser
no flags Details

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

  None (edit)
Description Haakon Riiser 2007-04-18 07:24:56 EDT
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 07:31:56 EDT
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 08:09:33 EDT
Created attachment 152892 [details]
Output from ldd
Comment 3 Haakon Riiser 2007-04-18 08:10:36 EDT
Created attachment 152893 [details]
Output from strace
Comment 4 Haakon Riiser 2007-04-18 08:11:07 EDT
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 05:57:22 EDT
not run in a xen guest os or anything like that I guess either ?
Comment 6 Haakon Riiser 2007-04-23 06:14:31 EDT
No, nothing like that.  There's nothing out of the ordinary about my
Comment 7 Caolan McNamara 2007-04-23 11:05:01 EDT
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 04:42:30 EDT
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 06:23:56 EDT
Created attachment 153405 [details]
Single thread backtrace
Comment 10 Haakon Riiser 2007-04-25 06:25:02 EDT
Created attachment 153406 [details]
Multi thread backtrace
Comment 11 Caolan McNamara 2007-04-25 06:30:15 EDT
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 06:34:21 EDT
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 06:41:56 EDT
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 06:58:19 EDT
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 07:07:02 EDT
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 07:11:55 EDT
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 07:14:51 EDT

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