Unable to trace an crash from the backtrace, no trace for my own code

help
1

Windows, use msvc toolchain, release build and already config 'debug = true' in [profile.release]
the problem is unable to trace an crash from the backtrace, no trace for my own code.
while debug build backtrace works, can find my own code line

rustc 1.29.1 (b801ae664 2018-09-20)
cargo 1.29.0 (524a578d7 2018-08-05)

the trace is below:

PS D:\rust-projects\hello_cargo\target\release> $env:RUST_BACKTRACE=1
PS D:\rust-projects\hello_cargo\target\release> .\hello_cargo.exe
The value of x is: 5
thread 'main' panicked at 'Not a number!: ParseIntError { kind: InvalidDigit }', libcore\result.rs:945:5
stack backtrace:
0: std::sys::windows::backtrace::set_frames
at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:104
1: std::sys::windows::backtrace::set_frames
at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:104
2: std::sys_common::backtrace::_print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
3: std::sys_common::backtrace::_print
at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
4: std::panicking::default_hook::{{closure}}
at C:\projects\rust\src\libstd\panicking.rs:211
5: std::panicking::default_hook
at C:\projects\rust\src\libstd\panicking.rs:227
6: std::panicking::rust_panic_with_hook
at C:\projects\rust\src\libstd\panicking.rs:475
7: std::panicking::continue_panic_fmt
at C:\projects\rust\src\libstd\panicking.rs:390
8: std::panicking::rust_begin_panic
at C:\projects\rust\src\libstd\panicking.rs:325
9: core::panicking::panic_fmt
at C:\projects\rust\src\libcore\panicking.rs:77
10: core::result::unwrap_failedcore::num::ParseIntError
at C:\projects\rust\src\libcore\macros.rs:26
11: core::result::Result<u32, core::num::ParseIntError>::expect
at C:\projects\rust\src\libcore\result.rs:809
12: core::result::Result<u32, core::num::ParseIntError>::expect
at C:\projects\rust\src\libcore\result.rs:809
13: std::rt::lang_start::{{closure}}<()>
at C:\projects\rust\src\libstd\rt.rs:74
14: std::rt::lang_start_internal::{{closure}}
at C:\projects\rust\src\libstd\rt.rs:59
15: std::rt::lang_start_internal::{{closure}}
at C:\projects\rust\src\libstd\rt.rs:59
16: panic_unwind::__rust_maybe_catch_panic
at C:\projects\rust\src\libpanic_unwind\lib.rs:105
17: std::panicking::try
at C:\projects\rust\src\libstd\panicking.rs:289
18: std::panicking::try
at C:\projects\rust\src\libstd\panicking.rs:289
19: std::panicking::try
at C:\projects\rust\src\libstd\panicking.rs:289
20: main
21: invoke_main
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
22: invoke_main
at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:78
23: BaseThreadInitThunk
24: RtlUserThreadStart
PS D:\rust-projects\hello_cargo\target\release>

2

This is something that may happen in release builds. In particular it looks like your code's fn main has been inlined in the calling function. If you want the full "resolution" of debugging info, use unoptimized builds.

3

I marked #[inline(never)], it doesn't work.
In production, release build should be used. Unfornately, crash happens, and I can not find which line crash. I think it's a bad feeling.
Suppose a server service written by Rust, crash in production, and hardly reproduce in debug build in development environment.

Edit:
When I put opt-level = 1, it works!
backtrace does't show my own code in opt-level = 2 or 3

In cargo doc:

opt-level = 0      # controls the `--opt-level` the compiler builds with.
                   # 0-1 is good for debugging. 2 is well-optimized. Max is 3.
                   # 's' attempts to reduce size, 'z' reduces size even more.
4

If nothing comes intuitively then you can try set_hook and get a core dump to be read later by debugger. Maybe setting panic=abort is enough on some platforms.