New submission from Serhiy Storchaka:
Deallocation scheme for memoryview is complex and unsafe. It crashes with
chained memoryviews (issue25498), but I suppose deallocating unchained
memoryview can crash too if the memoryview itself had exported buffers
(self->exports != 0).
Both memoryview and ManagedBuffer support garbage collector. If there is a
reference to memoryview from reference loop, memoryview becomes a part of the
reference loop.
refloop -> memoryview -> ManagedBuffer -> obj
First garbage collector calls tp_clear for all objects in the loop
(memory_clear() for memoryview).
If self->exports != 0 for memoryview, _memory_release() fails and the
_Py_MEMORYVIEW_RELEASED flag is not set. However following Py_CLEAR(self->mbuf)
deallocates ManagedBuffer and set self->mbuf to NULL. Then memoryview's owner
releases memoryview, and it is deallocated (memory_dealloc). _memory_release
reads self->mbuf->exports, but self->mbuf is NULL. Segmentation fault.
Following patch makes deallocation scheme for memoryview simpler and more
reliable.
1) memory_clear does nothing if self->exports != 0. The buffer will be released
when memoryview's owner release the memoryview.
2) ManagedBuffer no longer supports garbage collector. This prevents buffer
releasing before memoryview or its owner are cleared.
----------
components: Interpreter Core
messages: 253803
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Deallocation scheme for memoryview is unsafe
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue25525>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
