From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; 0.9) Gecko/20010228 BuildID: 2001022809 After a time, browsing gets really slow (network connections in general get really slow). I first noticed it when connecting to yahoo's mail server got _really_ slow. I ran netstat and observed a whole buttload of entries like the following: tcp 1 0 sesquipedalian.wco:2440 dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2439 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2437 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2436 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2435 dgproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedali:codasrv-se pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wc:venus dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2429 pmproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2426 pmproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2425 dgproxy00.wco:pop3 CLOSE_WAIT tcp 1 0 sesquipedalian.wco:2423 pmproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2422 dgproxy00.wco:pop3 CLOSE_WAIT tcp 0 0 sesquipedalian.wco:2421 pmproxy00.wco:pop3 CLOSE_WAIT I then decided to run 'netstat | grep pop3 | wc -l', which returned a staggering 55 entries (it was later up to 409 when I forgot to shut down mail/news over the weekend)... one for each time Mozilla had connected to the pop server to check for new mail (I ascertained this by counting the times it said "You have no mail" or "Y'all got mail!" in the terminal I ran mail/news from). Upon shutting down Mail/News, the count immediately drops to zero. I suppose that the "CLOSE_WAIT" status may indicate that the server it's connecting too isn't reponding to the close request, in which case it may not be Mozilla's problem. I'm behind a "transparent firewall". Reproducible: Always Steps to Reproduce: 1.) Configure pop3 account 2.) Set it to automatically check for new messages at intervals (I have it set not to download automatically). 3.) Leave mail/news running for some time (I run it in a separate terminal from the browser with mozilla -mail). 4.) After it has checked for new messages on the sever several times, run netstat and check for entries like I described above. Actual Results: Connections stay in CLOSE_WAIT state indefinitely Expected Results: Connections should be closed after checking for new mail. The only other bug I found that might be related is bug 67957 (Too many sockets open).

Just talked to a co-worker who wasn't seeing this problem on 20010118 but, upon upgrading to 2001030609, started seeing it also. We also figured out that the mail server isn't outside the firewall so that (along with the fact that the firewall is transparent) would seem to suggest that the firewall isn't an issue. Changing summary.

May be it is related to nsMsgProtocol::CloseSocket() where we just delete the stream and not close it. I 'll investigate

accepting. I am also seeing this.

nominating

cc bienvenu

I think Scott knows a lot more about this stuff than I do.

marking nsbeta1-

I marked the wrong bug. This one hasn't been evaluated yet. removing nsbeta1- for the moment.

For what it's worth when this is evaluated, I find it pretty annoying...

This problem is a regression between 2/20 (not reproducible) and 2/22(reproducible) . I see most of the changes being related to necko carpool. cc dougt for his comments

marking nsbeta1+

Just built a cvs build applying the patch from bug 71391, and this now WFM. (I think it's a dup of bug 67957 btw)

marking worksforme now, based on the previous comments.

vrfy