Closed Bug 14651 Opened 21 years ago Closed 20 years ago

[PP] [DOGFOOD] ftp not working on Mac

Categories

(Core :: Networking, defect, P1)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: paulmac, Assigned: gordon)

References

()

Details

(Whiteboard: [PDT+])

No directories or anything is showing up when I try to load
ftp://ftp.netscape.com or ftp://sweetlou or whatever on the Mac. It is treated
almost like a bad URL.

This is using 9/22 builds.

On linux and windows95, ftp://ftp.netscape.com loads the directory structure
correctly.
Target Milestone: M11
Subject:
             Re: Mac FTP debugging help
       Date:
             Mon, 27 Sep 1999 22:03:00 -0700
       From:
             Warren Harris <warren@netscape.com>
          To:
             Simon Fraser <sfraser@netscape.com>
         CC:
             Brendan Eich <brendan@meer.net>, pinkerton@netscape.com,
valeski@netscape.com, gagan@netscape.com
 References:
             1 , 2




Thanks Simon. Tomorrow might be a little tight, but I'll try to drop by.
Meanwhile, here's how you can reproduce it:

Set a breakpoint in nsFtpConnectionThread::Process on the switch statement
(in netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp in the ftp
dll/component). Then go to an ftp URL like ftp://ftp.netscape.com. You'll
see that the ftp connection thread doesn't wake up for quite a long time
(maybe 2 minutes), and when it does, the connection is always closed, so it
fails. Now the failure mode is a little screwed up unless Jud has fixed it,
but you can set a breakpoint in nsFtpConnectionThread::R_list in the same
file, in the if statement after the Read call. You'll see Read return 0
(meaning EOF) before it gets any data.

Call Jud for help too: 303-546-0061

Warren

Simon Fraser wrote:

> Brendan Eich wrote:
> >
> > Hey pink, necko guys need a little event/thread-level debugging help
> > on the Mac to figure out why ftp sucks there.  If you can't help 'em
> > cuz you're maxed out elsewhere, can you nominate someone for me to
> > bug?  From what I hear, it might be some intensive debug sessions but
> > not days worth of time.
> >
> > Maybe I should be asking sfraser, cuz he's on the Time team.
>
> I can look at this with warren, if he'd like to wander over to my cube
> sometime.
>
> Simon
Summary: [PP] ftp not hooked up on Mac → [PP] ftp not working on Mac
Assignee: valeski → gordon
Here's the basics of what happen here:
The main FTP connection opens fine (if a little slowly, because of some timeout
that happens on Mac when USE_POLLABLE_EVENTS is off.
This connection gets as far as the LIST command, whence it spawns the second
passive FTP connection. This second connection never completes the connection
stage; it just sits there until a disconnect.

After talking to gordon, I have a suspicion that this is because of the
USE_POLLABLE_EVENTS stuff that does not work on Mac. Could it be that having
two connections on the same thread results in one of them not getting
serviced?

I'm going to reassign this bug to gordon, because you have a better chance of
understanding this than I do. Also ccing rpotts, who knows about the
USE_POLLABLE_EVENTS.
Status: NEW → ASSIGNED
Priority: P3 → P1
The fact that sfrasier is seeing successful reads/writes on the command channel
indicates that there's a problem w/ > 1 connections (in blocking mode at
least) on the same thread on the mac.
ugh. we're seeing some interesting behavior. fraser and I watched ftp work just
fine (dir listing's showed up and we downloaded a file) this morning :\.

In my windows build I built w/ out USE_POLLABLE_EVENTS defined (as mac does) and
things worked. I don't think this means it's not the culprit on mac (because mac
threading is certainly implemented differently anyway), but I just wanted see
what would happen if I turned them off for windows.
Oh this is a great bug. I just used the same mac build that was failing
yesterday, and was able to view directoreis without incident. I saw some
sporratic behavior at ftp.microsoft.com (I was asked to authenticate when I
shouldn't have been).
I'm thinking that the state machine is somehow getting whacked on the mac, or
the ftp connection thread isn't being initialized properly.
Blocks: 17432
Summary: [PP] ftp not working on Mac → [PP] [DOGFOOD] ftp not working on Mac
Whiteboard: [PDT+]
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I'm able to view directories and download files with the latest version of
AppRunner.  There is still a problem after the file download has been completed,
the progress dialog doesn't go away, but this behavior is identical on all
platforms.  Bill Law indicates it is related to an xpconnect bug.
Status: RESOLVED → REOPENED
This only sorta works on the Mac.
For the MacOS86 1999120608 mozilla build, the first time you enter an ftp url, it
works fine.  If you try to drive deeper into the url (by typing in the location
field) or if you attempt to go to a different url (i.e. ftp://sweetlou/ then
ftp://ftp.netscape.com), there is no visible or functional response from the
browser.  To put it another way, the browser doesn't appear to be able to load
more than one ftp url per session.

Also tested and behaves correctly on:
	- Linux6 1999120608
	- WinNT 1999120608

Re-opening bug.
Resolution: WORKSFORME → ---
Target Milestone: M11 → M12
Clearing WorksForMe resolution due to reopen.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
This recent re-opening was really bug 20917 which I just fixed.
warren, when you say you just fixed it, does that mean it's a fix that we'll see
in tomorrow's builds?  Or is it something that was supposed to work in today's
builds?
Status: RESOLVED → VERIFIED
ok, Marking this verified because the original bug (as described in the
comments, not the summary field) appears fixed.  I will open a more
specific report for what Chris is seeing.  It does seem as though you
can only access one ftp site per session on both mac and nt.  1999120908
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.