> I tried recreating the leak with more controllable types, but I haven't
> got very far. It seems to be caused by some weird interaction between
> io.FileIO, _fileio._FileIO and io.IOBase, specifically io.IOBase.__del_
> _() calling self.close(), and io.FileIO.close() calling
> _fileio._FileIO.close() *and* io.RawIOBase.close(). The weird thing is
> that the contents of RawIOBase.close() doesn't matter. The mere act of
> calling RawBaseIO.close (self) causes the leak. Remove the call, or
> change it into an attribute fetch, and the leak is gone. I'm stumped.
I think the problem is that the class remains referenced in
io.RawIOBase._abc_cache:
py> io.RawIOBase._abc_cache
set()
py> class f(io.RawIOBase):pass
...
py> isinstance(f(), io.RawIOBase)
True
py> io.RawIOBase._abc_cache
{<class '__main__.f'>}
py> del f
py> io.RawIOBase._abc_cache
{<class '__main__.f'>}
Each time test_destructor is called, another class will be added to
_abc_cache.
Regards,
Martin
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
