Random linker failure involving alloc symbols on stable 1.72.0 to currently nightly

[konnorandrews]

I have a toy program to fuzz Rust's compilation errors. I noticed that on nightly it randomly fails with linker issues. I then went and tested it on stable 1.72.0 and the same thing happens. This error seems to be almost completely random, and the fuzzer has to generate a few thousand rustc compilations to find it.

It is unclear to me what is happening and if there are existing issues open for this. I can provide the fuzzer code if needed.

Meta

rustc --version --verbose:

rustc 1.72.0 (5680fa18f 2023-08-23)
binary: rustc
commit-hash: 5680fa18feaa87f3ff04063800aec256c3d4b4be
commit-date: 2023-08-23
host: x86_64-unknown-linux-gnu
release: 1.72.0
LLVM version: 16.0.5

Backtrace

``` ```

[konnorandrews]

I am unable to post the error output in the issue because it's to long for github.

[konnorandrews]

Here is the error output from rustc: https://pastebin.com/LVnU0yhd (note this is the nightly one, the stable one looks to be the same except for the paths)

[konnorandrews]

After playing around with is some more, it looks like its a file system timing issue. If I give each rustc instance the fuzzer is running it's own working directory using tempfile then this doesn't happen any more.

[konnorandrews]

This also looks to effect more or less every version of rustc. I went through and tested a lot of older versions with the failing setup.

[bjorn3]

If you are building multiple crates with the same --out-dir, same crate name and same -Cmetadata arguments they will overwrite files of each other as the names of temporary files are exclusively based on those things.

[saethlin]

@konnorandrews I don't know what to do with this bug report. On the one hand, what you're reporting sounds spooky and I'm interested in making sure our toolchain doesn't have strange edge cases where it just falls over.

But also, you haven't provided enough information to reproduce this. I don't even know where to start. Can you link the fuzzer that generated the crash and how to run it? Can you tar up the output directory when the error happens and provide a rustc invocation that causes such a linker error with that directory? Any one of these could help us make something of this issue, but having none of them and given bjorn3's comment, I'm not sure there's anything we can do here. Perhaps harden the toolchain to detect this situation and produce a different diagnostic, but that's it.