The binding coroutines in libretro builds are constructed on the VM
stack, so reallocating the VM memory would corrupt the memory of any
currently existing coroutines.
I've changed it so that the coroutines are no longer constructed on the
VM stack so that they're unaffected by VM memory reallocations, and
added a "slot" mechanism for storing variables on the VM stack. (Any
Ruby `VALUE`s used by a coroutine have to be stored on the VM stack so
that the Ruby garbage collector doesn't free them while they're being
used, which is why the slot mechanism is necessary.)
Okay, the coroutine implementation of `sandbox_malloc` is clearly
broken. It would be working if Asyncify instrumented the `memory.grow`
WebAssembly instruction, but it doesn't instrument it.
This commit reverts commit 42c4ff9497 and
also increases the default VM memory allocation from 64 MiB to 96 MiB to
account for the lack of ability to increase the memory allocation at run
time. I'll find some new way to implement increasing the memory
allocation later.
In release 1.0 of the WebAssembly Specification, it says that all the
bytes in WebAssembly memory need to be initialized to 0 on creation of
the memory, and when memory is grown, the new bytes also need to be
initialized to 0.
It seems this zeroing behaviour is indeed required for the sandbox to
operate correctly. Not zeroing leads to undefined behaviour. This
manifested as a crash that occurred when restarting the libretro core,
but for some reason, only on Emscripten. Not sure why this didn't happen
on other platforms. Even sanitizers weren't able to detect the bug!
(cherry picked from commit edf061e323b8f0ab0c6a72c76ae7ccc07a1649c0)
According to AddressSanitizer, when `sandbox_malloc` causes the
WebAssembly memory to grow in size, every single coroutine on the
sandbox stack gets corrupted. So if `sandbox_malloc` is going to cause
the memory to grow in size, we need to yield so that there are no
coroutines on the sandbox stack while the reallocation occurs.
