46136 - Ftp hangs browser if there is no activity for a short time

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Barrett Lindstrom]

From Bugzilla Helper:
User-Agent: Mozilla/4.73C-CCK-MCD NSCPCD473 [en] (X11; U; HP-UX B.11.00
9000/785)
BuildID:    

On Hpux 11.00, ftp will hang the browser if you log into an ftp server and do
nothing for a period of time, then try to browse thru a directory.

Reproducible: Always
Steps to Reproduce:
1.  Start browser
2.  In the location bar, type "ftp://sweetlou".  Hit enter to go to the site
3.  WAIT for 7 - 10 minutes after the site has displayed.
4.  Click on a directory to enter it and browse.


Actual Results:  The browser hangs and quits responding.  

The following text is displayed in the terminal window:

Entry at index 0 is ftp://sweetlou
WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line 404
Document: Done (3.104 secs)
*** check number of frames in content area 
Error getting url widget service: TypeError: Components.classes[progid] has no
properties
Document ftp://sweetlou/ loaded successfully
directory.js: Init()
base URL = ftp://sweetlou/
WARNING: not calling OnDataAvailable, file nsAsyncStreamListener.cpp, line 404
Assertion failure: mIPv6Checked == PR_FALSE, at nsFtpConnectionThread.cpp:173
							

Expected Results:  Not sure what is expected, but it should either get a message
that the connection has timed out, or just continue browsing thru the
directory.  Linux just continues to browse.

Comment 1

[kzhou]

This is a cross platform bug. It happens to Linux debugging build, too. I 
haven't try windows, yet. The main reason this bug happens is when the
memory usage grows to high enough for a ftp connection, such as a Linux 
debugging build or a HP-UX build, the process in nsFtpConnectionThread.cpp
file, nsFtpConnectionThread::Process() function gets into
case FTP_ERROR:
	...if (mResponseCode == 421 && 
                    mInternalError != NS_ERROR_FTP_LOGIN) {
                    // The command channel dropped for some reason.
                    // Fire it back up, unless we were trying to login
                    // in which case the server might just be telling us
                    // that the max number of users has been reached...
	......
and the ftp connection needs to be reset. Then the process goes to 
CASE HFTP_COMMAND_CONNECT:
	......
However, there is a variable mIPv6Checked has been set up as PR_TRUE to make
sure the server's protocol is a IP version 6 before the command channel dropped
and it never has been reset as PR_FALSE! So when the process hits
PR_ASSERT(mIPv6Checked == PR_FALSE); at nsFtpConnectionThread.cpp:173
The browser either hangs or crashes. I have a fix but I can't find information
to get a right person to review it. Jim, do you know who I should go. Those
mozilla/netwerk/protocol files seems so clean that I could not find anybody
had a check in.
I tested this fix for both Linux and HP-UX.
trieste>cvs diff -c nsFtpConnectionThread.cpp
Index: nsFtpConnectionThread.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v
retrieving revision 1.125
diff -c -r1.125 nsFtpConnectionThread.cpp
*** nsFtpConnectionThread.cpp   2000/07/25 05:45:38     1.125
--- nsFtpConnectionThread.cpp   2000/07/28 18:58:57
***************
*** 295,300 ****
--- 295,304 ----
                      // that the max number of users has been reached...
                      mState = FTP_COMMAND_CONNECT;
                      mNextState = FTP_S_USER;
+                   //fix for bug #46136
+                   if (mIPv6Checked) {
+                       mIPv6Checked = PR_FALSE;
+                   }
                  } else {
                      PR_LOG(gFTPLog, PR_LOG_DEBUG, ("%x Process() - ERROR\n", m
URL.get()));
                      rv = StopProcessing();
trieste>

Comment 2

[kzhou]

       From: 
             Judson Valeski <[e-mail]>
 Organization: 
             Netscape Communications
         To: 
             Gagan Saksena <[e-mail]>
         CC: 
             Kevin Zhou <[e-mail]>
  References: 
             1
Gagan Saksena wrote: 

  Jud this seems ok to me... but can you just do a quick look-see to say if this 
is ok. 
  Thanks!

r=valeski. Please remove the comment in the code about "// fix for 46136" 
though. CVS does all this for
us (if you specify the bug in the checkin comment) and the comments clutter up 
the code. 

Jud 

Jim, I don't have seamonkey account to check in the code. Would you please do
that?

Comment 3

[kzhou]

Approval: Leaf.

fix checked in.
Checking in nsFtpConnectionThread.cpp;
/cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v  <-- 
nsFtpConnectionThread.cpp
new revision: 1.126; previous revision: 1.125
done

Comment 4

[Tom Everingham]

verified