-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blazor - WebAssembly build_id
section
#91049
Comments
build_id
section
Just realized perhaps this belongs in |
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsIs there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.Production stack traces are hard to debug:
Tools like Sentry support several debug file format. Including DWARF, PDB, Portable PDBs, etc. Patching the Describe the solution you'd likeAttach a section called 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 contextNo response
|
/cc @maraf @pavelsavara - please triage this issue, and set milestone accordingly. |
Related WebAssembly/tool-conventions#133 |
Note that the stack above is most likely C code of the MonoVM and it's interpreter. |
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). |
Is there LLVM/emcc support for the |
I believe so: https://reviews.llvm.org/D107662 |
Hey, we're looking into improving the Blazor debugability. Is there any update on this? |
It seems LLVM now has |
@thaystg we should discuss what we can do |
maybe |
and we could also expose that ID on JavaScript |
Any updates on this one? I imagine for .NET 9 it's too late, but perhaps we get this going for .NET 10?
Would be great to have full/proper stack trace for production exception with server side symbolication so app deployments can be small/optimized and developers can have good debugging tools in production |
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Production stack traces are hard to debug:
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 throughBlazorCacheBootResources
set tofalse
.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
The text was updated successfully, but these errors were encountered: