Red Hat Bugzilla – Bug 495169
mini_commander_applet ties up X in CPU intensive state
Last modified: 2009-04-21 19:09:01 EDT
Description of problem:
mini_commander_applet ties up X in CPU loop for about 5 minutes then finally
I added mini_commander_applet and system-monitor to my panel when I
created my local user after installing fedora 11 beta.
I rebooted the system and logged in, and the gnome session screen drew
itself normally with icons and panels and wot-not, but the pointer cursor
was the busy rotating arrow and X was mostly non-responsive (cursor
moved, but I couldn't get any response from clicking on anything).
I did a Ctrl-Atl-F2 to get to a terminal (which worked fine), ran top,
and found 'X' using about 87% of the CPU and mini_commander_applet using
about 10% of the CPU with some other gnome bits and pieces picking up
smaller percentages of time as well.
While trying to decide what to try, I noticed the top display suddenly
change to "top" getting the most CPU and X and mini_commander were out of
the picture. My impression is that was about 5 minutes after the initial
I switched back to the GUI with Ctrl-Alt-F1 and found a popup saying that
mini_commander_applet had quit unexpectedly, and things have been working
pretty normally since then.
Version-Release number of selected component (if applicable):
I've only seen it this once, and wanted to report it while the details were
fresh. I'll add a not if I see it again.
Steps to Reproduce:
1. see above
non-responsive X session
working X session
Well, I just added mini-commander back to the panel with no problem,
logged out and back in with no problem and even rebooted and logged back
in with no problem, so it looks like a one time event so far.
On the other had, it was doing it again today when I booted into f11 again.
I don't have all the debuginfo files loaded, but I attached to it with gdb
just to see what I could see and a routine that seemed like it might be
important in the list was something with bonobo and timeout in the name.
Could there be some problem with some server not being fully initialized
at login that is a timing dependent thing which makes this bug random?
Maybe the faster startup work in f11 has gotten a little carried away?
(Just random theories).
Also I noticed in the panel that the area where the command line would
normally appear was constantly flickering like it was drawing itself, dying,
and drawing itself again about as fast as it possibly could.
I've yum updateed quite a few updates since I reported this, and I have not seen
this behavior in a while, so maybe one of the updates fixed it (or just
changed the timing enough that it no longer happens).
Ok, closing for now.