Message95952
The following code causes a segmentation fault (or glibc error, or other
problems):
>>> x = someobject()
>>> y = memoryview(x)
>>> z = memoryview(y)
The problem is that someobject.bf_releasebuffer will be called two times
with an identical Py_buffer structure.
This can be seen in memoryobject.c:
static int
memory_getbuf(PyMemoryViewObject *self, Py_buffer *view, int flags)
{
int res = 0;
/* XXX for whatever reason fixing the flags seems necessary */
if (self->view.readonly)
flags &= ~PyBUF_WRITABLE;
if (self->view.obj != NULL)
res = PyObject_GetBuffer(self->view.obj, view, flags);
if (view)
dup_buffer(view, &self->view);
return res;
}
At the end of the call, view and self->view contain identical data
because of the call to dup_buffer.
static void
memory_releasebuf(PyMemoryViewObject *self, Py_buffer *view)
{
PyBuffer_Release(view);
}
But when the outer memoryview is destroyed, memory_releasebuf calls
PyBuffer_Release for the original object once.
And when the inner memoryview is destroyed, PyBuffer_Release is called
by memory_dealloc the second time. Both calls supply an identical
Py_buffer structure.
Now, if the original object's bf_getbuffer and bf_releasebuffer allocate
some memory dynamically, this will likely cause a double-free of memory,
usually leading to a segmentation fault.
There is no feasible way the bf_releasebuffer can keep track of how many
calls to it have been made. So probably the code in memory_getbuf is
wrong -- at least the dup_buffer function looks wrong. |
|
Date |
User |
Action |
Args |
2009-12-03 22:40:29 | pv | set | recipients:
+ pv |
2009-12-03 22:40:29 | pv | set | messageid: <1259880029.03.0.2026580728.issue7433@psf.upfronthosting.co.za> |
2009-12-03 22:40:20 | pv | link | issue7433 messages |
2009-12-03 22:40:19 | pv | create | |
|