vmware-labs / webassembly-language-runtimes

Wasm Language Runtimes provides popular language runtimes (Ruby, Python, …) precompiled to WebAssembly that are tested for compatibility and kept up to date when new versions of upstream languages are released
Apache License 2.0
336 stars 29 forks source link

Runtime memory errors when importing modules in the se2-bindings wrapper #79

Closed flaki closed 1 year ago

flaki commented 1 year ago

Describe the bug

The following affects the experimental runtime wrapper of the bindings branch.

Whenever py-plugin/plugin.py imports any built-ins (tested with re, string, enum), the code will fail during runtime with a "memory access out of bounds" style error.

Reproduction steps

  1. add import "string" at the top of "py-plugin/plugin.py"
  2. run the wrapper with the given plugin (e.g. /run-e2e.sh)
  3. observe the runtime exit with a memory error

Expected behavior

The wrapper script should be able to import built-in modules. In fact the mainline Wasm-ified Python interpreter imports modules just fine.

Additional context

Example of the runtime error with the displayed backtrace:

``` [runtime.js] | Loading module ../wasm-wrapper-c/target/wasm32-wasi/wasm-wrapper-c.wasm ... (node:1475955) ExperimentalWarning: WASI is an experimental feature and might change at any time (Use `node --trace-warnings ...` to show where the warning was created) [utils.c] | Current working dir: / [runtime.js] | Error: RuntimeError: memory access out of bounds at dlmalloc (wasm://wasm/060a20c6:wasm-function[16951]:0xb98135) at malloc (wasm://wasm/060a20c6:wasm-function[16950]:0xb9797f) at _PyMem_RawMalloc (wasm://wasm/060a20c6:wasm-function[2766]:0x13262f) at PyObject_Malloc (wasm://wasm/060a20c6:wasm-function[2803]:0x1354e8) at new_keys_object (wasm://wasm/060a20c6:wasm-function[2014]:0xebbbe) at _PyDict_NewKeysForClass (wasm://wasm/060a20c6:wasm-function[2120]:0xfb9b0) at type_ready_managed_dict (wasm://wasm/060a20c6:wasm-function[3232]:0x15f654) at type_ready (wasm://wasm/060a20c6:wasm-function[3172]:0x158b9b) at PyType_Ready (wasm://wasm/060a20c6:wasm-function[3165]:0x158380) at type_new_impl (wasm://wasm/060a20c6:wasm-function[3204]:0x15c569) ```

When discussed with @assambar he reports that this reproduces, albeit only seems to happen for toplevel imports.

assambar commented 1 year ago

Thanks for reporting this.

So, I tried testing with the interpreter from libpython (via Py_BytesMain). Still seeing the same weird memory allocation or deallocation behavior - failures are consistent, but different depending on which modules you try to import.

I am debugging ...

assambar commented 1 year ago

So, this turns out to be a stack overflow. What got me off the proper trail is that we were getting these errors in python memory operations. The fix is to simply build the wasm module with a bigger stack. E.g. 512K, as they do in Python.wasm. Just passing this to the linker will suffice

-Wl,-z,stack-size=524288