unix: uncaught NLR on qemu-m68k #18183
Description
Port, board and/or hardware
Unix port (Linux)
MicroPython version
MicroPython v1.27.0-preview.252.gb2871e0d0a on 2025-10-02; linux [GCC 14.2.0] version
Reproduction
sudo apt install qemu-user-static gcc-m68k-linux-gnu
make -C mpy-cross
make -C ports/unix \
DEBUG=1 \
CROSS_COMPILE=m68k-linux-gnu- \
LDFLAGS_EXTRA=-static \
MICROPY_STANDALONE=1 \
MICROPY_PY_BTREE=0 \
MICROPY_PY_FFI=0
qemu-m68k-static ports/unix/build-standard/micropythonFATAL: uncaught NLR 0xc0807ec0
Expected behaviour
Expected to launch REPL
Observed behaviour
I am testing the compilation of MicroPython binaries for different architectures, using either glibc or musl, and running them with qemu-user.
Most of the binaries work as expected, but the m68k binary refuses to start and throws an "uncaught NLR" error.
$ qemu-m68k-static -g 1234 ports/unix/build-standard/micropython &
$ gdb-multiarch
...
(gdb) target remote :1234
Remote debugging using :1234
...
0x80000328 in _start ()
(gdb) b nlr_jump_fail
Breakpoint 1 at 0x80065adc: file main.c, line 808.
(gdb) c
Continuing.
Breakpoint 1, nlr_jump_fail (val=0xc0807ec0) at main.c:808
808 mp_hal_stdio_mode_orig();
(gdb) bt
#0 nlr_jump_fail (val=0xc0807ec0) at main.c:808
#1 0x800004ae in nlr_jump (val=0xc0807ec0) at ../../py/nlrsetjmp.c:32
#2 0x80010928 in mp_raise_msg_varg (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4) at ../../py/runtime.c:1715
#3 0x80010c68 in mp_call_function_n_kw (fun_in=0x8011785a <vfs_posix_mount_obj>, n_args=2, n_kw=0, args=0xc07ffa74) at build-standard/genhdr/compressed.data.h:13
#4 0x80010da0 in mp_call_method_n_kw (n_args=2, n_kw=0, args=0xc07ffa6c) at ../../py/runtime.c:728
#5 0x800359b8 in mp_vfs_proxy_call (vfs=0xc0807e60, meth_name=585, n_args=2, args=0xc07ffac4) at ../../extmod/vfs.c:128
#6 0x80035eca in mp_vfs_mount (n_args=2, pos_args=0xc07ffb08, kw_args=0x8010f3f0 <mp_const_empty_dict_obj+4>) at ../../extmod/vfs.c:257
#7 0x800654f2 in main_ (argc=1, argv=0xc07ffda4) at main.c:554
#8 0x80065ad6 in main (argc=1, argv=0xc07ffda4) at main.c:494
(gdb)
Additional Information
In some odd cases, vfs.mount() called by the startup code in ports/unix/main.c can fail. Then the program will exit with "FATAL: uncaught NLR ..." not printing the error message.
Do we need to add nlr_push / nlr_pop and handle_uncaught_exception processing on it?
Update:
The vfs.mount() failure is caused by the wrong result from mp_obj_get_type(). That raises a TypeError.
#1 0x80002bce in mp_vprintf (print=0xc07ff9bc, fmt=0xc07ff9d6 "' object isn't callable", args=<optimized out>) at ../../py/mpprint.c:399
#2 0x80017f98 in mp_obj_new_exception_msg_vlist (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4, args=0xc07ffa44) at ../../py/objexcept.c:523
#3 0x80010920 in mp_raise_msg_varg (exc_type=0x8010f500 <mp_type_TypeError>, fmt=0x801007c4) at ../../py/runtime.c:1713
#4 0x80010c68 in mp_call_function_n_kw (fun_in=0x8011785a <vfs_posix_mount_obj>, n_args=2, n_kw=0, args=0xc07ffa84) at build-standard/genhdr/compressed.data.h:13
#5 0x80010da0 in mp_call_method_n_kw (n_args=2, n_kw=0, args=0xc07ffa7c) at ../../py/runtime.c:728
#6 0x800359b8 in mp_vfs_proxy_call (vfs=0xc0807e60, meth_name=585, n_args=2, args=0xc07ffad4) at ../../extmod/vfs.c:128
#7 0x80035eca in mp_vfs_mount (n_args=2, pos_args=0xc07ffb18, kw_args=0x8010f3f0 <mp_const_empty_dict_obj+4>) at ../../extmod/vfs.c:257
#8 0x800654f2 in main_ (argc=1, argv=0xc07ffdb4) at main.c:554
#9 0x80065ad6 in main (argc=1, argv=0xc07ffdb4) at main.c:494
The default alignment on m68k is 2 bytes instead of 4 bytes. See #18194
Code of Conduct
Yes, I agree