3 ms·

That's very true. Do you think I should have written it differently? I might want to add a clause in the caveats section at the very least.

by hansihe 10y ago

Anderkent 10y ago
Nah, just nitpicking. Though I guess the point is that AFAIK there's no documentation for all the ways that safe rust code is allowed to segfault; the distinction between a in-rust panic is that a segfault would probably crash beam, whereas an in-rust panic might be recoverable?
- kibwen 10y ago
  > there's no documentation for all the ways that safe rust code is allowed to segfault I wouldn't say "allowed" to segfault. :P The behavior you're referring to is currently due to a deficiency in LLVM for non-Windows platforms. Here's the bug on the Rust repo tracking it: https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012 Its resolution is long-awaited, to say the least, but it requires someone proficient with LLVM to do the legwork... > an in-rust panic might be recoverable? Anytime you're writing an interface where code is going to be calling into Rust via C FFI, you ought to be using https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html , which is specifically intended to prevent panics from crossing FFI boundaries.
  - iopq 10y ago
    > This function only catches unwinding panics, not those that abort the process. How do you expect a stack overflow to unwind? I have difficulty imagining the implementation
    - kibwen 10y ago
      Anytime our guard pages detect a stack overflow, an abort is issued with no chance to unwind. (The segfault bug mentioned above is caused by crafting data on the stack such that you bypass the guard page, which would go from a segfault into an abort in the presence of stack probes.) I did not intend to imply that there was any chance that a stack overflow wouldn't bring down your process, only to clarify Rust's stance on the theoretical memory safety implications. :)
- steveklabnik 10y ago
  Safe code isn't allowed to segfault. As kibwen says, the ways this can happen currently are bugs. They'll be fixed.

That's very true. Do you think I should have written it differently? I might want to add a clause in the caveats section at the very least.

by hansihe 10y ago

That's very true. Do you think I should have written it differently? I might want to add a clause in the caveats section at the very least.

Anderkent 10y ago

Nah, just nitpicking. Though I guess the point is that AFAIK there's no documentation for all the ways that safe rust code is allowed to segfault; the distinction between a in-rust panic is that a segfault would probably crash beam, whereas an in-rust panic might be recoverable?

kibwen 10y ago
> there's no documentation for all the ways that safe rust code is allowed to segfault I wouldn't say "allowed" to segfault. :P The behavior you're referring to is currently due to a deficiency in LLVM for non-Windows platforms. Here's the bug on the Rust repo tracking it: https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012 Its resolution is long-awaited, to say the least, but it requires someone proficient with LLVM to do the legwork... > an in-rust panic might be recoverable? Anytime you're writing an interface where code is going to be calling into Rust via C FFI, you ought to be using https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html , which is specifically intended to prevent panics from crossing FFI boundaries.
- iopq 10y ago
  > This function only catches unwinding panics, not those that abort the process. How do you expect a stack overflow to unwind? I have difficulty imagining the implementation
  - kibwen 10y ago
    Anytime our guard pages detect a stack overflow, an abort is issued with no chance to unwind. (The segfault bug mentioned above is caused by crafting data on the stack such that you bypass the guard page, which would go from a segfault into an abort in the presence of stack probes.) I did not intend to imply that there was any chance that a stack overflow wouldn't bring down your process, only to clarify Rust's stance on the theoretical memory safety implications. :)
steveklabnik 10y ago
Safe code isn't allowed to segfault. As kibwen says, the ways this can happen currently are bugs. They'll be fixed.