Hang when finishing the download.
Categories
(Toolkit :: Downloads API, defect)
Tracking
()
People
(Reporter: of_rings, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(4 files)
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Avant Browser; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MEGAUPLOAD 2.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/2.0.0.14;MEGAUPLOAD 1.0 I was downloading files and when they were going to finish Firefox just didn't respond. It freezed completely. It also freezed my desktop and entire computer. So im reporting this using Avant Browser. It will be lame that Firefox crashes just when im reporting this... P.S: It also crashes on some Flash .swfs and on some Youtube videos..... P.P.S: Info doesn't show... It just says: "Doesn't respond" then it suddenly exits without showing any another window. Reproducible: Always Steps to Reproduce: 1.Download a file 2.Wait for it to finish. 3.Look and see at the bug. I was using Aero Fox 3.0.1 theme... As it wouldn't let me install the new one. And yes the bug still occurs with the default theme. No talkback crash ID... It didn't show any Talkback or w/e window. My computer's configuration? Default always. Sorry no stack traces found or HTML testcases. My build configuration is: --enable-application=browser --enable-update-channel=release --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc --with-crashreporter-enable-percent=25
Not a security bug.
Comment 2•16 years ago
|
||
Do you have any extensions installed?
Reporter | ||
Comment 3•16 years ago
|
||
I uninstalled them all and it still crashes. Reinstalled Firefox but still crashes. O.O
Assignee | ||
Updated•16 years ago
|
Comment 4•16 years ago
|
||
Have you yet upgraded to Firefox 3? If so, does it still crash? (It might bring up Breakpad, if so.)
Reporter | ||
Comment 5•16 years ago
|
||
Ok, i upgraded to Firefox 3 and this is still buggy. It still crashes. And no, it doesn't bring up Breakpad. It just freezes, just like Firefox 2.
Comment 6•16 years ago
|
||
A freeze is not a crash; that's a hang. Sadly, I can't reproduce with the information given here.
Hi -- I'm seeing the hang also, its intermittent on my Vista32 SP1 laptop but it only happens once a download finishes, using FF 3.0.7. Was able to grab a crash dump during the hang using ADPlus, let me know if you guys are interested in the dump. Thanks, Patrick
Comment 8•15 years ago
|
||
(In reply to comment #7) > I'm seeing the hang also, its intermittent on my Vista32 SP1 laptop but it only > happens once a download finishes, using FF 3.0.7. Was able to grab a crash > dump during the hang using ADPlus, let me know if you guys are interested in > the dump. Yes, please attach it to the bug.
(In reply to comment #8) > (In reply to comment #7) > > I'm seeing the hang also, its intermittent on my Vista32 SP1 laptop but it only > > happens once a download finishes, using FF 3.0.7. Was able to grab a crash > > dump during the hang using ADPlus, let me know if you guys are interested in > > the dump. > Yes, please attach it to the bug. The user-mode dmp is ~65MB, bugzilla won't allow me to attach, is there a FTP that I can upload to? Thanks.
Comment 10•15 years ago
|
||
Hrm - no there isn't. Can you zip or tar it up to be small enough? (unlikely, I know)
Comment 11•15 years ago
|
||
(In reply to comment #10) > Hrm - no there isn't. Can you zip or tar it up to be small enough? (unlikely, > I know) I used the max compression with 7z which yields ~65MB. :-( Bugzilla returns a msg during the upload: "The file you are trying to attach is ... in size. Non-patch attachments cannot be more than 1024KB, etc etc..." Thoughts?
Comment 12•15 years ago
|
||
Can you get just the stack of the threads from that dump? That's really all we need. If not, find somewhere to upload it.
Comment 13•15 years ago
|
||
Attaching ADPlus analysis with all threads & their stacks dumped
Updated•15 years ago
|
Comment 14•15 years ago
|
||
Oh, you don't have symbols. Can you point it at the symbols mentioned here so we can get useful stacks please? https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server
Comment 15•15 years ago
|
||
Thanks for the FF symbol server, attached new log. - !analyze -v -hang - dump all threads and their stacks
Comment 16•15 years ago
|
||
rob(s) - any idea what is up with these hangs?
Comment 17•15 years ago
|
||
Regretfully no... perhaps Jim does
Comment 18•15 years ago
|
||
Any anti-virus programs running on this machine? If so you can try to disable them temporarily to see if that might be the cause. It doesn't look like the built in Fx virus scanning is a part of this though.
Comment 19•15 years ago
|
||
Yes I do have Norton IS 2009, but the bug is intermittent and not always reproducible. So if I disable my AV, it'll have to be disabled for a while and I don't prefer that. :-( Was there any questionable threads in the log file that pointed to AV? Thanks.
Comment 20•15 years ago
|
||
Perhaps you can test by setting the browser.download.manager.scanWhenDone pref to false. Type about:config in your url bar to get to those prefs: http://kb.mozillazine.org/Browser.download.manager.scanWhenDone
Comment 21•15 years ago
|
||
(In reply to comment #20) > Perhaps you can test by setting the browser.download.manager.scanWhenDone pref > to false. Type about:config in your url bar to get to those prefs: > http://kb.mozillazine.org/Browser.download.manager.scanWhenDone It might, but according to the dump, his scanning thread was idle.
Comment 22•15 years ago
|
||
Guys, as suggested, I've disabled browser.download.manager.scanWhenDone, FF still hanged after download a couple of days ago. Attaching analysis from dump
Comment 23•15 years ago
|
||
This is happening when an open file handle is being closed - 001bf7ac 76a3cc2e 000008d8 066da840 001bf7d8 ntdll!ZwClose+0xc 001bf7bc 600ce388 000008d8 066da840 600c7905 kernel32!CloseHandle+0x40 001bf7c8 600c7905 0491aee0 600da220 00000000 nspr4!_MD_CloseFile+0x8 [e:\fx19rel\winnt_5.2_depend\mozilla\nsprpub\pr\src\md\windows\w95io.c @ 463] For me this tends to point to something external like a virus scanning app.
Comment 24•14 years ago
|
||
Pretty sure it is. The problem is that the whole app hangs, not just the download. Dupe to my bug 551427?
Comment 25•13 years ago
|
||
Definitely it is caused by antivirus scanning, in my case for some days, until something happened, nod32 used 99% cpu.
Comment 26•13 years ago
|
||
Yes, after the download of a big file, for example 2 GByte, Firefox freezes all open sessions during the virus scan of the big file. It takes up to 5 minutes depending on the filesize. It does not matter which virus scanner you use. I use F-secure and have also the problem. If you have multiple downloads wich such sizes, Firefox freezes several times and the only thing you can do ist to wait. Firefox should outsource the scanning to a thread, which work without freezing als browser windows. You can easilly check, if you install a virus scanner and download a big file 1-3 GByte.
Comment 27•13 years ago
|
||
Virus scanning has always been on a new thread in Firefox specifically for this reason. I believe on Windows Vista and higher we even turn down the IO priority for the thread.
Comment 28•13 years ago
|
||
It might be in a new thread, but I'm also seeing this hang, so I'm marking this bug to NEW.
Comment 29•12 years ago
|
||
I believe I am also seeing this hang, with the same stack as Jim Mathies mentioned in comment #23. I'm including this profile in hopes it might point to why this is hanging the entire browser (generated with the built-in profiler; I'm not sure how to copy/paste the text). I got this hang downloading a ~225 MiB file and, as you can see, it stalled the browser for about 20 seconds, almost all of which was in NtClose. Incidentally, I have browser.download.manager.scanWhenDone set to false.
Comment 30•12 years ago
|
||
(In reply to Rob Arnold [:robarnold] from comment #27) > Virus scanning has always been on a new thread in Firefox specifically for > this reason. I believe on Windows Vista and higher we even turn down the IO > priority for the thread. Modern anti-virus software will scan for viruses during file operations (including close(), apparently), independently of any virus scanning we initiate. So, even though we are initiating virus scanning off the main thread, the close() that happens on the main thread will trigger the virus scanning on the main thread. The solution is to close the file off the main thread.
Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)
Comment 32•1 year ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Comment 33•6 months ago
|
||
The severity field is not set for this bug.
:mak, could you have a look please?
For more information, please visit BugBot documentation.
Comment 34•6 months ago
|
||
I think the BackgroundFileSaver delegates the closing to NS_AsyncCopy, so I'd expect the file closing to happen off the main-thread today.
Jesup, could you please check to confirm the stream is no longer invoking FileClose() on the main thread, when BackgroundFileSaver::Finish
is invoked?
Comment 36•16 hours ago
|
||
I believe this is fixed
Description
•