`array('I')`: resizing with active memoryview leaves stale view; `readinto()` corrupts heap and segfaults during file close
Port, board and/or hardware
Unix port
MicroPython version
MicroPython v1.27.0-preview.107.gd1607598f on 2025-09-09; linux [GCC 14.2.0] version
Reproduction
try:
from array import array; import os
except ImportError:
print("SKIP: missing deps")
else:
path = "test_E69_typed_I_grow_then_read_1.bin"
msg = None
try:
# Prepare a 16-byte file
with open(path, 'wb') as f:
f.write(bytes(range(16)))
a = array('I', [0]*4)
mv = memoryview(a) # export a view
a.extend([1]*2048)
with open(path, 'rb') as f:
try:
_ = f.readinto(mv)
msg = "OK"
except Exception as e:
msg = "EXC %s" % type(e).__name__
except Exception as e:
msg = "EXC %s" % type(e).__name__
finally:
try:
os.remove(path)
except Exception:
pass
print(msg if msg is not None else "OK")
Expected behaviour
Resizing an exporter (array, bytearray, etc.) while it has active memoryviews should raise a Python exception (e.g., BufferError: existing exports; object cannot be resized). At minimum, the VM must not be corrupted by subsequent operations like readinto().
Observed behaviour
The resize succeeds; the existing memoryview retains a stale pointer to the old storage. readinto(mv) writes into freed/reused memory, corrupting heap objects (in this case the file object). The process later crashes (here, SIGSEGV in mp_get_stream() during file close).
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
Resizing bytearray with active memoryviews corrupts state and segfaults
Port, board and/or hardware
Unix
MicroPython version
MicroPython v1.27.0-preview.107.gd1607598f on 2025-09-09; linux [GCC 14.2.0] version
Reproduction
import gc
ba = bytearray(b"abcdefghij")
views = [memoryview(ba) for _ in range(4)]
ba[:] = ba + b"X"*256
gc.collect()
for i, mv in enumerate(views):
mv[0:1] = b"Y"
Expected behaviour
Attempting to resize a bytearray that has active memoryview exports should raise a Python exception and must not corrupt the VM or crash.
Observed behaviour
The resize succeeds; existing memoryviews retain stale pointers to the old buffer. After gc.collect() (or later operations), the VM state gets corrupted and the process segfaults in unrelated code paths (e.g., during enumerate, inside mp_load_method_maybe).
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree