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 quits unexpectedly. 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 login. 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): gnome-applets-2.25.92-4.fc11.x86_64 xorg-x11-server-Xorg-1.6.0-17.fc11.x86_64 How reproducible: 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 2. 3. Actual results: non-responsive X session Expected results: working X session Additional info:
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.