On Fri, Jul 18, 2008 at 9:30 PM, 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.
I've attached a test script. Chuck