`thread_local!` initialization code panics on some `aarch64-apple-darwin` envs, works on others

[dj8yfo]

I tried this code:

https://github.com/near/near-sdk-rs/blob/master/near-sdk/src/environment/mock/mod.rs#L11-L16

thread_local! {
    static BLOCKCHAIN_INTERFACE: RefCell<MockedBlockchain>
         = RefCell::new(MockedBlockchain::default());
}

I expected to see this happen:

thread_local! initialization code for RefCell::new(MockedBlockchain::new)
works

Instead, this happened:

on unclarified aarch64-apple-darwin environment(s) thread_local!
panics on https://doc.rust-lang.org/src/core/ptr/mod.rs.html#1277 .

The issue doesn't reproduce on other aarch64-apple-darwin real macs,
and on macos-14-arm64 github actions vm.

Original issue: near/near-sdk-rs#1252

Meta

rustc --version --verbose:

stable: 1.80, 1.81, 1.82 panics
beta 1.83 panics
nightly 1.84 panics

backtrace from original issue:
near/near-sdk-rs#1252 (comment)

[dj8yfo]

Somewhat limited pre-analysis (can be safely ignored)

ub_checks::assert_unsafe_precondition! check inside of
https://github.com/rust-lang/rust/blob/master/library/std/src/sys/thread_local/native/lazy.rs#L66
fails,
because earlier LazyStorage::new failed to put State::Initial
into an adress with correct alignment for State<T,D>
https://github.com/rust-lang/rust/blob/master/library/std/src/sys/thread_local/native/lazy.rs#L37,
where T is RefCell<MockedBlockchain<Memory = MockedMemory>>

related case

earlier we had a similar issue with aarch64-apple-darwin with somewhat similar panics:

0x102f569ec - core::ptr::replace::he9e2c42f9fe96d9b
                  at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ub_checks.rs:73:17
0x102f569ec - core::ptr::mut_ptr::<impl *mut T>::replace::hcc3425bab485c184
                  at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/core/src/ptr/mut_ptr.rs:1560:18
0x102f569ec - std::sys::thread_local::lazy::LazyKeyInner<T>::take::h11414c1b64d26b2a
                  at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library/std/src/sys/thread_local/mod.rs:102:30

which originated in some register_dtor functions when trying to run doc-tests
for the same near-sdk-rs project : #126643

It was later confirmed that the issue stopped to manifest itself on exactly the same
rustc 1.79.0 (129f3b996 2024-06-10) compiler after macos-14-arm64 github actions
vm was updated.

[madsmtm]

I tried going through the linked issues, but I couldn't figure out how you reproduce the issue (what commands do you run?).

A hypothetical minimal reproducer based on the code you posted doesn't reproduce on my Mac (M2, macOS 14.7):

use std::cell::RefCell;

#[repr(align(16))]
#[derive(Debug)]
struct MockedBlockchain {
    _size: [u8; 2512],
}

thread_local! {
    static BLOCKCHAIN_INTERFACE: RefCell<MockedBlockchain> = RefCell::new(MockedBlockchain {
        _size: [1; 2512],
    });
}

fn main() {
    BLOCKCHAIN_INTERFACE.with(|b| println!("{b:?}"));
}

So it sounds like it might be something else that is causing the issue?

[madsmtm]

on unclarified aarch64-apple-darwin environment(s) thread_local! panics on https://doc.rust-lang.org/src/core/ptr/mod.rs.html#1277 .

What do you mean by "unclarified"? Knowing that might help us to reproduce the issue?

[dj8yfo]

@madsmtm you might ask @peitalin from the linked issue about specifics of his environment, where he reproduced it. We didn't reproduce it on our macs either.

The command sequence to run the same scenario which triggered panic would be

# install cargo-near to $CARGO_HOME/bin
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/near/cargo-near/releases/latest/download/cargo-near-installer.sh | sh
cargo near new test
cd test/
cargo test

If the binary installer doesn't work for some reason, it can be installed from source by cargo install cargo-near

[dj8yfo]

@madsmtm the code you tried is much simpler than the one from near-sdk repo. One from near-sdk repo uses generic parameter and also some unsafe to create references to self (without ouroborous). The self-referential part has been there for some odd 3 years, while the generic parameter has been added recently, a couple of months ago.