Bug 119443

Summary: gnome-panel uses all CPU time as displayed in top.
Product: [Fedora] Fedora Reporter: Robin <robin.laing>
Component: gnome-panelAssignee: Mark McLoughlin <markmc>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: medium    
Version: 1   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:02:15 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:
Attachments:
Description Flags
Tail of last strace before killing.
none
Screen capture of top and ps for gnome-panel just before killing.
none
Another trace from after restarting gnome-panel.
none
Gzip of captured strace. none

Description Robin 2004-03-30 16:28:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
All updates.

Almost on a daily basis my computer will start to slow down. 
Sometimes, multiple times per day.  Checking top shows gnome-panel
running >90% CPU usage.

Closing all applications does not change the CPU usage.  

Leaving the computer idle does not change the usage.

Killing gnome-panel with apps still running will reset normal operation.

This problem was first brought to my attention by one of the system
admins when Seti@home was running slow on my computer.

There is no information that I can find in any log files.

Version-Release number of selected component (if applicable):
gnome-panel-2.4.2-3, gnome-libs-1.4.1.2.90-36, gnome-desktop-2.4.0-1

How reproducible:
Sometimes

Steps to Reproduce:
1.  Login as normal I start in init 3 and use startx
2.  Use applications as normal.  gimp, mozilla, gnome-terminal
3.  System slows down.  Check top and see gnome-panel running slow.

    

Actual Results:  System starts running slow after a period of time. 
It may not be noticable on a newer computer.  Almost a daily basis 

Expected Results:  gnome-panel should not start using all the
processing power of the computer.



Additional info:

gnome-panel-2.4.2-3
gnome-libs-1.4.1.2.90-36
gnome-desktop-2.4.0-1

mozilla-1.6-1.0.0
gimp-1.2.5-1
gnome-terminal-2.4.0.1-1

Comment 1 Mark McLoughlin 2004-04-07 12:39:21 UTC
Could you strace the panel while its doing this and see if there is
anything interesting in the log ? i.e. strace -p $(panel-pid)

Thanks

Comment 2 Robin 2004-04-07 17:07:48 UTC
Created attachment 99197 [details]
Tail of last strace before killing.

This is the tail of the last strace (250,000 lines).  I piped ps to the end of
the file.

Comment 3 Robin 2004-04-07 17:12:02 UTC
Created attachment 99198 [details]
Screen capture of top and ps for gnome-panel just before killing.

In "top" gnome-panel showed 88.8% while ps only showed 29.2 %.

Comment 4 Robin 2004-04-07 18:52:26 UTC
Created attachment 99203 [details]
Another trace from after restarting gnome-panel.

With this trace, ps was showing close to 80%.

I started the file with times and ps captures to show that the CPU usage
increased over time.
The strace file grows by MB per second.

I hope this helps.

Comment 5 Mark McLoughlin 2004-04-08 12:30:16 UTC
Okay, its obvious what's going on from strace:

poll([.., {fd=19, events=POLLIN, revents=POLLNVAL}, ..], ..) = 1

Something (possibly gnome-vfs) is causing the panel to poll on a file
descriptor that has been closed. poll() immediately returns an error
and then we poll() again and it goes on and on.

So, we need to track down what is closing that file desciptor without
removing it from the set of pollfds.

Some questions:

  + Is this stock Fedora Code 1 with Fedora Core 1 updates? Have you
    updated to any development versions of libraries or anything?

  + What version of glib2, gtk2, linc, ORBit2 and gnome-vfs are you
    using?

  + Have you noticed any specific trigger for this happening?

  + Does it happen when Seti@home isn't running (probably unrelated)

  + If you disable the FAM service does it stop happening?

What I need you to try and do now is to get an strace log of the
period when this starts happening. Basically, you'll want to strace
the panel until you notice it happening, then go back through the
logs and find when the ioctl/gettimeofday/poll continous loop started
happening. Once you find where that started, just attach a few
thousand lines of the log from before that.

Its quite possibly the same bug as bug #116127 - we just need to
confirm that.

Thanks :)

Comment 6 Robin 2004-04-14 19:30:32 UTC
>Some questions:
>
>  + Is this stock Fedora Code 1 with Fedora Core 1 updates? Have you
>    updated to any development versions of libraries or anything?

Almost stock.  Some extra libs required for graphics and movies.  It
was an upgrade from RH8.  I should try it at home on a clean install.


>
>  + What version of glib2, gtk2, linc, ORBit2 and gnome-vfs are you
>    using?
glib2-2.2.3-1.1
gtk2-2.2.4-5.1
linc-1.0.3-2
ORBit2-2.8.2-1
gnome-vfs-1.0.5-15

>  + Have you noticed any specific trigger for this happening?
No.  I use the same applications on an almost daily basis.  Mozilla,
gimp, gnome-terminal.  I thought it may be related to the size of
files that I am working with in "the gimp" but the latest fault trace,
gimp was not opened.

One of the latest time, I only opened Mozilla and Mozilla mail.  I am
starting to suspect that it may be Mozilla mail.

>  + Does it happen when Seti@home isn't running (probably unrelated)
Yes it has.

>  + If you disable the FAM service does it stop happening?

I will try later and see what happens.

>What I need you to try and do now is to get an strace log of the
>period when this starts happening. Basically, you'll want to strace
>the panel until you notice it happening, then go back through the
>logs and find when the ioctl/gettimeofday/poll continous loop started
>happening. Once you find where that started, just attach a few
>thousand lines of the log from before that.


I will attach a log file that was created and cut from over 1,900,000
line to ~10,900 lines. 

I am not sure of what I am actually looking for to ensure that the
loop has started.  I kept as much info as possible as I would not know
what I should remove and keep to ensure nothing was missed.

I restarted X (startx) and opened two instances of gnome-terminal.  I
then started strace.

I opened mozilla, mozilla mail and gedit.  I sent a couple of messages
and read a couple of messages in a test.  I repeated this procedure
but the fault did not occur as quickly.  When it does occur, I have to
be watching or I will fill my free disk space.

I will try turning off fam and see if I can recreate the fault.  This
will have to wait a couple of days due to work.


Comment 7 Robin 2004-04-14 19:33:39 UTC
Created attachment 99421 [details]
Gzip of captured strace.

When I cut the file down, I think the loop starts about the middle but I am not
sure.

Comment 8 Mark McLoughlin 2004-04-15 12:17:50 UTC
Okay, thanks much for extra info. This is definitely a duplicate of
bug #116127. The FAM daemon is crashing and that's what's causing the
problem. Disabling FAM should make it go away.

*** This bug has been marked as a duplicate of 116127 ***

Comment 9 Stan Mulder 2005-02-12 16:37:47 UTC
I just experienced this bug with Fedora Core 3 on amd64 with all
updates applied  as of a few days ago and some extra stuff for
movies/audio from freshrpms.net. The fix was to run top and see which
programs are taking all the cpu time and kill them. They automatically
restart. I killed the following: gam_server (?? not sure how this got
loaded; sirtet is all I loaded), gnome-panel, gnome-settings-daemon
and gnome-vfs-daemon.

Comment 10 Red Hat Bugzilla 2006-02-21 19:02:15 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.