Rob Hooft rob@hooft.net writes:
On Tue, 2004-02-10 at 15:09, Leo Breebaart wrote:
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. [...]
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.
Well, I've tried to test this, but even after multiple subsequent exceptions the memory taken up by the numarrays is not freed, at least not on my machine and with Python 2.3.3. Does it work for you if you try running the above code and then generating an exception?
BTW Todd, if you are reading this: you said in your earlier response that you logged this bug on SourceForge somewhere, but I can't seem to find it in what I think is the numarray bug page, at: http://sourceforge.net/tracker/?group_id=1369&atid=101369. Am I looking in the wrong place?