hard crash when producing a large string via "*"
Port, board and/or hardware
unix port, coverage variant, x86_64 linux
MicroPython version
v1.27.0-preview-32-g141f7d0c35
Reproduction
Run micropython with the following script (via -c for example): 'a' * 8 * (1 << 62)
Expected behaviour
A Python exception occurs, which can be caught and continued from.
Observed behaviour
A crash inside memcpy, or other low level misbehavior (e.g., unicorn hangs)
Starting program: /home/jepler/src/micropython/ports/unix/build-coverage/micropython -c "'aaaa' * (1 << 62)"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:366
warning: 366 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory
(gdb) where
#0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:366
#1 0x0000555555619c62 in mp_seq_multiply (items=items@entry=0x7ffff7c15c20, item_sz=item_sz@entry=1, len=8,
times=4611686018427387904, dest=0x7ffff7c97000) at ../../py/sequence.c:41
#2 0x0000555555610ef1 in mp_obj_str_binary_op (op=MP_BINARY_OP_MULTIPLY, lhs_in=<optimized out>,
rhs_in=<optimized out>) at ../../py/objstr.c:391
Additional Information
Many variants (such as 1<<59) instead give the message MemoryError: memory allocation failed, allocating 1 bytes. This is due to always printing the size as a int; a proposed fix for that is in https://github.com/micropython/micropython/pull/17931
This finding is from a fuzzer.
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