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.

Sign up for GitHub

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

Jump to bottom

STATUS_HEAP_CORRUPTION in rust-lld with a custom target on x86_64-pc-windows-gnu #115985

Open
ehuss opened this issue Sep 19, 2023 · 1 comment
Open

STATUS_HEAP_CORRUPTION in rust-lld with a custom target on x86_64-pc-windows-gnu #115985

ehuss opened this issue Sep 19, 2023 · 1 comment
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows

Comments

@ehuss
Copy link
Contributor

ehuss commented Sep 19, 2023

The following example has recently started causing rust-lld to crash on x86_64-pc-windows-gnu:

#![no_main]
#![allow(internal_features)]
#![feature(no_core)]
#![feature(lang_items)]
#![no_core]

#[lang = "sized"]
pub trait Sized {
    // Empty.
}
#[lang = "copy"]
pub trait Copy {
    // Empty.
}

with a custom JSON target:

{
    "llvm-target": "x86_64-unknown-none-gnu",
    "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
    "arch": "x86_64",
    "target-endian": "little",
    "target-pointer-width": "64",
    "target-c-int-width": "32",
    "os": "none",
    "linker-flavor": "ld.lld",
    "linker": "rust-lld",
    "executables": true
}

Building with:

rustc --target custom-target.json main.rs

This causes rust-lld to fail about 50% of the time, with errors like:

error: linking with `rust-lld` failed: exit code: 0xc0000374
  |
  = note: "rust-lld" "-flavor" "gnu" "main.main.4fa2520d328b6ba3-cgu.0.rcgu.o" "--as-needed" "-L" "C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-o" "main" "--gc-sections"
  = note: rust-lld: warning: cannot find entry symbol _start; not setting start address

error: aborting due to previous error

or

error: linking with `rust-lld` failed: exit code: 0xc0000005
  |
  = note: "rust-lld" "-flavor" "gnu" "main.main.4fa2520d328b6ba3-cgu.0.rcgu.o" "--as-needed" "-L" "C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-o" "main" "--gc-sections"
  = note: rust-lld: warning: cannot find entry symbol _start; not setting start address
          PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
          Stack dump:
          0.    Program arguments: rust-lld -flavor gnu main.main.4fa2520d328b6ba3-cgu.0.rcgu.o --as-needed -L C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib -Bdynamic --eh-frame-hdr -z noexecstack -L C:\\Users\\eric\\.rustup\\toolchains\\nightly-2023-09-01-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib -o main --gc-sections
          Exception Code: 0xC0000005
          0x00007FFDD755633C, C:\WINDOWS\SYSTEM32\ntdll.dll(0x00007FFDD7530000)   0x2633C byte(s), RtlGetCurrentServiceSessionId()   0x1AEC byte(s)
          0x00007FFDD7555B74, C:\WINDOWS\SYSTEM32\ntdll.dll(0x00007FFDD7530000)   0x25B74 byte(s), RtlGetCurrentServiceSessionId()   0x1324 byte(s)
          0x00007FFDD75547B1, C:\WINDOWS\SYSTEM32\ntdll.dll(0x00007FFDD7530000)   0x247B1 byte(s), RtlFreeHeap()   0x51 byte(s)
          0x00007FFDD5609C9C, C:\WINDOWS\System32\msvcrt.dll(0x00007FFDD55F0000)   0x19C9C byte(s), free()   0x1C byte(s)
          0x00007FFDD5609366, C:\WINDOWS\System32\msvcrt.dll(0x00007FFDD55F0000)   0x19366 byte(s), _aligned_free()   0x16 byte(s)
          0x00007FF74451890A, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x351890A byte(s)
          0x00007FF742807BF9, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x1807BF9 byte(s)
          0x00007FF7426D9634, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x16D9634 byte(s)
          0x00007FF742256947, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x1256947 byte(s)
          0x00007FF74208C943, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x108C943 byte(s)
          0x00007FF74106032E, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x6032E byte(s)
          0x00007FF74457EB45, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x357EB45 byte(s)
          0x00007FF741001395, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x1395 byte(s)
          0x00007FF7410014E6, C:\Users\eric\.rustup\toolchains\nightly-2023-09-01-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\rust-lld.exe(0x00007FF741000000)   0x14E6 byte(s)
          0x00007FFDD6CF7614, C:\WINDOWS\System32\KERNEL32.DLL(0x00007FFDD6CE0000)   0x17614 byte(s), BaseThreadInitThunk()   0x14 byte(s)
          0x00007FFDD75826B1, C:\WINDOWS\SYSTEM32\ntdll.dll(0x00007FFDD7530000)   0x526B1 byte(s), RtlUserThreadStart()   0x21 byte(s)

