[Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> The reference leak seems specific to the float32 and complex64 types 
> called with default arguments.
>
> In [1]: import sys, gc
>
> In [2]: t = float32
>
> In [3]: sys.getrefcount(dtype(t))
> Out[3]: 4
>
> In [4]: for i in range(10) : t();
>    ...:
>
> In [5]: sys.getrefcount(dtype(t))
> Out[5]: 14
>
> In [6]: for i in range(10) : t(0);
>    ...:
>
> In [7]: sys.getrefcount(dtype(t))
> Out[7]: 14
>
> In [8]: t = complex64
>
> In [9]: sys.getrefcount(dtype(t))
> Out[9]: 4
>
> In [10]: for i in range(10) : t();
>    ....:
>
> In [11]: sys.getrefcount(dtype(t))
> Out[11]: 14
>
> In [12]: t = float64
>
> In [13]: sys.getrefcount(dtype(t))
> Out[13]: 19
>
> In [14]: for i in range(10) : t();
>    ....:
>
> In [15]: sys.getrefcount(dtype(t))
> Out[15]: 19
>  
> This shouldn't actually leak any memory as these types are singletons, 
> but it points up a logic flaw somewhere.
>
That is correct.   There is no memory leak, but we do need to get it 
right.  I appreciate the extra eyes on some of these intimate details.   
What can happen (after a lot of calls) is that the reference count can 
wrap around to 0 and then cause a funny dealloc (actually, the dealloc 
won't happen, but a warning will be printed). 

Fixing the reference counting issues has been the single biggest 
difficulty in converting PyArray_Descr from a C-structure to a regular 
Python object.  It was a very large pain to begin with, and then there 
has been more code added since the original conversion some of which 
does not do reference counting correctly (mostly my fault).

I've looked over ticket #848 quite a bit and would like to determine the 
true cause of the growing reference count which I don't believe is fixed 
by the rest of the patch that is submitted there.

-Travis