Prism parser crashes in WASM (wasm32-wasi): `pm_parser_init` out-of-bounds memory access

[aim2bpg]

Summary

When Ruby 3.4 or 4.0 is compiled to WebAssembly (wasm32-wasi) with Prism as the default parser, string-based eval and class_eval calls crash with an out-of-bounds memory access in pm_parser_init.

Building with --with-parser=parse.y and overriding RB_DEFAULT_PARSER to RB_DEFAULT_PARSER_PARSE_Y avoids the crash.

This issue is filed to investigate whether pm_parser_init has a WASM-specific bug. The parse.y workaround is a temporary measure; ideally Prism should work correctly in WASM environments without requiring a parser downgrade.

Environment

• Ruby: 3.4.8 / 4.0.2 (compiled to wasm32-unknown-wasip1 via ruby_wasm 2.9.0)
• wasi_sdk: 24.0
• WASM runtime: wasmtime

Steps to reproduce

1. Build Ruby 3.4 or 4.0 for WASM with the default Prism parser
2. Run wasmtime run ruby-core.wasm -e 'eval("puts \"hello\"")'

Observed behaviour

The process crashes with exit code 134 (SIGABRT):

Error: failed to run main module ruby-core.wasm
...
ruby!pm_parser_init
ruby!pm_parse_string
ruby!eval_make_iseq
ruby!eval_string_with_cref
ruby!specific_eval
ruby!rb_mod_module_eval_internal
...
memory fault at wasm address 0xfffffffc in linear memory of size 0xffd30000
wasm trap: out of bounds memory access

The crash occurs in the call chain:
rb_mod_module_eval_internal → specific_eval → eval_string_with_cref → eval_make_iseq → pm_parse_string → pm_parser_init.

Ruby 3.3 (which uses parse.y by default) does not exhibit this crash.
Note that puts "hello" without eval does not crash; the issue is specific to string-based eval paths that invoke Prism.

Workaround

Forcing the parse.y parser avoids the crash. Two changes are needed:

1. Source patch (version.c): override RB_DEFAULT_PARSER to
   RB_DEFAULT_PARSER_PARSE_Y
2. Build flag: pass --with-parser=parse.y to configure

Patch file:
https://github.com/aim2bpg/rubree/blob/main/ruby_wasm_patches/fix-default-parser-parse-y.patch

With this workaround applied, Ruby 3.4.8 and 4.0.2 boot and run successfully in WASM (verified with a Rails 8.1.3 application).

Note: this is a temporary workaround for WASM environments only and has no effect on native Ruby builds.

Related

• Seems to be a compatibility issue with Ruby 3.4 palkan/wasmify-rails#7 — another Ruby 3.4 WASM incompatibility (different
  root cause: missing C extension)

[aim2bpg]

Related issues (for context)

While investigating this issue, we found two additional WASM-related problems that required separate workarounds:

• deprecate.rb methods fail in WASM (wasm32-wasi): blocks not received by class_eval / define_method rubygems#9456 — deprecate.rb block passing fails in WASM (triggered after applying the parse.y workaround above)
• Fix source URL override: build_source_aliases → build_config_aliases palkan/wasmify-rails#11 — source URL override silently broken in ruby_wasm 2.9.0+ (PR open)
• Add require rubygems to shim.rb for Ruby 4.0 compatibility palkan/wasmify-rails#12 — shim.rb missing require "rubygems" for Ruby 4.0 (PR open)

All three were encountered while building a Rails 8.1.3 app for WASM with Ruby 3.4.8 and 4.0.2.

For a full overview of all WASM-related issues we encountered, see our WASM Build Notes.

[Earlopain]

This seems to be a documented limitation of wasm support in ruby and not directly related to prism. Please see step 6 on https://github.com/ruby/ruby/blob/661344b1041fbbe661038d28ac0a2c8895ab608b/wasm/README.md#steps which mentions this:

If you got Out of bounds memory access while running the produced ruby, you may need to increase the maximum size of stack.

Please try building with a increased stack size as mentioned and see if it resolves the error.

[aim2bpg]

Thank you for the quick response and the helpful pointer!

I wasn't aware of the stack size option — I'll give it a try.

[kddnewton]

@aim2bpg can you confirm if that fixes the problem? I'm assuming this is beyond the realm of just Prism, so am looking to close.

[aim2bpg]

@Earlopain @kddnewton
I haven't been able to verify the stack size fix yet, but given your assessment I'll go ahead and close this. Sorry for the noise, and thank you both for taking the time to look into it.