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.
Somehow, using `rb_class_new_instance` causes use-after-free errors in
the subsequent call to `set_private_data`.
Well, `rb_obj_alloc` is what's used in the normal MRI bindings. I just
replaced the `rb_obj_alloc` calls with `rb_class_new_instance`
at some point in binding-sandbox. Guess that wasn't a good idea.
This allows more flexibility when loading games in libretro builds,
since we can now load games either from a directory or from a ZIP or 7Z
archive. Also, the path cache is now active for all filesystem calls
made from inside Ruby.
This line is sometimes throwing an exception when the sandbox is
destroyed because the sandbox is being destroyed while it's in the
middle of yielding, and I guess it's undefined behaviour to call
`__wasm_call_dtors()` while the sandbox is yielding.
As evidenced by the try/catch block, I anticipated that
`__wasm_call_dtors()` could throw an exception. But I forgot that you
can't catch exceptions in a destructor! Let's just not call
`__wasm_call_dtors()` then. What harm can that do anyways, given that we
clean up all the memory used by the sandbox in the immediately following
lines in the destructor?
I've made it so that `Graphics.update` pauses the Ruby VM and returns to
the libretro frontend. Once the libretro frontend calls `retro_run()`
again, the Ruby VM resumes. This allows the libretro frontend to control
the rendering loop.
To stop Ruby's garbage collector from freeing Ruby `VALUE`s while we're
in the middle of using them in libretro builds, we need to make sure all
the `VALUE`s we use are on the sandbox's stack.
Also, to allow Ruby to recognize `VALUE`s on the sandbox's stack on
big-endian targets, I've changed the serialization of `VALUE`s. Before,
any `VALUE`s returned by a sandbox function were always converted to the
target's endian, and any `VALUE`s passed to sandbox functions as
argument were then converted back to WebAssembly's endianness,
little-endian. Now, `VALUE`s are always little-endian; they are no
longer converted to the target's endianness. That should be fine since
`VALUE`s are supposed to be opaque values.
I've decided to stop gambling with ways to make `-e` not crash Ruby on
startup in libretro builds (see commit
1473416a5a for context). Making Ruby load
a dummy script seems to work better.
Guys, I think I'm going insane. Every time I build the libretro Ruby
sandbox with a different version of Ruby, or even when I build Ruby at a
different path on my computer, there's some chance that the builds
produced with that version of Ruby and/or that path on my computer
result in Ruby crashing on startup in libretro builds. I've been
tweaking these command-line arguments that are passed to Ruby for a
while now, and I *think* these are the correct ones that will stop Ruby
from crashing.
