Skip to content

std: abort the process on failure to allocate a TLS key #141455

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.

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

joboet
Copy link
Member

@joboet joboet commented May 23, 2025

The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see #140798 (comment)). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.

The panic machinery uses TLS, so panicking if no TLS keys are left can lead to infinite recursion (see rust-lang#140798 (comment)). Rather than having separate logic for the panic count and the thread name, just always abort the process if a TLS key allocation fails. This also has the benefit of aligning the key-based TLS implementation with the documentation, which does not mention that a panic could also occur because of resource exhaustion.
@rustbot
Copy link
Collaborator

rustbot commented May 23, 2025

r? @tgross35

rustbot has assigned @tgross35.
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 rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 23, 2025
@tgross35
Copy link
Contributor

tgross35 commented May 23, 2025

The reasoning at #140798 (comment) makes sense to me and this diff is straightforward enough, r=me with green CI.

It would be nice if somebody (@Berrysoft?) could confirm that we get an abort rather than the overflow with this patch.

(if this comment posts about 4 times, blame it on the apparent github outage)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants