Making UNIX nanbox on Ubuntu 22.04

[yf13]

Dear experts,

I built the nanbox variant of UNIX port on Ubuntu 22.04 with minor tweaks on upstream makefile system and here comes the test result:

$ cd micropython/tests
$ BUILD=/tmp/bbb MICROPY_MICROPYTHON=${BUILD}/micropython ./run-tests.py -j2
platform=linux
pass  basics/bytes_mult.py 
pass  basics/0prelim.py
...
skip  unicode/unicode_ure.py
pass  extmod/hashlib_md5.py 
pass  extmod/hashlib_sha1.py
902 tests performed (28444 individual testcases)
902 tests passed
98 tests skipped: attrtuple2 class_inplace_op2 builtin_range_binop fun_code fun_code_micropython io_buffered_writer memoryview_itemsize sys_getsizeof sys_tracebacklimit namedtuple_asdict machine_disable_irq machine_i2s_rate machine_rtc machine_soft_timer machine_spi_rate machine_uart_irq_txidle machine_uart_tx marshal_basic marshal_micropython marshal_stress re_debug re_groups cmd_parsetree re_span ssl_ioctl ssl_poll repl_sys_ps1_ps2 asyncio_as_uasyncio heap_locked import_mpy_native import_mpy_native_gc native_closure native_const native_const_intbig native_for native_fun_attrs native_fun_attrs_code native_gen native_misc native_try native_try_deep native_while native_with viper_addr viper_args viper_binop_arith viper_binop_arith_uint viper_binop_bitwise_uint viper_binop_comp viper_binop_comp_imm viper_binop_comp_uint viper_binop_divmod viper_binop_multi_comp viper_cond viper_const viper_const_intbig viper_error viper_globals viper_import viper_misc viper_misc2 viper_misc3 viper_misc_intbig viper_ptr16_load viper_ptr16_load_boundary viper_ptr16_store viper_ptr16_store_boundary viper_ptr32_load viper_ptr32_load_boundary viper_ptr32_store viper_ptr32_store_boundary viper_ptr8_load viper_ptr8_load_boundary viper_ptr8_store viper_ptr8_store_boundary viper_storeattr viper_subscr viper_subscr_multi viper_try viper_types viper_unop viper_with cexample_class cexample_module cexample_subclass sys_settrace_features sys_settrace_generator sys_settrace_loop extra_coverage ffi_int_base ffi_int_long32 ffi_int_long64 ffi_int_types cryptolib_aes128_ctr deflate_compress deflate_compress_memory_error deflate_stream_error unicode_ure

If above result is correct I can send a PR later.

[stinos]

Looks normal: no failures, and the skipped ones should be all for features which aren't enabled.

[yf13]

@stinos, thanks for confirmation.

The issue I noticed is at ports/unix/Makefile:L124 . Currently it uses non-existing folder i686-linux-gnu which should be i386-linux-gnu on Ubuntu 22.04 after 32 bit toolchains are installed:

$ dpkg -S /usr/include/i386-linux-gnu/
linux-libc-dev:i386, libffi-dev:i386, libstdc++-11-dev:i386, libc6-dev:i386: /usr/include/i386-linux-gnu

However, I tried nanbox variant again just now but failed to reproduce the issue I met earlier. Or that folder i686-linux-gnu did exist in a different Linux environment before?

[yf13]

Thanks for the suggestion. I can still build following variants with that line commented:

• make VARIANT=nanbox MICROPY_PY_FFI=1
• make MICROPY_PY_FFI=1 MICROPY_FORCE_32BIT=1

So that block can really be removed. Let's see how CI check goes with this PR.

[yf13]

This CI error can't reproduce on Ubuntu 22.04 locally here:

$ $ clang -v
Ubuntu clang version 14.0.0-1ubuntu1.1
...
$ (source tools/ci.sh && ci_unix_float_clang_build)
$ (source tools/ci.sh && ci_unix_float_clang_run_tests)
...
954 tests performed (27530 individual testcases)
954 tests passed
51 tests skipped

