23933 - Mozilla Crashes downloading multiple files

Status: VERIFIED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Ken Beattie]

I use WinNT 4.0 with SP5 on a HP Vectra VL Pentium2-350 with 128Mb of RAM. I'm
using Milestone 12 (build ID 2000010308).

Every time I try to download more than one file at a time the second download
will start and within a second or two Mozilla locks up. No Mozilla windows are
active and they don't refresh if I alt-tab to something else and back again.
Task manager reports Mozilla as "Not responding". I've tried leaving the
downloads for several minutes to see if they complete but they haven't. Each
time I have to use "end task" in Task Manager to shut down Mozilla.

The problem is not isolated (for me) - it happens *every* time I try to download
two files at once.

Comment 1

[leger]

tever, can you check this out please?

Comment 2

[Warren Harris]

Jud: did you just fix something like this?

Ken (the bug reporter): What exactly were you trying to download? ftp, http,
what URLs...?

Comment 3

[Warren Harris]

From Ken Beattie...

Do I reply to this email or use Bugzilla to reply? If I'm supposed to use
Bugzilla I couldn't find where, sorry.

In any event I just tried the following files;

http://tucows.kewl.com.au/files4/djdemo11.exe
http://tucows.kewl.com.au/files3/Digital-AMP-Setup.exe

They can be reached by this page: http://tucows.kewl.com.au/mp395.html

And Mozilla has locked up. The first file was approximately 30% into the
download when I attempted to save the second. After the second "Saving File"
dialog appears Mozilla locks up.

The debug code in the Mozilla DOS window is as follows;

Start Paste------>

Error loading URL http://tucows.kewl.com.au/files4/djdemo11.exe
WEBSHELL+ = 9
WEBSHELL- = 8
nsLayoutHistoryState::AddState OOPS!. There was already a
state in the hash
table for the key
nsLayoutHistoryState::AddState OOPS!. There was already a
state in the hash
table for the key
nsLayoutHistoryState::AddState OOPS!. There was already a
state in the hash
table for the key
Error loading URL
http://tucows.kewl.com.au/adnload/dldigitalamp95.html
Document: Done (4.466 secs)
DocLoaderFactory: Unable to create ContentViewer for command=view,
content-type=application/x-msdos-
program
Document: Done (0.381 secs)
WEBSHELL+ = 9
JavaScript Error: ReferenceError: onUnload is not defined

Error loading URL
http://tucows.kewl.com.au/files3/Digital-AMP-Setup.exe
WEBSHELL+ = 10
WEBSHELL- = 9
JavaScript Error: ReferenceError: onUnload is not defined

<-----End Paste

