Inconsistent crash reporting on Rust

[cunning ravine]

When using a minimal Sentry panic reporting example, it work as intended, but when integrating Sentry in a bigger project it works for the first few crashes then no more crashes can be found in the sentry console. What could be the cause?

[keen widget]

Hi @cunning ravine. I'm happy to dig into this for you! I'll check my internal sources for answers to your question! :wave:

---

Based on the knowledge sources, there are several potential causes for inconsistent crash reporting in Rust with Sentry:

1. Multiple versions of sentry-core: One common issue is having multiple versions of sentry-core in your application, which can cause errors to be silently dropped. This happens because different parts of your application might be using different versions of the SDK, leading to conflicts.

   As mentioned in Feature flag to error if multiple versions of sentry-core are found, this is a "very common issue" where "some errors come through just fine - it just depends which crate is reporting the error."

2. Recursive error handling: If there's a panic inside Sentry's error handling code, it can lead to infinite recursion or the application getting stuck. This was described in Sentry stuck forever or recursive forever when capturing an error, where a panic inside Sentry's handlers could cause the application to hang.

3. Missing debug_images feature: For proper symbolication and crash reporting, the debug_images feature needs to be enabled. In older versions of the SDK, this wasn't enabled by default, which could lead to incomplete crash reports.

   As noted in Sentry not associating stacktrace with corresponding uploaded Windows pdb, upgrading to a newer version of the SDK (0.30.0+) where this feature is enabled by default resolved the issue.

4. Delayed reporting: Sometimes crash reports might take time to appear in the Sentry dashboard. As mentioned in Sentry Install instructions For Rust not Working, a user observed that "they're showing up almost an hour after the transaction was initiated."

5. Transaction not finished on panic: If a panic occurs within a transaction, the transaction might not be properly finished and reported. This was fixed in the Rust SDK as mentioned in Transaction is not finished if panic occurs within it.

For your specific case, I would recommend:

• Check if you're using multiple versions of sentry-core in your project
• Ensure you're using a recent version of the Sentry Rust SDK (0.30.0+)
• Verify that your ClientOptions are properly configured
• Check if there are any panics occurring within Sentry's own code

If the issue persists, you might want to enable debug mode in your Sentry configuration to get more detailed logs:

let _guard = sentry::init((
    "your-dsn",
    sentry::ClientOptions {
        debug: true,
        // other options
        ..Default::default()
    },
));

---

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

@cunning ravine Our robots are still learning and improving, please let us know if this response was correct by reacting below.

[peak leaf]

Hey @cunning ravine, my first guess would be that you're inadverently dropping the ClientInitGuard returned by sentry::init. When that happens, the client is deactivated and events are not sent to Sentry.
You can set debug: true in your ClientOptions on init and when that happens (and also when events are captured) logs will be emitted.
Please give it a try and let me know if that works!

[cunning ravine]

Hi, actually i save the sentry Client statically using Lazy, so that's not what you're saying. I found the actual bug and it was much more obscure. My application relies on multiple entry points from a native application, and my Rust code is invoked using extern "C" functions. All panics originating from external threads were not being captured, because extern "C" aborts instead of unwinding. Only panics from threads spawned from Rust were captured

[cunning ravine]

I have more info on this behavior. I tried to make a minimum reproducible example:

extern "C" fn test() {
    panic!("Hello from sentry_test extern C");
}

fn main() {
    let _guard = sentry::init((
        "https://[e-mail]/XXXXXXXXXXXXX",
        sentry::ClientOptions {
            release: sentry::release_name!(),
            ..Default::default()
        },
    ));

    // panic!("Hello from sentry_test");

    test();
}

When I panic on main(), I can see the panic on the sentry console. Instead when I don't panic on main and instead call test(), I can't see the panic in the console, instead I got only this

the terminal instead shows both panics:

Using std::panic::catch_unwind().unwrap() to wrap the panic inside the extern "C" function managed to log it to sentry. On the terminal I also got a panic on the unwrap on catch_unwind(), which did not get logged to sentry

Is this behavior already documented?

[peak leaf]

I'm not sure what's the behavior that we want here (2 panics reported or only one), but if I use your example in a release build on 1.85.0, then both are reported to Sentry

[cunning ravine]

It seems that the problem is a bit inconsistent. The behavior described is especially reproducible on macOS