Bug 205513 - X hang in oocalc: Got unexpected buttonTimer in state 0
Summary: X hang in oocalc: Got unexpected buttonTimer in state 0
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: David Lawrence
Keywords: Reopened, Triaged
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-06 20:08 UTC by Trevor Cordes
Modified: 2009-12-18 05:53 UTC (History)
0 users

Clone Of:
Last Closed: 2009-12-18 05:53:19 UTC

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 7974 None None None Never

Description Trevor Cordes 2006-09-06 20:08:43 UTC
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 [])
child_tidptr=0xb7f57708) = ? ERESTARTNOINTR (To be restarted)

Running fully patched FC5, nvidia binary 8762, sawfish.

Version-Release number of selected component (if applicable):

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

Comment 1 Adam Jackson 2006-09-06 20:59:48 UTC
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.

Comment 2 Trevor Cordes 2006-09-06 21:33:07 UTC
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"?

Comment 3 Trevor Cordes 2006-09-06 21:37:04 UTC
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.

Comment 4 Adam Jackson 2006-09-15 21:06:05 UTC
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:


Comment 5 Trevor Cordes 2006-09-21 22:50:22 UTC
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.

Comment 6 Trevor Cordes 2007-04-12 08:51:47 UTC
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:

Comment 7 Adam Jackson 2007-04-13 13:33:14 UTC
Alright, WORKSFORME for now.  Please do reopen if this hits you again.  Thanks
for the report!

Comment 8 Trevor Cordes 2009-06-15 16:13:40 UTC
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:


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!!

Comment 9 Bug Zapper 2009-11-18 08:07:56 UTC
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: 

Comment 10 Bug Zapper 2009-12-18 05:53:19 UTC
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.

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