This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients sbt, skrah
Date 2012-09-20.20:37:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
In-reply-to
Content
A memoryview which does not own a reference to its base object can point to freed or reallocated memory.  For instance the following segfaults for me on Windows and Linux.


import io

class File(io.RawIOBase):
    def readinto(self, buf):
        global view
        view = buf
    def readable(self):
        return True

f = io.BufferedReader(File())
f.read(1)                       # get view of buffer used by BufferedReader
del f                           # deallocate buffer
view = view.cast('P')
L = [None] * len(view)          # create list whose array has same size
                                # (this will probably coincide with view)
view[0] = 0                     # overwrite first item with NULL
print(L[0])                     # segfault: dereferencing NULL


I realize there are easier ways to make Python segfault, so maybe this should not be considered a serious issue.  But I think there should be some way of guaranteeing that a memoryview will not try to access memory which has already been freed.

In #15903 skrah proposed exposing memory_release() as PyBuffer_Release().  However, I don't think that would necessarily invalidate all exports of the buffer.

Alternatively, one could incref the buffered reader object and set mview->mbuf->obj to it.  Maybe we could have

    PyMemoryView_FromMemoryEx(char *mem, Py_ssize_t size, int flags, PyObject *obj)

which guarantees that if obj is non-NULL then it will not be garbage collected before the memoryview.  This should *not* expose obj as an attribute of the memoryview.
History
Date User Action Args
2012-09-20 20:37:22sbtsetrecipients: + sbt, skrah
2012-09-20 20:37:21sbtsetmessageid: <1348173441.91.0.841080415833.issue15994@psf.upfronthosting.co.za>
2012-09-20 20:37:21sbtlinkissue15994 messages
2012-09-20 20:37:17sbtcreate