e.g., allocating a 192x32x6bpp matrix would be enough to trigger this
reliably on a Metro M4 Express using the "memory hogging" layout.
Allocating 64x32x6bpp could trigger it, but somewhat unreliably.
There are several things going on here:
* we make the failing call with interrupts off
* we were throwing an exception with interrupts off
* protomatter failed badly in _PM_free when it was partially-initialized
Incorporate the fix from protomatter, switch to a non-throwing malloc
variant, and ensure that interrupts get turned back on.
This decreases the quality of the MemoryError (it cannot report the size
of the failed allocation) but allows CircuitPython to survive, rather
than faulting.
Otherwise, out of range writes would occur in tilegrid_set_tile, causing a safe mode reset.
```
Hardware watchpoint 6: -location *stack_alloc->ptr
Old value = 24652061
New value = 24641565
0x000444f2 in common_hal_displayio_tilegrid_set_tile (self=0x200002c8 <supervisor_terminal_text_grid>, x=1, y=1, tile_index=0 '\000')
at ../../shared-module/displayio/TileGrid.c:236
236 if (!self->partial_change) {
(gdb)
```
Builds of the esp32s2 targets frequently fail:
```
-- Found Git: /usr/bin/git (found version "2.28.0")
-- Initialising new submodule components/asio/asio...
warning: could not look up configuration 'remote.origin.url'. Assuming this repository is its own authoritative upstream.
Submodule 'components/asio/asio' (/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git) registered for path 'components/asio/asio'
fatal: repository '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' does not exist
fatal: clone of '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' into submodule path '/home/runner/work/circuitpython/circuitpython/ports/esp32s2/esp-idf/components/asio/asio' failed
Failed to clone 'components/asio/asio'. Retry scheduled
fatal: repository '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' does not exist
fatal: clone of '/home/runner/work/circuitpython/circuitpython/ports/espressif/asio.git' into submodule path '/home/runner/work/circuitpython/circuitpython/ports/esp32s2/esp-idf/components/asio/asio' failed
Failed to clone 'components/asio/asio' a second time, aborting
CMake Error at esp-idf/tools/cmake/git_submodules.cmake:48 (message):
Git submodule init failed for components/asio/asio
Call Stack (most recent call first):
esp-idf/tools/cmake/build.cmake:78 (git_submodule_check)
esp-idf/tools/cmake/build.cmake:160 (__build_get_idf_git_revision)
esp-idf/tools/cmake/idf.cmake:49 (__build_init)
esp-idf/tools/cmake/project.cmake:7 (include)
CMakeLists.txt:8 (include)
```
It's not clear how/why this happens--is it something to do with our
multithreaded build?. Attempt to clear it up by manually checking out these
submodules ourselves.
A crash like the following occurs in the unix port:
```
Program received signal SIGSEGV, Segmentation fault.
0x00005555555a2d7a in mp_obj_module_set_globals (self_in=0x55555562c860 <ulab_user_cmodule>, globals=0x55555562c840 <mp_module_ulab_globals>) at ../../py/objmodule.c:145
145 self->globals = globals;
(gdb) up
#1 0x00005555555b2781 in mp_builtin___import__ (n_args=5, args=0x7fffffffdbb0) at ../../py/builtinimport.c:496
496 mp_obj_module_set_globals(outer_module_obj,
(gdb)
#2 0x00005555555940c9 in mp_import_name (name=824, fromlist=0x555555621f10 <mp_const_none_obj>, level=0x1) at ../../py/runtime.c:1392
1392 return mp_builtin___import__(5, args);
```
I don't understand how it doesn't happen on the embedded ports, because
the module object should reside in ROM and the assignment of self->globals
should trigger a Hard Fault.
By checking VERIFY_PTR, we know that the pointed-to data is on the heap
so we can do things like mutate it.
Since e121e267ad, the shared bindings matrix uses the stubs.
Therefore, we must build them! This should fix the failure to build
the docs on readthedocs.org.
Neither @sommersoft nor I saw this locally since we had previously built
the stubs. github CI didn't see it, because it manually builds the stubs
in an earlier step of the build process, and does not clean the tree
in between.
.. this makes it take a fraction of the time, at least on systems
with a lot of CPU threads. Even on my old laptop with a 2-core CPU
it reduces the time from 55s to 27s.
