On a free-threaded debug build, concurrently exhausting a memoryview iterator can abort with a negative refcount. The exporter is not mutated or explicitly released.
Run PYTHON_GIL=0 ./python.exe repro.py repeatedly to trigger the following crash:
Python/brc.c:69: _Py_NegativeRefcount: Assertion failed: object has negative ref count
Enable tracemalloc to get the memory block allocation traceback
object address : 0x2000296d670
object refcount : 0
object type : 0x1038bc060
object type name: memoryview
object repr : <refcnt 0 at 0x2000296d670>
Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailed
Python runtime state: initialized
Stack (most recent call first):
File "/Users/goldbaum/Documents/test.py", line 11 in worker
File "/Users/goldbaum/.pyenv/versions/3.16t-dev-debug/lib/python3.16t/threading.py", line 1160 in run
File "/Users/goldbaum/.pyenv/versions/3.16t-dev-debug/lib/python3.16t/threading.py", line 1218 in _bootstrap_inner
File "/Users/goldbaum/.pyenv/versions/3.16t-dev-debug/lib/python3.16t/threading.py", line 1180 in _bootstrap
[1] 61221 abort python -Xfaulthandler test.py
With PYTHON_GIL=1 on the same binary I'm unable to trigger any crashes.
memoryiter_next() reads it_seq before clearing and decrementing it at exhaustion, so two threads can drop the iterator's single owning reference. @devdanzin reported this race earlier in a comment, with a separate reproducer and sanitizer results.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Output from running 'python -VV' on the command line:
Activity
ZeroIntensity commented on Oct 20, 2026
Possibly a duplicate of #127716?
ngoldbaum commented on Oct 20, 2026
I guess that's fair but I was hoping we could merge Neil's PR more or less as-is and leave this behind as a followup.