rust-lang / rust-lang/rust

Stripped executables don't print backtrace with RUST_BACKTRACE=1

Open
#147,846 4 comments 0 reactions 1 assignee View on GitHub

@eggyal is already working on this.

Since Jan 27, 2026.

A-backtrace C-bug T-compiler
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

I tried this code:

echo 'fn main() { panic!(); }' | rustc - -Cstrip=symbols
RUST_BACKTRACE=1 ./rust_out
RUST_BACKTRACE=full ./rust_out

I expected to see this happen: Both invocations of the executable show a backtrace.

Instead, this happened: RUST_BACKTRACE=1 results in an empty backtrace:

RUST_BACKTRACE=1 ./rust_out
thread 'main' panicked at <anon>:1:13:
explicit panic
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

While RUST_BACKTRACE=full does print a backtrace with addresses in the place of symbols:

RUST_BACKTRACE=full ./rust_out
thread 'main' panicked at <anon>:1:13:
explicit panic
stack backtrace:
   0:     0x5593502b9312 - <unknown>
   1:     0x5593502d4a93 - <unknown>
   2:     0x5593502b7023 - <unknown>
   3:     0x5593502b9162 - <unknown>
   4:     0x5593502ba203 - <unknown>
   5:     0x5593502b9fe5 - <unknown>
   6:     0x5593502babd5 - <unknown>
   7:     0x5593502baaac - <unknown>
   8:     0x5593502b9809 - <unknown>
   9:     0x5593502ba9c2 - <unknown>
  10:     0x559350298e3a - <unknown>
  11:     0x559350298dc3 - <unknown>
  12:     0x559350298da6 - <unknown>
  13:     0x559350298d89 - <unknown>
  14:     0x5593502b4f70 - <unknown>
  15:     0x559350298d71 - <unknown>
  16:     0x559350298e55 - <unknown>
  17:     0x7fe198532ca8 - __libc_start_call_main
                               at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  18:     0x7fe198532d65 - __libc_start_main_impl
                               at ./csu/../csu/libc-start.c:360:3
  19:     0x559350298c81 - <unknown>
  20:                0x0 - <unknown>

This is probably because __rust_end_short_backtrace is matched by symbol name rather than by address causing the trimmed backtrace to never start. As solution we could either also check __rust_end_short_backtrace by address or if the backtrace is empty create a new backtrace but this time untrimmed.

Meta

rustc --version --verbose:

rustc 1.90.0 (1159e78c4 2025-09-14)
binary: rustc
commit-hash: 1159e78c4747b02ef996e55082b704c09b970588
commit-date: 2025-09-14
host: x86_64-unknown-linux-gnu
release: 1.90.0
LLVM version: 20.1.8
Backtrace

<backtrace>

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.