about summary refs log tree commit diff
path: root/src/liballoc_system
diff options
context:
space:
mode:
authorBrian Campbell <lambda@continuation.org>2016-01-31 18:30:32 -0500
committerBrian Campbell <lambda@continuation.org>2016-02-05 20:41:18 -0500
commitee79bfa18affe95959a5f9a036c17bbd77979e21 (patch)
tree3a34c04d7cddb6a79afad023a91050e250e1f565 /src/liballoc_system
parent303892ee156e5c31222b10786e661abb24dcf241 (diff)
downloadrust-ee79bfa18affe95959a5f9a036c17bbd77979e21.tar.gz
rust-ee79bfa18affe95959a5f9a036c17bbd77979e21.zip
Abort on stack overflow instead of re-raising SIGSEGV
We use guard pages that cause the process to abort to protect against
undefined behavior in the event of stack overflow.  We have a handler
that catches segfaults, prints out an error message if the segfault was
due to a stack overflow, then unregisters itself and returns to allow
the signal to be re-raised and kill the process.

This caused some confusion, as it was unexpected that safe code would be
able to cause a segfault, while it's easy to overflow the stack in safe
code.  To avoid this confusion, when we detect a segfault in the guard
page, abort instead of the previous behavior of re-raising the SIGSEGV.

To test this, we need to adapt the tests for segfault to actually check
the exit status.  Doing so revealed that the existing test for segfault
behavior was actually invalid; LLVM optimizes the explicit null pointer
reference down to an illegal instruction, so the program aborts with
SIGILL instead of SIGSEGV and the test didn't actually trigger the
signal handler at all.  Use a C helper function to get a null pointer
that LLVM can't optimize away, so we get our segfault instead.

This is a [breaking-change] if anyone is relying on the exact signal
raised to kill a process on stack overflow.

Closes #31273
Diffstat (limited to 'src/liballoc_system')
0 files changed, 0 insertions, 0 deletions