Repository navigation
Description
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/wasm
SDK Version
Framework Version
N/A (plain browser JS + Emscripten WASM)
Link to Sentry event
https://sentry-sdks.sentry.io/issues/7296298931/events/86fe929d3bd942dea18b2536af515eb3/
Reproduction Example/SDK Setup
Minimal reproduction project attached as ZIP (see README):
wasm-symbolication.zip
Sentry.init({
dsn: __YOUR_DSN__,
debug: true,
integrations: [Sentry.wasmIntegration()],
});
// Non-streaming load (broken)
fetch("crash.wasm")
.then(function (r) { return r.arrayBuffer(); })
.then(function (buf) { return WebAssembly.instantiate(buf); })
.then(function (result) {
result.instance.exports.divide(1, 0); // triggers RuntimeError
});Steps to Reproduce
- Build the repro:
npm run build(compiles C to WASM withbuild_idvia Emscripten) - Upload symbols:
npm run upload:symbols(uploads WASM debug files + JS source maps) - Serve:
npm run dev - Open
/index.html(non-streaming load) and click "Divide by zero" - Compare with
/streaming.html(streaming load) — same button, same WASM
Expected Result
Both loading methods should produce an event with debug_meta.images containing the WASM module, allowing Sentry to symbolicate the stack frame (resolve to crash.c:5, function divide).
Actual Result
Streaming (/streaming.html) works:
debug_meta.imagescontains the WASM image with correctcode_id,debug_file- Frame symbolicated to
crash.c:5withaddr_mode=rel:0
Non-streaming (/index.html) is BROKEN:
debug_metais completely absent from the event- WASM frame has
platform=nativeandinstruction_addrbut noaddr_mode - No symbolication occurs despite symbols being uploaded
Additional Context
We are adding support for Web platform in Sentry for Godot Engine. This bug was discovered during development.
The SDK only patches WebAssembly.instantiateStreaming() and WebAssembly.compileStreaming(). Non-streaming APIs (instantiate(buffer), compile(), new Module()) are never intercepted, so modules loaded through them are never registered in the image registry.
This affects any runtime using non-streaming loading, including Emscripten's dynamic library loader (used by Godot Engine, GDExtensions, side modules, etc).
Priority
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.
Metadata
Metadata
Assignees
Projects
- StatusShow more project fieldsNo status
Activity
linear commentedon Feb 27, 2026
JS-1825
andreiborza commentedon Feb 27, 2026
Thanks Serhii, I'll take a look on Monday. Thanks again for the repro!
harshit078 commentedon Mar 9, 2026
@andreiborza , If not being worked internally. Mind if I take this up ?
andreiborza commentedon Mar 10, 2026
@harshit078, I had a quick look over it but didn't really start on it yet. One key question is how we actually map these back to URLs...
Feel free to take a stab at it! 🙏
mydea commentedon Oct 23, 2026
Fixed by #23767 (patching non-streaming
WebAssembly.instantiate/WebAssembly.compileload paths) with a follow-up in #23999. Closing.