Bug 365871 - Firefox Consuming 5% of CPU when idle
Firefox Consuming 5% of CPU when idle
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
7
i386 Linux
low Severity low
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
firefox3INSUFFICIENT_DATAmassClosing
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-04 11:31 EST by Charlie Bennett
Modified: 2008-04-09 10:05 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-09 10:05:15 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)

  None (edit)
Description Charlie Bennett 2007-11-04 11:31:07 EST
Description of problem:

Just upgraded to F7 on a thinkpad 600x: that's a whopping 650 MHz.
I've noticed firefox hogging 5% of CPU even when it's just sitting
there displaying a local static page.

It's doing this:
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=18, events=POLLIN}, {fd=3, events=POLLIN}, {fd=33,
events=POLLIN|POLLPRI}, {fd=36, events=POLLIN|POLLPRI}, {fd=35,
events=POLLIN|POLLPRI}, {fd=65, events=POLLIN}, {fd=26, events=POLLIN,
revents=POLLIN}], 7, -1) = 1
read(26, "\372", 1)                     = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=18, events=POLLIN}, {fd=3, events=POLLIN}, {fd=33,
events=POLLIN|POLLPRI}, {fd=36, events=POLLIN|POLLPRI}, {fd=35,
events=POLLIN|POLLPRI}, {fd=65, events=POLLIN}, {fd=26, events=POLLIN,
revents=POLLIN}], 7, -1) = 1
read(26, "\372", 1)                     = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=18, events=POLLIN}, {fd=3, events=POLLIN}, {fd=33,
events=POLLIN|POLLPRI}, {fd=36, events=POLLIN|POLLPRI}, {fd=35,
events=POLLIN|POLLPRI}, {fd=65, events=POLLIN}, {fd=26, events=POLLIN,
revents=POLLIN}], 7, -1) = 1
gettimeofday({1194192359, 357979}, NULL) = 0
gettimeofday({1194192359, 358372}, NULL) = 0
gettimeofday({1194192359, 361144}, NULL) = 0
gettimeofday({1194192359, 361591}, NULL) = 0
gettimeofday({1194192359, 361962}, NULL) = 0
futex(0x90700b0, FUTEX_WAKE_OP, 1, 1, 0x90700ac, {FUTEX_OP_SET, 0,
FUTEX_OP_CMP_EQ, 0}) = 1
write(27, "\372", 1)                    = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=18, events=POLLIN}, {fd=3, events=POLLIN}, {fd=33,
events=POLLIN|POLLPRI}, {fd=36, events=POLLIN|POLLPRI}, {fd=35,
events=POLLIN|POLLPRI}, {fd=65, events=POLLIN}, {fd=26, events=POLLIN,
revents=POLLIN}], 7, -1) = 1
read(26, "\372", 1)                     = 1
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=18, events=POLLIN}, {fd=3, events=POLLIN}, {fd=33,
events=POLLIN|POLLPRI}, {fd=36, events=POLLIN|POLLPRI}, {fd=35,
events=POLLIN|POLLPRI}, {fd=65, events=POLLIN}, {fd=26, events=POLLIN,
revents=POLLIN}], 7, -1) = 1
read(26, "\372", 1)                     = 1
ioctl(3, FIONREAD, [0])                 = 0
poll(194192359, 556815}, NULL) = 0

It's doing it at top speed, all the time.  All of these fd's appear to be
local.  What in the world is it doing?  Does it really need gettimeofday()
five times in rapid succession?

Note that FD 26 and FD 27 appear to be opposite ends of the same pipe.

Is this debug code that forgot to get turned off?

Version-Release number of selected component (if applicable):
firefox-2.0.0.8-1.fc7

How reproducible:
Every time I've launched it since upgrading a few days ago.

That may not be an issue on your run-of-the-mill quad-core workstation
but everything I own is coppermine-vintage and sloppy performance bites.

Steps to Reproduce:
1. start firefox.  Let it sit on the release notes page
2. run top, note that on an idle box, firefox is the #1 consumer of cpu
3. run strace on the pid and watch it working it's heart out
  
Actual results:

It's busy, busy, busy.

Expected results:

Less busy.

Additional info:
Comment 1 Matěj Cepl 2008-02-21 17:34:47 EST
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.
Comment 2 Matěj Cepl 2008-02-21 17:36:04 EST
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.
Comment 3 Matěj Cepl 2008-04-09 10:05:15 EDT
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

[This is a mass-closing request, if you think that this bug shouldn't be closed,
please, reopen with additional information.]

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