Mozilla leaks HTTP sockets

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Networking: HTTP
--
major
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Xuân Baldauf, Assigned: Darin Fisher)

Tracking

({memory-leak, perf})

Trunk
mozilla0.9.1
x86
All
memory-leak, perf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: required for 0.9.1, URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mlk, perf

Comment 2

17 years ago
-->sockets
Assignee: neeti → darin
(Assignee)

Comment 3

17 years ago
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...
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
(Assignee)

Updated

17 years ago
Keywords: qawanted

Comment 4

17 years ago
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

17 years ago
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. 
Whiteboard: required for 0.9.1
(Assignee)

Comment 6

17 years ago
changing OS to all... removing "pipelining" from summary.
Keywords: qawanted
OS: Windows 98 → All
Summary: Mozilla leaks sockets with HTTP pipelining. → Mozilla leaks HTTP sockets
(Assignee)

Comment 7

17 years ago
Created attachment 35308 [details] [diff] [review]
fixes the problem
(Assignee)

Comment 8

17 years ago
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.
Keywords: patch

Comment 9

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

Comment 10

17 years ago
r=gagan
(Assignee)

Comment 11

17 years ago
dougt says: 'sr='
(Assignee)

Comment 12

17 years ago
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 13

17 years ago
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?
(Assignee)

Comment 14

17 years ago
try a build from 5/23
VERIFIED with comm branch 2001060713 linux build. Not marking this as verified
until other platforms have been checked.

Comment 16

16 years ago
Verified. The host URL no longer exists. Reopen if this bug still exists.
Status: RESOLVED → VERIFIED
QA Contact: tever → junruh
You need to log in before you can comment on or make changes to this bug.