Repository navigation
Windows 7 i686 does not reliably align 16 byte aligned thread locals #138903
Description
The following program will reliably crash using the i686-win7-windows-msvc target on a Windows 7 installation using latest nightly.
I tried this code:
#[repr(align(16))]
struct Align16(u8);
thread_local! {
static ALIGN16: Align16 = Align16(0);
}
fn main() {
let mut threads = Vec::new();
for _ in 0..10 {
threads.push(std::thread::spawn(|| {
ALIGN16.with(|r| println!("ALIGN16 {:p}", r as *const _));
}));
}
for thread in threads {
thread.join().unwrap();
}
}This reliably produces the following panic.
unsafe precondition(s) violated: ptr::replace requires that the pointer argument is aligned and non-null
This indicates a bug in the program. This Undefined Behavior check is optional, and cannot be relied on for safety.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused a non-unwinding panic. aborting.
My experience with/understanding of thread locals is mostly limited to what i've researched due to this issue, but it does appear that an i686 targeted executable on Windows 7 does not reliably align thread locals when 16 byte alignment is requested. I didn't see issues with even 8 byte alignment. I was not able to reproduce this issue on Windows 10.
Given that i686 win7 is a likely pretty niche target, do you think it would be reasonable to partially undo #123257 by disabling has_thread_local for i686-win7-windows-msvc. It seems that i686 on Windows 7 can't be trusted for alignment of thread locals. I did test adjusting the i686-win7-windows-msvc target in a local build of the compiler and it does appear to work for the test program.
The 16 byte aligned thread local came from matrixmultiply which actually works around misalignment internally, but compiled this way I get the UB check panic anyway. I can certainly work around it by seeing if matrixmultiply can be patched, or just doing that locally. But it seems like this should be fixed in the compiler ideally.
Activity
moxian commentedon Mar 24, 2025
@rustbot label: +O-windows-7 +O-x86_32 +A-thread-locals +A-align -needs-triage +T-compiler
cc @roblabla @ChrisDenton
Exclude alignment for MaskBuffer for i686-win7-windows-msvc
roblabla commentedon Apr 18, 2025
So I dug into this a bit, and was able to reproduce. Thankfully there's a bit of a similar issue in GNU targets, with some instructions on how to investigate: #135719 (comment)
llvm-objdump --allgives me the following information:Characteristics 5242880 is 0x500000 in hex, which equals IMAGE_SCN_ALIGN_16BYTES, which matches what we expect. However, when running the reproducer, I indeed get the same crashes. So this would indicate that Windows 7 does not respect the
IMAGE_SCN_ALIGN_16BYTESflag in the TLS directory.I'll make a PR to put has_thread_local back to false.
Rollup merge of rust-lang#140007 - roblabla:fix-win7, r=ChrisDenton
Rollup merge of rust-lang#140007 - roblabla:fix-win7, r=ChrisDenton
Rollup merge of rust-lang#140007 - roblabla:fix-win7, r=ChrisDenton
Rollup merge of rust-lang#140007 - roblabla:fix-win7, r=ChrisDenton
Unrolled build for rust-lang#140007
Exclude alignment for MaskBuffer for i686-win7-windows-msvc