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.