gc.garbage from paramiko

[Andrew Bennetts]

On Wed, Feb 08, 2006 at 09:33:01PM -0800, Robey Pointer wrote:
> 
> On 8 Feb 2006, at 8:14, Andrew Bennetts wrote:
> 
> >On Mon, Feb 06, 2006 at 07:09:24PM +1100, Andrew Bennetts wrote:
> >>On Fri, Feb 03, 2006 at 10:41:11AM -0800, Robey Pointer wrote:
> >[...]
> >>>
> >>>Do you have any way to reproduce this outside of Zope?  I tried
> >>>running the bzr selftests (and a few other tests, like 'bzr push' to
> >>>an sftp site) with 'python -i' and then doing gc.collect() and
> >>>looking in gc.garbage, but wasn't able to reproduce it.
> >>
> >>I'm working on this.  I'll let you know when I've got something  
> >>minimal and
> >>complete I can share with you.
> >
> >I have some progress to report.
> 
> Thanks!  That was enough to help me reproduce it.  And fix it.  It  
> turned out to be a paper-bag bug where the auth_handler was pretty  
> blatantly creating a cycle.  I'm embarrased. :)  (Oddly, Packetizer  
> wasn't involved, so its presence in gc.garbage was a red herring.)

Well, the Packetizer instances are referenced from the uncollectable Transports,
hence they were also uncollectable.  Being uncollectable and having __del__
means Python will put it in gc.garbage, as described at
http://docs.python.org/lib/module-gc.html#l2h-410

> I fixed the cycle by using a weakref, then I removed Transport's  
> __del__ since it doesn't need one anyway.  The bzr branch for  
> paramiko is <http://www.lag.net/paramiko/bzr/paramiko>, so if you  
> want a quick fix, you should be able to pull it from there.

Thanks!

While we're on the subject, why does Packetizer have a __del__?  Sockets take
care of closing themselves when collected.

-Andrew.