Missing panic line when running app in release mode

[gdesmott]

Environment

Using crate sentry 0.34.0

Steps to Reproduce

Run the following test app in release mode.

fn main() {
    let _guard = sentry::init(("XXX", sentry::ClientOptions {
    release: sentry::release_name!(),
    ..Default::default()
  }));

    let a = None::<bool>;
    #[allow(clippy::unnecessary_literal_unwrap)]
    a.unwrap();
}

Expected Result

The app crashes and provides the line with the failing assertion:

thread 'main' panicked at src/bin/sentry.rs:9:7:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This line should be part of the sentry crash report.

Actual Result

Unfortunately the line is missing from the report:

Note that it works fine when running in debug mode:

At the very least the release report should have the line where the assertion failed as it's part of the crash output.

[lcian]

Hi @gdesmott
This is a good observation but I think that incorporating that information is not possible to do reliably.
We would have to associate those lines with a particular frame which would involve making a possibly wrong guess.

In general, I recommend compiling with debug = true in your release builds, you can set that up in your Cargo.toml.
That way you will get source code lines and possibly more frames in cases where inlining is involved.

To understand why we cannot use that information reliably, consider the following example:

fn main() {
    whatever::f();
}

mod whatever {

    #[inline(never)]
    pub fn f() {
        let a = None::<bool>;
        a.unwrap();
    }
}

Compiled in release without debug info, it produces:

thread 'main' panicked at src/main.rs:10:11:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0:        0x1023e9c10 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h6e25c13836847e70
   1:        0x1023fd5e4 - core::fmt::write::h37cdb50ab8af3d55
   2:        0x1023e7fc8 - std::io::Write::write_fmt::hd4c273f34c4c0a33
   3:        0x1023e9ac4 - std::sys::backtrace::BacktraceLock::print::h1df7364dde63dc75
   4:        0x1023ea9e0 - std::panicking::default_hook::{{closure}}::h646e398272c5759a
   5:        0x1023ea7d4 - std::panicking::default_hook::hf65fd28e95db7176
   6:        0x1023eb25c - std::panicking::rust_panic_with_hook::hc9e2ec2a12b10e12
   7:        0x1023eaeac - std::panicking::begin_panic_handler::{{closure}}::h3b6449e2eb83bf4c
   8:        0x1023ea0c4 - std::sys::backtrace::__rust_end_short_backtrace::h38d85099ddd107a3
   9:        0x1023eab8c - _rust_begin_unwind
  10:        0x1024021b0 - core::panicking::panic_fmt::hd4003258f6ab7b29
  11:        0x102402220 - core::panicking::panic::h86f2c7562f835270
  12:        0x102402190 - core::option::unwrap_failed::h36089c7b3b3b33af
  13:        0x1023cd9d4 - example::whatever::f::h528394d591805724
  14:        0x1023cd9c0 - example::main::h438c4e30ae30a17f
  15:        0x1023cd990 - std::sys::backtrace::__rust_begin_short_backtrace::h761dcaecfc0737c2
  16:        0x1023cd978 - std::rt::lang_start::{{closure}}::hdc7b511f11356bbb
  17:        0x1023e693c - std::rt::lang_start_internal::h5f91760815528aa2
  18:        0x1023cda08 - _main

In this case the only option would be for the SDK to guess and associate src/main.rs:10:11 with frame 14, while the correct one would be 13, but we have no way to know that in general. If there's inlining involved you won't event see the correct frame.

If you run this with debug = true instead, you will get information on the source code lines for each frame, which will be reflected in Sentry when the panic is reported.

[gdesmott]

Thanks for the explanations @lcian

Unfortunately building with debug = true increases the size of my app from 72M to 882M. Is there any way to keep proper source lines info for Sentry without exploding the binary size that much?

[lcian]

Thanks for the explanations @lcian

Unfortunately building with debug = true increases the size of my app from 72M to 882M. Is there any way to keep proper source lines info for Sentry without exploding the binary size that much?

Yeah I understand. There is a way, which is to use sentry-cli to upload your debug information files to Sentry, without keeping them in the binary. I will document that very soon as that's currently undocumented. Then you will also be able to see your source code with your stack frames if you want that.

[gdesmott]

That sounds perfect, thanks!

[lcian]

@gdesmott We've documented it here https://docs.sentry.io/platforms/rust/source-context/ (for Linux, macOS also coming when getsentry/sentry-docs#13211 is merged).
Feel free to give it a try and provide feedback if any :)

[gdesmott]

Thanks @lcian

I think there is a typo here, it should be:

[profile.release]
debug = true

Also, the upload example is missing the -p argument.

Other than that it worked fine for me. 👍

[lcian]

Thanks @lcian

I think there is a typo here, it should be:

[profile.release]
debug = true
Also, the upload example is missing the -p argument.

Other than that it worked fine for me. 👍

@gdesmott Thank you so much, I'll update the docs :)