-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
run-pass tests are failing on travis with "fatal runtime error: failed to initiate panic, error 3" #35011
Comments
Any ideas what's different about Travis? This test passed on my local builds (as well as on buildbots, obviously). (BTW, am I the only one who's always getting confused about which test has failed? I don't see anything in the compiletest's output to indicate the culprit). |
No idea what's different about travis, everything worked fine locally for me as well. We may want to just do a PR with some additional logging to see which one (if any) of the Yeah, I can also only guess, I'm believe compiletest only prints something after running the test... |
@vadimcn I wonder if it's different ubuntu versions on Travis here? It may be some glibc version thing going on. If you execute tests in the dockerfile it should in theory reproduce. |
I'm also experiencing this on #35018 and it's working fine locally. |
If I read our Dockerfile correctly, it uses LLVM 3.7 release, not whatever dev version is currently in rust-lang/llvm? I think that's far more likely to cause codegen differences than a different glibc. |
@vadimcn ah yeah that makes sense too yeah |
This is also causing #34970 to fail |
Looks like the PRs were merged - should this be closed? |
Indeed! |
In order to fix failing tests of rust-lang#35011
The EH actions stored in the LSDA follows the format of GCC except table (even for LLVM-generated code). An missing action in the table is the encoding for `Terminate`, see [1]. The currently code interprets it as `None`, as a workaround for rust-lang#35011, an issue that seems to occur in LLVM 3.7 and not after 3.9. These are very old versions of LLVM and we don't support them anymore, so remove this workaround and interpret them properly. Note that LLVM currently does not emit any `Terminate` actions, but GCC does. Although GCC backend currently doesn't do unwinding, removing it preemptively would prevent future developers from wasting time to figure out what's wrong. [1]: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L522-L526
Interpret EH actions properly The EH actions stored in the LSDA follows the format of GCC except table (even for LLVM-generated code). An missing action in the table is the encoding for `Terminate`, see https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L522-L526. The currently code interprets it as `None`, as a workaround for rust-lang#35011, an issue that seems to occur in LLVM 3.7 and not after 3.9. These are very old versions of LLVM and we don't support them anymore, so remove this workaround and interpret them properly. Note that LLVM currently does not emit any `Terminate` actions, but GCC does. Although GCC backend currently doesn't do unwinding, removing it preemptively would prevent future developers from wasting time to figure out what's wrong. `@rustbot` label: +T-compiler
Interpret EH actions properly The EH actions stored in the LSDA follows the format of GCC except table (even for LLVM-generated code). An missing action in the table is the encoding for `Terminate`, see https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L522-L526. The currently code interprets it as `None`, as a workaround for rust-lang#35011, an issue that seems to occur in LLVM 3.7 and not after 3.9. These are very old versions of LLVM and we don't support them anymore, so remove this workaround and interpret them properly. Note that LLVM currently does not emit any `Terminate` actions, but GCC does. Although GCC backend currently doesn't do unwinding, removing it preemptively would prevent future developers from wasting time to figure out what's wrong. ``@rustbot`` label: +T-compiler
Interpret EH actions properly The EH actions stored in the LSDA follows the format of GCC except table (even for LLVM-generated code). An missing action in the table is the encoding for `Terminate`, see https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L522-L526. The currently code interprets it as `None`, as a workaround for rust-lang#35011, an issue that seems to occur in LLVM 3.7 and not after 3.9. These are very old versions of LLVM and we don't support them anymore, so remove this workaround and interpret them properly. Note that LLVM currently does not emit any `Terminate` actions, but GCC does. Although GCC backend currently doesn't do unwinding, removing it preemptively would prevent future developers from wasting time to figure out what's wrong. ``@rustbot`` label: +T-compiler
For example https://travis-ci.org/rust-lang/rust/builds/147001444
Log excerpt:
From the timing I suspect this is related to #34832, cc @alexcrichton @vadimcn
Edit: The failing test is probably either
run-pass/backtrace.rs
orrun-pass/backtrace-debuginfo.rs
.Edit2: very likely caused by #34832, since it's travis build is the first to exhibit this error.
The text was updated successfully, but these errors were encountered: