[Python-Dev] Daily reference leaks (12de1ad1cee8): sum=6024

[Antoine Pitrou]

On Wed, 18 Jan 2012 11:14:50 -0500
Brett Cannon <brett at python.org> wrote:

> On Wed, Jan 18, 2012 at 10:56, Antoine Pitrou <solipsis at pitrou.net> wrote:
> 
> > On Thu, 19 Jan 2012 01:06:07 +1000
> > Nick Coghlan <ncoghlan at gmail.com> wrote:
> > > On Wed, Jan 18, 2012 at 2:31 PM,  <solipsis at pitrou.net> wrote:
> > > > results for 12de1ad1cee8 on branch "default"
> > > > --------------------------------------------
> > > >
> > > > test_capi leaked [2008, 2008, 2008] references, sum=6024
> > >
> > > Yikes, you weren't kidding about that new subinterpreter code
> > > execution test upsetting the refleak detection...
> >
> > Well, these are real leaks, but I expect them to be quite difficult to
> > track (I've found a couple of them), because they can be scattered
> > around in C module initialization routines and the like. I suggest we
> > skip this test on refleak runs.
> >
> 
> Do we have any general strategy to help make it more fine-grained to detect
> where the leak might be coming from?

Unfortunately not. I've tried to track down the remaining leaks (*) by
using gc.get_objects(), but apart from a couple of false positives
(dead weakrefs lingering in some tp_subclasses slots until the next
subclasses take their place ;-)), most refleaks seem to be either on
long-lived objects (meaning the leaks are not severe) or on
non-gc-tracked objects.

(*)

$ ./python -m test -R 3:2 test_capi
[1/1] test_capi
beginning 5 repetitions
12345
.....
test_capi leaked [152, 152] references, sum=304


> We could then maybe try to get some
> people pound on this at the PyCon sprints. Otherwise I'm reluctant to skip
> it since they are legitimate leaks that should be get fixed.

Well it's the old well-known issue with pseudo-"permanent" references
not being appropriately managed/cleaned up. Which only shows when
calling Py_Initialize/Py_Finalize multiple times, or using
sub-interpreters.

Regards

Antoine.