In urllib2.AbstractHTTPHandler.do_open, the following like creates a
circular link:

        r.recv = r.read

[r.read is a bound method, so it contains a reference to 'r'. Therefore,
r now refers to itself.]

If the GC is disabled or doesn't run often, this creates a FD leak.

How to reproduce:

import gc
import urllib2
u = urllib2.urlopen("http://google.com")
s = [ u.fp._sock.fp._sock ]
u.close()
del u
print gc.get_referrers(s[0])
[<socket._fileobject object at 0xf7d42c34>, [<socket object, fd=4,
family=2, type=1, protocol=6>]]

I would expect that only one reference to the socket would exist (the
"s" list itself).

I can reproduce with 2.4; the problems seems to still exist in SVN HEAD.

Since the socket object is added to a list, a reference to the object
always exists right? That would mean that it would not be garbage
collected as long as the reference exists.  

On the other hand, it should also be noted that in close method, the
socket is not explicitly closed and for a single urlopen, atleast 3
sockets are opened.

The list is not the problem. The problem is the other reference, from
"<socket._fileobject object at 0xf7d42c34>".

Also note that the workaround (u.fp.recv = None) removes the second
reference.

This is fine (at least in CPython), because the socket is destroyed when the
refcount reaches zero, thus calling the finalizer.

So if I add a:

class _WrapForRecv:
    def __init__(self, obj):
        self.__obj = obj

    def __getattr__(self, name):
        if name == "recv": name = "read"
        return getattr(self.__obj, name)

...and then change:

        r.recv = r.read

...into:

        r = _WrapForRecv(r)

...it stops the leak, and afaics nothing bad happens.

Has (non-unittest) test and proposed (non-diff) patch inline.

I can't reproduce in python 2.5.4, 2.6.2, or 2.7 trunk (though I can
with 2.4.6 and 2.5) on mac & linux.  

Quick bisection suggests that it was fixed in r53511 while solving
related bug http://bugs.python.org/issue1601399, and the explanation
given there is consistent with the symptom here: the _fileobject doesn't
close itself, and r53511 makes sure that it does.

Suggest closing as fixed.

not reproducable in head as stated.