80975 - Mozilla leaks HTTP sockets

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Xuân Baldauf]

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (Win98; U)
BuildID:    2001051420

After connecting to a site, downloading some HTTP document, etc., mozilla leakes 
some sockets used for the connection to that site. The sockets remain CLOSE_WAIT 
state until mozilla is shut down.

This behaviour can be seen at least when HTTP pipelining is active.

Reproducible: Always
Steps to Reproduce:
1. Set a proxy server in "Edit/Preferences/Advanced/Proxies", so that
all connections will be routed through that proxy server. For reproduction, you 
might not even need real access to the proxy server, all the proxy server has to 
do is to return you a HTML document (errors are okay) for every request.
2. Check "Edit/Preferences/Debug/Networking/Enable HTTP Pipelining"
3. Go to http://justchat4.medium.net:4000/chat/test/mozilla/net/socketLeak.html

This page contains some javascript which makes mozilla connect to different 
hosts with different hostnames every 5 seconds. The connects should fail, and 
your proxy server should complain about it. (Alternatively, your proxy server 
could complain about anything, that should be sufficient.) It is not sufficient 
to try to connect to the same hostname, they must differ, but it seems to be 
sufficient to try to connect to different hostnames using the same proxy server. 
(This looks like a proxy server handling inefficiency, where for every new site 
a new proxy-connection is established, while it is sufficient to have a fixed 
amount of proxy connections.)
4. Regularily enter "netstat -n" in your console. For windows: Use the DOS-Box. 
For UNIX: Any shell should do it.

Actual Results:  You will see an increasing amount of connections in the 
CLOSE_WAIT state. If you run short of filedescriptors|sockets, you can close 
mozilla completely. After that, all the connections in the CLOSE_WAIT state will 
be gone.

Expected Results:  The amount of connections (in CLOSE_WAIT state) (used by 
mozilla) should be constant, not increasing.

That bug is tricky, because you seem to need different sites to reproduce it 
reliably. But it is common, because you surf to different sites. It is bad 
especially on Win95|Win98, because the amount of filedescriptors is artificially 
limited to some dozens. If all filedescriptors are used, mozilla complains about 
"connection refused" while no connection was ever made.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[neeti]

-->sockets

Comment 3

[Darin Fisher]

enabling pipelining has no effect currently, so this seems strange.  but, if
we are leaking sockets at all then this needs to be fixed with high priority.
investigating...

Comment 4

[R.K.Aa.]

I use no proxy but with 2001051813 linux i see heaps of http sockets remain open
to sites i left long ago. On some sites it seems i overload the server while
trying to browse a page, so it stops servinge me rest of content.

Sample page that no longer completes loading is http://www.dinside.no/motor
Clicking Stop button, or simply right-clicking in page (to invoke context menu)
makes it load some more, but then it spins again. Looking at the sockets there
are pretty many open to the site (and banner sites) - serving nothing anymore.

There might be a related problem opening sockets as well. I frequently have to
click "submit" button in bugzilla query form to make it send a request.

Comment 5

[chris hofmann]

for me on win98, browser buster seems to be able to load only
15-20 urls before I start seeing 'connection refused' messages
and attempts to view pages aborted.   definite test blocker,
and if users on some key platforms are only going to be able
to use the browser for 15 or 20 sites then its a beta blocker. 

Comment 6

[Darin Fisher]

changing OS to all... removing "pipelining" from summary.

Comment 7

[Darin Fisher]

Attachment: fixes the problem

Comment 8

[Darin Fisher]

the attached patch solves the problem by pruning out dead connections as new
connections are requested.  this does not prevent the browser from holding onto
dead connections, but it does ensure that the number of dead connections will
always tend to zero while browsing.  we'd need some sort of timer event to
properly clear out dead connections.  but, with my patch at least the browser
won't run out of sockets... servers may still dislike us for holding onto dead
connections, though ;-)

instituting the periodic cleanup of dead connections is a separate bug.

Comment 9

[Keyser Sose]

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

Comment 10

[Gagan]

r=gagan

Comment 11

[Darin Fisher]

dougt says: 'sr='

Comment 12

[Darin Fisher]

fix checked in

Comment 13

[chris hofmann]

looking forward to this fix...  I still see the problem
in build from this morning but doesn't seem to be as bad...
I'm I just hitting the right side of randomness?

Comment 14

[Darin Fisher]

try a build from 5/23

Comment 15

[Bradley Baetz (:bbaetz)]

VERIFIED with comm branch 2001060713 linux build. Not marking this as verified
until other platforms have been checked.

Comment 16

[John Unruh]

Verified. The host URL no longer exists. Reopen if this bug still exists.