On Fri, Jul 18, 2008 at 9:30 PM, Travis E. Oliphant <
oliphant@enthought.com> wrote:
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