SIGSEGV when printing backtrace across inline assembly

[purplesyringa]

I tried this code: playground

// x86-64, obviously
fn main() {
    unsafe {
        core::arch::asm! {
            "push 1",
            "push 1",
            "call {}",
            "pop rax",
            "pop rax",
            sym panicking_func,
            clobber_abi("C"),
        };
    }
}

extern "C" fn panicking_func() {
    panic!();
}

I expected to see this happen: panic!() is caught at the boundary to the extern "C" function and the process aborts.

Instead, this happened: the panic is caught, then std tries to print a backtrace, and libgcc crashes with SIGSEGV during this process.

This happens even without debuginfo. Are we, by any chance, assuming that non-unwinding code is allowed to have broken .eh_frame records?

Meta

Crashes on stable as per the playground link. Also crashes locally with

rustc --version --verbose:

rustc 1.90.0-nightly (a00149764 2025-07-14)
binary: rustc
commit-hash: a001497644bc229f1abcc5b2528733386591647f
commit-date: 2025-07-14
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

Backtrace

thread 'main' panicked at src/main.rs:17:5:
explicit panic
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

thread 'main' panicked at library/core/src/panicking.rs:226:5:
panic in a function that cannot unwind
stack backtrace:
   0:     0x5d61d3466362 - std::backtrace_rs::backtrace::libunwind::trace::h74680e970b6e0712
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/../../backtrace/src/backtrace/libunwind.rs:117:9
   1:     0x5d61d3466362 - std::backtrace_rs::backtrace::trace_unsynchronized::ha3bf590e3565a312
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/../../backtrace/src/backtrace/mod.rs:66:14
   2:     0x5d61d3466362 - std::sys::backtrace::_print_fmt::hcf16024cbdd6c458
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/sys/backtrace.rs:66:9
   3:     0x5d61d3466362 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h46a716bba2450163
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/sys/backtrace.rs:39:26
   4:     0x5d61d347f863 - core::fmt::rt::Argument::fmt::ha695e732309707b7
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/fmt/rt.rs:181:76
   5:     0x5d61d347f863 - core::fmt::write::h275e5980d7008551
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/fmt/mod.rs:1446:25
   6:     0x5d61d3464363 - std::io::default_write_fmt::hdc4119be3eb77042
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/io/mod.rs:639:11
   7:     0x5d61d3464363 - std::io::Write::write_fmt::h561a66a0340b6995
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/io/mod.rs:1914:13
   8:     0x5d61d34661b2 - std::sys::backtrace::BacktraceLock::print::hafb9d5969adc39a0
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/sys/backtrace.rs:42:9
   9:     0x5d61d3467222 - std::panicking::default_hook::{{closure}}::hae2e97a5c4b2b777
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:300:22
  10:     0x5d61d3467025 - std::panicking::default_hook::h3db1b505cfc4eb79
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:327:9
  11:     0x5d61d3467ad2 - std::panicking::rust_panic_with_hook::h409da73ddef13937
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:833:13
  12:     0x5d61d3467936 - std::panicking::begin_panic_handler::{{closure}}::h159b61b27f96a9c2
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:699:13
  13:     0x5d61d3466859 - std::sys::backtrace::__rust_end_short_backtrace::h5b56844d75e766fc
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/sys/backtrace.rs:168:18
  14:     0x5d61d34675fd - __rustc[4794b31dd7191200]::rust_begin_unwind
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/std/src/panicking.rs:697:5
  15:     0x5d61d34470ad - core::panicking::panic_nounwind_fmt::runtime::h4c94eb695becba00
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/panicking.rs:117:22
  16:     0x5d61d34470ad - core::panicking::panic_nounwind_fmt::hc3cf3432011a3c3f
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/intrinsics/mod.rs:3196:9
  17:     0x5d61d3447142 - core::panicking::panic_nounwind::h0c59dc9f7f043ead
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/panicking.rs:226:5
  18:     0x5d61d3447266 - core::panicking::panic_cannot_unwind::hb8732afd89555502
                               at /rustc/6b00bc3880198600130e1cf62b8f8a93494488cc/library/core/src/panicking.rs:331:5
  19:     0x5d61d34479c5 - playground::panicking_func::hacc554f719b42fb7
                               at /playground/src/main.rs:16:1
  20:     0x5d61d344799c - playground::main::h18ec2414aa43863f
                               at /playground/src/main.rs:3:9
<SIGSEGV>

@rustbot label +A-backtrace +A-inline-assembly +E-needs-investigation +T-compiler

[purplesyringa]

I'm a little uncertain whether this is "really" a bug. One could argue that push inside inline assembly needs to be accompanied by .cfi_adjust_cfa_offset. But I don't think we've ever documented this is necessary?

[Mark-Simulacrum]

Per https://doc.rust-lang.org/nightly/reference/inline-assembly.html#r-asm.rules.unwind, this looks like UB, so I don't think a crash is unexpected. I don't think there's any way to mark assembly as potentially unwinding today.

Missed the extern "C".

[zachs18]

(For comparison: the segfault does not happen and the backtrace appears to be correct if the inline asm does include the relevant CFI directives: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=2b34f0fb2d8763050dca442b7db587ea )

[bjorn3]

I think it is expected that incorrect unwind info will cause backtrace generation to produce incorrect results or even crash as it has to dereference arbitrary pointers. And without the explicit CFI directives, the unwind info for main is incorrect.

[folkertdev]

for naked_asm! we do explicitly mention that the CFI directives are required for correct behavior

https://doc.rust-lang.org/nightly/reference/inline-assembly.html#r-asm.naked-rules.unwind

So most likely the reference should be updated to include some similar statement.

[bjorn3]

One complication is that in the case of panic=abort (unless -Cforce-unwind-tables is used or the target always forces unwind tables), LLVM may be omitting the CFI prologue and epilogue, in which case using CFI directives in the inline asm body will result in an error.

[purplesyringa]

for naked_asm! we do explicitly mention that the CFI directives are required for correct behavior

Unwinding out of a naked_asm! block is allowed.

We only mention it for "unwinding", not correct behavior in general. As far as I'm aware, every single use of "unwinding" in our documentation refers to panics or exceptions, not backtracing. extern "C-unwind" is allowed to unwind, extern "C" isn't, and we catch unwinding on the boundary, making it safe; LLVM uses nounwind for functions that don't throw; etc.

Even the example in the reference specifies

// We can now call a function that may panic.

...as if CFI is only useful/necessary for calling functions that may panic.