Closed Bug 128553 Opened 23 years ago Closed 22 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: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.