crashes running on itself
matthiaskrgr opened this issue · comments
rustc 1.30.0-nightly (73c78734b 2018-08-05)
binary: rustc
commit-hash: 73c78734bae8f2947a4bfdeabebeeb84ccf0b0e1
commit-date: 2018-08-05
host: x86_64-unknown-linux-gnu
release: 1.30.0-nightly
LLVM version: 7.0
repo is at 41a73a8
cargo build
RUST_BACKTRACE=1 ./target/debug/bingrep target/debug/bingrep
crashes:
[...]
0x0 0x0
781870 GLOBAL FUNC _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i8$GT$3fmt17h4c27396496188f2dE
0x91 .text(16) 0x0
781910 GLOBAL FUNC _ZN4core3fmt3num52_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i8$GT$3fmt17h62566deaeb3faf4cE
0x91 .text(16) 0x0
7819b0 GLOBAL FUNC _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..LowerHex$u20$for$u20$i16$GT$3fmt17hf381e43bda4c6951E
0x92 .text(16) 0x0
781a50 GLOBAL FUNC _ZN4core3fmt3num53_$LT$impl$u20$core..fmt..UpperHex$u20$for$u20$i16$GT$3fmt17h93eac570e2e7c86eE
0x92 .text(16) 0x0
785bc0 GLOBAL FUNC _ZN4core3fmt9Formatter12pad_integral17h0a1e2b34e19c7ddcE
0x3d7 .text(16) 0x0
782cc0 GLOBAL FUNC _ZN49_$LT$i8$u20$as$u20$core..slice..SliceContains$GT$14slice_contains17h417b7695ed3578c1E
0x12 .text(16) 0x0
853b0 GLOBAL OBJECT _ZN4core3str15UTF8_CHAR_WIDTH17h727782c8fa92515fE
0x100 .rodata(5) 0x0
785290 GLOBAL FUNC _ZN4core3num21_$LT$impl$u20$u64$GT$25checked_next_power_of_two17h9ebcca98f19e8d85E
0x29 .text(16) 0x0
787d30 GLOBAL FUNC _ZN82_$LT$core..fmt..builders..PadAdapter$LT$$u27$a$GT$$u20$as$u20$core..fmt..Write$GT$9write_str17h2ae040e1ef527b3cE
0x24e .text(16) 0x0
7884f0 GLOBAL FUNC _ZN4core3fmt8builders8DebugSet5entry17h69411f4b5bb034afE
0xe .text(16) 0x0
7897e0 GLOBAL FUNC _ZN62_$LT$core..num..bignum..Big32x40$u20$as$u20$core..cmp..Ord$GT$3cmp17hfee4d6134a187f3dE
0x55 .text(16) 0x0
0 GLOBAL FUNC __register_atfork
0x0 0x0
0 GLOBAL FUNC __cxa_atexit
0x0 0x0
0 GLOBAL FUNC __xstat64
0x0 0x0
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: BadOffset(131072)', libcore/result.rs:983:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:475
5: std::panicking::continue_panic_fmt
at libstd/panicking.rs:390
6: rust_begin_unwind
at libstd/panicking.rs:325
7: core::panicking::panic_fmt
at libcore/panicking.rs:77
8: core::result::unwrap_failed
at /checkout/src/libcore/macros.rs:26
9: <core::result::Result<T, E>>::unwrap
at /checkout/src/libcore/result.rs:782
10: bingrep::format_elf::Elf::print::{{closure}}
at /home/matthias/.cargo/registry/src/github.com-1ecc6299db9ec823/goblin-0.0.14/src/strtab.rs:99
at src/format_elf.rs:284
11: bingrep::format_elf::Elf::print
at src/format_elf.rs:300
12: bingrep::run
at src/main.rs:103
13: bingrep::main
at src/main.rs:166
14: std::rt::lang_start::{{closure}}
at /checkout/src/libstd/rt.rs:74
15: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
16: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:105
17: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
18: std::rt::lang_start
at /checkout/src/libstd/rt.rs:74
19: main
20: __libc_start_main
21: _start
Hi @matthiaskrgr thanks for the bug report ! I’ll investigate this. Looks like something wrong with strtab in elf format. The backtrack helps tremendously, thanks for posting it!
I'm seeing the same error with various binaries e.g. ones produced by GHC on FreeBSD
I have a patch updating bingrep to latest goblin (among other things); will try to repro this. @myfreeweb can you attach a binary if you have spare time?
Are either of you using LLD by any chance? I think some bsd's have switched entirely to lld, wondering if freebsd is one of them? I ask because lld will emit some elf files that are slightly unorthodox (but still valid), and this can cause issues in the bias computation, see here: m4b/goblin#106
and this PR which hopefully makes the dynsym length calculation more robust: m4b/goblin#109
Yes, I'm indeed on FreeBSD -CURRENT which uses lld as the default linker :)
@myfreeweb if you don't mind, would you mind testing this branch? https://github.com/m4b/bingrep/tree/update_goblin
it should compile out of box, then try cargo run -- <path to ghc binary> or cargo run -- target/debug/bingrep
If it still breaks, I'll need a binary exhibiting the behavior that crashes bingrep
That branch works great, thanks!
Awesome! I'll work on a new release (though I am still seeing infintie loops on note parsing, which is annoying and I don't feel like dealing with it, heh)
mokay, version 0.6 is published; please reopen if any other related issues :)