Blazor - WebAssembly `build_id` section

[bruno-garcia]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Production stack traces are hard to debug:

    at _mono_wasm_invoke_js_blazor (https://localhost:5001/_framework/dotnet.7.0.10.hef7nl7p9e.js:14:103886)
    at wasm://wasm/009931b2:wasm-function[313]:0x1d6b6
    at wasm://wasm/009931b2:wasm-function[283]:0x1cae4
    at wasm://wasm/009931b2:wasm-function[221]:0xe1d4
    at wasm://wasm/009931b2:wasm-function[220]:0xd044
    at wasm://wasm/009931b2:wasm-function[8115]:0x1a2377
    at wasm://wasm/009931b2:wasm-function[2040]:0x85b46
    at wasm://wasm/009931b2:wasm-function[2038]:0x85abc
    at wasm://wasm/009931b2:wasm-function[1395]:0x6889a
    at wasm://wasm/009931b2:wasm-function[313]:0x1d66f
    at wasm://wasm/009931b2:wasm-function[283]:0x1cae4
    at wasm://wasm/009931b2:wasm-function[221]:0xe1d4
    at wasm://wasm/009931b2:wasm-function[220]:0xd044
    at wasm://wasm/009931b2:wasm-function[8115]:0x1a2377
    at wasm://wasm/009931b2:wasm-function[2040]:0x85b46
    at wasm://wasm/009931b2:wasm-function[2045]:0x861ae
    at wasm://wasm/009931b2:wasm-function[2072]:0x8826d
    at wasm://wasm/009931b2:wasm-function[114]:0x9d80

Tools like Sentry support several debug file format. Including DWARF, PDB, Portable PDBs, etc.
It also supports Wasm DWARF but it requires a way to identify the wasm modules at runtime. It has a JavaScript integration that patches things at runtime in order to collect the loaded modules. And with that it can load debug files when events come into the service.

Patching the wasm with a debug id after the fact breaks ASP.NET's ability to check for integrity, forcing the user to abandon it through BlazorCacheBootResources set to false.

Describe the solution you'd like

Attach a section called debug_id in the .NET wasm module :

https://docs.sentry.io/platforms/native/guides/wasm/data-management/debug-files/identifiers/#wasm-build-ids

This way crash reporting tools can build integrations for Blazor to have better debuggability for production builds.

https://github.com/WebAssembly/tool-conventions/pull/183/files

Additional context

No response

[bruno-garcia]

Just realized perhaps this belongs in dotnet/runtime?

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Production stack traces are hard to debug:

    at _mono_wasm_invoke_js_blazor (https://localhost:5001/_framework/dotnet.7.0.10.hef7nl7p9e.js:14:103886)
    at wasm://wasm/009931b2:wasm-function[313]:0x1d6b6
    at wasm://wasm/009931b2:wasm-function[283]:0x1cae4
    at wasm://wasm/009931b2:wasm-function[221]:0xe1d4
    at wasm://wasm/009931b2:wasm-function[220]:0xd044
    at wasm://wasm/009931b2:wasm-function[8115]:0x1a2377
    at wasm://wasm/009931b2:wasm-function[2040]:0x85b46
    at wasm://wasm/009931b2:wasm-function[2038]:0x85abc
    at wasm://wasm/009931b2:wasm-function[1395]:0x6889a
    at wasm://wasm/009931b2:wasm-function[313]:0x1d66f
    at wasm://wasm/009931b2:wasm-function[283]:0x1cae4
    at wasm://wasm/009931b2:wasm-function[221]:0xe1d4
    at wasm://wasm/009931b2:wasm-function[220]:0xd044
    at wasm://wasm/009931b2:wasm-function[8115]:0x1a2377
    at wasm://wasm/009931b2:wasm-function[2040]:0x85b46
    at wasm://wasm/009931b2:wasm-function[2045]:0x861ae
    at wasm://wasm/009931b2:wasm-function[2072]:0x8826d
    at wasm://wasm/009931b2:wasm-function[114]:0x9d80

Tools like Sentry support several debug file format. Including DWARF, PDB, Portable PDBs, etc.
It also supports Wasm DWARF but it requires a way to identify the wasm modules at runtime. It has a JavaScript integration that patches things at runtime in order to collect the loaded modules. And with that it can load debug files when events come into the service.

Patching the wasm with a debug id after the fact breaks ASP.NET's ability to check for integrity, forcing the user to abandon it through BlazorCacheBootResources set to false.

Describe the solution you'd like

Attach a section called debug_id in the .NET wasm module :

https://docs.sentry.io/platforms/native/guides/wasm/data-management/debug-files/identifiers/#wasm-build-ids

This way crash reporting tools can build integrations for Blazor to have better debuggability for production builds.

https://github.com/WebAssembly/tool-conventions/pull/183/files

Additional context

No response

Author:	bruno-garcia
Assignees:	-
Labels:	arch-wasm, untriaged, area-VM-meta-mono
Milestone:	-

[SamMonoRT]

/cc @maraf @pavelsavara - please triage this issue, and set milestone accordingly.

[pavelsavara]

Related WebAssembly/tool-conventions#133

[pavelsavara]

Note that the stack above is most likely C code of the MonoVM and it's interpreter.
Looking at it's DWARF would not help you understanding the managed stack trace.

[bruno-garcia]

That's fair. I truncated off the C# code from the stack trace in this example. And it's true this was running in the interpreter. And I'm more interested in production environments so not really the interpreter. What I'm after is being able to map every frame back to something in its original form. App and "System" frames that is. I understand that might require going through DWARF for some native frames, and perhaps Portable PDB for some managed frames (at least to get line numbers in release builds, which we do already for normal .NET JIT workloads when users upload PDBs).

[pavelsavara]

Is there LLVM/emcc support for the build_id section already ?