Description of problem: Had X hang on me. Started oocalc (OpenOffice) and clicked a menu button, instantly X hung, mouse would move jerkily but no screen updates or input handling. ssh in from another comp I see X taking up 100% CPU. Log had this as last (and only odd) thing: Got unexpected buttonTimer in state 0 I had it happen a second time a week later. Exact same thing. The menu button I was selecting (and probably did before) was INSERT in oocalc. So this bug is reproducible, but I don't know exactly what makes it triggerable because I often press INSERT with no hang. strace on the 2nd hang shows nothing but tons of: Process 3714 attached - interrupt to quit --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7f57708) = ? ERESTARTNOINTR (To be restarted) Running fully patched FC5, nvidia binary 8762, sawfish. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.0.1-9.fc5.5 openoffice.org-calc-2.0.2-5.17.2 How reproducible: happened twice seemingly at random after X was alive for 4-8 days, oocalc had just been started (4-10 mins). Steps to Reproduce: 1. start X, use for a while 2. run oocalc 3. click insert menu button Actual results: X hangs Expected results: X does not hang
That's a pretty impressive bug to hit, there's no way we should be calling clone from the rendering code. Does this happen with the nv driver? Also, try installing the xorg-x11-server-debuginfo package, and next time this happens, rather than attaching with strace, attach to the X server with gdb and get a backtrace.
I can't use the nv driver as it makes mythtv nearly unviewable. I suppose I could try a test, but there's not much point if I can't figure out a way to make this hang occur on demand as there's no way I could use nv for 1-2 weeks. I'll install debuginfo for next time. Can you point me to step-by-step instructions on how to "attach to the X server with gdb and get a backtrace"?
I can't seem to find xorg-x11-server-debuginfo with yum. Is that the full package name? What repository? Also, I see that a new nvidia binary driver is up on livna so I'll upgrade to that and see if that helps.
Debuginfo packages are in the corresponding -debuginfo repository. You'll need to edit /etc/yum.repos.d/fedora-core.repo and enable the debuginfo repo. For gdb instructions, see: http://xorg.freedesktop.org/wiki/DebuggingTheXserver
OK, I've got it all ready to go (thanks for the links) and I'm trying hard to make it crash. But of course, it isn't. So I'll leave the gdb going on my other computer and wait for the crash (few days maybe?) and hopefully capture the goods. One interesting thing I noticed: the first time you click a menu in oocalc, gdb reports "detaching after fork from child". From what I know of such things, doesn't this mean that X is forking a child? If I immediately ps on the provided pid, no process with that pid exists. Note, it only does this on the first menu click after loading oocalc -- never on subsequent ones. And now that I think of it, all the crashes I can remember are usually after I just opened a new oocalc -- the first time I click the menu. Why would clicking on a menu cause the _X server_ to fork? I can see it causing oocalc to fork, but why X? And what is it forking such that the child only lives very briefly. Does this make sense? Lastly, the last time it crashed on me (today), I'm pretty sure that the sequence was this: 1. things are ok, trying to avoid hitting menus in oocalc 2. accidentally hit menu in oocalc, system bogs down very briefly (1-2 secs?), I thought it was going to crash, but it turned out to be ok 3. (hours later) accidentally hit menu in oocalc, system froze/crashed as usual The key here being that stage #2 was a bit "new" to me. I had never noticed it "half-freezing" before. I'll report back once I get the freeze. I'll try to make it happen asap, but Murphy says it won't happen until I get my normal 100+ windows of work open.
This bug has not hit me again since my last post. I was running the debugger religiously for a long while, but no crash. I use it only sparingly, but enough that it should have hit by now. Perhaps an upstream fix solved it. (I'm still rather scared of the menus though!) I will report back if it starts up again, but my guess is this is closed. Current versions: openoffice.org-base-2.0.2-5.21.2 xorg-x11-server-Xorg-1.0.1-9.fc5.6
Alright, WORKSFORME for now. Please do reopen if this hits you again. Thanks for the report!
This bug just hit again. The first time since my last report! I was in an oocalc session that was open for 2 days or so and went to hit the File menu to open a new file. As soon as I hit File, the screen got a bunch of repeating horiz lines of weird colors then went black. The keyboard was frozen (numlock wouldn't toggle LED). As before, I could ssh in to the box and cleanly reboot. This is the exact same bug as I report above. My versions now: kernel-PAE-2.6.27.24-170.2.68.fc10.i686 openoffice.org-calc-3.0.1-15.4.fc10.i386 openoffice.org-base-3.0.1-15.4.fc10.i386 xorg-x11-server-Xorg-1.5.3-15.fc10.i386 My computer has had extensive upgrades since 2007, including new board, cpu, ram, etc. Again, it scares me that a simple OOo menu click can crash the entire X server!!
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.