Closed Bug 444467 Opened 16 years ago Closed 16 hours ago

Hang when finishing the download.

Categories

(Toolkit :: Downloads API, defect)

x86
Windows XP
defect

Tracking

()

RESOLVED WORKSFORME

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.
Group: security
Do you have any extensions installed?
I uninstalled them all and it still crashes. Reinstalled Firefox but still crashes. O.O 
Product: Firefox → Toolkit
Have you yet upgraded to Firefox 3?  If so, does it still crash?  (It might bring up Breakpad, if so.)
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.
A freeze is not a crash; that's a hang.

Sadly, I can't reproduce with the information given here.
Summary: Crash when finishing the download. → Hang when finishing the download.
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
(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.
Hrm - no there isn't.  Can you zip or tar it up to be small enough?  (unlikely, I know)
(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?
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.
Attaching ADPlus analysis with all threads & their stacks dumped
Attachment #366926 - Attachment mime type: application/octet-stream → text/plain
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
Thanks for the FF symbol server, attached new log.
- !analyze -v -hang
- dump all threads and their stacks
rob(s) - any idea what is up with these hangs?
Regretfully no... perhaps Jim does
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.
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.
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
(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.
Guys, as suggested, I've disabled browser.download.manager.scanWhenDone, FF still hanged after download a couple of days ago.

Attaching analysis from dump
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.
Pretty sure it is. The problem is that the whole app hangs, not just the download. Dupe to my bug 551427?
Definitely it is caused by antivirus scanning, in my case for some days, until something happened, nod32 used 99% cpu.
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.
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.
It might be in a new thread, but I'm also seeing this hang, so I'm marking this bug to NEW.
Status: UNCONFIRMED → NEW
Depends on: 551427
Ever confirmed: true
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.
(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!)

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.

Severity: critical → --

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(mak)

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?

Flags: needinfo?(mak) → needinfo?(rjesup)
Duplicate of this bug: 429789

I believe this is fixed

Status: NEW → RESOLVED
Closed: 16 hours ago
Flags: needinfo?(rjesup)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: