std: thread: Return error if setting thread stack size fails #144210
+12
−1
Conversation
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
|
r? @ibraheemdev rustbot has assigned @ibraheemdev. Use |
rustbot
added
O-unix
bjorn3
reviewed
Jul 21, 2025
|
CI failure is unrelated and spurious, could you perhaps retry it? |
Gelbpunkt
force-pushed
the
thread-stack-size-musl
branch
from
8e5114a to
e143986
Compare
|
Rebased to squash the fixup and re-trigger CI. |
|
Two weeks passed, I guess I'll re-roll reviewers. r? libs |
|
@bors r+ Tagging as release notes as this is something that may be worth calling out. |
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
bors
removed
the
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
|
💔 Test for 63955d1 failed: CI. Failed jobs:
|
This comment has been minimized.
This comment has been minimized.
|
Failed in rollup: #145285 (comment) @bors r- |
bors
added
S-waiting-on-author
|
See also #145299, which aims to make the relevant test insensitive to thread scheduling. |
|
I don't really see how that fail would be related at all, this PR only changes an assert to an error. The test doesn't rely on this assert, so I assume it was already broken before? |
|
I thought it might have been flaky too, but it failed twice in rollup, and then failed again with just this PR. 🤷♂️ I agree that the test is probably broken. Maybe this change is unlucky enough to perturb codegen in a way that happens to trigger the pre-existing problem. |
|
Might as well do another try job to see if we can catch the test being flaky instead of just failing: @bors try jobs=x86_64-gnu-aux |
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.
|
💔 Test for 5266eb8 failed: CI. Failed jobs:
|
joboet
reviewed
Aug 12, 2025
|
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 <[email protected]>
Gelbpunkt
force-pushed
the
thread-stack-size-musl
branch
from
25fe461 to
5d01d90
Compare
|
Rebased to include the fix for the failing test and to address the feedback from @joboet |
|
oops, forgot to: @rustbot ready |
rustbot
added
S-waiting-on-review
|
@bors try jobs=x86_64-gnu-aux |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Aug 15, 2025
std: thread: Return error if setting thread stack size fails try-job: x86_64-gnu-aux
|
@bors r+ |
bors
added
S-waiting-on-bors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.