so it seems that FTP is broken on the mac... Mar26 MacMonkey build to repro: 1. launch apprunner 2. type in any valid url beginning with ftp:// -or- follow a link to an ftp site. 3. wait a sec. What should happen: You connect to the page and load up the resulting directory list. What does happen: It acts like things are fine by connecting to the page (read in status bar) then crashes -hard. clicking on the url link above will get you the same result. I went to mozilla.org and followed the perLDAP link about a pagefull down.

Hmm.. I'll grab a Mac weenie tomorrow and look into this more

Robert churchill looked at the ftp code before. Ah he is in hawaii now.

we need to release note mac ftp is not working for m4. moving to m5.

I added to release notes

problem still exists in 4/27 builds MAC, Okay on Windows/Linux.

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

Ah, this bug should have been the one marked as a duplicate of bug # 4702 as that bug has a lot more info (like a stack trace) and is owned by one of the Netlib guys. Reassigning this bug to Gagan for when the new Netlib lands.

don't be sidetracked by info from bug 4702. This bug is for tracking the Mac ftp:// crash behaviour. That bug contains a windows stack trace that must invlove a different crash/reason because it works fine now(1999042608) and Mac still crashes hard (reboot system).

Robert can you help investigate this one like a stack trace, hunch ! If we cant get this nailed, I have no option but to yank this one to M6 (read as wait for necko)

I can't easily get a stack trace as this bug locks up my Mac hard. The only option would be to basically start single stepping through Netlib to try and figure out the problem. Can we not wait for Necko? Let me know. Figuring this one out is a big investment of energy, especially if the code is going to be thrown away in a few weeks.

I see your point. Since ftp working is blocking two other groups, I would like to invest a few hours into seeing we can resolve this. But it proves to not lead anywhere after say 3 hours of work, I think waiting for necko would be the right thing. Once suggestion: i am hoping that the hard crash would happen after the last bytes are read in and the connection is being closed. That was the problem on win/unix that I fixed. Search for XXX in mkftp.c for wierdities I was seeing. Also, are we sure that both ftp directory and ftp access to say a .html file both core dump.

Notes: I can download a file via FTP on the Mac with no problem. Even the dialogs are working (althogh they look crappy right now.) FTP crashes *BEFORE* it finishes reading the directory, though. <Bummer.>

GOD DAMM this is some nasty code...

Wow, it wasn't a Netlib bug! Who would have thought that could be? This is basically the same bug and same bug fix as bug # 3405. Somebody needs to fix this all up for real... the current solution isn't something we could be proud of. I think we should make Kathy Brade do it (Hi Kathy!) as she introduced the bug. CC'ing brade. Also cc'ing sdagley as he is the guy who fixed # 3405 so he might know of the best way to clean this all up.

Just to note bug #3559 is currently assigned to me for cleaning up the #define to existing names mess but I'd be happy to give it to Kathy since it is currently deferred to M8.

ru or has it there is a build this evening (4/30) did this by any chance get checked in in time? When can I hope to see (and verify) it?

Claudius, I checked in my fix around 4:15 PM today (4/30/99).

VERIFIED for Mac Build 1999050308

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.