-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
libgreen's stack_bounds implementation includes the guard page #12897
Comments
It needs a guard page, because it's the only thing stopping a stack overflow in C code called by Rust. The guard page will allow removing |
Yes, obviously the guard page is needed. The question is should we report the guard page in the stack bounds. I think not, since obviously you aren't supposed to use that memory. |
Yeah, that makes sense. |
This is mostly just an implementation detail, and anyone worried about the stack bounds doesn't need to be bothered with the red zone because it's not usable anyway. Closes #12897
Update to Chalk 88 This Chalk release introduces fuel for the recursive solver ([chalk#774](rust-lang/chalk#774)). I'm not sure how often it calls `should_continue` compared to the other solver, so we might want to increase `CHALK_SOLVER_FUEL`, the current default value of 100 might be too low. This should fix a lot of hangs and crashes, for example this solves the hang in rust-lang#12897.
…ult, r=dswij Lint `manual_unwrap_or_default` for Result as well This PR is modifying the `manual_unwrap_or_default` to be applied/linted for `Result`s as well. It is part of the fixes desired by rust-lang/rust-clippy#12618 changelog:[`manual_unwrap_or_default`]: Lint for Result types.
rust-mozjs uses the stack bounds to inform SpiderMonkey's conservative stack scanner, but it started segfaulting on the guard page after the most recent upgrade. Does it really make sense to include this page, or should we add some kind of usable_stack_bounds method?
The text was updated successfully, but these errors were encountered: