Author pv
Recipients jcon, kermode, mark.dickinson, ncoghlan, petri.lehtinen, pitrou, pv, rupole, skrah, teoliphant, vstinner
Date 2011-07-04.14:36:55
SpamBayes Score 1.92051e-10
Marked as misclassified No
Message-id <1309790216.55.0.139193640866.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
@skrah:

Ahh, this always happens when I don't run it :)  But my point stands -- the reason why it does not crash with Numpy is that Numpy calls PyMemoryView_FromObject to obtain a new memoryview and then uses PyMemoryView_GET_BUFFER. Along this code path the refcount of self->mbuf gets properly incremented, as it's explicitly done in PyMemoryView_FromObject. However, if you have a custom object Foo which just calls `PyObject_GetBuffer`, and then do the same sequence

    a = memoryview(whatever)
    b = Foo(a)  # --> only grabs the buffer with PyObject_GetBuffer
    a.release() # --> will invalidate the buffer
    b.mogrify_buffer_contents()  # --> boom

Here, the buffer is released too early, as the refcount of `self->mbuf` is not incremented during the `PyObject_GetBuffer` call.

> Is there anything stopping us just storing the flags on
> PyManagedBuffer?

Slicing memoryviews can invalidate the contiguity flags, and no-strides flags, so some checks are still probably needed in `memory_getbuf`.

> It's OK if the construction API requires the flag
> information in addition to the Py_buffer struct. 

This would be useful, yes.
History
Date User Action Args
2011-07-04 14:36:56pvsetrecipients: + pv, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou, vstinner, skrah, jcon, petri.lehtinen
2011-07-04 14:36:56pvsetmessageid: <1309790216.55.0.139193640866.issue10181@psf.upfronthosting.co.za>
2011-07-04 14:36:56pvlinkissue10181 messages
2011-07-04 14:36:55pvcreate