Skip to content
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

Closed
TimNN opened this issue Jul 24, 2016 · 10 comments
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc

Comments

@TimNN
Copy link
Contributor

TimNN commented Jul 24, 2016

For example https://travis-ci.org/rust-lang/rust/builds/147001444

Log excerpt:

test [run-pass] run-pass/autoderef-method-priority.rs ... ok
test [run-pass] run-pass/autoderef-method-twice.rs ... ok
test [run-pass] run-pass/autoderef-method-twice-but-not-thrice.rs ... ok
test [run-pass] run-pass/autoderef-method.rs ... ok
test [run-pass] run-pass/autoderef-privacy.rs ... ok
test [run-pass] run-pass/backtrace-debuginfo-aux.rs ... ignored
test [run-pass] run-pass/autoref-intermediate-types-issue-3585.rs ... ok
fatal runtime error: failed to initiate panic, error 3
Aborted (core dumped)
make: *** [tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-rpass.ok] Error 134
/build/mk/tests.mk:769: recipe for target 'tmp/check-stage2-T-x86_64-unknown-linux-gnu-H-x86_64-unknown-linux-gnu-rpass.ok' failed

From the timing I suspect this is related to #34832, cc @alexcrichton @vadimcn

Edit: The failing test is probably either run-pass/backtrace.rs or run-pass/backtrace-debuginfo.rs.

Edit2: very likely caused by #34832, since it's travis build is the first to exhibit this error.

@vadimcn
Copy link
Contributor

vadimcn commented Jul 24, 2016

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).

@TimNN
Copy link
Contributor Author

TimNN commented Jul 24, 2016

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 return _URC_FATAL_PHASE1_ERROR triggers the error.

Yeah, I can also only guess, I'm believe compiletest only prints something after running the test...

@alexcrichton
Copy link
Member

@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.

@cgswords
Copy link
Contributor

cgswords commented Jul 25, 2016

I'm also experiencing this on #35018 and it's working fine locally.

@vadimcn
Copy link
Contributor

vadimcn commented Jul 25, 2016

I wonder if it's different ubuntu versions on Travis here? It may be some glibc version thing going on.

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.

@alexcrichton
Copy link
Member

@vadimcn ah yeah that makes sense too yeah

@jhod0
Copy link

jhod0 commented Jul 25, 2016

This is also causing #34970 to fail

@steveklabnik steveklabnik added the A-testsuite Area: The testsuite used to check the correctness of rustc label Jul 25, 2016
@jhod0
Copy link

jhod0 commented Jul 30, 2016

Looks like the PRs were merged - should this be closed?

@alexcrichton
Copy link
Member

Indeed!

jhod0 pushed a commit to jhod0/rust that referenced this issue Jul 30, 2016
nbdd0121 added a commit to nbdd0121/rust that referenced this issue Oct 5, 2022
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
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Oct 11, 2022
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
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Oct 11, 2022
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
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc
Projects
None yet
Development

No branches or pull requests

6 participants