Bug 155779 - Gnome races and eats up CPU
Gnome races and eats up CPU
Status: CLOSED DUPLICATE of bug 196444
Product: Fedora
Classification: Fedora
Component: gnome-vfs2 (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Larsson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-22 18:21 EDT by David Kaplan
Modified: 2008-08-02 19:40 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-01 11:07:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the snapshot of relevant processes (95.95 KB, text/plain)
2005-05-25 09:01 EDT, chri
no flags Details

  None (edit)
Description David Kaplan 2005-04-22 18:21:39 EDT
Description of problem:
The last couple of weeks, I have run into some sort of race condition several
times while logged into gnome on FC3 with all of the updates.  Four processes
(gnome-settings-daemon, gnome-vfs-daemon, gnome-panel, nautilus) eat up all the
CPU time and the machine runs very slowly.  It has happened several times while
openoffice is running, suggesting that it might be connected to the last
openoffice update (April 14), but I am not certain that there is a link. 
Closing openoffice and all other open applications does not fix the problem and
generally I have to log out to get back to a normal state.

Running top while this is going on, I get the following:

[me@chupacabra ~]$ top

top - 13:23:33 up  2:16,  4 users,  load average: 5.22, 5.05, 3.95
Tasks:  94 total,   6 running,  88 sleeping,   0 stopped,   0 zombie
Cpu(s): 68.3% us, 31.7% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    514604k total,   508860k used,     5744k free,     2244k buffers
Swap:   923696k total,   116500k used,   807196k free,   127600k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5045 me        25   0 19420 5776 5400 R 26.0  1.1   5:29.26 gnome-settings-daemon
 5102 me        25   0 21260 3028 2608 R 25.0  0.6   5:28.34 gnome-vfs-daemon
 5087 me        25   0 23476 9.9m 7108 R 23.6  2.0   5:30.11 gnome-panel
 5089 me        25   0 37868  10m 7620 R 23.6  2.0   5:31.48 nautilus
 5098 me        17   0 60144  12m 9280 D  1.0  2.4   0:04.92 gaim
 4848 root      15   0  163m  17m 6772 S  0.3  3.4   2:17.92 X
 .....



Version-Release number of selected component (if applicable):
FC3 with all the updates

How reproducible:
Irregularly

Steps to Reproduce:
1. Log into gnome and fool around
2.
3.
  
Actual results:
Wow, lots of CPU usage, fan working overtime, everything slows down.

Expected results:
Should run smooth.

Additional info:
I know this is a vague report, but if there are any techniques I can use to
isolate the problem while it is happening, please let me know.
Comment 1 David Kaplan 2005-04-29 14:48:10 EDT
This problem has become exceedingly annoying.  If there is anyone who has a
suggestion for taming this problem, even if it means loosing gnome
functionality, please let me know.
Comment 2 David Kaplan 2005-04-29 18:47:59 EDT
I have determined that this bug is brought on by trying to insert an image or
open a file from openoffice.  it appears that this only happens when the file
opener hasn't been used in a while, suggesting that it happens when openoffice
calls the file selector into memory.

the only fix is to kill gnome-settings, gnome-panel and nautilus.  killing any
one does not appear to fix the problem.
Comment 3 chri 2005-05-25 09:01:02 EDT
Created attachment 114823 [details]
the snapshot of relevant processes
Comment 4 chri 2005-05-25 09:01:40 EDT
Hi, 

I have the same problem but I'm quite sure that it's not triggered by OO.org
only (it happened to me with evolution and up2date too). I guess the problem is
with some IPC problem in Gnome. These are clues I collected. I'm attaching the
output of top, the output of strace -p for the process that are spinning in a
busy loop, the relevant lines of lsof and the output from netstat -x. As you can
see all the processes do a poll on a unix domain socket I cannot identify what's
for. I'll do some more research ASAP but I really don't know much about how
Gnome works.

Thanks,
Comment 5 David Kaplan 2005-05-25 13:06:59 EDT
It is good to know that I am not alone, though we very well might be - i.e. we
need to get a maintainer's attention.  Part of the problem is that it is still
not clear what the direct cause of the problem is.  If we (or you) can isolate
that then we can contact the correct person and hopefully get more support in
figuring this out.
Comment 6 David Kaplan 2005-06-03 21:35:30 EDT
With the information given in comments #3 and #4, I would think that someone at
redhat might have a comment on this problem.  Perhaps this bug is not assigned
to the correct package.  Could David Zeuthen suggest where it should be?

This bug is extremely annoying and has totally changed my work habits and
productivity.  Now I open openoffice, use it rapidly (which is hard to do if you
are writing a paper) and close it.
Comment 7 Caolan McNamara 2005-07-15 11:16:05 EDT
gaim maybe, or gnome-vfs ?
Comment 8 Ola Thoresen 2005-09-21 07:14:02 EDT
Same issue here.
Fedora Core Development/Rawhide
x86_64

These three are fighting over the CPU:
 2956 olen      25   0  166m 4896 3320 R 33.5  1.0 298:47.02 gnome-panel
 2911 olen      25   0  141m 2264 1920 R 33.2  0.4 299:21.14 gnome-settings-
daemon
 2958 olen      25   0  191m 4092 2836 R 32.9  0.8 296:44.35 nautilus

I hardly ever use OO.org, so I don't think it is directly related to OO.
I do use evolution though - but not now, because it gets so painstakingly slow 
with these three processese eating all CPU.

Here are a few relevant packages:
gnome-panel-2.12.0-2
nautilus-2.12.0-1
control-center-2.12.0-2
gamin-0.1.6-1

A short excerpt from an strace of the nautilus process:

ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|
POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN, 
revents=POLLNVAL}], 5, -1) = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|
POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN, 
revents=POLLNVAL}], 5, -1) = 1
ioctl(3, FIONREAD, [32])                = 0
read(3, "n\2\227\32\267\252\275\5\0\4\4\0\0\0\0\0\0\0\0\4\4\4\4"..., 32) = 32
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|
POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN, 
revents=POLLNVAL}], 5, 0) = 1
write(3, "\225\4\2\0\0\1 \1", 8)        = 8
read(3, 0x7fffffa31490, 32)             = -1 EAGAIN (Resource temporarily 
unavailable)
select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
read(3, "\1\0\230\32\0\0\0\0\4\4\0\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0"..., 32) = 32
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|
POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN, 
revents=POLLNVAL}], 5, -1) = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|
POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN, 
revents=POLLNVAL}], 5, -1) = 1
ioctl(3, FIONREAD, [0])                 = 0


There are "millions" of those polls, with an occational read and write.
Exactly the same for gnome-panel and gnome-settings-daemon
Comment 9 Matthew Miller 2006-07-10 18:31:48 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 10 Alexander Larsson 2006-09-01 11:07:30 EDT
This looks like the gamin problem in bug 196444. Marking as dup.


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

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