@stinos any hints?

[stinos]

It's unrelated to your PR. The test seems faulty: what I think is happening is that the thread_main function is still running in another thread while the main thread is already exiting, removing names from the main scope, so one gets weird errors like (expand the 'print failures')

Unhandled exception in thread started by <function thread_main at 0x7f567b405420>
Traceback (most recent call last):
  File "/home/runner/work/micropython/micropython/tests/extmod/select_poll_eintr.py", line 27, in thread_main
NameError: name 'lock' isn't defined

or

Unhandled exception in thread started by <function thread_main at 0x7ff2a3405420>
Traceback (most recent call last):
  File "/home/runner/work/micropython/micropython/tests/extmod/select_poll_eintr.py", line 28, in thread_main
NameError: name 'time' isn't defined

I'd say it's simply missing a join call.

[yf13]

Thanks for sharing the analysis.
Did you assume that poll() could return for reasons other than gc_collect()?

I don't see threading module, how about join like below:

$ git diff 
...
@@ -19,6 +19,7 @@ def thread_main():
     # Could possibly use _thread._interrupt_main() instead if MicroPython had it.
     gc.collect()
     print("thread gc end")
+    lock.release()
 
 
 # Start a thread to interrupt the main thread during its call to poll.
@@ -37,6 +38,9 @@ poller.register(s, select.POLLIN)
 # Poll on the UDP socket for a set timeout, which should be reached.
 print("poll")
 lock.release()
+while not lock.locked():
+    pass
+
 t0 = time.time_ns()
 result = poller.poll(400)
 dt_ms = (time.time_ns() - t0) / 1e6
@@ -46,5 +50,9 @@ if 380 <= dt_ms <= 600:
 else:
     print("dt not in range:", dt_ms)
 
+# join thread_main
+while lock.locked():
+    pass
+
 # Clean up.
 s.close()

[stinos]

see py/modthread.c

There doesn't seem to be a join method though. Not sure if spinning on locked is the right way, but looking at the tests in the tests/thread directory simply putting a time.sleep(1) at the end of a script is a simple and accepted way to wait for thread termination.

[yf13]

I've added a commit in #17638 and it passed CI. The change is to add `global lock` in `thread_main`. I checked it locally with: ```sh $ for i in {1..100}; do ./firmware.elf select_poll_eintr.py; done ``` A sleep() based implementation by replacing `pass` with `time.sleep(0.01)` didn't pass same test until the `global` line was added. So I think that `global` line helps more?

[stinos]

it passed CI.

I wouldn't be surprised if this is just a coincidence and doesn't gurantee no failurs in the future. Because global isn't needed, the code can work without it as the succesful tests (you not being able to reproduce this locally, from other PRs etc) show, and per Python syntax rules.

time.sleep(0.01)`

That's still 100 times less than sleep(1) so might simply not be sufficient.

[yf13]

Thank you @stinos. I revised join implementation and updated the PR.

Can you teach why main thread can exit before gc_collect() called? The NameErrors happened before the gc_collect call line. Is something other than gc_collect() can cause poll() to return?

[yf13]

@stinos per further notes in #17638, it looks the root cause does relate to globals map rehashing. see #11604 for more explanations.

[stinos]

it looks the root cause does relate to globals map rehashing

Aha, in that case: apologies, my guess wrt threads was wrong then.

Can you teach why main thread can exit before ...

In general: the threads in MicroPython are threads impleneted in C. So if the main script exits, the main thread is still running C code to cleanup MicroPython objects and whatnot. While at the same time the other thread can also still be running the other MicroPython code. I.e. it's not because the last line of Python code in the main thread has executed that all other threads stop right at that point.

[yf13]

@stinos many thanks!

I was wondering that poll() in main thread won't return before a timeout triggered by gc_collect() at about 400ms? if so, then the child thread should has no use for lock after gc_collect(), thus won't throw exception at L14 or L15.