[Numpy-discussion] Garbage collection fails after numarray exception

[Todd Miller]

On Tue, 2004-02-10 at 15:09, Leo Breebaart wrote:
> Hi all,
> 
> I'm not sure if I have found a bug, or simply a type of behaviour
> that should not have surprised me -- but I most definitely did
> not expect the following numarray 0.8 behaviour:
> 
> 
>    >>> import numarray
>    >>> a = numarray.zeros(100000000)
>    >>> del a
>    >>> a = numarray.zeros(100000000)
>    >>> a + ''
>    Traceback (most recent call last):
>      File "<stdin>", line 1, in ?
>      File "/usr/lib/python2.3/site-packages/numarray/numarraycore.py", line 664, in __add__
>        return ufunc.add(self, operand)
>      File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 870, in _cache_miss2
>        (in1, in2), insig, scalar = _inputcheck(n1, n2)
>      File "/usr/lib/python2.3/site-packages/numarray/ufunc.py", line 391, in _inputcheck    raise TypeError(
>    TypeError: UFunc arguments must be numarray, scalars or numeric sequences
>    >>> del a
>    >>>
> 
> 
> If I execute these statements alongside 'top' or another memory
> monitor, I of course see a big memory increase after each call to
> 'zeros', as well as a big decrease after the first 'del a' -- but
> no change whatsoever any more after the second 'del a', not even
> if I explicitly call the garbage collector via the gc module.
> 
> As far as I can tell, the occurrence of the exception somehow
> causes a permanent increase in a's refcount, with a big memory
> leak as a result.
> 
> (In case anyone's curious about the context for this, the 
> """ a + '' """" construct was taken straight from the Python
> Cookbook, as a way of determining whether an object exhibits
> string-like behaviour (useful for printing methods, etc.))
> 
> I understand that I can easily work around this problem so that
> numarray objects will not be fed to this construct to begin with,
> but I do wonder if it is really true (and intended) that numarray
> exceptions have the side effect of making certain potentially
> huge objects indestructible.
> 
> Can anyone here shed some light on this?

It looks like a bug.  I logged it on Source Forge and I'm working on the
solution.  

> Many thanks in advance,

Thanks for the report,
Todd

-- 
Todd Miller <jmiller at stsci.edu>