Closed Bug 431094 Opened 15 years ago Closed 15 years ago
Using FF3 will cause load average to climb to near 4 on single-CPU system
(Firefox :: General, defect)
(Reporter: rdaly76, Unassigned)
5.25 KB, application/x-tbz
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.4 (like Gecko) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042604 Minefield/3.0pre I have been noticing that using recent builds of FF3 will cause the load average on my system to climb to near 4. I'm running valgrind on the firefox-bin process and am seeing the following: ==4327== Source and destination overlap in memcpy(0xBE8A6324, 0xBE8A6324, 16) ==4327== at 0x4006CA6: memcpy (mc_replace_strmem.c:116) ==4327== by 0x49648BB: (within /opt/firefox/libxul.so) ==4327== by 0x43317F0: (within /opt/firefox/libxul.so) ==4327== by 0x43419EF: (within /opt/firefox/libxul.so) ==4327== by 0x4341DC1: (within /opt/firefox/libxul.so) ==4327== by 0x434212D: (within /opt/firefox/libxul.so) ==4327== by 0x4404523: (within /opt/firefox/libxul.so) ==4327== by 0x4402185: (within /opt/firefox/libxul.so) ==4327== by 0x441D220: (within /opt/firefox/libxul.so) ==4327== by 0x440147D: (within /opt/firefox/libxul.so) ==4327== by 0x440558F: (within /opt/firefox/libxul.so) ==4327== by 0x4402244: (within /opt/firefox/libxul.so) Reproducible: Always Steps to Reproduce: 1. Start FF3. 2. Browse the web normally. 3. See if load average begins to climb. Actual Results: CPU utilization will spike, and the overall load average of the system begins to climb. I will attach the entire output from the valgrind process.
15 years ago
I saw CPU utilization spikes related with so-called "safebrowsing", during updates of local list of hashes. Try this: 1) run FF3 on default settings 2) go to about:blank 3) run some packet sniffer (wireshark, ngrep, tcpdump, whatever; I prefer ngrep, see eg. http://bb.homelinux.org/en/firefox/howtobug368255.html for a little howto) 4) you will watch CPU usage spikes during transfers of data from Google. You can try disabling so-called "safebrowsing" (uncheck "Tell me if the site I'm visiting is a suspected attack site" AND "Tell me if the site I'm visiting is a suspected forgery") to verify whether or not CPU usage spikes are related with this.
The main firefox-bin process PID was 4327. The other files in the archive are for completeness (and in case I missed something there).
I have FF3 going and do see quite a bit of traffic for me having about:blank in the URL. I do notice the CPU spiking while this traffic is going on, and the load average definitely increases during this time, as well.
Unchecking "Tell me if the site I'm visiting is a suspected attack site" & "Tell me if the site I'm visiting is a suspected forgery" looks to have fixed things up. Does that mean these functions have the memory problems that valgrind was reporting?
15 years ago
Do you also noticed high disk activity when the load average climbed? That should be bug 430530. The valgrind log file you attached shouldn't be related to that issue above. Apparently, nothing leaked: ==4327== definitely lost: 0 bytes in 0 blocks. ==4327== possibly lost: 0 bytes in 0 blocks. The other warnings should be harmless, some are not Firefox fault (when happening in system libraries). Building with symbols would provide more informative results.
Yes. High disk activity does accompany the load average climbing. I read through bug 430530 and it does seem to be what I'm experiencing. My entire system will frequently lock up during the high disk activity, as well.
15 years ago
I got relief from this same symptom under Windows 2000, by following the tip in comment 4. It seems to be much worse with plugins -- Flash, in particular; I've been able to keep an FF3 window with Netflix open without the huge load, but it really seemed to crank up when just sitting there with a runnable or completed Flash anim.
15 years ago
Ok, thanks for your testing, I'm marking it as a duplicate.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.