std: thread: Return error if setting thread stack size fails - #144210
Merged
Merged
Conversation
Collaborator
|
r? @ibraheemdev rustbot has assigned @ibraheemdev. Use |
rustbot
added
O-unix
bjorn3
reviewed
Jul 21, 2025
Contributor
Author
|
CI failure is unrelated and spurious, could you perhaps retry it? |
Gelbpunkt
force-pushed
the
thread-stack-size-musl
branch
from
July 26, 2025 20:34
8e5114a to
e143986
Compare
Contributor
Author
|
Rebased to squash the fixup and re-trigger CI. |
Contributor
Author
|
Two weeks passed, I guess I'll re-roll reviewers. r? libs |
Member
|
@bors r+ Tagging as release notes as this is something that may be worth calling out. |
Collaborator
bors
added
S-waiting-on-bors
jhpratt
added
relnotes
jhpratt
added
S-waiting-on-bors
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 11, 2025
…r=jhpratt std: thread: Return error if setting thread stack size fails Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds. This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully. There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed. [1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
fmease
added a commit
to fmease/rust
that referenced
this pull request
Aug 12, 2025
…r=jhpratt std: thread: Return error if setting thread stack size fails Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to `pthread_attr_setstacksize` succeeds. This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of `usize::MAX / 4 - PTHREAD_STACK_MIN` [1], triggering the assert rather than erroring gracefully. There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed. [1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5
fmease
reviewed
Aug 12, 2025
Member
bors
removed
the
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
added a commit
that referenced
this pull request
Aug 12, 2025
std: thread: Return error if setting thread stack size fails try-job: x86_64-gnu-aux
This comment has been minimized.
This comment has been minimized.
commented
Aug 12, 2025
Contributor
|
💔 Test for 5266eb8 failed: CI. Failed jobs:
|
commented
Aug 14, 2025
Member
|
The failing test has been updated by #145299. |
Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to pthread_attr_setstacksize succeeds. This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of usize::MAX / 4 - PTHREAD_STACK_MIN [1], triggering the assert rather than erroring gracefully. There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed. [1]: https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_attr_setstacksize.c#n5 Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Gelbpunkt
force-pushed
the
thread-stack-size-musl
branch
from
August 14, 2025 18:37
25fe461 to
5d01d90
Compare
commented
Aug 14, 2025
Contributor
Author
|
Rebased to include the fix for the failing test and to address the feedback from @joboet |
commented
Aug 14, 2025
Contributor
Author
|
oops, forgot to: @rustbot ready |
rustbot
added
S-waiting-on-review
commented
Aug 15, 2025
Member
|
@bors try jobs=x86_64-gnu-aux |
This comment has been minimized.
This comment has been minimized.
commented
Aug 15, 2025
Contributor
commented
Aug 15, 2025
Member
|
@bors r+ |
commented
Aug 15, 2025
Collaborator
bors
added
S-waiting-on-bors
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, when setting the thread stack size fails, it would be rounded up to the nearest multiple of the page size and the code asserts that the next call to
pthread_attr_setstacksizesucceeds.This may be true for glibc, but it isn't true for musl, which not only enforces a minimum stack size, but also a maximum stack size of
usize::MAX / 4 - PTHREAD_STACK_MIN1, triggering the assert rather than erroring gracefully.There isn't any way to handle this properly other than bailing out and letting the user know it didn't succeed.