Closed Bug 651993 Opened 12 years ago Closed 10 years ago
continual HDD activity, (flash related?)
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; FDM; .NET4.0C; .NET4.0E) Build Identifier: 3.6.3, 3.6.13 i have used Fire fox 3.6.3 on this computer (EEE laptop) for a while without any issue, then after getting it back from warranty i had to reinstall everything. this time the hdd LED was absent so i did not find out what firefox was doing undercover until i replaced it much later on (recently), i just saw the performance drop and thought it was the new hardware. i have even tried safe mode and it still does it. i am using process explorer and OpenedFilesView, but these are not telling me which file is getting all the attention. if i am able to supply a screenshot, Process explorer shows that the I/O write bytes is (MB): 93MB, and read bytes (MB): 63MB (and counting). the largest file handle open is urlclassifier3 but this file is only 39.9MB so this does not match. there is no internet activity during file activities. EVENTUALLY it does stop but on a flash drive this is going to degrade my computer fast. i have tried two versions of firefox, and updated flash to the latest version which i thought was triggering it. (even with sites with simple flash programs that animated only a button) the bug is writing to the drive in bursts, it transferrs maybe 13MB in a single second and the drive is continually working to write it, then later on it adds some more, maybe 2mb (i see this using process explorer), and the light doesnt go out untill the bug is done. suspending the process in process explorer does not allow immediate relief as the buffer is still writing. due to the drive activity windows is sluggish. this may be a hard one to reproduce (considering that this might have been the third reinstall) so i cant give steps, but i would like it fixed as i created a backup of my reinstall after installing all my software so i didnt have to reinstall the software again - i believe the backup also contains the bug. Reproducible: Always
in the new install (the backup), i installed 3.6.13, and upon finding bug i removed it and installed 3.6.3 to see if it was 13 related (as i think i had 3 installed on my previous installs) and there is no change.
my pc is the EEE 901, it has two flash drives, with the installed softwares on the 8gig D: drive and windows and the user files on the C: drive. the C: drive is getting the continual read/writing.
Are you able to reproduce the problem with a recent Firefox version? http://www.mozilla.com/en-US/firefox/all.html Does the issue still occur if you start Firefox in Safe Mode? https://support.mozilla.com/en-US/kb/Safe+Mode
the issue still occurs in safemode. is it possible to find out which file is being written to? i dont know with files on the local system. not yet attempted with any other versions yet.
(In reply to comment #4) > is it possible to find out which file is being written to? Maybe Process Monitor can do that? http://technet.microsoft.com/en-us/sysinternals/bb896645 Tools/File Summary.../By Path
upgrading to 4.0 did seem to fix the problem but i do find it curious that i have never seen this problem before in the past installations. that util might be useful. (might try 3.6 again if the plugins dont work)
yes it is still ocurring again, and the output is very unusual. this time i had to freeze firefox, the other one, plugincontainer is ok. these four files are getting hit: (Mbytes read/Mbytes write/file sizeMB) (15.9/28.6/06.2)urlclassifier3.sqlite-journal (00.0/07.6/39.9)urlclassifier3.sqlite (04.8/07.8/00.5)places.sqlite-wal (09.7/02.4/10.0)places.sqlite note: the Mbytes read/write figures is the bytes figure devided by 1M not 1024^2 this is with firefox 4.0 Charlie.
last comment was erronous this is correct: this is with firefox 4.0 yes it is still ocurring again, and the output is very unusual. this time i had to freeze firefox, the other one, plugincontainer is ok. these four files are getting hit, this is when firefox is frozen by PE, expect figures to be ramp, however the figures do not reflect the process explorer figures, is there more files (Mbytes read/Mbytes write/file sizeMB) (15.9/28.6) total (00.0/07.6/06.2)urlclassifier3.sqlite-journal (04.8/07.8/39.9)urlclassifier3.sqlite (01.3/10.5/00.5)places.sqlite-wal (09.7/02.4/10.0)places.sqlite process explorer figures: (Mbytes read/ Mbytes write) (39.6/77.7) firefox.exe (01.5/00.04) plugincontainer.exe note: the Mbytes read/write figures is the bytes figure devided by 1M not 1024^2 Charlie.
the last post was erronous redoing it and i will let it finish this time. this is with firefox 4.0. (Mbytes read/Mbytes write/file sizeMB) (46.8/85.0) total (11.8/24.8/39.9)urlclassifier3.sqlite (08.8/17.4/11.3)places.sqlite-wal (11.7/17.3/10.0)places.sqlite (09.6/13.1/----)urlclassifier3.sqlite-journal (file no longer exists) process explorer figures: (Mbytes read/ Mbytes write) (42.9/67.0) firefox.exe (not open now) plugincontainer.exe note: the Mbytes read/write figures is the bytes figure devided by 1M not 1024^2 note: hosts file in use to get rid of ads and internet activity tracking servers (ie, google) i have heard you make your browser contact google to do the URLclass3 file, but their stuff is on many sites allowing them to track you so i just block them and their ads are not necessary for the web content i am after anyway. Charlie.
Well indeed, Google is contacted to build the urlclassifier3.sqlite file. Just killing the requests by an evil hosts file sounds to me like a potential source of problems. If you don't want to retrieve anti-phishing information from Google then uncheck: Tools/Options/Security/Block reported attack sites Tools/Options/Security/Block reported web forgeries By the way, when in use that information is retrieved and used locally to protect your integrity. Thus Google will not be contacted for each and every site you visit. How big is your urlclassifier3.sqlite? (should be about 50M)
comment 8 was fine, i thought i deleted it which is why post 9 says that last comment was errornous. evil? its like a firewall and very trustworthy! the file size hasnt changed, its still 39.9MB (i wrote it in the last posts) it would be good if can you do a fix please! i will try that though. what server does firefox try to contact in order to get its information? Charlie.
(In reply to comment #11) > what server does firefox try to contact in order to get its information? browser.safebrowsing.provider.0.updateURL in about:config says the server is safebrowsing.clients.google.com.
the only ones i have with google.com in them are: 127.0.0.1 www.google-analytics.com 127.0.0.1 ssl.google-analytics.com 127.0.0.1 partner.googleadservices.com 127.0.0.1 googlesyndication.com 127.0.0.1 fusion.google.com 127.0.0.1 www.googleadservices.com 127.0.0.1 pagead2.googlesyndication.com and i know these do not interfere with the one you have listed.
you can pop them into yours see if it happens on yours (i doubt it because it is my only time), i have 90 other entries. im not one of those people who collect hosts files and add them together as i have found that the internet becomes laggy so i started from scratch again.
ok i did as you said and unchecked what you said: Tools/Options/Security/Block reported attack sites Tools/Options/Security/Block reported web forgeries and i didnt see the bug, had it on till now. then i renamed the hosts file and re-checked the boxes, i saw the google ads very clearly so hosts file was NOT in effect (http://www.aquariumadvice.com/forums/f24/plants-rotting-108331.html). and within minutes the bug occurred again. got to 34MBR 78MBW according to PE before i noticed it, upon resuming to change options again it was nearly finished. so i do thank you for the partial fix but it is better if you had found the problem. Charlie.
i will try again youtube may have interfered..
yes still does it.
I'm seeing a similar problem with SeaMonkey 2.0.14 on Ubuntu (Linux), and have had the problem for about two years, since the SeaMonkey 1.x series on Ubuntu 8.x, but have never seen SeaMonkey do the same on Windows 98SE or Windows XP. (SeaMonkey 1.x is based on the old Mozilla code base, while SeaMonkey 2.x is based on the more recent Firefox code.) It happens after the browser has been running for several hours, possibly after other applications have been launched and subsequently shut down. On occasion I've returned to find the hard drive churning continuously with nothing else apparently happening on the system. The keyboard and mouse are practically unresponsive, and it can take 10-15 minutes to get a Gnome GUI menu to pop up to close SeaMonkey, and many minutes after that for the OS to kill the application. Sometimes I still need to use System Monitor to kill seamonkey-bin manually, because the GUI (seamonkey) has been closed, but the non-GUI part of SeaMonkey is still left running as a zombie. Once SeaMonkey is killed, the hard drive churning invariably stops and I can continue to run the system as if nothing had happened. SeaMonkey can be restarted, and it runs normally -- for a while. I have Firefox 3.6 on my Ubuntu system, but haven't used it enough to see if it has the same problem. * Disabling page prefetching in SeaMonkey hasn't prevented the problem from occurring. * My installations have always included the Adobe Flash plug-in, both on Linux and Microsoft Windows systems.
Does it happen in newer versions using a new profile?
The problem continues with SeaMonkey 2.7.2 on Ubuntu Linux, although perhaps a bit less frequently. SeaMonkey keeps slamming the hard drive even when other applications are closed down, leaving SeaMonkey as the only running application on the desktop. It seems as if SeaMonkey is experiencing some kind of memory allocation panic and is unaware of RAM being freed up for it to run, so the only way to get it to behave is shut it down and restart it as the sole desktop application. I've seen this happen with new installations and new profiles, too.
(In reply to Charlie B from comment #17) > yes still does it. Charlie do you still see it when using current version?
Whiteboard: [closeme 2012-12-10]
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2012-12-10]
You need to log in before you can comment on or make changes to this bug.