This is part of cargo's testsuite, which is causing issues in our CI.

I have bisected the regression to #114048 (starting nightly-2023-08-09). cc @nikic

It doesn't seem to be happening on any other platforms.

Meta

rustc --version --verbose:

rustc 1.74.0-nightly (203c57dbe 2023-09-17)
binary: rustc
commit-hash: 203c57dbe20aee67eaa8f7be45d1e4ef0b274109
commit-date: 2023-09-17
host: x86_64-pc-windows-gnu
release: 1.74.0-nightly
LLVM version: 17.0.0
@ehuss ehuss added O-windows-gnu Toolchain: GNU, Operating system: Windows C-bug Category: This is a bug. labels Sep 19, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 19, 2023
@saethlin saethlin added A-linkage Area: linking into static, shared libraries and binaries and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Sep 19, 2023
@ehuss ehuss added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Oct 2, 2023
@ehuss ehuss mentioned this issue Oct 2, 2023
Merged
bors added a commit to rust-lang/cargo that referenced this issue Oct 2, 2023
@bors
Auto merge of #12763 - ehuss:custom_bin_target-windows-gnu, r=weihanglo
1f94bf2 
Disable custom_target::custom_bin_target on windows-gnu

The `custom_target::custom_bin_target` test has been crashing frequently in CI on the x86_64-pc-windows-gnu target since the last LLVM 17 update. This disables the test to reduce the disruption in CI. The issue is being tracked in rust-lang/rust#115985.
@cr1901
Copy link
Contributor

cr1901 commented Oct 10, 2023 •
edited
Loading

Maybe this is another useful data point, but I can duplicate with the following from riscv-rt:

RUSTFLAGS="-C link-arg=-Texamples/device.x" cargo build --example empty --target=riscv32i-unknown-none-elf

Sometimes it succeeds, sometimes it crashes, sometimes it hangs.

I found this line in my global cargo config from a while ago:

[target.riscv32i-unknown-none-elf]
rustflags = [ "-C", "link-arg=--threads=1" ]

Unfortunately, I don't remember where I learned this- there's probably a Zulip thread- but multithreaded lld is (was?) known to be buggy and hang a lot on Windows, and there's not been much interest in fixing it on the LLD side. So I was a bit surprised to see this issue appear after a while not needing lld.

Apparently, setting RUSTFLAGS on the command line for quick testing overrides my config. When I add the link-arg flag back in, the crashes go away for me:

RUSTFLAGS="-C link-arg=--threads=1 -C link-arg=-Texamples/device.x" cargo build --example empty --target=riscv32i-unknown-none-elf

William@DESKTOP-3H1DSBV MINGW64 ~/Projects/rust-embedded/riscv-rt
$ rustc -Vv
rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-pc-windows-gnu
release: 1.73.0
LLVM version: 17.0.2

@ehuss ehuss mentioned this issue Nov 14, 2023
Merged
bors added a commit to rust-lang/cargo that referenced this issue Nov 14, 2023
@bors
Auto merge of #12972 - ehuss:windows-gnu-ignore-json-target, r=epage
360059e 
Ignore changing_spec_relearns_crate_types on windows-gnu

This disables the `custom_target::changing_spec_relearns_crate_types` on windows-gnu targets for the same reason as #12763. The update to LLVM 17 has started to cause lld to crash when using a custom target. cc rust-lang/rust#115985

I surveyed the rest of the testsuite, and I don't see any other tests that perform linking with custom targets.
yupferris added a commit to xenowing/xenowing that referenced this issue Jan 2, 2024
@yupferris
sw: Link rv32 code with only one thread
8788155 
For quite some time now, on Windows, the bootloader and program builds would randomly hang with what looked to be some kind of deadlock issue in lld. I never spent much time looking into this, but when randomly googling, I found rust-lang/rust#115985 (comment), which describes similar symptoms and a workaround, which this patch implements.

Admittedly, I haven't spent _that_ much time verifying this, but it appears to work as expected after a few clean/build cycles, so I'll keep going with it for now and revert if the problem comes back again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-linkage Area: linking into static, shared libraries and binaries A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. O-windows-gnu Toolchain: GNU, Operating system: Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ehuss @cr1901 @saethlin @rustbot