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

[Leo Breebaart]

Rob Hooft <rob at 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?

-- 
Leo Breebaart  <leo at lspace.org>