Author pv
Recipients kermode, loewis, mark.dickinson, ncoghlan, pitrou, pv, rupole, teoliphant
Date 2011-02-13.14:35:09
SpamBayes Score 3.00717e-07
Marked as misclassified No
Message-id <1297607710.96.0.641485698052.issue10181@psf.upfronthosting.co.za>
In-reply-to
Content
> Hmm, there's a misunderstanding. bf_releasebuffer is called exactly
> once for each call to bf_getbuffer.

Wrong: http://bugs.python.org/issue7433

static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
    int res = 0;
    CHECK_RELEASED_INT(self);
    if (self->view.obj != NULL)
        res = PyObject_GetBuffer(self->view.obj, view, flags);
    if (view)
        dup_buffer(view, &self->view);
    return res;
}

After this, PyBuffer_Release will be called twice: once on the data in *view, by whoever acquired the buffer from memoryview, and once on self->view, by memory_dealloc. Both with the same bit-by-bit content of the Py_buffer structure.

Because there are two Py_buffer structures here, setting view.obj to NULL in PyBuffer_Release does not guarantee correct calls to bf_releasebuffer.

Note that the view.internal pointer is also clobbered above.

> >  So, `bf_releasebuffer` cannot rely on (i) the data in Py_buffer
> > being what `bf_getbuffer` put there,
> 
> Well, why should it rely on that?

Because that makes implementing the exporter much easier. Also, writing an implementation for MemoryViewObject does not require clobbering the structure, and I doubt it helps much.

> > So, `bf_releasebuffer` cannot be used to release any resources
> > allocated in `bf_getbuffer`.
>
> AFAICT, it can. That's what the "internal" pointer is for.

Sure, guaranteeing that view->internal pointer is not toyed with would also be enough.

But the documentation should spell out very explicitly what the bf_releasebuffer call can rely on.
History
Date User Action Args
2011-02-13 14:35:11pvsetrecipients: + pv, loewis, teoliphant, mark.dickinson, ncoghlan, rupole, kermode, pitrou
2011-02-13 14:35:10pvsetmessageid: <1297607710.96.0.641485698052.issue10181@psf.upfronthosting.co.za>
2011-02-13 14:35:10pvlinkissue10181 messages
2011-02-13 14:35:10pvcreate