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 restart. 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. Thanks, Kanwar Sandhu Systems Aligned Inc. Version-Release number of selected component (if applicable): 1.0.2-4 How reproducible: Always Steps to Reproduce: 1. Load an OpenOffice application from Gnome's main menu. 2. 3. Actual Results: The OpenOffice application locks up immediately after it finishes loading, as well as the desktop. Nothing works, except for the mouse pointer. 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. Additional info: Toshiba Satellite 3000 P3 800 384 MB 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 things.
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 canadiandriver.com). 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 OOo app. 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: http://www.openoffice.org/issues/show_bug.cgi?id=13685