[Numpy-discussion] Garbage collection fails after numarray exception

[Leo Breebaart]

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?

Many thanks in advance,

-- 
Leo Breebaart  <leo at lspace.org>