Closed Bug 128553 Opened 23 years ago Closed 23 years ago

Download fails. It stalls when it is ~20-30% finished.

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 129364

People

(Reporter: pbergsagel, Assigned: sfraser_bugs)

References

(
URL
)

Details

(Keywords: qawanted, regression)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020301 BuildID: 2002030108 Go to http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/ and attptempt to download the latest nightly for OS X. The dowload will begin, but shortly after it has begun the download will stall when it is about 20-30% complete. I am able to download this file correctly using the 0.98 milestone. BTW I am connected to the internet through a cable Broadband Cable connection and common download speeds range from 100 to 140kb/sec. Reproducible: Always Steps to Reproduce: 1.Go to http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/ 2.Begin downloading Actual Results: The download fails. Expected Results: File should finish downloading. I am reporting this bug seperately from others which may be duplicates. The reason for this is that the duplictaes I have located are reported prior to 0.98. Prior to 0.98 I did not experience this bug. Also all of the duplictes I have located are for platforms other than the Mac OS X. Here are the similar bug reports, but I do not feel they are duplicates for the reasons stated above: bug 92239 bug 114877 bug 121532 . I am not connected to the internet through a proxy server.
Keywords: mozilla1.0, nsmac1
As I was posting this bug one thought came to mind: Is this bug not reported becuase it is not experienced unless connected to the internet with a broadband connection? Please do not mark this bug as resolved:worksforme until it has been tested by someone using a broadband connection.
Keywords: regression
The url you gave is http, not ftp. In any event, both WFM at about 260Kps. Have you got enough disk space? If you're running the macho build, then you need to have enough space in /tmp. -> file handling
Assignee: bbaetz → law
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
I'm not using the Macho build, I have 13.22 GB free on the Hard Disk Mozilla is installed on. I cannot remeber when i first started experiencing this bug, but it was shortly after the release of 0.98 release. Bradley how fast was your download. I gave upwaiting for the download to start up again after 5 minutes since I figured it was not going to happen. I download a new nightly each day. Each time Mozilla stalls and refuses to resume I launch Mozilla 0.98 and the download is over in ~2min. I also have 256 MB of memory installed so I don't beleive I am short in this department. This is a very annoying problem that may not be experienced by everyone.
As I said, it went at about 250 K per second, bot with the http linmk you gave, and the matching ftp url. However, I don't have a mac - that was on a linux machine, which is why I moved it to file handling.
/me notes that Bill Law recently made some changes to the DL progress window. Possibly related?
I'm having the same problem. It'll stall until you cause Mozilla to do some other type of network I/O (clicking a link, for example). This is a major problem and needs to be fixed ASAP.
There are quite a few dupes + similar bugs - see bug 128378, bug 121532, bug 128553, bug 114877, bug 128907 and several others I've seen recently, not including dupes. This is a mizture of http and ftp, so I don't think its protocol code. (Despite the server name, http://ftp.mozilla.org/ is http). Most of thse bugs are filed on networking, but there are a few in random other places. Some of the reports are older than others, though (114877 may not be related, but that bug is a bit of a mess) There are enough of these recently, + confirmation in the bugs by others, + the dupes, to suggest that something did break. I didn't see this earlier in the week on linux via http or ftp though, and other people don't see the problem to the exact same server using the same build. Reports have been on windows and mac. bz, you were playing with save as code recently. Any ideas?
Actually, 114877 isn't the mess, thats one of the others. Its still earlier, and was reported using 0.9.6+, so....
*** Bug 129094 has been marked as a duplicate of this bug. ***
Just for reference, this was the description for bug 129094, which was marked as a dupe of this bug. I think it describes the problem a lot better. -------START QUOTE------- On MacOS X, Build 2002030414 Steps to reproduce: 1. Attempt to download a large file 2. Download starts normally, and maximizes connection 3. Within seconds, download of file halts (most apparent using NetMonitor) 4. Download will temporarily resume upon broswer activity (ie click on a link etc) but again stops a few seconds after browser activity terminates If you surf long enough, download completes succesffuly. Clearly however, downloads should not be pausing on their own. --------END QUOTE--------
i cannot reproduce this using 2002.03.05.08 comm bits on mac 10.1.3. here is the test i'm using: 1. click on http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-macosX-trunk.smi.bin 2a. in the resulting helper app dialog, i select "save to disk". 2b. or, in the resulting helper app dialog, i select "open with Stuffit" (actually, this is the default selection on my machine). 3. click OK. 4. for (2a): selected the desktop to download on (in the resulting file picker) and clicked "save". results: for 2a: the file downloaded completely onto my desktop. for 2b: the file was downloaded and successfully decompressed/decoded by Stuffit. is this the correct test case for this bug? or, is this bug no longer a problem with the most recent trunk bits?
Using 2002.03.05.08, Mozilla preferences deleted, OS X 10.1.3, broadband connection (max: 240Kb/s) results for 2a: the file hung at 0%. I browsed to bugzilla, file download started. Halted when page finished loading, and hung at 7%. Observations: 1. Subsequent page loads (a second source of network i/o) trigers file download to resume. 2. Attempting a second file download (a second source of network i/o) causes Mozilla to resume first download and second download never pauses. 3. If second network i/o operation terminates before first file download is complete, that first file download halts once again. 4. If first file donwload is canceled or completes before second file download completes, second file download then halts itself. 5. File donwloads burst every ~32 seconds for a 1 second interval (second network i/o from somewhere in mozilla?) Reproducible following Step 2b. Reproducible in 0.9.9 branch.
This looks like core networking, then. Darin?
cc'ing sfraser... can you repro this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
if this is core networking, then over to that component for triaging. pls reassign as needed.
Assignee: law → new-network-bugs
Component: File Handling → Networking
Keywords: qawanted
QA Contact: sairuh → benc
Reporter (and other reproducers): please state what kind of machine you are testing on, in particular whether it is a dual CPU machine.
I reported this bug. I am using a Blue and White G-3 350 Mhz (single processor) with 128 MB of ram. I am currently running OS X 10.1.3 . I don't believe this bug is specific to dual processors. (For what it is worth: I am able to view Quicktime trailers at www.apple.com/quicktime . This bug does not effect the download of the trailer to the quictime p-lugin.)
not a duel processor machine here running PowerBook G4, 550Mhz, 512MB RAM
This has been occuring on my Ti550, OSX10.1.3 for at least a week. I didn't know about the workaround of clicking another link, but it indeed works.
i did some performance measurements for both ftp and http over several builds --the data are in bug 129364, which might be the same as or related (at least) to this one.
*** Bug 128378 has been marked as a duplicate of this bug. ***
i saw this problem this evening when i tried downloading the 7pm osx branch build. Since i was downloading over the intranet this would have normally taken about 4 seconds but instead it took a few minutes. According to the progress meter, a bit of it downloaded, then it stalled. Then some more downloaded, then it stalled again and then it finally finished. I think i was using a trunk build from feb twentysomething. I don't have access to the machine right now to be sure. i have a single processor 500mh g4. osx if this is in the branch i'd like to get either a fix or a relnote
Probably my NSPR poll changes. I'd appreciate it if someone could see when this regressed in OS 9.
Assignee: new-network-bugs → sfraser
this happens for me on osx with the feb26 build and today's osx 0.9.9 branch. It doesn't seem to be a problem with the intranet because the same file downloads quickly via ncftp on the command line.
One bit of information which may, or may not be useful. If I download a file with the 0.98 milestone and immediately launch the latestest nightly and immediately attempt to download the same file this file downloads very quickly and succeeds, even though the same nightly still fails on other files not recently downloaded. I am connected to the internet with a cable modem using os x 10.1.1.3 single processor Mac G-3.
We have a race condition in the NSPR code. Working on it...
Status: NEW → ASSIGNED
would like to get this for 0.9.9. adding it to the tracker so we don't forget.
Blocks: 122050
Duping to bug 129364 since that has better regression info. *** This bug has been marked as a duplicate of 129364 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.