Message139775
| 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:56 | pv | set | recipients:
+ pv, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou, vstinner, skrah, jcon, petri.lehtinen |
| 2011年07月04日 14:36:56 | pv | set | messageid: <1309790216.55.0.139193640866.issue10181@psf.upfronthosting.co.za> |
| 2011年07月04日 14:36:56 | pv | link | issue10181 messages |
| 2011年07月04日 14:36:55 | pv | create |
|