xorg freezes when running openoffice

Forgot to mention, this happens when trying to open the file menu. I am trying to work out a way to reproduce this.

Thanks for taking the time to report this bug and helping to make Ubuntu better.

This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers.
You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage .

I have classified this bug as a bug in "openoffice.org".

You indicate that the CPU is consumed 95%, is this by the openoffice process? You could check using the command 'top' when connected to the system by ssh. Thanks in advance.

It's the Xorg process that is running wild.

If there is anything I can do to provide more data, please let me know.

Could you please add your '/etc/X11/xorg.conf' file and your '/var/log/Xorg.0.log' file as attachments to your bug report? The Xorg log file will be most useful if you copy after starting Open Office. Thanks in advance.

Attached is the xorg log file just after the crash.

And the xorg config file

Could you test this without using the nvidia driver and using the nv driver? Thanks again.

Actually that is a bit inconvenient as the box also runs vdr and the
second display is used for tv. AFAIK the NV driver doesn't support
multiple displays.

I also remembered that I updated the xorg.conf file with RenderAccel =
false after last crash when I was searching for a solution to this
bug, and forgot to mention that. It's now been a week since the last
crash, but I wouldn't call this the solution yet as the crashing has
always been very random.

I'll keep you posted.

Unfortunately the RenderAccell wasn't a solution. The issue keeps coming up, and it's also occurs with other programs than openoffice. This time it froze with firefox. I also noticed that I cannot connect via ssh to the box anymore. Again, no logs show any signs of anything out of order, except for this in xorg log.

(WW) NVIDIA(1): WAIT (0, 1, 0x2000, 0x00008814, 0x00008814, 0)

I'm thinking of starting to use the kernel from dapper to get rid of this issue. Any reason not to?

This issue https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.17/+bug/58019 seems to show similar symptoms as mine.

Actually, if you take a look at the logfile, there's some real problem:

(WW) NVIDIA(1): Unresolved symbol: xf86ExecX86int10

which seems to suggest that the issue https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.20/+bug/89290 is related to this one.

