Bug 495169

Summary:	mini_commander_applet ties up X in CPU intensive state
Product:	[Fedora] Fedora	Reporter:	Tom Horsley <horsley1953>
Component:	gnome-applets	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED WORKSFORME	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide	CC:	mclasen, rstrode
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-04-21 23:09:01 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Horsley 2009-04-10 02:20:01 UTC

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:

Comment 1 Tom Horsley 2009-04-10 02:26:17 UTC

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.

Comment 2 Tom Horsley 2009-04-11 14:50:37 UTC

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.

Comment 3 Tom Horsley 2009-04-21 16:12:34 UTC

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).

Comment 4 Matthias Clasen 2009-04-21 23:09:01 UTC

Ok, closing for now.