rustc aborts when there is a compilation failure on FreeBSD and OpenBSD #43575
Labels
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
O-freebsd
Operating system: FreeBSD
O-openbsd
Operating system: OpenBSD
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Mark-Simulacrum
added
C-bug
|
I have the same problem with OpenBSD if I switch from Under this configuration ( A simple way to reproduce the error is to run 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 ? |
Mark-Simulacrum
added
I-crash
|
I confirm that building with |
dumbbell
changed the title
|
Using a rustc binary compiled with the main difference is where libunwind stop to unwind the stack trace. in bogus one, libunwind found in right one, libunwind found an anonymous function just after, and continue unwinding with |
|
I finally found that i686-unknown-linux-musl, which use also libunwind from LLVM, uses a workaround for the same issue: it uses 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. |
|
I confirm that setting 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 |
uqs
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Nov 30, 2017
Before the patch, the default behavior of the compiler was to omit frame
pointers. However, even though it looks fine for the code produced
by the compiler, the compiler itself was broken. When there was a
compilation error, rustc panics to report that error. While handling
that panic, it tries to unwind the stack but fails to do so, which
results in an abort(3).
Here is an example:
$ rustc hello.rs
error: invalid reference to argument `0` (no arguments given)
--> hello.rs:2:5
|
2 | println!("Hello {}")
| ^^^^^^^^^^^^^^^^^^^^
|
= note: this error originates in a macro outside of the current crate
error: aborting due to previous error
fatal runtime error: failed to initiate panic, error 5
Abort trap (core dumped)
The problem also exists on other systems such as OpenBSD and
i686-unknown-linux-musl. "omit frame pointers" was already disabled for
i686-unknown-linux-musl:
https://github.com/rust-lang/rust/blob/88a28ff6028cf197ed6b4185d8cd4887f05e3e07/src/librustc_back/target/i686_unknown_linux_musl.rs#L22
The patch does the same for *-unknown-freebsd.
See the upstream bug for more informations:
rust-lang/rust#43575
git-svn-id: svn+ssh://svn.freebsd.org/ports/head@455198 35697150-7ecd-e111-bb59-0022644237b5
uqs
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Nov 30, 2017
Before the patch, the default behavior of the compiler was to omit frame
pointers. However, even though it looks fine for the code produced
by the compiler, the compiler itself was broken. When there was a
compilation error, rustc panics to report that error. While handling
that panic, it tries to unwind the stack but fails to do so, which
results in an abort(3).
Here is an example:
$ rustc hello.rs
error: invalid reference to argument `0` (no arguments given)
--> hello.rs:2:5
|
2 | println!("Hello {}")
| ^^^^^^^^^^^^^^^^^^^^
|
= note: this error originates in a macro outside of the current crate
error: aborting due to previous error
fatal runtime error: failed to initiate panic, error 5
Abort trap (core dumped)
The problem also exists on other systems such as OpenBSD and
i686-unknown-linux-musl. "omit frame pointers" was already disabled for
i686-unknown-linux-musl:
https://github.com/rust-lang/rust/blob/88a28ff6028cf197ed6b4185d8cd4887f05e3e07/src/librustc_back/target/i686_unknown_linux_musl.rs#L22
The patch does the same for *-unknown-freebsd.
See the upstream bug for more informations:
rust-lang/rust#43575
|
It seems like this workaround no longer works on FreeBSD but I'm not sure. |
|
Actually it does work, will submit a PR for it. |
bdrewery
added a commit
to bdrewery/rust
that referenced
this issue
Feb 24, 2018
Same problem as OpenBSD, tracking bug rust-lang#43575.
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Feb 25, 2018
…, r=eddyb Workaround abort(2) on compilation error on FreeBSD. Same problem as OpenBSD, tracking bug rust-lang#43575. @semarie @dumbbell
bdrewery
added a commit
to bdrewery/rust
that referenced
this issue
Mar 9, 2018
Same problem as OpenBSD, tracking bug rust-lang#43575.
bdrewery
added a commit
to bdrewery/rust
that referenced
this issue
Mar 14, 2018
Same problem as OpenBSD, tracking bug rust-lang#43575. Backport from rust-lang#48494
jonas-schievink
added
the
T-compiler
|
Is this issue resolved now? I see: And no fatal runtime error or abort trap. FreeBSD 13ish, rust-nightly 1.49. If it's resolved, let's close it! Thanks. |
|
The bugzilla issue referenced in the code that works around this problem (https://bugs.llvm.org/show_bug.cgi?id=30879) has been fixed. Could anyone test with the workaround reverted? |
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Jul 26, 2021
…petrochenkov freebsd remove compiler workaround. related issue rust-lang#43575
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When there is a compilation failure, the Rust compiler aborts with the following output:
I used the following invalid source file:
Here is the backtrace:
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:
I don't know how to debug this further. I tried with
debuginfo = trueanddebuginfo-lines = trueinconfig.toml, but then the problem vanishes. I'm willing to help but I would like some pointers to where to look :-)The text was updated successfully, but these errors were encountered: