[Numpy-discussion] Garbage collection fails after numarray exception
Rob Hooft
rob at hooft.net
Sun Feb 29 00:13:02 EST 2004
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 || rob at hooft.net || http://www.hooft.net/people/rob/
More information about the NumPy-Discussion
mailing list