Closed Bug 53429 Opened 24 years ago Closed 24 years ago

FTP d/l stalls 1 out of 5 times

Categories

(Core Graveyard :: Networking: FTP, defect, P1)

Product:
Core Graveyard
Component:
Networking: FTP
Platform:
PowerPC
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 60509
Milestone:
mozilla0.9.1

People

(Reporter: mikepinkerton, Assigned: dougt)

References

Details

- go to sweetlou to d/l the packaged bits - dbl-click to start the ftp download at least 1 out of 5 times (many times more often), the d/l will just stall and never complete. this has been happening for months, i guess i was hoping i was on crack or it would get fixed.
this makes it _very_ hard to d/l installed bits with the product, making me use 4.x to do it. That's dogfood to me.
Keywords: dogfood, nsbeta3
didn't get fixed? hmm... that means you must be on crack :) just kidding. ->rjc. Giving this a plus and marking P2.
Assignee: gagan → rjc
Priority: P3 → P2
Whiteboard: [nsbeta3+]
Yes, this is an evil bug... but as I understand it, you can try again (when it stalls) and get it to complete 4 out of 5 times?? I think I've seen the same problem with 4.x for years on Windows (some percentage of the time the download hangs, and I have to cancel and restart). Marking dogfood-minus, since the work-around is easy and obvious. IF I misunderstood, and the *app* hangs (and you can't cancel/restart the download), then I'd agree this is dogfood-plus.
Whiteboard: [nsbeta3+] → [nsbeta3+][dogfood-]
Hmmm... reverting to revision 1.10 of mozilla/xpcom/threads/plevent.c seems to make this happen much less frequently (although, still occasionally; it happened for me once in over a dozen downloads after reverting.) Doug, I'm going to bounce this bug over to you to investigate further your changes regarding event ordering.
Assignee: rjc → dougt
Is this MAC only? If so, it has nothing to do with my plevent changes since the mac does not have native notifications.
Target Milestone: --- → M18
pdt agrees p2.
back to rjc. Robert, can you try that patch I mailed you last night (also posted on the xpcom newsgroup) regarding nested events queues?
Assignee: dougt → rjc
dougt, I applied your patch on my Mac (obviously, not the GTK parts of the patch) and FTP'ing seems to work better for me now... couldn't get it to stall. So, looks good.
Assignee: rjc → dougt
Adding PDTP2 per selmer/PDT comment of 9/21
Whiteboard: [nsbeta3+][dogfood-] → [nsbeta3+][dogfood-][PDTP2]
patch in 52667 as well as the xpcom newgroup.
Is it really really critical that we have this for PR3? Could we get some QA confirmation that either the Mac installer works ok for PR3 or that it's completely broken?
Depends on: 54371
yes, will check out.
this has nothing to do with the installer, and everything to do with FTP.
I agree with Mike, Mac Installer is behaving and installing successfully, - used todays M18 installer to test this. This is FTP issue, however, I am not failing - 10 out of 10 downloads so far of MN6 branch bits
I just failed on about my 9th attempt downloading a .gz file. Confirming there is a problem.
i just tried to d/l the installer (200K) and it stalled. ugh. this is almost 50/50 for me these days.
failed again after another dozen or so tries this time downloading a .bin file. If you cancel after the lockup you can continue downloading until the next failure. mac os9 2000092711
PDT marking nsbeta3-, nominate for rtm if appropriate.
Whiteboard: [nsbeta3+][dogfood-][PDTP2] → [nsbeta3-][dogfood-][PDTP2]
nominating for rtm. Downloading should be more reliable than this.
Keywords: rtm
I Checked in a fix for this and this problem should be gone now. Please verify with either tomorrow Trunk or NSCP Branch build.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
This is still not working for me on mac os9 2000-10-05-13-MN6. Stalled out twice in about 15 or so attempts. re-opening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I am not sure that this is an event problem anymore. You might want to try reverting the changes to the threadpool. reassigning to rjc.
Assignee: dougt → rjc
Status: REOPENED → NEW
Would this have anything to do with the fixes for bug 36750? Could anyone with this problem (Hi, Pink!) try the patch in that bug and see if it gets better?
Whiteboard: [nsbeta3-][dogfood-][PDTP2] → [nsbeta3-][dogfood-][PDTP2][rtm need info]
that patch is too big for me to apply by hand, has it already landed on the trunk?
Yes, it has landed on the TRUNK. Can't you use MPW's patch tool?
Giving dougt some bug luv'in... as this smells like an event problem.
Assignee: rjc → dougt
fwiw, this still happens to me regularly with branch builds.
3 out of 3 stalls, trying to d/l the bits: ftp://sweetlou/products/client/6.0x/macos/8.x/ppc/2000-10-11-10-MN6/MacNS6FullInstaller.sea.bin it normally (frustratingly) get's 80% of the way through this large d/l then stalls out, wasting even more of my time.
pink, is this mac only?
at least mac, dunno about anything else. just stalled again. that makes 4 for 4 today on d/l's larger than 200K. this is dogfood for me i can barely download builds to test!
Priority: P2 → P1
Whiteboard: [nsbeta3-][dogfood-][PDTP2][rtm need info] → [nsbeta3-][PDTP2][rtm need info]
Ok... I'm convinced... 4 for 4 is bad. (I'm assuming this is on the branch, which is really the critical item currently for the netscape staff that would be diverted to this bug).
OS: All
Whiteboard: [nsbeta3-][PDTP2][rtm need info] → [nsbeta3-][PDTP2][rtm need info][dogfood+]
And no progress on this after 10 days?
Whiteboard: [nsbeta3-][PDTP2][rtm need info][dogfood+] → [nsbeta3-][PDTP2][rtm need info][dogfood+] FIXED ON TRUNK
gordon, do you have time to look at this?
I'm working on a security bug at the moment. Status Whiteboard says this was fixed on the trunk. Who? What? When? Where? How? Why hasn't it been applied to the branch?
jce2@po.cwru.edu marked it fixed on trunk. jce2@po.cwru.edu what gives??
cc: jce2@po.cwru.edu What about your "FIXED ON TRUNK" in the status whiteboard? Wrong bug maybe?
Huh? Bonsai referenced this bug, but I don't quite remember when I marked it fixed on trunk, I just remember that there was SOME check-in related to this one.
Whiteboard: [nsbeta3-][PDTP2][rtm need info][dogfood+] FIXED ON TRUNK → [nsbeta3-][PDTP2][rtm need info][dogfood+]
still stalling on my os9 system - this time after about 20 trys 10/30 branch
the bigger the file, I've found, the greater the chance you'll stall. That's why downloading the full install bits triggers this a lot. I've heard rumors that we also stall downloading large quicktime movies. Probably the same issue.
can this be reproduced when you just list the contents of an FTP directory? Or does this only happen when you try to download a particular file? What I am getting as is, could this be a problem with the Save As code and not FTP? Pinkerton, can you browse around ftp://ftp.mozilla.org/pub sucessfully?
yes, i can browse FTP just fine. it's in the downloading of files over FTP that stalls.
but FWIW, i don't know of many ftp directory listings that are 12MB in size, or anywhere close to large enough to stall....so I don't think this really tells us anything.
Questions: 1. How long do the downloads go before they stall? Seconds? Minutes? 2. What are you doing in the meantime? Surfing web pages, downloading another file, reading mail?
1. it varies how long before they stall, but in the "seconds" category, given that downloading most files around here (on our network) rarely takes minutes. If it takes 30 seconds, say, to D/L the full installer bits, it will fail anytime in that period. Sometimes after 5 seconds, sometimes after 25. 2. Doing nothing in the meantime. It happens even when I don't move the mouse during the download.
ok, I added that "FIXED ON TRUNK" notation after the comments of 10/6.
Doug, was anything ever checked in on the trunk? Is there a patch that can be attached to this bug for reviews? Adding mscott in case this is download dialog related. Adding Jud to see if this can get some immediate attention.
I've seen this before to and i started debugging it one day. It seems to be a problem with ftp. The uriloader just stops getting OnDataAvailable events on its thread. Related to 57679 maybe?
Could we get some sort of updated confirmation of how and when this bug manifests itself with current builds? If we are worried about getting our bits installed, then users can use our installer which does the download without using the browser FTP, in which case we might be able to minus this.
rtm-, not stopper.
Whiteboard: [nsbeta3-][PDTP2][rtm need info][dogfood+] → [nsbeta3-][PDTP2][rtm-][dogfood+]
ftp bug. no time to play. assigning to gagan.
Assignee: dougt → gagan
*** Bug 50474 has been marked as a duplicate of this bug. ***
ftp bugs to component:ftp
Assignee: gagan → dougt
Component: Networking → Networking: FTP
Target Milestone: M18 → M19
Blocks: 62352
This bug was marked to be fixed in a previous milestone but it didn't get fixed properly. Nominated for beta1.
Keywords: nsbeta1
this happened to me today with a 1/4 build with http download. any eta? there's no target milestone.
Pink, if this is happening with HTTP as well, please file a seperate bug. As for the ETA of ftp, I have reduced the number of threads that it uses down to zero (it now uses the socket transport thread). I have reviewed diffs ready to go, but I still need to get it working/tested on the mac. After that, I should check it in. But note that the premise I am working on is the Mac FTP is slow because it uses many threads; I have no hard evidence that this is the case. I will no more when I try my new code on a mac. If you are interested in help, please let me know. I could use a mac guru on my side.
Could someone familiar with this bug investigate the possibility of it being a dupe of bug 60509? I don't think it is, but someone suggested it, and I figured who better to determine this than someone familiar with 53429?
I landed a rewrite of ftp which may address this problem.
I tried the 1/29/01 build and no matter how hard i tried, I couldn't get this sucker to stall on ftp downloads. I even downloaded two 15MB files concurrently and both came through just fine. Anyone else? I'm tempted to say doug fixed it.
not sure about ftp, but http still stalls for me with 1/29 builds. did we ever determine if that was a separate issue?
Pinkerton, Check out bug 60509. It is an http transfer of a 135MB file, and it keeps stalling with build 2001012608.
I stand corrected. it stalled for me today, build 1/31/01 on my powerbook downloading a 2MB file from ftp.interarchy.com. So it is _not_ fixed.
This bug should be fixed my recently checked in necko changes.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Doug T, Would your checkins also have fixed bug 60509? If so, when is the first build with your changes being released so I can check it?
The fixes would be in today's build. I have not verified that specific bug fixed. ALso, I believe that simon and I found that this bug is possibly still not closed. Simon, did we reproduce this stall w/o your nspr timer changes?
well, i haven't seen it stall (yet) but the max speed is 60k/sec to sweetlou. opening another bug on that one.
dougt: we stalled on a big HTTP download. FTP was so slow that we didn't wait long enough. Verifying this bug is therefore blocked by slow FTP performance.
Depends on: 69836
sfraser says it still stalls with a more normal buffer size. reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
We even seem to stall when doing directory listings etc, tho this may be a different issue. Getting FTP listings is generally unreliable.
i've seen that as well. most of the time i only get 1/2 the contents of a folder when i dink the triangle. the 2nd time, i get the full contents.
The directory view has a bunch of problems which will led you to a stall. So, there is a difference between a file download stall and a directory listing stall. I am going to have an option to toogle the directory view on and off. When off, ftp will produce html instead of html-indexed.
Keywords: nsbeta3, rtm
Whiteboard: [nsbeta3-][PDTP2][rtm-][dogfood+]
Target Milestone: --- → mozilla0.9.1
Maybe the patch in bug 70408 fixes this? If I could get FTP to work at all, I'd test it.
Keywords: dogfood → nsdogfood
this does still happen, and what is worse is that we _think_ the download completes, but the entire file isn't there! I've twice seen necko fall 4-5MB short of the full d/l even though the progress dialog goes away and the file is renamed! (note, this is with ftp) 3/21/01 build, mac os9.
actually, you will need to update mozilla/netwerk/protocol/ftp and rebuild necko2.
Marking 60509 as a dup of this bug *** This bug has been marked as a duplicate of 60509 ***
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.