Skip to content
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

Use a range to identify SIGSEGV in stack guards #47912

Merged
merged 2 commits into from
Feb 5, 2018

Commits on Jan 31, 2018

  1. Configuration menu
    Copy the full SHA
    e2de8de View commit details
    Browse the repository at this point in the history
  2. Use a range to identify SIGSEGV in stack guards

    Previously, the `guard::init()` and `guard::current()` functions were
    returning a `usize` address representing the top of the stack guard,
    respectively for the main thread and for spawned threads.  The `SIGSEGV`
    handler on `unix` targets checked if a fault was within one page below
    that address, if so reporting it as a stack overflow.
    
    Now `unix` targets report a `Range<usize>` representing the guard
    memory, so it can cover arbitrary guard sizes.  Non-`unix` targets which
    always return `None` for guards now do so with `Option<!>`, so they
    don't pay any overhead.
    
    For `linux-gnu` in particular, the previous guard upper-bound was
    `stackaddr + guardsize`, as the protected memory was *inside* the stack.
    This was a glibc bug, and starting from 2.27 they are moving the guard
    *past* the end of the stack.  However, there's no simple way for us to
    know where the guard page actually lies, so now we declare it as the
    whole range of `stackaddr ± guardsize`, and any fault therein will be
    called a stack overflow.  This fixes rust-lang#47863.
    cuviper committed Jan 31, 2018
    Configuration menu
    Copy the full SHA
    55b54a9 View commit details
    Browse the repository at this point in the history