illumos: rustup 1.28.{0,1,2} are miscompiled #4420
Description
Verification
- I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
- I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.
Problem
Sorry for the dramatic title, it's not existential or anything, but is quite unfortunate. Sometimes rustup panics in Tokio alleging that a read or write returned an error with errno set to 0. We've seen this manifest as unpredictable panics in Tokio when we're installing toolchains via rustup, details are here if you're interested. To summarize, though, C code built against illumos headers must have _REENTRANT defined, otherwise among other references to errno will be to the global rather than thread-local forms. And so an eventfd returning EAGAIN can be clobbered by an unrelated operation succeeding, and calamity ensues.
The issue is actually a now-fixed target-specific define that was needed in cc, rust-lang/cc-rs#1496. But the rustup binaries from before last week obviously don't have that fix, so they sometimes panic if you're unlucky.
I think this wasn't as much of an issue in older rustups because 1.28.0 picked up mio changes that on illumos would more vocally observe the errno clobbering.
Steps
root@helios:~# shasum -a 256 $(which rustup)
42828b1c55ee5c4370337d389318aa2f90d904030b5cfc991a493756763faa7b /root/.cargo/bin/rustup
root@helios:~# /usr/bin/nm $(which rustup) | grep 'errno@SUNW'
[34057] | 0| 0|FUNC |GLOB |0 |UNDEF |___errno@SUNW_0.7
[28614] | 0| 0|OBJT |GLOB |0 |UNDEF |errno@SUNW_0.7
where there's no reason a multithreaded program should link to errno@SUNW_0.7 at all.
the crash in the Helios issue is a race between parts I have relatively little control over (which Tokio tasks get EAGAIN, when network activity is happening, etc), so reproducing the exact clobber behavior is harder :)
Possible Solution(s)
c1bf2e6 includes a bump of cc to 1.2.30, which has the cc change, so I think at this point just rebuilding rustup should yield a binary with one errno: ___errno@SUNW_0.7. Of course, you'd know better if you could easily backport the cc update as rustup 1.28.3 or if we'd just wait for a rustup 1.29.0.
I took a look at the x86_64-unknown-illumos Dockerfile and don't understand which headers would be used here. Presumably x86_64-illumos-gcc has a copy of illumos headers from.. some point?
Notes
No response
Rustup version
root@helios:~# rustup --version
rustup 1.28.2 (e4f3ad6f8 2025-04-28)Installed toolchains
rather irrelevant?OS version
root@helios:~# uname -a
SunOS helios 5.11 ixi/even-more-7c1a8fa456-0-g3281cede55 i86pc i386 i86pc
but seen across a few illumos versions now, this is less interesting.