homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.9205076e-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

AltStyle によって変換されたページ (->オリジナル) /