Red Hat Bugzilla – Bug 88527
OpenOffice.org and desktop lock up after OpenOffice is loaded
Last modified: 2007-04-18 12:52:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
Description of problem:
I installed RH9 on a test system here, and fired up OOo Writer for the
first time yesterday. The address book import wizard started up, and I was able
to click around for about 4 seconds before Writer locked
up. The mouse pointer was still working, so I tried opening Gnome's main menu,
but it wouldn't respond. Everything on the desktop,
including OpenOffice, was frozen. I attempted to restart X with
ctrl-alt-backspace, but that didn't work. I also couldn't switch to
any of the terminal screens. I was forced to shut the machine off and
After restarting, I fired up OOo Writer again, but this time it locked
immediately after it finished loading. The desktop locked up at the
same time as well.
I uninstalled everything releated to OOo, and reinstalled it, but the
problem remains. OOo Writer, Calc, and everything else in OpenOffice
refuses to run.
I have started OpenOffice applications from Gnome's main menu as a regular user,
and from the Gnome terminal as a regular user and as root. Each attempt has
resulted in a completely frozen desktop.
Systems Aligned Inc.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Load an OpenOffice application from Gnome's main menu.
Actual Results: The OpenOffice application locks up immediately after it
finishes loading, as well as the desktop. Nothing works, except for the mouse
Expected Results: OpenOffice applications should load and work without any
problems. If the application itself experiences problems, the entire desktop
should not lock up. I should be able to kill the OpenOffice process.
Toshiba Satellite 3000
30 GB HD
nVidia 2 Go
I reinstalled RH9, and tried to use OpenOffice.org once again. Immediately
after the reinstall, OOo worked without any problems. None of the applications
locked up, even after repeated closing/reloading.
I then installed the JRE from Sun's (1.4.1_02) website. I tested OOo again, and
the lockup problem returned: OOo is locking up right after it finishes loading,
and is also causing X to lockup. My laptop becomes completely unresponsive
after this happens.
I do not know if this issue is related to Sun's JRE version 1.4.1_02, but it is
odd that my problems with OOo returned after I installed the package.
Uninstalling the JRE has not fixed the lockup problem.
I have other issues with Sun Java 1.4.1_0.2 in Shrike when NPTL is enabled. Does this
behave any better with NPTL disabled?
Have you tried Sun Java 1.4.2 beta? It seems to work much better for me on Shrike for other
I found a thread through Google (I'll attach the thread) that mentions Sun's JRE
version 1.4.1 has problems with NPTL. This is probably the reason why
OpenOffice is dying on me.
Sun's JRE 1.4.1_02 is no longer installed, but OpenOffice is continuing to
lockup (on the upside, Mozilla isn't crashing anymore when I visit cnet.com or
I haven't tried disabling NPTL. I'll give the beta JRE a shot, and reinstall
OpenOffice as well. Hopefully that will clear up my problems with OOo.
If you are using openoffice packaged in the distro, then it has no Java support
and never executes a single line of Java code. What JDK you have installed
does not make any difference.
Seeing NVidia in your hardware list, are you using their binary only drivers?
Yes, I am using their drivers. I have RH9 running another test machine here,
but it has an ATI card in it. OOo hasn't caused any problems on that PC.
I am fairly certain that the nvidia binary only drivers are causing the halo
problems (bug #88259), so it is very possible that they are also causing the
problems with OOo.
I managed to SSH into the machine with the nVidia chipset from the other test
box, ran top, and noticed that OOo was running fine (well, it looked like it).
X was taking up almost 100% of CPU time. I think that X locks up after OOo
loads, and makes it look like OOo is causing the problem. If this is true, then
the drivers from nVidia are the cause.
I will uninstall the nVidia drivers to see if that fixes the problem.
Uninstalling the nvidia binary drivers and dropping back to the "nv" driver
provided with XFree fixed the X problems. When using the "nv" driver, X doesn't
lock up when I load an OOo app.
I decided to try the nvidia binary drivers again. Without ANY options enabled
in the XF86Config file for the nvidia binary driver, loading OOo does not lock
up X. However, when I enabled a few options, X again locked up when loading an
I then commented out all of the binary driver options except for the "NoLogo"
option (which I use to supress the nVidia logo display just before the login
screen is displayed). With this option enabled, OOo apps don't lock up X.
Therefore, one of the other nvidia binary options I am using is causing the
problem with X when I start an OOo application.
I now know which option in the XF86Config file is causing the OOo lockups:
RenderAccel. I find this extremely odd because I had RenderAccel enabled in RH
8.0, and it worked without any problems. My system was stable before.
With the new Nvidia binary only drivers, OOo locks up when RenderAccel is enabled.
This means this should be reported to NVidia, not us. There is nothing we can do
about bugs in NVidia binary only stuff.
We could not run OOo when nvidia drivers were installed until we altered the
grub.conf file. Our notes are documented here: