On Tue, Oct 20, 2015, at 15:57, Antoine Pitrou wrote: > > > These leaks have been here a while. Anyone know the cause? > > > > On Tue, 20 Oct 2015 at 01:47 <solipsis at pitrou.net> wrote: > > > >> results for d7e490db8d54 on branch "default" > >> -------------------------------------------- > >> > >> test_capi leaked [5411, 5411, 5411] references, sum=16233 > >> test_capi leaked [1421, 1423, 1423] memory blocks, sum=4267 > >> test_functools leaked [0, 2, 2] memory blocks, sum=4 > >> test_threading leaked [10820, 10820, 10820] references, sum=32460 > >> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 > > Bisection shows they were probably introduced by: > > changeset: 97413:dccc4e63aef5 > user: Raymond Hettinger <pyt...@rcn.com> > date: Sun Aug 16 19:43:34 2015 -0700 > files: Doc/library/operator.rst Doc/whatsnew/3.6.rst > Lib/operator.py Lib/test/test_operator.py > description: > Issue #24379: Add operator.subscript() as a convenience for building > slices. > > > If you comment out `@object.__new__` on line 411 in operator.py, or if > you remove the __slots__ assignment (which is a bit worrying), the leak > seems suppressed.
The problem is that the "subscript" class is not a GC type, but participates in a cycle through its type. I suspect it's type to force all heap types to have GC. Armin Rigo found previous examples where this special case caused problems, and I don't see what it buys anyway. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
