"FATAL: uncaught exception" on KeyboardInterrupt during large printout at normal REPL #4921
Comments
|
Thanks for the report.
Yes that's pretty much it. In detail it looks like the following is happening:
The problem exists for all ports that use Note that it's not enough to fix point (2) and make the VM always check for pending exceptions on return, because there's always the chance an exception comes in betwee the VM returning and execution of One option to fix it is to make |
A variation on this would be for this function to first set the interrupt char to |
Pending exceptions would otherwise be handled later on where there may not be an NLR handler in place. Fixes issues micropython#4921 and micropython#5488.
Pending exceptions would otherwise be handled later on where there may not be an NLR handler in place. A similar fix is also made to the unix port's REPL handler. Fixes issues micropython#4921 and micropython#5488.
Pending exceptions would otherwise be handled later on where there may not be an NLR handler in place. A similar fix is also made to the unix port's REPL handler. Fixes issues micropython#4921 and micropython#5488.
|
Fixed by 5a91cd9 |
Pending exceptions would otherwise be handled later on where there may not be an NLR handler in place. A similar fix is also made to the unix port's REPL handler. Fixes issues micropython#4921 and micropython#5488.
Pending exceptions would otherwise be handled later on where there may not be an NLR handler in place. A similar fix is also made to the unix port's REPL handler. Fixes issues micropython#4921 and micropython#5488. Change-Id: I258443be7c6b7368bf7fb50b507d5e18b9d9bd5a
This is a bug that I originally found in our own commercial product running a fork of MicroPython, but I have since reproduced on the mainline STM32 port as well.
At the friendly REPL, if you enter an expression such as
"a" * 10000and then very quickly hit Ctrl-C, MicroPython will crash with "FATAL: uncaught exception<pointer>", where<pointer>corresponds tomp_state_ctx.vm.mp_kbd_exception.I am able to reproduce this with both the v1.10 and v1.11 branches, including the current master (154062d). For v1.11 reproduction, I am using an STM32F415ZG based dev board internal to our company (compiled on a branch whose only changes are board-specific, no core tweaks). My other reproduction is on our Silicon Labs EFM32 based product. The fact that I can reproduce on STM32 tells me the bug is not specific to our product.
I am not able to reproduce on v1.9, at least where I've tested (including a microbit).
From my own analysis of the "uncaught exception" message, I believe the cause of the crash is that the REPL runs
parse_compile_executeto execute the given expression, which sees the KeyboardInterrupt being raised, restores context, and re-raises -- but there's no surroundingnlr_pushat the REPL, sonlr_jump_failends up being called.The text was updated successfully, but these errors were encountered: