Closed Bug 441052 Opened 13 years ago Closed 11 years ago
Crash then I save complete page with very many JPEG's (NEGATIVE speed) [@ xul
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.9) Gecko/2008052906 Firefox/220.127.116.11;MEGAUPLOAD 1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.9) Gecko/2008052906 Firefox/18.104.22.168;MEGAUPLOAD 1.0 - Build ID: 2008052906 Crash then I save complete page with very many JPEG's. Before crash show NEGATIVE download speed. Reproducible: Always Steps to Reproduce: 1. Open http://www.dleex.com/crimgs.php?dne=287&diup=74&dip=8701&pw=1014&hp=1544&s=0 2. Slow(!!!) scroll it to the end for load all JPEG's 3. File - Save as - Comlpete HTML Actual Results: 1. Show NEGATIVE speed in download manager. 2. Crash!!!!!!! 3. Crash report dont't send. Probally because very big use virtual memory. Expected Results: Save page and his JPEG on HDD. Disk cache device Number of entries: 409 Maximum storage size: 2000000 KiB Storage in use: 3413 KiB Cache Directory: F:\Documents and Settings\Jef\Local Settings\Application Data\Mozilla\Firefox\Profiles\default.s4u\Cache
Works for me, Firefox 3.0 on Linux. Jury, does the problem also occur in Firefox Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode
YES. I check Safe Mode - crash present. Additional details: On 31% of saving i see 44.1MB оf 153MB and speed 2.8MB/sec. On 95% of saving i see 32MB оf 23MB and NEGATTIVE save speed. Crash dump not saved probally becasuse FireFox Use above 400MB of memory and I don't have anouth virual memory for dump.
Jury, does it still happen for you with Firefox 3.0 or the beta version of Firefox 3.1?
Version: 1.9.0 Branch → 1.8 Branch
FireFox 3.0 I not test it on FireFox 3.1
Does it mean yes, it still crashes with the latest FF3 release?
Yes. See Crash report in http://crash-stats.mozilla.com/report/index/3baac82b-cd90-465f-b716-4551c2090120
Juri, there are some suspicious files in the list of modules. You should check those first if they are malicious software: switchit.cpl, PDFShell.RUS
Summary: Crash then I save complete page with very many JPEG's (NEGATIVE speed) → Crash then I save complete page with very many JPEG's (NEGATIVE speed) [@ xul.dll@0x24777]
switchit.cpl is a keyboard russian-englsh switcher PDFShell.RUS is Adobe Acrobat Activex from \Program Files\common files\Adobe\Acrobat\ActiveX\ They are not malicious software!
Ok, so please try to run your Firefox in Safe Mode or even with a fresh profile: http://support.mozilla.com/en-US/kb/Managing+profiles We have to make sure that it is not caused by an add-on.
(In reply to comment #9) > We have to make sure that it is not caused by an add-on. I am already sure - see comment 2. Now I again check in safemode - see http://crash-stats.mozilla.com/report/index/dd157b12-ff7e-4dfd-9ff6-8bbce2090121 and atached picture. Have you this crash or not in your firefox?
No, I'm not able to. Please remove both applications from comment 8 and do a test afterward. Probably one of them could cause this crash.
(In reply to comment #12) > No, I'm not able to. Please remove both applications from comment 8 and do a > test afterward. Probably one of them could cause this crash. It's wrong. Another crash in safe mode http://crash-stats.mozilla.com/report/index/48410026-4f8a-4e8c-8d85-45fb12090125?p=1 without this dll. Have any great idea, for example repeat this crash on your firefox?
Ok, I'm able to reproduce it now. While saving the page as complete after all the images have been loaded, the transfer rates are jumping up and down after a while. Means also negative values are shown. If you let the download run for a while, in my case about 2 mins, the browser hangs. Around 2 mins later it also crashed: bp-35f5b4a8-71cc-45b3-bbaf-0795b2090126 I'll try to get some more information from the stack.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.8 Branch → 1.9.0 Branch
Saving works fine with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:22.214.171.124) Gecko/2009011912 Firefox/3.0.6 But running a trunk build on OS X and doing the same steps lets the browser freeze completely. There is no crash happening so far. The negative speed is showed too for each of the above builds.
OS: Windows 2000 → All
Hardware: x86 → All
I not read firefox code, but i 25 year work in programming. Probally it is incorrect or null pointer. Look at memory usage on crash. At freeze firefox use near 2GB memory. It's limit on Windows system without 3GB extension. Probally on next memory get system give null pointer and firefox crash.
The hang I can see will probably happen because of bug 475078. We have to wait and see if the patch on that bug will also fix the crash.
Depends on: 475078
I Intall http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/firefox-3.0.7pre.ru.win32.installer.exe build at 28-Jan-2009 08:46. It work without crash and hung. But: 1) I see negative speed. See https://bugzilla.mozilla.org/attachment.cgi?id=359429 2) Firefox use 1.5Gb memory for saving this page. See https://bugzilla.mozilla.org/attachment.cgi?id=359430
Thanks Henrik Skupin and Daniel Holbert!!!! But hung on 1-2 minutes for memory eating is very big. Can anybody replace slow eating on fastfood? :)
Comment on attachment 359430 [details] Memory use grafic in 3.0.7 nightly build Befor negative speed - saving uses near 500 mb (left). Then it grow to 2GB and drop down to 500MB at the end pf saving.
That's interesting. The fix of the dependent bug wasn't checked into 1.9.0.x branch. So your crash has been fixed by another patch. Jury, can you please download a build from the upcoming FF3.0.6 and check if the crash is fixed there too? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.6-candidates/build1/ That would be very helpful. Thanks!
(In reply to comment #25) > Jury, can you please download a build from the upcoming FF3.0.6 and check if > the crash is fixed there too? > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.6-candidates/build1/ NO. I Don't know how install .MAR files. I will test http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/firefox-3.0.6pre.ru.win32.installer.exe at 20-Jan-2009 03:43 - probally it is the same
You have to scroll down. The build you need is nearly at the bottom. But here the complete link: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.6-candidates/build1/firefox-3.0.6.ru.win32.installer.exe TIA!
3.0.6 is like 3.0.7 - no crash, only temporary hang. 3.0.6 is litlle better 3.0.7, because it have hang shorter time.
(In reply to comment #27) > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.6-candidates/build1/firefox-3.0.6.ru.win32.installer.exe Test on it too???
No, this build is a day older. But you could do me a favor. Can you test how the latest trunk build behaves on your machine? Please do a backup of your profile before or better only run it inside a new profile! http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/01/2009-01-29-03-mozilla-central/
(In reply to comment #27) > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.6-candidates/build1/firefox-3.0.6.ru.win32.installer.exe It's the same as other 3.0.6. I see two intersting moment (in 3.0.6 and 3.0.7). 1) At the hang time in the download manadger I see words about "antivirus scanning". May be hang is the normal work of antivirus programm???? Test without it? 2) At saving the size of all page is decreases. Size of saved part is first grow, but then decreased too. It's give the neagtive speed
(In reply to comment #30) > Can you test how the latest trunk build behaves on your machine? O!!!!!!! 1) + No Crash! 2) + No Hang! 3) + No memory usage overhead - Line and litle gauss "impulse" at end. 4) - Negative speed present. 5) - Time to save - 6 minutes. 6) ? Probally, all images load from internet, not from cache/ 7) - Indicator is run left and right, left and right....
(In reply to comment #31) > I see two intersting moment (in 3.0.6 and 3.0.7). > 1) At the hang time in the download manadger I see words about "antivirus > scanning". May be hang is the normal work of antivirus programm???? Test > without it? You can toggle "browser.download.manager.scanWhenDone" to see if that helps. (In reply to comment #32) > 5) - Time to save - 6 minutes. What's you connection speed? > 6) ? Probally, all images load from internet, not from cache/ I can see this too. Even after the page has been finished loading. The cache is set to 50MB. Boris, could you have a look at this heavy site? > 7) - Indicator is run left and right, left and right.... Yes, this still happens on trunk.
Almost certainly due to the urls hash-colliding. Worth retesting once that bug is fixed.
(In reply to comment #34) > Almost certainly due to the urls hash-colliding. Worth retesting once that bug > is fixed. Do you have a bug number for the mentioned bug?
(In reply to comment #33) > (In reply to comment #32) > > 5) - Time to save - 6 minutes. > > What's you connection speed? 2MBit/sec
Bug 290032. Though honestly, you could have searched for "hash collision" as easily as I just did...
Depends on: 290032
I don't crash with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090424 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090424041640 and it only takes 1-2 minutes to finish (24 aDSL line with 15335 Kbps actual download speed), ... but I do see negative speed at some point and the progress bar moves to the left instead of right (keeps going back and forth during the process). Other things I've tried/noticed: - This is a rather big save (~55MB) with 105 +1 images to be saved. I am mentioning this because Henrik in comment #33 says the cache is set to only 50MB. So, I disabled the antivirus scan (as suggested in comment #33 again), increased the cache to 100MB, cleared the cache, restarted firefox and tried again. Again saved without a crash and took around the same around to finish as before the changes. - You need to scroll rather slowly and make sure that each image has at least started loading before scrolling further down. That is, if you want the entire page with all images fully loaded. - IE8 behaves the same way to display the page with all images loaded (need to scroll slowly and wait before moving to the next image), but instead of the less than 200-250MB of ram that firefox requires, it loads at 1400MB!!! This (I guess) is because once the user has scrolled a bit further towards the end of the page, firefox unloads the images at the very top, keeping the system memory use as low as possible. If once you've reached the end of the page and thus all images have loaded, you scroll to the top of the page really fast (using the mouse roller), you'll notice the memory jump to 700-800MB and then drop to ~200MB again once you've reached the top and stopped scrolling. - No matter how long it takes for firefox to save the page and despite the quirks in the Download Manager UI, now that it doesn't crash (at least not in the 3.6 nightlies I'm testing it)... No matter as I said, the page is actually saved, while in IE8 it only saves the main html page, the 'crimgs.js' and the 'tr.gif' files (none of the 105 images displayed in the actual page are saved). I don't know if this has anything to do with a relative msg displayed in ie8's status bar saying the page contains some error, but this is not ie bug reporting/fixing we're trying to do. Just mentioning this because it might actually be a thing with the page's code after all (site specific). As for the progress bar's back and forths, I guess this has to do with the download manager not knowing the # of total files or the total size that need to be saved beforehand. So, each time it starts downloading another file (the next image), it recalculates things and somehow that's where the issue lies. Don't know what might be wrong with the negative speed issue though. Hope my thoughts/tests will help. [Going to test on linux as well]
Firefox 3.6.8. No crash. Work good. But full size at the saving is changing in both side: 159-160-161-160-159-160...... (kb)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
P.S.Speed only positive - it's very good.
Good to hear that! But as long as we do not know which check-in has fixed this issue we have to close it as WFM.
Resolution: FIXED → WORKSFORME
Crash Signature: [@ xul.dll@0x24777]
You need to log in before you can comment on or make changes to this bug.