Cannot list C++ sources or hit a breakpoint with large WASM bundles

[ecorm]

Environment info:

• Windows 10
• "JavaScript and TypeScript Nightly" extension
• "WebAssembly DWARF Debugging" extension version 1.0.1.
• VSCode version 1.95.1.

I have a large 274MB WASM file served to a browser that I've been able to successfully debug using Chrome via its WASM DWARF debugging extension.

I cannot get VSCode to list any C++ source files in the Loaded Scripts window, nor can I get it to hit any breakpoints in a C++ file.

I can see the myapp.wasm file under all the worker threads in the Loaded Scripts window, but no C++ source files appear next to it.

If I try to open the myapp.wat file, it loads the following text:

Could not load source 'localhost/myapp.wat': Error processing source: RangeError: Invalid string length
      at Array.join (<anonymous>)
      at vg.getDisassembly (c:\Users\emile.cormier\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:72:20864)
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
      at async ht.content (c:\Users\emile.cormier\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:70:4385)
      at async r._onSource (c:\Users\emile.cormier\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:134:3006)
      at async ou._onMessage (c:\Users\emile.cormier\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:48:4942).

Searching for "RangeError: Invalid string length" reveals that the maximum Javascript string length is roughly 268 million characters, which my non-disassembled 274MB WASM file already exceeds.

I also noticed that the Output > Windows outputs these errors:

2024-11-07 15:41:21.851 [error] [Extension Host] (node:30644) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11
uncaughtException listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

(Use `Code --trace-warnings ...` to show where the warning was created)

2024-11-07 15:41:21.860 [error] [Extension Host] (node:30644) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 unhandledRejection listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

2024-11-07 15:53:08.204 [error] [Extension Host] (node:30644) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [Worker]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

The timestamps seem to correspond to when I launch and stop the debugging session.

[jpothier-figma]

+1 on this. My company also has a large WASM bundle that is not debuggable with this extension.

Update: After some investigation, I found this bit in the chromium library this extension relies on: https://chromium.googlesource.com/v8/v8/+/refs/heads/main/src/inspector/v8-debugger-agent-impl.cc#79. Seems the size limitation stems from JSON encoding of the WASM bundle.

[jpothier-figma]

I'd like to share a workaround we found. It turns out, the string-length limitation only affects loading wasm from a binary blob. When you do WebAssembly.instantiate(fs.readFileSync(wasmPath)), this is saved into v8 with an auto-generated identifier like my-wasm-abc123.wasm. The extension references the module with a URI like wasm://my-wasm-abc123.wasm and retrieves its contents by sending the getScriptSource request to the v8 debugging agent within the target node process, which is subject to the string length limitation.

However, if you instead do WebAssembly.instantiateStreaming(fetch(wasmUrl)), the extension downloads the wasm source directly via fetch--bypassing the v8 debugging agent--which never creates an intermediate string. And then debugging works!

[ecorm]

@jpothier-figma , can you clarify in which context your proposed workaround must be done? I'm not the one who set up our WASM project, so it's mostly "magic" to me. If you can provide some hints on where to apply your workaround, I can forward that information to my colleagues who are in the know.

[jpothier-figma]

@jpothier-figma , can you clarify in which context your proposed workaround must be done? I'm not the one who set up our WASM project, so it's mostly "magic" to me. If you can provide some hints on where to apply your workaround, I can forward that information to my colleagues who are in the know.

Sure, basically the problem we had was we were reading our wasm file off disk then loading it as a binary blob into the runtime:

const wasmBlob = fs.readFileSync("/path/to/app.wasm")
WebAssembly.instantiate(wasmBlob)

The way I solved our debugging problem was changing this to streaming from an http request:

// First, set up an http server at localhost:1234 that will serve app.wasm as a static file. Then:
WebAssembly.instantiateStreaming(fetch("http://localhost:1234/app.wasm"))

This actually accomplishes two things:

1. extension can successfully download and parse the wasm file, regardless of how big it is
2. also helps preserve file origin information such that the extension also downloads our app.wasm.dwp file properly ("split-dwarf" debug info)

With this, I can see and breakpoint in C++ sources. If you don't, you may have to play with the sourceMapPathOverrides setting to remap paths in the DWARF.

Note it will still crash if you try to get disassembly, since that still serializes the wasm to a string. But the extension will no longer try to step into disassembly because it should have the sources now.