Rustc version 1.94.1 fails with error "fatal runtime error: out of TLS keys, aborting"

[lordmulder]

After the Rust toolchain got updated from 1.89.0 to 1.94.1 on Haiku OS, I noticed that my project now fails to build with error:

fatal runtime error: out of TLS keys, aborting

out of TLS keys, aborting (screenshot)

---

I suppose here "TLS" refers to thread-local storage rather than transport layer security 🤔

So, it would seem that the new version of rustc attempts to use more TLS slots (keys) than the operating system can provide.

From what I understand, the maximum number of TLS (thread-local storage) keys is equal to PTHREAD_KEYS_MAX, i.e., the "Maximum number of data keys that can be created by a process". It appears that this constant is platform-specific, but the POSIX standard defines the "Minimum Acceptable Value" as another constant called _POSIX_THREAD_KEYS_MAX – which is defined as 128.

See here:
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

---

So, this means that rustc probably should be very conservative with the number of TLS keys that it uses, because one must not assume that more than 128 TLS keys are available on any operating system. Nonetheless, it appears that Rust 1.94.1 violates the limit, whereas older Rust versions, such as 1.89.0, have been working flawlessly 😕

To make it clear, the exactly same code used to compile just fine with Rust 1.89.0 on Haiku OS. Also, my code does not even use thread_local! at all! So, I think, this must be a problem with the excessive use of thread_local! in rustc itself, not in my own code. Furthermore, the problem only started after Haiku OS updated their Rust toolchain from 1.89.0 to 1.94.1, so the "problematic" change must be anywhere in between these versions. I cannot say which version exactly broke the build, since rustup does not support Haiku OS yet, so I can only use the Rust version that Haiko OS itself provides (via pkgman).

Best regards.

---

Might be related:
#147590

[chenyukang]

The error comes from

rust/library/std/src/sys/thread_local/key/unix.rs

Lines 25 to 33 in 597d9e4

	#[inline]
	pub fn create(dtor: Option<unsafe extern "C" fn(*mut u8)>) -> Key {
	let mut key = 0;
	if unsafe { libc::pthread_key_create(&mut key, mem::transmute(dtor)) } != 0 {
	rtabort!("out of TLS keys");
	}
	key
	}

On Haiku, target_thread_local is not enabled, so thread_local! falls back to an OS/pthread-key based implementation. When pthread_key_create fails, std aborts with fatal runtime error: out of TLS keys.

In 1.94.x, parse_attribute_list finalizes all parsers unconditionally, which touches each parser's thread_local! state even if that attribute was never used. Since there are early and late parser sets, sumed to more than size of 200, this can easily exceed platforms that only provide the POSIX-minimum 128 TLS keys.

There is a relevant fix: #151382.
That fix is not in 1.94.1, but it is contained in 1.95.0. So it would be very useful to test whether Rust 1.95.0 still reproduces this on Haiku.

If 1.95.0 works, this issue is likely fixed by #151382, or could be considered for a backport.

[chenyukang]

But seems #151382 changed rustc only runs the finalizers for parsers that actually accepted an attribute. This avoids eagerly touching all parser TLS states, and should significantly reduce the number of pthread TLS keys used in normal compilations.

seems it still a mitigation of the problem. Each attribute parser still has its own potential thread_local! state. If a compilation actually uses enough different parsed attributes, rustc may still initialize many TLS states.

[teor2345]

It might be useful to add a "Christmas tree" UI test which contains as many attributes as possible, so we don't go over the TLS limit on a tier 1 / CI platform.

[lordmulder]

That fix is not in 1.94.1, but it is contained in 1.95.0. So it would be very useful to test whether Rust 1.95.0 still reproduces this on Haiku.

Update to version 1.95.0 has been requested:
haikuports/haikuports#14042