Port, board and/or hardware
any, where MICROPY_ENABLE_PYSTACK is 0
MicroPython version
MicroPython v1.27.0
Reproduction
Run MicroPython with the default C stack for bytecode (i.e. without MICROPY_ENABLE_PYSTACK, so VM state can fall back to alloca after a failed heap allocation — adjust if your build differs).
In the REPL (or a small script), run something like:
num = 140_000; num = eval(str(list(range(num))))
The eval compiles and executes a huge list display, which drives a very large n_state in fun_bc_call.
Binary search on num: if the expression completes, increase num; if the interpreter crashes or raises an unrecoverable error, decrease num. Repeat until you bracket the failure threshold.
On a constrained stack, a crash often appears within on the order of ~5–7 steps of this search from a starting guess like 140_000 (exact count depends on stack size, heap limits, and build).
Expected behaviour
It should not crash.
Observed behaviour
In function fun_bc_call. Code correctly ask if (state_size > VM_MAX_STATE_ON_STACK) and then it tries to allocate memory by m_malloc_maybe on heap by m_new_obj_var_maybe.
Problem is, that if m_new_obj_var_maybe fails, it does not raise an exception, but it tries to allocate dozen kilobytes for code_state by alloca , which usually means, your stack grows out of expected space.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
Port, board and/or hardware
any, where MICROPY_ENABLE_PYSTACK is 0
MicroPython version
MicroPython v1.27.0
Reproduction
Run MicroPython with the default C stack for bytecode (i.e. without MICROPY_ENABLE_PYSTACK, so VM state can fall back to alloca after a failed heap allocation — adjust if your build differs).
In the REPL (or a small script), run something like:
num = 140_000; num = eval(str(list(range(num))))The eval compiles and executes a huge list display, which drives a very large n_state in fun_bc_call.
Binary search on num: if the expression completes, increase num; if the interpreter crashes or raises an unrecoverable error, decrease num. Repeat until you bracket the failure threshold.
On a constrained stack, a crash often appears within on the order of ~5–7 steps of this search from a starting guess like 140_000 (exact count depends on stack size, heap limits, and build).
Expected behaviour
It should not crash.
Observed behaviour
In function fun_bc_call. Code correctly ask
if (state_size > VM_MAX_STATE_ON_STACK)and then it tries to allocate memory bym_malloc_maybeon heap bym_new_obj_var_maybe.Problem is, that if m_new_obj_var_maybe fails, it does not raise an exception, but it tries to allocate dozen kilobytes for code_state by alloca , which usually means, your stack grows out of expected space.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree