Rust stack traces on Dart side during a panic

[fzyzcjy]

To ensure #1487 (reply in thread) is not a bug of FRB
It is expected Rust behavior, but we can improve it.

EDIT

• implement
• update doc

[fzyzcjy]

@AlienKevin I realize my memory was too blur that I confused how I setup anyhow error vs panic in my app. For anyhow error, it is there as long as backtrace env variable is configured. For panic, it involves a bit more:

1. To ensure it is captured in PanicException.message, need to PR like https://stackoverflow.com/questions/69593235/how-to-get-panic-information-i-e-stack-trace-with-catch-unwind (that was asked by me myself and I completely forget what I did)
2. Alternatively, what is done in my app is that, just setup "sentry rust" (in addition to "sentry dart" we are already using). The rust side will report another event in sentry dashboard with correct stack traces.

Looking backward, it seems that next time when near #1487 (reply in thread), I should ask "please show the complete messages", and then it may be easier to realize it is this problem since I will realize there is no error message inside PanicException.message.

[AlienKevin]

Alternatively, what is done in my app is that, just setup "sentry rust" (in addition to "sentry dart" we are already using). The rust side will report another event in sentry dashboard with correct stack traces.

I see. Would you mind providing a short example on how to integration sentry_rust into the FRB setup? I tried two ways but somehow the panic is not registered:

1. Calling sentry::init in the constructor of my Api struct
2. Calling sentry::init in lazy_static and getting back a global ClientInitGuard

The init code is copied from the Sentry doc:

let guard = sentry::init((include_str!("../sentry_dsn.txt"), sentry::ClientOptions {
        release: sentry::release_name!(),
        ..Default::default()
    }));

Or maybe I need to configure my Flutter Sentry project to also accept Rust errors?

[fzyzcjy]

Just call sentry::init, and let the guard be never dropped.

call it may not be enough, because the guard is dropped.
lazy_init may not be enough, because if you dont touch it, it is never inited.

This is indeed a Sentry issue, not FRB issue, IMHO...

[AlienKevin]

Just call sentry::init, and let the guard be never dropped.

That works, thanks! I basically used a OnceCell: static SENTRY_GUARD: OnceCell<sentry::ClientInitGuard> = OnceCell::new(); and initialized it in my Api struct's constructor.

This is indeed a Sentry issue, not FRB issue, IMHO...

You are right. And after doing more research, I found out that panic backtracing is a long-standing pain point at the intersection of rust-lang, sentry, and mobile platforms:

• iOS: symbols are supported but no line numbers or source files. See a stale issue at backtrace.rs (I also saw your comment from 3 years ago. Unfortunately, not much has improved since then for iOS)
• Android: Using the default cargokit setup, no symbols seem to be included and the backtrace is obscured. Uploading the symbol files using Sentry's experimental sentry_dart_plugin also doesn't help, even though it claims to work with native code/Android NDK. I'm thinking about filing an issue at cargokit to have better control over symbol stripping and easier access to symbol file. Though at the same time, I'm not sure if this is a Sentry issue.

[AlienKevin]

The new setup_default_user_utils is super neat! Now I don't need to include sentry in my rust code anymore.

Also, I tested my code with FRB's backtrace-rs solution and found that the Android backtrace is still redacted. So now I'm pretty sure that cargokit is not including the debug symbols somehow. I filed an issue at cargokit (irondash/cargokit#49).

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new issue.