Re: [Numpy-discussion] Garbage collection fails after numarray exception

[Rob H. <ro...@ho...>]

Todd Miller wrote:
> 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.  

Hmm.... Isn't this the standard python thing that it keeps the context 
of the last exception somewhere for queries? Just generate another 
exception and you should see that the memory taken by a is liberated 
because the indirect reference from sys.exc_traceback to a disappears.

Rob

-- 
Rob W.W. Hooft  ||  ro...@ho...  ||  http://www.hooft.net/people/rob/