In what cases do we not get the backtrace even after running with the variable set
I am compiling it with
rustc +nightly <my program>
and I get the output as
thread 'main' panicked at 'attempt to subtract with overflow', /rustc/aadbc459bd97a0325897e2ff94999efbec6a499c/src/libcore/ops/arith.rs:198:45
note: Run with RUST_BACKTRACE=1
environment variable to display a backtrace.
what platform is this? Linux?
@pnkfelix MacOs. I manged to get back stack trace but I don't get the line numbers.
I found this #46346 but this was closed.
A backtrace can be useful even without line numbers. You should be able to get a backtrace with line numbers by building the compiler yourself (or maybe by using https://crates.io/crates/rustup-toolchain-install-master)
@oli I have
debuginfo-lines = true in the config.toml
and you're still not getting line numbers? Can you still post the backtrace? Even without line numbers we might be able to figure out where the issue comes from
@blitzerr I don't understand, you said you're running
rustc +nightly ... ; that is not running your local build then, right?
@pnkfelix That is true. With nightly or with stage 1 compiler, I don't get line numbers with stack trace.
For nightly I think that’s expected, since nightly is built without debuginfo
I'm having a very similar problem: I get backtraces, but every level of the stack is identified only with
unknown and nothing else. I've tried with every knob in
config.toml that could possibly be related. Last few nightlies also have the same behavior. Platform is also macos.
An example of the output:
$ RUST_BACKTRACE=full rustc +devel file.rs -Ztreat-err-as-bug error: couldn't read file.rs: No such file or directory (os error 2) thread 'rustc' panicked at 'aborting due to `-Z treat-err-as-bug=1`', src/librustc_errors/lib.rs:534:13 stack backtrace: 0: 0x10cd72c84 - <unknown> 1: 0x10cd70036 - <unknown> 2: 0x10cd6fdba - <unknown> 3: 0x10a982322 - <unknown> 4: 0x10cd70731 - <unknown> 5: 0x10c9d43b4 - <unknown> 6: 0x10c9ef9b6 - <unknown> 7: 0x10c9fefdc - <unknown> 8: 0x10c17959f - <unknown> 9: 0x10c177e9e - <unknown> 10: 0x106c0f742 - <unknown> 11: 0x106c0edfa - <unknown> 12: 0x106b573b9 - <unknown> 13: 0x106bb6280 - <unknown> 14: 0x106c390bb - <unknown> 15: 0x10691fe4b - <unknown> 16: 0x10699e086 - <unknown> 17: 0x10698d175 - <unknown> 18: 0x10699b484 - <unknown> 19: 0x106942e69 - <unknown> 20: 0x10cd91cce - <unknown> 21: 0x10698c408 - <unknown> 22: 0x1068fb16b - <unknown> 23: 0x10cd5858d - <unknown> 24: 0x10cd9134d - <unknown> 25: 0x10cd86bc8 - <unknown> 26: 0x7fff784492ea - <unknown> 27: 0x7fff7844c248 - <unknown> query stack during panic: end of query stack
@varkor reported similar in Discord and linked to #60852, @Esteban Küber
that was after I saw @Esteban Küber's issue :P
Ah, I just saw both messages this morning and though they could be related.
The stack frame addresses look sane, so the unwinder probably just fails to figure out what lines/functions/files/etc the instruction pointers come from)