This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients amaury.forgeotdarc, christian.heimes, gvanrossum, janssen
Date 2007-12-10.23:37:14
SpamBayes Score 0.00059571734
Marked as misclassified No
Message-id <ca471dc20712101537g1483ae65x940397532df77769@mail.gmail.com>
In-reply-to <1197329455.82.0.535751756577.issue1469@psf.upfronthosting.co.za>
Content
I wonder if Christian Heimes was correct that the ssl object needs GC
support? This was part of his patch (which I checked in and then
reverted because the other part of it didn't work as advertised).

Alternatively, if 's' is involved in a cycle *and* any of the objects
in the cycle has a __del__ method, the GC won't call __del__. This
seems counter-intuitive but is actually correct since __del__ can only
be called when there are no references to an object left.

--Guido

On Dec 10, 2007 3:30 PM, Bill Janssen <report@bugs.python.org> wrote:
>
> Bill Janssen added the comment:
>
> The other leak comes from this code:
>
>    s = ssl.wrap_socket(socket.socket(), ...)
>    s.connect((SOME BOGUS ADDRESS OR SERVER))
>
> The connect() fails, and the SSLSocket "s"gets dropped on the floor,
> but never seems to be GC'd, (or the GC never seems to call the __del__
> method).  Any idea why?
>
> Could this be because the base class is a C class?
>
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1469>
> __________________________________
>
History
Date User Action Args
2007-12-10 23:37:15gvanrossumsetspambayes_score: 0.000595717 -> 0.00059571734
recipients: + gvanrossum, amaury.forgeotdarc, janssen, christian.heimes
2007-12-10 23:37:15gvanrossumlinkissue1469 messages
2007-12-10 23:37:14gvanrossumcreate