I've changed the sandbox fibers in libretro builds to be stored in a
linked list, with an unordered map mapping fiber keys to linked list
nodes for efficient lookup. The original implementation was just having
all the fibers in an unordered map.
The new implementation has the benefit that fibers are always iterated
in the same order on every platform, which allows save state creation to
be more deterministic.
Libretro provides a way to detect when the OpenGL context is destroyed,
like on Android and possibly also iOS when switching between apps. This
commit implements reinitializing all OpenGL objects when this happens so
that the graphics continue to function in this case.
This field needs to be initialized when `struct frame` is constructed,
or its value may be random.
I also changed the type of `stack_index` to `wasm_size_t` so that it's
the same size on every platform.
This commit adds `sb()->create_object()`, `sb()->get_object()`,
`sb()->check_object_type()` and `sb()->destroy_object()` in libretro
builds to keep track of all C++ objects allocated by the bindings in
libretro builds. This has some benefits:
* Any C++ objects allocated by the bindings that are still alive when
the game terminates can now be deallocated instead of being leaked
like before.
* We now keep track of the types of all objects allocated by the
bindings, so we will be able to detect when the bindings attempt to
access objects of mismatching type.
* Keeping track of all allocated objects is required to implement
libretro save states.
* Objects are now kept track of using numeric keys whose sizes are the
same on every platform rather than pointers, which helps with making
save states portable across platforms.
In big-endian libretro builds, the WebAssembly memory is reversed, so no
byte-swapping is required to read from/write to WebAssembly memory
(which is little-endian).
However, that means the ways to get and set values in WebAssembly memory
are endianness-dependent, so I've added the correct such ways for
big-endian platforms.
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.)
Any relative paths that the game tries to access in libretro builds will
now be relative to whatever is the current working directory in the Ruby
sandbox, which will also now be initialized to the game directory during
initialization. Before, all of the bindings that took paths were
hardcoded to prepend the path with the game directory.
The copy constructors are causing problems when the `fiber.stack` vector
gets reallocated when its capacity is full, since when vectors are
reallocated, the elements are moved (or copied if there's no usable move
constructor) to the reallocated memory and then the original elements
are destroyed.
This premature calling of destructors leads to double-free and
use-after-free errors.
I fixed it by deleting the copy constructors and explicitly defining
move constructors.
Not sure why, but this fixes crashes when calling variadic functions in
the Ruby API in libretro builds when Ruby is built without `-DNDEBUG`.
Maybe the previous way of calling varargs functions was undefined
behaviour somehow.
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.
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.
