Workaround for windows-gnu rust-lld test failure

[ChrisDenton]

The test run-make/amdgpu-kd has an issue on windows-gnu where rust-lld will sometimes fail with error 0xc0000374 (STATUS_HEAP_CORRUPTION).

This works around the issue by passing --threads=1 to the linker as suggested here. Note I don't know if this will help and it happens only sometimes in our CI so it's hard to test.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[ChrisDenton]

@bors try

[bors]

⌛ Trying commit b107e98 with merge 46b91f6...

[jieyouxu]

Yeah, this is one of the tests where this can happen, but there's also other tests that run into rust-lld heap corruption.

r=me if the try-job comes back green, I guess even r=me if it fails due to heap corruption anyway (hopefully single thread makes it less likely)...

[petrochenkov]

@ChrisDenton Have you seen the RUSTC_RETRY_LINKER_ON_SEGFAULT hack in the compiler? 😄
If the issue may appear on something different than tests/run-make/amdgpu-kd/rmake.rs then something like that may make sense on Windows as well.

[jieyouxu]

Lmao I did not know that was a thing

[ChrisDenton]

Me neither, ha.

Though this issue does seem to be specific to this windows-gnu, rust-lld and this test in particular. I looked at some of the older test fails and they don't seem to exist any more (I guess this test replaced them?). Like tests/ui/amdgpu-require-explicit-cpu.rs

[jieyouxu]

I believe there's also avr-rjmp-offset where we disabled the test on windows-gnu because of rust-lld too (#133480)

[ChrisDenton]

Ah, that's already disabled so I didn't see it in the logs. Also it is a STATUS_ACCESS_VIOLATION instead of a STATUS_HEAP_CORRUPTION but it possibly has a similar cause.

[jieyouxu]

@ChrisDenton Have you seen the RUSTC_RETRY_LINKER_ON_SEGFAULT hack in the compiler? 😄 If the issue may appear on something different than tests/run-make/amdgpu-kd/rmake.rs then something like that may make sense on Windows as well.

Apparently that was for a similarly cursed problem, #38878.

rust/compiler/rustc_codegen_ssa/src/back/link.rs

Lines 842 to 861 in a932eb3

	// Here's a terribly awful hack that really shouldn't be present in any
	// compiler. Here an environment variable is supported to automatically
	// retry the linker invocation if the linker looks like it segfaulted.
	//
	// Gee that seems odd, normally segfaults are things we want to know
	// about! Unfortunately though in rust-lang/rust#38878 we're
	// experiencing the linker segfaulting on Travis quite a bit which is
	// causing quite a bit of pain to land PRs when they spuriously fail
	// due to a segfault.
	//
	// The issue #38878 has some more debugging information on it as well,
	// but this unfortunately looks like it's just a race condition in
	// macOS's linker with some thread pool working in the background. It
	// seems that no one currently knows a fix for this so in the meantime
	// we're left with this...
	if !retry_on_segfault || i > 3 {
	break;
	}
	let msg_segv = "clang: error: unable to execute command: Segmentation fault: 11";
	let msg_bus = "clang: error: unable to execute command: Bus error: 10";

[ChrisDenton]

So I think I'd personally prefer not to pile on the hack if it can be avoided. If this PR fixes the issue and we don't get more cropping up then I'd like to leave that alone. If it does crop up again then adding 0xc0000374 and 0xc0000005 to the hack would be the least worst option, I guess.

I do wonder if we could work around this in run-make. The thing the avr test and this one have in common is cross-compiling for a more specialised target. But I'd like to first confirm that setting --threads=1 does in fact help.

[jieyouxu]

Yeah, that is reasonable

[jieyouxu]

@bors r+ rollup

[bors]

📌 Commit 52594ef has been approved by jieyouxu

It is now in the queue for this repository.

[ChrisDenton]

That seems to an entirely different spurious failure 😅. A stack overflow in mir-opt\building\issue_49232.rs, We've had other such spurious errors before but they seem to come and go, e.g. #138110

[jieyouxu]

That is... yeah.

[jieyouxu]

Oh I didn't realize the try-job didn't finish... Just in case
@bors r-

[jieyouxu]

@bors r+

[bors]

📌 Commit 52594ef has been approved by jieyouxu

It is now in the queue for this repository.

[ChrisDenton]

Oh, oops, I need to be more explicit about types. I forgot it's ignored on my local machine

@bors r=jieyouxu

[bors]

📌 Commit 3c42dc2 has been approved by jieyouxu

It is now in the queue for this repository.