Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NetBSD: backtrace support broken #96914

Closed
0-wiz-0 opened this issue May 10, 2022 · 9 comments
Closed

NetBSD: backtrace support broken #96914

0-wiz-0 opened this issue May 10, 2022 · 9 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. O-netbsd Operating system: NetBSD

Comments

@0-wiz-0
Copy link

0-wiz-0 commented May 10, 2022

I tried this code:

fn main() { panic!("explode!") }                                                                                                                

I expected to see this happen:

$ rustc t.rs
$ ./t
thread 'main' panicked at 'explode!', t.rs:1:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ RUST_BACKTRACE=1 ./t
thread 'main' panicked at 'explode!', t.rs:1:13
stack backtrace:
   0: std::panicking::begin_panic
   1: t::main
   2: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

(provided by a friendly Linux user)

Instead, this happened (on NetBSD)

I see this instead:

$ ./t    
thread 'main' panicked at 'explode!', t.rs:1:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ RUST_BACKTRACE=1 ./t
thread 'main' panicked at 'explode!', t.rs:1:13
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
$ RUST_BACKTRACE=full ./t
thread 'main' panicked at 'explode!', t.rs:1:13
stack backtrace:
   0:         0x6dc13726 - <unknown>
   1:         0x6dc3790c - <unknown>
   2:         0x6dc25ea5 - <unknown>
   3:         0x6dc0c981 - <unknown>
   4:         0x6dc0c581 - <unknown>
   5:         0x6dc0ced1 - <unknown>
   6:         0x6dc07a9e - <unknown>
   7:         0x6dc07d85 - <unknown>
   8:         0x6dc07a22 - <unknown>
   9:         0x6dc07e79 - <unknown>
  10:         0x6dc07f63 - <unknown>
  11:         0x6dc07d29 - <unknown>
  12:         0x6dc08749 - <unknown>
  13:         0x6dc209a1 - <unknown>
  14:         0x6dc08731 - <unknown>
  15:         0x6dc07f03 - <unknown>
  16:         0x6dc05b7d - <unknown>

Meta

rustc --version --verbose:

rustc 1.59.0
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-netbsd
release: 1.59.0
LLVM version: 13.0.1
Backtrace

Yes, exactly that's the problem.

On the C level, I know that Linux provides the backtrace() family of functions in libc.
NetBSD provides all the functions too, but you need to link against libexecinfo, see
https://man.netbsd.org/backtrace.3

So I guess it's probably not too hard to add, I hope someone can take this on.

@0-wiz-0 0-wiz-0 added the C-bug Category: This is a bug. label May 10, 2022
@ijackson
Copy link
Contributor

@rustbot modify labels +O-netbsd +A-runtime

@rustbot rustbot added A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows O-netbsd Operating system: NetBSD labels May 13, 2022
@0-wiz-0
Copy link
Author

0-wiz-0 commented May 19, 2022

Patches fixing this now exist:
https://mail-index.netbsd.org/pkgsrc-changes/2022/05/18/msg254732.html
thanks to Håvard Eidnes. What's the best way to get them integrated?

@workingjubilee
Copy link
Member

If you submit the backtrace stuff to https://github.com/rust-lang/backtrace-rs then I will try to get it merged.

@workingjubilee
Copy link
Member

Oh, it was submitted to backtrace in rust-lang/backtrace-rs#512

Is there anything left?

@0-wiz-0
Copy link
Author

0-wiz-0 commented Jul 24, 2024

Thank you for looking at this, @workingjubilee !
I've just tried 0.3.73 on NetBSD-10.99.11/amd64, and it seemed to work fine, here's the output:

backtrace-rs-0.3.73> RUST_BACKTRACE=1 cargo test
   Compiling backtrace v0.3.73 (/home/wiz/a/backtrace-rs-0.3.73)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.56s
     Running unittests src/lib.rs (target/debug/deps/backtrace-ed5435a466558a04)

running 3 tests
test symbolize::gimli::parse_running_mmaps::check_maps_entry_parsing_32bit ... ok
test symbolize::gimli::parse_running_mmaps::check_maps_entry_parsing_64bit ... ok
test capture::tests::test_frame_conversion ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

     Running tests/accuracy/main.rs (target/debug/deps/accuracy-b042c1723a62a800)

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/concurrent-panics.rs (target/debug/deps/concurrent_panics-2be74b7ee972732b)
test result: ok
     Running tests/current-exe-mismatch.rs (target/debug/deps/current_exe_mismatch-e7ad37dd6f4cbaa7)
stdout:

stderr:

code: signal: 11 (SIGSEGV) (core dumped)
thread 'main' panicked at tests/current-exe-mismatch.rs:72:5:
explicit panic
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::panic_display
   3: core::panicking::panic_explicit
   4: current_exe_mismatch::parent::panic_cold_explicit
             at /scratch/lang/rust/work/rustc-1.79.0-src/library/core/src/panic.rs:87:13
   5: current_exe_mismatch::parent
             at ./tests/current-exe-mismatch.rs:72:5
   6: current_exe_mismatch::main
             at ./tests/current-exe-mismatch.rs:15:15
   7: core::ops::function::FnOnce::call_once
             at /scratch/lang/rust/work/rustc-1.79.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass `--test current-exe-mismatch`

I also tried my original test program with rust 1.79:

> RUST_BACKTRACE=1 cargo run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/rust-backtracetest`
thread 'main' panicked at src/main.rs:1:13:
explode!
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: rust_backtracetest::main
             at ./src/main.rs:1:13
   3: core::ops::function::FnOnce::call_once
             at /scratch/lang/rust/work/rustc-1.79.0-src/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

That's what it should look like, right?
If yes, please feel free to close this! Thanks.

@workingjubilee
Copy link
Member

SIGSEGV

uh

that seems incorrect.

@0-wiz-0
Copy link
Author

0-wiz-0 commented Jul 24, 2024

Oh, true. I was just happy that the backtrace had function names instead of <unknown>

@0-wiz-0
Copy link
Author

0-wiz-0 commented Jul 24, 2024

Should I file a new ticket with backtrace-rs about the segfault?

@workingjubilee
Copy link
Member

Yeees, let's do that and call this issue good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-bug Category: This is a bug. O-netbsd Operating system: NetBSD
Projects
None yet
Development

No branches or pull requests

4 participants