esp32: viper tests fail after a while
If I execute a micropython/viper test on an esp32 in a loop it starts failing after a while (I started with a HW reset before this):
> while true; ./run-tests --device /dev/ttyUSB0 --target esp32 micropython/
viper_ptr32_load.py; end
pass micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
1 tests passed
[...]
pass micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
1 tests passed
FAIL micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
0 tests passed
1 tests failed: viper_ptr32_load
skip micropython/viper_ptr32_load.py
0 tests performed (0 individual testcases)
0 tests passed
1 tests skipped: viper_ptr32_load
It takes less than a minute to get there. I noticed because running the full test suite shows this, e.g.:
> ./run-tests --device /dev/ttyUSB0 --target esp32 -d micropython
[...]
pass micropython/viper_misc_intbig.py
pass micropython/viper_ptr16_load.py
pass micropython/viper_ptr16_store.py
pass micropython/viper_ptr32_load.py
pass micropython/viper_ptr32_store.py
FAIL micropython/viper_ptr8_load.py
FAIL micropython/viper_ptr8_store.py
FAIL micropython/viper_subscr.py
FAIL micropython/viper_try.py
FAIL micropython/viper_types.py
FAIL micropython/viper_with.py
65 tests performed (411 individual testcases)
59 tests passed
4 tests skipped: heap_locked heapalloc_bytesio2 meminfo memstats
6 tests failed: viper_ptr8_load viper_ptr8_store viper_subscr viper_try viper_types viper_with
The tests that fail at the end are because they're at the end, not because they fail per-se.
tests/micropython: Make tests behave in low memory condition.
Summary
This PR changes the "viper_ptr*_store_boundary" tests to make them fail more gracefully in low memory conditions.
The original version of the tests compiled viper code blocks on the fly when it needed them, making them fail at runtime on some boards that do not come with enough memory for this test. This clashes with "run-tests.py"'s ability to look for a particular signature to mark tests as skipped due to not enough memory.
Now compiled code blocks are generated at the beginning of the test inside an appropriate exception handler. In case of a memory error when pre-compiling a code block, the running test exits reporting a low memory condition to the test runner. This allows to have clean test runs on all platforms when it comes to viper pointer tests.
Testing
Modified tests were run on an ESP8266 without any parameters to make sure they were reported as too large, and then with an appropriate prologue file to make sure the output is correct. The same tests were also executed on the Unix port on x64, just to be sure.
Trade-offs and Alternatives
I've tried to simplify certain parts of the test to counter the added complexity of generating blocks upfront, although it came with a test output data rearrangement to make it work. On the other hand, now those tests share most of their code except for the typed getters and setters.