Skip to content

rustc aborts when there is a compilation failure on FreeBSD and OpenBSD #43575

Open
@dumbbell

Description

@dumbbell

When there is a compilation failure, the Rust compiler aborts with the following output:

$ rustc invalid.rs
error: requires at least a format string argument
 --> invalid.rs:2:5
  |
2 |     print!()
  |     ^^^^^^^^
  |
  = note: this error originates in a macro outside of the current crate

error: aborting due to previous error(s)

fatal runtime error: failed to initiate panic, error 5
Abort trap (core dumped)

I used the following invalid source file:

fn main() {
    print!()
}

Here is the backtrace:

(gdb) r
Starting program: /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/rustc invalid.rs
[New LWP 101467 of process 50322]
error: requires at least a format string argument
 --> invalid.rs:2:5
  |
2 |     print!()
  |     ^^^^^^^^
  |
  = note: this error originates in a macro outside of the current crate

error: aborting due to previous error(s)

fatal runtime error: failed to initiate panic, error 5

Thread 2 received signal SIGABRT, Aborted.
[Switching to LWP 101467 of process 50322]
0x0000000801be1b5a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x0000000801be1b5a in thr_kill () from /lib/libc.so.7
#1  0x0000000801be1b24 in __raise (s=6) at /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/gen/raise.c:52
#2  0x0000000801be1a99 in abort () at /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libc/stdlib/abort.c:65
#3  0x000000080184b5a1 in std::sys_common::util::abort::h1ff3fd43e3f3affb () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/libstd-8923652fdd8a524a.so
#4  0x0000000801859f2e in rust_panic () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/libstd-8923652fdd8a524a.so
#5  0x0000000801859e96 in std::panicking::rust_panic_with_hook::h625888e35dbc23f2 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/libstd-8923652fdd8a524a.so
#6  0x0000000805b69a29 in std::panicking::begin_panic::h334ae91969cdd553 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/lib/../lib/librustc_errors-7119f0b402b67ca4.so
#7  0x0000000805b84415 in rustc_errors::Handler::abort_if_errors::h0cb792d8711ba104 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/lib/../lib/librustc_errors-7119f0b402b67ca4.so
#8  0x0000000801515cd8 in rustc_driver::driver::phase_2_configure_and_expand::_$u7b$$u7b$closure$u7d$$u7d$::hed28ccb91f2e1d2f ()
   from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#9  0x000000080150df01 in rustc_driver::driver::phase_2_configure_and_expand::hfdbd55e50731a10a ()
   from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#10 0x00000008015058f7 in rustc_driver::driver::compile_input::ha42b7de34a40dbc4 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#11 0x0000000801550877 in rustc_driver::run_compiler::h166e93bfe8677c78 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#12 0x00000008014744dc in std::sys_common::backtrace::__rust_begin_short_backtrace::h31e6f5e865f4c216 ()
   from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#13 0x0000000801865907 in __rust_maybe_catch_panic () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/libstd-8923652fdd8a524a.so
#14 0x000000080149a2e1 in _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h8348efc58e17166f ()
   from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/librustc_driver-d90bd0899d4860c7.so
#15 0x0000000801858948 in std::sys::imp::thread::Thread::new::thread_start::h40165c228796f269 () from /var/ports/obj/mnt/home/dumbbell/Projects/freebsd/ports/SVN/lang/rust/work/rustc-1.19.0-src/build/x86_64-unknown-freebsd/stage2/bin/../lib/libstd-8923652fdd8a524a.so
#16 0x00000008067e8bc5 in thread_start (curthread=0x80b8a2b00) at /mnt/home/dumbbell/Projects/freebsd/src/SVN/head/lib/libthr/thread/thr_create.c:289
#17 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfffe000

As you can see in the paths, this is with Rust 1.19.0. The same happens with previous versions, so this isn't a regression (or not a recent one).

In the example, Rust was compiled with Clang 4.0.0, but the bundled LLVM was used.

When I compile and run a program which panics, the panic looks to be handled correctly:

fn main() {
    panic!()
}
$ RUST_BACKTRACE=1 ./panic 
thread 'main' panicked at 'explicit panic', panic.rs:2
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: panic::main
   7: __rust_maybe_catch_panic
   8: std::rt::lang_start
   9: main
  10: _start

I don't know how to debug this further. I tried with debuginfo = true and debuginfo-lines = true in config.toml, but then the problem vanishes. I'm willing to help but I would like some pointers to where to look :-)

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.I-crashIssue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.O-freebsdOperating system: FreeBSDO-openbsdOperating system: OpenBSDT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions