Open
Description
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
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
semarie commentedon Aug 7, 2017
I have the same problem with OpenBSD if I switch from
stdc++tolibc++andlibc++abi.Under this configuration (
libc++), the compilation of rustc is done right, but several tests failed, specially in failing tests (compile-fail or parse-fail tests for example).A simple way to reproduce the error is to run
rustc -v: the compiler will crash.The error is correctly reported ("no input filename given"), but just after rustc die due to internal panic error.
I am suspecting a problem between rust and libc++ regarding unwinding. It could be a rustc problem as a libc++/libc++abi problem.
Please note that all unitary tests on panicking/unwinding passes.
Running via gdb, with unwind debugging:
@Mark-Simulacrum could you update the tags please ?
semarie commentedon Aug 8, 2017
I confirm that building with
debuginfo=trueis enough to make to crash disappear.[-]rustc aborts when there is a compilation failure on FreeBSD[/-][+]rustc aborts when there is a compilation failure on FreeBSD and OpenBSD[/+]semarie commentedon Aug 8, 2017
Using a rustc binary compiled with
debuginfo=true, I traced the program using libunwind debugging.the main difference is where libunwind stop to unwind the stack trace.
in bogus one, libunwind found
_ZN12rustc_driver12run_compiler17h8fb3410f76685058Eand stop (return_URC_END_OF_STACK).in right one, libunwind found an anonymous function just after, and continue unwinding with
__rust_maybe_catch_panicwhere it founds the handler (and unwinding phase2 could start).semarie commentedon Nov 16, 2017
I finally found that i686-unknown-linux-musl, which use also libunwind from LLVM, uses a workaround for the same issue: it uses
eliminate_frame_pointer = falseinTargetOptions.This way, all programs compiled with rustc will be compiled with functional unwinding.
For me, it is still a workaround, but it seems to work well.
The problem seems that some information (need usually by libunwind) is missing for anonymous function (unwinding-tables information ?), and with explicit framepointer libunwind is able to compensate this lake of information.
dumbbell commentedon Nov 29, 2017
I confirm that setting
eliminate_frame_pointertofalseresults in a working compiler.I talked to Ed Maste and Dimitry Andric about the bug in LLVM bugtracker you mentionned and they don't think this is the same problem. Ed told me about Clang's
-fexceptionsflag which could help. I find little to no informations about it, but I'll play a bit with it.lang/rust: Disable "omit frame pointers"
lang/rust: Disable "omit frame pointers"
bdrewery commentedon Feb 24, 2018
It seems like this workaround no longer works on FreeBSD but I'm not sure.
bdrewery commentedon Feb 24, 2018
Actually it does work, will submit a PR for it.
Workaround abort(2) on compilation error on FreeBSD.
10 remaining items