Skip to content
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

LogPlugin silently overwrites the panic hook in WASM #12546

Closed
simbleau opened this issue Mar 17, 2024 · 5 comments · Fixed by #12557
Closed

LogPlugin silently overwrites the panic hook in WASM #12546

simbleau opened this issue Mar 17, 2024 · 5 comments · Fixed by #12557
Labels
A-Diagnostics Logging, crash handling, error reporting and performance analysis C-Bug An unexpected or incorrect behavior

Comments

@simbleau
Copy link
Contributor

The LogPlugin silently overwrites the panic handler on WASM. This means if you attempt to set your own panic handler, or use something like https://github.com/vectorgameexperts/web_panic_report, you have to overwrite it on Startup (thus, your panic handler can't be added until Startup)

Problematic code:

#[cfg(target_arch = "wasm32")]
{
console_error_panic_hook::set_once();
finished_subscriber = subscriber.with(tracing_wasm::WASMLayer::new(
tracing_wasm::WASMLayerConfig::default(),
));
}

This should not be considered acceptable default behavior.

3 options here, open to discussion.

  • (1) Provide a hook to the LogPlugin
  • (2) Take it out (my preferred answer - Logging really has nothing to do with panicking.)
  • (3) Consume the previous hook and wrap it, e.g.
    let old_handler = panic::take_hook();
    panic::set_hook(Box::new(move |infos| {
    eprintln!("{}", tracing_error::SpanTrace::capture());
    old_handler(infos);
    }));
@alice-i-cecile alice-i-cecile added C-Bug An unexpected or incorrect behavior A-Diagnostics Logging, crash handling, error reporting and performance analysis labels Mar 17, 2024
@alice-i-cecile
Copy link
Member

Why was this added in the first place? Can you check through the git history and link the PR?

@simbleau
Copy link
Contributor Author

simbleau commented Mar 17, 2024

Why was this added in the first place? Can you check through the git history and link the PR?

I believe it was added as a default to give WASM users the stack trace in their console, instead of the cryptic unreachable error. (see image)

image

It's been untouched since the original LogPlugin PR, 4 years ago, by @cart

image

I think the reason it has gone unnoticed for so long is probably that it's uncommon and fairly technical to implement your own WASM panic handler. @Vrixyz and I just made the web_panic_report crate yesterday and we found no similar crates.

I would love to hear @cart 's original intention with this - and whether we can remove it. Should this logic be a separate PanicHandlerPlugin in the DefaultPlugins instead?

@alice-i-cecile
Copy link
Member

Thanks for the detective work! Splitting this out so it can be disabled or overwritten seems like a sensible direction to me. No strong feelings on the exact architecture though.

@james7132
Copy link
Member

I think the reason it has gone unnoticed for so long is probably that it's uncommon and fairly technical to implement your own WASM panic handler. Vrixyz and I just made the web_panic_report crate yesterday and we found no similar crates.

This is probably the case. According to console_error_panic_handler's README, the alternative is an opaque error message that is borderline unusable to figure out what caused a panic.

@simbleau
Copy link
Contributor Author

simbleau commented Mar 18, 2024

Thanks for the detective work! Splitting this out so it can be disabled or overwritten seems like a sensible direction to me. No strong feelings on the exact architecture though.

@alice-i-cecile - Went ahead with the separate plugin strategy outlined above. PR #12557

github-merge-queue bot pushed a commit that referenced this issue Mar 19, 2024
# Objective

- Allow configuring of platform-specific panic handlers.
- Remove the silent overwrite of the WASM panic handler
- Closes #12546

## Solution

- Separates the panic handler to a new plugin, `PanicHandlerPlugin`.
- `PanicHandlerPlugin` was added to `DefaultPlugins`.
- Can be disabled on `DefaultPlugins`, in the case someone needs to
configure custom panic handlers.

---

## Changelog

### Added
- A `PanicHandlerPlugin` was added to the `DefaultPlugins`, which now
sets sensible target-specific panic handlers.

### Changed
- On WASM, the panic stack trace was output to the console through the
`BevyLogPlugin`. Since this was separated out into `PanicHandlerPlugin`,
you may need to add the new `PanicHandlerPlugin` (included in
`DefaultPlugins`).

## Migration Guide

- If you used `MinimalPlugins` with `LogPlugin` for a WASM-target build,
you will need to add the new `PanicHandlerPlugin` to set the panic
behavior to output to the console. Otherwise, you will see the default
panic handler (opaque, `unreachable` errors in the console).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Diagnostics Logging, crash handling, error reporting and performance analysis C-Bug An unexpected or incorrect behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants