Closed Bug 204099 Opened 18 years ago Closed 17 years ago
download manager locks CPU usage @ 100% when started
. Downloads fail . Mozilla often crashes .
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312 Running MPower, which displays CPU and memory usage on the title bar, I can see that after starting Download manager, CPU usage peaks and stays at 100%. The file rarely downloads typically completing 1 - 5% before hanging. It is often impossible to recover from this. The back and refresh buttons cease to operate and sometimes disappear altogether. Sometimes Mozilla crashes. When Mozilla doesn't crash, I can cut the URL from the address bar, and paste it into Internet Explorer. After doing so, and clicking on the file I want to download, the download proceeds fine. Therefore it is not something wrong with the file. I am uncertain why you chose to implement a download manager to begin with as it seems to serve no purpose, and it is annoying when it pops up. Personally I'd like Mozilla to download the same way IE does: Save the file to disk, with a name and directory I choose at the time of download, and just do it. Also, there seems to be some overhead issues as downloads in IE are typically much faster. I LIKE Mozilla, but I don't like having to keep 2 browsers active in order download files. Reproducible: Always Steps to Reproduce: 1. Right click to download file 2. 3. Actual Results: Download Manager pops up, file starts to download and CPU usage goes to 100% 9 times out of 10, Mozilla hangs or crashes. The only viable action left is to kill that Mozilla session. Expected Results: Download file. It should not require the total CPU resources to download a file. the DM should do its job silently, without showing it's face, unless the download did not proceed due to a file error, and by file error I mean something wrong on the server end. If the file can't be DL'ed with IE, THEN I consider something wrong on the server end. But I shouldn't have to. The probelm has gotten worse since I changed skins from "classic" to Sky Pilot. I installed CyberTweak 1.1 Final Build 2 which speeds up page display, but has not done anything for better or worse regarding the DL issue. I have installed and are using Traceless 2003 v1.12 which empties all the temporary internet files, history, and cookies on browser exit. I am also using Mindbeat MPower 1.2 which defragments memory in realtime, and Zonealarm Pro v3.7.159 firewall. Mozilla has been cleared for operation in Zonealarm. I did not have this problem in Mozilla 1.1 -In 1.3 the problem has gotten steadily worse to the point that downloading is almost impossible.
I've had this happen twice today - using 1.5 - but have not seen it in previous builds.
Gregory, Patrick: does this still happen after you delete the file "downloads.rdf" in your profile directory? It contains a list of all the files you ever downloaded and will grow with time to be very large and slow to parse. If you can still reproduce, please say so and provide a talkback ID if you happen to crash (Talkback is included in the 1.6 and 1.7b Installer version).
If you think I'm going to download a 1 GB+ file to check if this is a bug or not you are sadly mistaken. I have download limits on my connection. Why is a list of all files I've ever downloaded maintained? Once I remove them from download manager I expect any trace of them to be removed (except perhaps in the http location history). I no longer have my old profile either.
Patrick, where did anybody say anything about downloading a 1 GB+ file?? > Why is a > list of all files I've ever downloaded maintained? Once I remove them from > download manager I expect any trace of them to be removed. Well, they _are_ removed from the file once you remove them from download manager. But some people do not use the download manager and therefore don't know there are files listed there. You could easily check the size of downloads.rdf in your profile folder. If it is much larger than maybe 100 kB it might begin to delay your downloads. (You can also look at its contents since it's a text file.) > I no longer have my old profile either. Ok... so the above (your downloads.rdf) maybe does not really apply anymore (but still for Gregory)... Did this also occur with your current profile? Are/were you also running "MPower" or just seeing the 100% CPU usage/delay?
Hello, After using Mozilla for some months, the download manager gets EXTREMLY slow. It takes at least 10 seconds to save a file, even if the file is only 100 bytes large, consuming 100% CPU time. Removing all files from the download manager list kept mozilla busy for over 2 hours, using 100% CPU time. (I stopped mozilla after 2 hours using the task manager). The solution for this problem is to clean the file "downloads.rdf" with a text editor and restart mozilla. The size of the file "downloads.rdf" was about 4.3 MB on my hardisk. I suppose the sorting algorithm for the downloads.rtf file is very slow. Best regards, Martin My System: Athlon 2400XP+, 512 MB, Windows XP/SP1, Mozilla 1.7
No response from reporter. Seems to be a dupe of Bug 159107 or Bug 132755. Please resolve it if you agree.
Yeah, duping to bug 159107 because there was no answer for months and no reason to assume it is not a dup. Martin Steen: look at the bugs mentioned in comment #7 for what causes your problem. In the future, you may just delete downloads.rtf to make downloads get faster again, the file will be re-created. *** This bug has been marked as a duplicate of 159107 ***
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
(In reply to comment #8) > Martin Steen: look at the bugs mentioned in comment #7 for what causes your > problem. In the future, you may just delete downloads.rdf to make downloads get > faster again, the file will be re-created. ... or if you don't need the download history for more than one browser session simply write-protect the (emptied) file in your profile. Then it will never be saved.
You need to log in before you can comment on or make changes to this bug.