[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Pauli Virtanen report at bugs.python.org
Mon Jul 4 16:36:56 CEST 2011


Pauli Virtanen <pav at iki.fi> added the comment:

@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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________


More information about the Python-bugs-list mailing list