Closed Bug 126468 Opened 23 years ago Closed 23 years ago

crash when displaying FTP directory listing

Categories

(Core Graveyard :: Networking: FTP, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mcs, Assigned: Brade)

References

()

Details

(Keywords: crash, testcase)

Attachments

(3 files)

BuildID: 20020218 (my own build actually) The code that parses FTP directory listings assumes that it will receive data in a specific format. Unfortunately, if that is not the case, Mozilla may crash. Reproducible: Always Steps to Reproduce: 1. Find an FTP server that will return "something weird" in a directory listing. Unfortunately the example I have is only accessible by authenticated users inside the Netscape firewall (ftp://<id>@maize.mcom/com/%2Fu/mcs/tmp). There is a file in /u/mcs/tmp that causes ls -l (and FTP dir listings) to return an error message. 2. Enter the URL to the bad FTP location in the URL bar and hit return. 3. Crash inside PR_FormatTimeUSEnglish(), called from nsFTPDirListingConv::DigestBufferLines() because the time structure is not initialized.
+helpwanted, crash - problem is well described. Ron, I'm assuming you have the same problem on a different URL. If it is public, can you post it here?
Keywords: crash
-> ftp
Assignee: new-network-bugs → bbaetz
Component: Networking → Networking: FTP
I can't repro this, but the patch looks fine - we do it everywere else to prevent this crash. See bug 116170, too. What about the patch "needs more work" ?
The output produced is somewhat unusual, which is why I said the patch needs more work (perhaps lines in the LIST results that are not parsable should be ignored? I am not sure). But given the rarity of FTP reachable servers and directories that have this kind of problem, the patch is probably good enough. Much better than crashing.
Comment on attachment 70362 [details] [diff] [review] patch that prevents the crash (needs more work) r=bbaetz. While I can't reproduce this, not initing the value here was just an oversight.
Attachment #70362 - Flags: review+
-> patch author. Mark, you should mail darin@netscape.com, and cc reviewers@mozilla.org, aksing for superreview for this bug. I can check it in after that + approval, if you don't have a cvs account. This should probably be done soon so that it gets in for 1.0.
Assignee: bbaetz → mcs
Keywords: patch, review
brade said she would talk to Darin about this. Reassigning.
Assignee: mcs → brade
Comment on attachment 70362 [details] [diff] [review] patch that prevents the crash (needs more work) sr=darin (nice catch)
Attachment #70362 - Flags: superreview+
Comment on attachment 70362 [details] [diff] [review] patch that prevents the crash (needs more work) a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #70362 - Flags: approval+
fix checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
mcs: if this works now, can you mark VERIFIED?
Keywords: testcase, verifyme
Verified with Mozilla 1.0rc2 on Solaris (as far as I know, 1.0 final builds are not available yet for Solaris).
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: