Created attachment 595500 [details] screenshot of desktop showing firefox and top Description of problem: If I start firefox, then start top to look at firefox, it will be using vast amounts of CPU time even doing nothing at all. For instance, the screen shot of my desktop I'm attaching to this bug shows an instance of firefox that was restarted in "safe mode" and is displaying about:blank. It is hard to get anymore nothing than that, yet the CPU usage is at 74.8% at the instant the screenshot was taken. This screenshot was also from a brand new user I just added, so there is nothing in the ~/.mozilla directory other than normal new user content. Version-Release number of selected component (if applicable): firefox-13.0.1-1.fc17.x86_64 How reproducible: The CPU fluctuates from 20 to 100 percent seemingly at random, but most of the time stays above 50%. Steps to Reproduce: 1.see above Actual results: Fantastic CPU usage to display nothing at all. Expected results: Pretty close to zero CPU usage. Additional info:
See this too. It crossed my mind that it might have something to do with the new kernel (3.4.4) since I started seeing it around the time I booted into it, but haven't tested that theory yet.
I tried booting into the two older kernels (3.4.2 and 3.4.3) and didn't see it. But after going back to 3.4.4, I'm not seeing it there anymore either.
I see this. An strace of the Firefox process sees it doing this: poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN| ↩ POLLPRI}, {fd=23, events=POLLIN}, {fd=21, events=POLLIN}, {fd=9, ↩ events=POLLIN|POLLPRI}, {fd=18, events=POLLIN}], 7, 0) = 0 (Timeout) read(5, 0x7fff5d7ce790, 16) = -1 EAGAIN (Resource temporarily ↩ unavailable) recvfrom(4, 0x7f88eab9f074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily ↩ unavailable) poll([{fd=5, events=POLLIN}, {fd=4, events=POLLIN}, {fd=7, events=POLLIN| ↩ POLLPRI}, {fd=23, events=POLLIN}, {fd=21, events=POLLIN}, {fd=9, ↩ events=POLLIN|POLLPRI}, {fd=18, events=POLLIN}], 7, 0) = 0 (Timeout) Keep looping forever, trying to read from file descriptor 5. File descriptor 5 is an event file descriptor. Firefox's usage of Linux event file descriptors is totally and completely ↩ broken.
This post mentions the leap second: http://lists.fedoraproject.org/pipermail/users/2012-July/421115.html And I suspect I didn't see this happening till after the lep second (which would have been midnight UTC). I'm not sure how just one app can be affected, but after rebooting this morning, the problem has indeed disappeared. Maybe the poll timeout in the trace above was wacko due to leap seconds and it kept coming out of poll and trying to read?
Possible. It went away after a reboot too, for me, but I also installed the newest kernel release, as well.
Same here, but: a) server installation (i.e. no Firefox) b) Fedora 15, kernel 2.6.43.8-1.fc15.x86_64 c) affected processes (i.e. those eating a lot of CPU, competing for it: MySQL, Tomcat/Java, btseed d) unaffected processes: PostgreSQL, httpd, ...
(In reply to comment #6) > Same here, but: > > a) server installation (i.e. no Firefox) > b) Fedora 15, kernel 2.6.43.8-1.fc15.x86_64 > c) affected processes (i.e. those eating a lot of CPU, competing for it: > MySQL, Tomcat/Java, btseed > d) unaffected processes: PostgreSQL, httpd, ... after just reboot all normal
Any sign of this issue after the leap second and reboot?
I haven't seen the problem since I rebooted after the leap second.
Closing as not a bug since this is kernel related and next leap second should already be fixed in newest kernel.