I've left the system for approximately 15 minutes (which should be enough
time for the downloads to complete) and it's still locked up. NT Task
Manager reports the Mozilla browser & the 2 file saves as "Not responding"
but the DOS Mozilla Seamonkey Process is still running OK. The Processes
List shows Mozilla with 0% CPU (and it doesn't change).

I've killed the Mozilla process and restarted and retried the same files.
The same error occurs. The error occurs consistently whether I reboot the
machine between retries or not. I can pick any two files on http and they
lock up.

I've also tried it on FTP files and encountered the following problems;

Firstly, it won't display an FTP site. I tried Mozilla's FTP, ftp.cdrom.com
and ftp.telepac.pt and none of them display in the browser window (another
bug?). The title changes correctly but the browser display doesn't change. I
tried viewing the source of the page but it didn't work either. The Debug
Code is;

Start paste ------->

Document http://www.cdrom.com/ loaded successfully
Document: Done (16.804 secs)
failed to set the page title.
Document ftp://ftp.cdrom.com/pub loaded successfully
Document: Done (40.578 secs)
BrowserViewSource();
WEBSHELL+ = 5
JavaScript Error: ReferenceError: Shutdown is not defined

nsXULKeyListenerImpl::Init()
WEBSHELL+ = 6
Setting content window
browser.startup.page = 1
startpage = http://www.mozilla.org/
Loading page specified via openDialog
Check if a view source window
 A view source window
failed to set the page title.
Error loading URL ftp://ftp.cdrom.com/pub
Document: Done (39.097 secs)

<-------End paste

I then tried to download two files from ftp sites via links on a web page -
http://www.3dfiles.com/utility/3dexplorer.shtml

The files are;

ftp.cdrom.com/pub/3dfiles/utility/3dexplor.exe
ftp.telepac.pt/pub/3dfiles/utility/3dexplor.exe

Unfortunately, I have been unable to recreate the original bug. There seems
to be another problem and Mozilla crashes (it completely shuts down, rather
than just locking up) when I try to access two of these files at once.

Notes:

I used two Mozilla Browser windows purely for convenience in opening two
files at once. The problem happens even if I try two
downloads with only one Mozilla Browser window open. Also, I currently have
a virus scanner running (Cheyenne Innoculan) and Microsoft SMS, plus
whatever other standard processes NT uses.


Ken Beattie

Comment 4

[Judson Valeski]

Interesting (I tested FTP). This has something to do w/ the way the unknown 
content handler is fired up (basically pointing to URI dispatching). Once you 
get one download going, the second one won't even begin until the first stream 
transfer dialog closes (via a cancel or normal completing). It's almost as 
though the second request never makes it into the UI eventQ.???

Comment 5

[Judson Valeski]

just tried HTTP. Same issue. This has to do w/ URI dispatching.

Repro steps (http or ftp) for lockup (probably ends in a crash at some point):
1. File->Open Web Location. Insert http://tucows.kewl.com.au/files4/djdemo11.exe 
and "open" it.

2. notice download begins all nice and dandy. File->Open Web Location. Insert 
http://tucows.kewl.com.au/files3/Digital-AMP-Setup.exe and "open" it.

3. The first download stalls, and the second save as dialog never even opens.

Repro steps (http or ftp) to illustrate dispatching problem:
1. File->Open Web Location. Insert http://tucows.kewl.com.au/files4/djdemo11.exe 
and "open" it.

2. notice download begins all nice and dandy. File->Open Web Location. Insert 
http://tucows.kewl.com.au/files3/Digital-AMP-Setup.exe, select "new navigator", 
then "open" it.

3. the first download continues just fine, when it's cancelled or it complets, 
the second download starts up.

I'm re-assigning to rpotts.

Comment 6

[Judson Valeski]

*** Bug 24636 has been marked as a duplicate of this bug. ***

Comment 7

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 8

[rpotts (gone)]

I bet that there are several things going wrong here...
1. The URI loader is probably incorrectly targeting the unknown-content-type 
loads.  I wouldn't be suprised if it is trying to cancel the first load when the 
second one comes in...
2. The unknown-content-type handler (ie. the save as window) is probably still 
synchronous.
3. The unknown-content-handler is probably not set up to handle multiple 
instances...

I'll take a look at it and see what's really going on.

Comment 9

[Alan S. Jones]

Looking at other bugs I was wondering if this bug could be related to bug 28153 
both bugs refer to multiple browser windows/threads going.

Comment 10

[Joseph Elwell]

*** Bug 24591 has been marked as a duplicate of this bug. ***

Comment 11

[leger]

valeski - can we avoid the crash here?  We could relnote for beta1.

Comment 12

[Judson Valeski]

I can't repro the crash.

Comment 13

[leger]

Putting on PDT+ radar for beta1.  PDT believes this is a works for me.

Comment 14

[Bill Law]

See also bug 31804.  That bug seems to make it impossible to reproduce this one 
and might be another symptom of the same problem.

Comment 15

[Tom Everingham]

I can't reproduce this either but waiting on 31804 before closing. 

Comment 16

[Tom Everingham]

I am not seeing a crash but I cannot download multiple files as described in bug 
32554 (which I just opened).  According to B.Law the crash problem with 
downloading multiple files is probably gone as the result of fixing bug 31804.  
But the changes may have affected some other areas and may be blocking me from 
getting to the point where this can be checked.  Waiting on 32554 for now.

Comment 17

[leger]

Marking Verified for the crash.  32554 will handle verification to make sure 
this works once fixed.

Comment 18

[benc]

-relnote.