Petri, couldn't hurt to try booting different kernel versions, however my bet would be that this may be a bug in the nvidia binary driver. If changing kernel versions doesn't solve it, it might be worthwhile to try installing a newer version of their driver (see http://www.nvidia.com/object/unix.html). I haven't tested it out myself, so don't yet know if there are problems with it; as far as I know, we won't be backporting this driver to Feisty (I plan to add it to Gutsy in the next week or two, but you probably don't want to install a pre-beta ubuntu release on your system!) Anyway, there are some installation tips here: http://www.nvnews.net/vbulletin/showthread.php?t=72490.

Also, if you ever see it when you're *not* running openoffice, that would be a useful data point for tracking this down further.

The Geforce 4 MX 440 is actually supported by the nvidia-glx (which corresponds to 1.0-96xx ) driver (see http://us.download.nvidia.com/XFree86/Linux-x86/1.0-9755/README/appendix-a.html ). I doubt NVIDIA will look at any problems that occur while the legacy driver is used with that card.

Bryce, the problem actually occurs with other software than openoffice, the same occurs with firefox as well, and I think it's not related to the application in question. I've been using the nvidia driver version 7184 for about two years if not more and there's been no problems with it. Back in debian days it worked, and also with dapper. From dapper I went straight to feisty, and the problem appeared.

The reason I've been using the legacy (7184) version is that the tv-out on my card doesn't work with newer nvidia drivers. I tried a few back in the day and it was found out on nvidia message boards that the newer (then 8xxx) drivers simply didn't support the tv-out. I have no idea about the new 9639 legacy driver that nvidia has on their page now. I'd rather not use that as things are so much simpler with plain debs.

Another symptom of the problem that I've noticed is a memory leak, the memory is being consumed little by little until it gets full. And when it gets full the freeze is more likely to occur.

Since the newest kernel, 2.6.20-16, I've not seen any indications of a memory leak and I'm starting to be optimistic. Uptime is 2 days and counting.. :-/ I'll keep you posted.

An update: Kernel upgrade didn't prevent crashing, it still happens. I also tried the 9639 driver (aka nvidia-glx package) and unfortunately the tv-out doesn't work with that either (seems to have stopped working after the legacy driver).

Maybe I should buy a new video card, it's cheaper than spending hours with this bug.

Thanks for the additional info Petri. Yes, since this is a proprietary piece of software there may not be much we can do to fix it, and since it's a legacy driver, it's unlikely nvidia will be investigating it. However, I'm going to leave this bug open rather than wontfix for now.

I think that the nvidia thing might be a red herring here. I am seeing the same thing, running an i915 video driver.

I am running kubuntu Feisty on two different machines that exhibit the same issue. I seem to recall seeing bugs reported against some KDE-compatible GTK+ theme package that was causing some people problems with Firefox as well. I have never seen this happen with Firefox, Gaim, or anything else, just OpenOffice. I'll try to ferret this out again.

It appears that someone does an XGrabServer and hangs before drawing the menu (the menu button appears "pressed"), consuming CPU in the process...

Does OO do it's own kde/gtk widget mapping?

Yeah...

https://bugs.launchpad.net/ubuntu/+source/openoffice.org2/+bug/126996

I can confirm that the symtoms in the mentioned bug
(https://bugs.launchpad.net/ubuntu/+source/openoffice.org2/+bug/126996)
are exactly the same as mine. Even the instructions on how to repeat
the issue works.

And I can now also confirm that the switch to nvidia-glx-new driver
didn't help, and neither did changing the graphics card. My bet is on
the #126996 issue.

The current xorg-server in Gutsy has a patch which should fix this:

xorg-server (2:1.3.0.0.dfsg-12) unstable; urgency=low

  [ Brice Goglin ]
  * Add 51_xkb-and-loathing.diff to fix a hang in OpenOffice.org
    when opening menus, closes: #433131.

Please test on a daily Gutsy livecd (or otherwise) if you can still reproduce this.

Oh, I can definitely still reproduce it. Working around it has just been a joy (sarcasm). I have become extremely adept at using the file menu from the keyboard. In fact, now I use the keyboard for all programs to access the file menu.

Dealing with this bug has been especially fun since I am using OpenOffice.org to write a book. I think I use openoffice more than I use Firefox now. That one time I slip up and press the File menu with the mouse, boom! My most recent work is lost (unless openoffice.org can recover successfully). Another reason I hit Ctrl+S about every other word.

Setting bug back to New after Dan's comment.

Dan:
Good grief. Doesn't autosave at least reduce the damage a bit?

Dan:

you do run uptodate gutsy, and not feisty (7.04)? This has been closed in other distributions for some time now.. Petri, what about you, does it work now?

I do not have the opportunity to update to gutsy for a while now. Is
it enough if I just grab the xorg-server package and/or all xorg
packages? Or will I break my feisty with that?

Trying a daily livecd is enough, since openoffice.org is there:

http://cdimage.ubuntu.com/daily-live

just burn & boot :)

I grabbed the source package from gutsy and built it against feisty. I'm now running the 1.3.0.0.dfsg-12ubuntu4 version and so far I haven't been able to reproduce the bug. However, I've never been able to reproduce it on demand, I'd like a week to decide whether it worked or not. At least during the 12 hours it's up, it has not crashed.

Ok, I'm marking this as fixed then. Thanks for testing!

I'm thinking that there is quite a desire to have this also fixed in Dapper LTS. I know this affects things greatly in those who are still running dapper.

Are there any plans for that?

Drew

Hi Drew,

In general we don't plan Dapper backports without a specific request for it from a customer, unless it was extremely important (like a major security issue). The release team is extremely strict for LTS changes.

I'd like to request this particular fix be considered for the version of x.org in Dapper, under the grounds that having your X session lock up and require restarting is causing data loss. The patch in question appears to be quite small, and should be reasonably easily reviewed.

Assuming that X doesn't try to use sigaction (rather than signal) on SIGALRM somewhere else, this patch looks fine for dapper-proposed. Bryce/Timo, would you look into preparing an update, please?

As long as we are still waiting for a fix for Dapper ... the following workaround lindered the problem for me: I'm running a second X-Server on :1 with a minimal WM (fluxbox) just for running OpenOffice within. Originally I thought this way I can at least kill a hanging xorg process without loosing other applications' data and my session each time (and usually when I have a customer on the phone that laughs at me when I'm telling him that I need to call him back later because my Linux box just crashed :-)). Surprisingly enough, OpenOffice never made my :1 server crash yet, and xorg is up since Nov 1, now. It's just a little bit tedious switching between servers every now and then and I miss copy&paste. Well, I actually have no idea why this works ...

I don't want to add insult to injury, but Tom's comment perfectly describes the severity of this problem (even if this bug is fixed, it could be something to learn from). To have the computer freeze is more than just an inconvenience. It is a deal-breaker. I am writing a book right now and I am on a very tight deadline. It never fails that when I have several chapters open and my flow going, OpenOffice.org (and sometimes just X in general) just locks the whole X session. It's 30 minutes to an hour before I am back to where I was mentally. I was going to use VMWare to write, but I like the idea of using a second X session as well.

Moving milestone. This won't make it to 6.06.2, since the release candidate CDs are prepared right now. Keeping dapper-updates, though, this should be a normal dapper SRU. 6.06.2 is server only anyway, so there's no X.org on the CDs.

@Dan
I am using Debian Etch and I have the same problem that accessing the menu of OpenOffice freezes or locks X11 / xorg.

It seems to be a Xorg problem:
https://bugs.freedesktop.org/show_bug.cgi?id=10525

As a Linux user I find the bug indeed very annoying, specially when giving a public demonstration of Linux...

I'll upload a new version to dapper-proposed.

Package has been uploaded, waiting for approval.

Accepted into dapper-proposed. Please add a TEST CASE: to the description and give plenty of feedback here (using the actual dapper-proposed .debs for a while). Given the last disaster of updating X.org in dapper a few years back we need to be absolutely confident in this before pushing this to -updates. Thank you!

I spoke too soon. This upload could not be accepted, you need to rebase the current upload against the version in -security (which is a different -10.8).

Any update on this bug? It's been about a month since the last message.

Drew

I've had this happen to me and I files tons of bug reports and was on IRC and so on. With the new video cards, the problem went away.

See also
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/117480

and

https://bugs.launchpad.net/ubuntu/+source/openoffice.org2/+bug/126996

I've done a new upload to dapper-proposed, please test.

Accepted into dapper-proposed. Please test and give feedback here! Also, please don't only test this OpenOffice case; run the packages for a while and work normally and check whether you see any regression. Thank you!

Failed to build.. I didn't have a dapper machine to test on, so hang on while I fix this.

Here's an adjusted debdiff with a fixed xkb-and-loathing.dpatch

This thing seems to be being built with -D_BSD_SOURCE, so it needs to be sig_t instead of sighandler_t

Let's try that again with the right debdiff...

Ok, the package built fine with that patch, so you can find it here:

deb http://ppa.launchpad.net/tjaalton/ubuntu dapper main

I'll upload to dapper-proposed once I get a confirmation that it fixes the problem, so please test.

Apparently this works for me, no OO crash for 6 days and I haven't noticed any obvious side effects yet.

Timo, can you please upload to dapper-proposed? Thanks!

It's been uploaded yesterday, and waiting in the queue.

Accepted fixed version into dapper-proposed. Please test and report feedback here. Thanks!

We've had favourable reports from internal verification.

I also tested it on amd64, and X.org generally works well.

Copied to dapper-updates.

I have had the identical bug occur in Feisty (up to date):

1. launch, say, OO calc. Don't visit a cell, just open.

2. click in the "File" menu

NOT ALWAYS, but many times, this will cause the x server to hang - CPU 100%, completely ignore keyboard events and mouse clicks, but still track mouse.

It turns out, ssh'ing and killing OO will *not* clean the system, for me. I need to kill Xorg (and of course, loose my session!)

QUESTION: is there an easy-to-apply fix for this??? This, to say the least, is a very annoying and time-consuming bug, in that your entire session must be restarted.

Thank you!

BTW, wrt previous post, I should add:

1. Machine has an nvidia board (but as others point out, this is probably not relevant).

2. I have *never* seen this happen with *any* other app for a year and a half - and I run lots of stuff. The xserver has been very stable, other than this.

3. I even updated to the latest OO from the OO site (2.4.1), and it *still* happens.

On Monday 01 September 2008, David Geller wrote:
> BTW, wrt previous post, I should add:
>
> 1. Machine has an nvidia board (but as others point out, this is
> probably not relevant).
>
> 2. I have *never* seen this happen with *any* other app for a year and
> a half - and I run lots of stuff. The xserver has been very stable,
> other than this.
>
> 3. I even updated to the latest OO from the OO site (2.4.1), and it
> *still* happens.

I think the nvidia driver is the key problem. It doesnt' happen with my
newer nvidia cards (01:00.0 VGA compatible controller: nVidia Corporation
G70 [GeForce 7300 GT] (rev a1))

Cheers

Well, it seems some folks have had this with intel, in addtion to nvidia.

But even so, is there a known fix for this?

Thanks!

On Thursday 04 September 2008, David Geller wrote:
> Well, it seems some folks have had this with intel, in addtion to
> nvidia.
>
> But even so, is there a known fix for this?
>
> Thanks!

nope, as far as I know. I bought anouther card and never had problems.
Does that make me happy ? Nope. But there are worse 'vistas' in this
world.

Of course, there is a fix for that, known since more than a year. I do not know, if there is an update available for Feisty, the updated packages for Dapper have been released only recently. Obviously, the Ubuntu team does not necessarily consider this problem being important since it only crashes your X-server and causes data loss - prove them that it can be used for denial of service attacks over the network (well, it can) or even for a break-in and you'll maybe get a fix :-))

However, current Ubuntu versions come with a fixed xorg-package AFAIK, so how about upgrading your installation rather than go on waiting for an update for Feisty or replacing your video adapter?

Best regards