On Fri, Jul 18, 2008 at 10:04 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
> > On Fri, Jul 18, 2008 at 9:15 PM, Travis E. Oliphant
> > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >     Michael Abbott wrote:
> >     > Only half of my patch for this bug has gone into trunk, and
> >     without the
> >     > rest of my patch there remains a leak.
> >     >
> >     Thanks for your work Michael.   I've been so grateful to have you and
> >     Chuck and others looking carefully at the code to fix its problems.
> >
> >     In this particular case, I'm not sure I see how (the rest of) your
> >     patch
> >     fixes any remaining leak.   We do seem to be having a disagreement
> >     about
> >     whether or not the reference to typecode can be pre-maturely
> >     destroyed,
> >     but this doesn't fit what I usually call a "memory leak."     I think
> >     there may be some other cause for remaining leaks.
> >
> >
> > Travis,
> >
> > There really is (at least) one reference counting error in
> > PyArray_FromAny. In particular, the obj == NULL case leaves a
> > reference to typecode, then exits through the first return after
> > finish. In this case robj doesn't steal a reference to typecode and
> > the result can be seen in the python program above or by printing out
> > the typecode->ob_refcnt from the code itself. So that needs fixing. I
> > would suggest a DECREF in that section and a direct return of robj.
> agreed!  I'll commit the change.
> >
> > The next section before finish is also a bit odd. The direct return of
> > an array works fine, but if that isn't the branch taken, then
> > PyArray_Return decrements the refcnt of arr, which in turn decrements
> > the refcnt of typecode. I don't know if the resulting scalar holds a
> > reference to typecode, but in any case the situation there should also
> > be clarified.
> This looks fine to me.   At the PyArray_Return call, the typecode
> reference is held by the array.  When it is decref'd the typecode is
> decref'd appropriately as well.   The resulting scalar does *not*
> contain a reference to typecode.  The scalar C-structure has no place to
> put it (it's just a PyObject_HEAD and the memory for the scalar value).
>

I was thinking of just pulling the relevant part out of PyArray_Return and
including it in the function, which would make what was going on quite
explicit to anyone reading the code.  Then maybe a direct return of robj as
I think it is always going to be a scalar at that point.


> Michael is correct that PyArray_Scalar does not change the reference
> count of typecode (as the comments above that function indicates).  I
> tried to be careful to put comments near the functions that deal with
> PyArray_Descr objects to describe how they affect reference counting.  I
> also thought I put that in my book.
>

Yep, it was a brain fart on my part.

Chuck
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to