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

1.53.0 test join_orders_after_tls_destructors fails on armhf (armv7-unknown-linux-gnueabihf) Debian #89584

Closed
infinity0 opened this issue Oct 6, 2021 · 7 comments
Labels
C-bug Category: This is a bug.

Comments

@infinity0
Copy link
Contributor

From the build log (warning several MB):

failures:

---- thread::local::tests::join_orders_after_tls_destructors stdout ----
thread 'thread::local::tests::join_orders_after_tls_destructors' panicked at 'internal error: entered unreachable code: sync state: Err(2)', library/std/src/thread/local/tests.rs:312:22
stack backtrace:
   0: rust_begin_unwind
             at /usr/src/rustc-1.53.0/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /usr/src/rustc-1.53.0/library/core/src/panicking.rs:92:14
   2: std::thread::local::tests::join_orders_after_tls_destructors
   3: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.53.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

CC @mzohreva who added the test in #84409

@jethrogb
Copy link
Contributor

jethrogb commented Oct 6, 2021

This was fixed in #86383 which landed in 1.55.0

@infinity0
Copy link
Contributor Author

Thanks, I will backport it into 1.53.0 on Debian.

@infinity0
Copy link
Contributor Author

The patch breaks self-bootstrapping on 1.53 (using 1.53 as the bootstrap compiler to build 1.53) as it relies on the later lang item slice_len_fn; I will revert it and ignore this test failure temporarily on armhf until 1.54.

@jethrogb
Copy link
Contributor

jethrogb commented Oct 6, 2021

You should only patch the test, not any of the other files touched by that PR.

@infinity0
Copy link
Contributor Author

So just this?

--- a/library/std/src/thread/local/tests.rs
+++ b/library/std/src/thread/local/tests.rs
@@ -297,7 +297,7 @@
             .unwrap();
 
         loop {
-            match SYNC_STATE.compare_exchange_weak(
+            match SYNC_STATE.compare_exchange(
                 THREAD1_WAITING,
                 MAIN_THREAD_RENDEZVOUS,
                 Ordering::SeqCst,

I am actually confused about our bootstrapping failures; it looks like slice_len_fn is defined wholely within that PR, so backporting it onto 1.53 should be fine? But we get:

error[E0522]: definition of an unknown language item: `slice_len_fn`
  --> library/core/src/slice/mod.rs:99:32
   |
99 |     #[cfg_attr(not(bootstrap), lang = "slice_len_fn")]
   |                                ^^^^^^^^^^^^^^^^^^^^^ definition of unknown language item `slice_len_fn`

     Running `/<<PKGBUILDDIR>>/build/x86_64-unknown-linux-gnu/stage0-std/release/build/unwind-216b748a34c54be2/build-script-build`

That is, not(bootstrap) seems to be true even though we are building stage0-std.

@infinity0
Copy link
Contributor Author

infinity0 commented Oct 6, 2021

Ah, ok nvmd I think it's because src/bootstrap/builder.rs detects we're running the "same" version, so explicitly does not set --cfg=bootstrap, but the "same" version actually does not have that lang item.

@infinity0
Copy link
Contributor Author

Closing as it's already fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

2 participants