New submission from Pauli Virtanen <p...@iki.fi>: 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. ---------- 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 <rep...@bugs.python.org> <http://bugs.python.org/issue7433> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com