[New-bugs-announce] [issue7433] MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer

Pauli Virtanen report at bugs.python.org
Thu Dec 3 23:40:29 CET 2009

New submission from Pauli Virtanen <pav at iki.fi>:

The following code causes a segmentation fault (or glibc error, or other

>>> 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)

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.

components: Interpreter Core
messages: 95952
nosy: pv
severity: normal
status: open
title: MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer
versions: Python 3.1

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list