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