7 ms·

From the article: > The Rust program got a segmentation fault because it attempted to write to inaccessible memory, but only through the stack pointer. None of

by Annatar 11y ago

From the article: > The Rust program got a segmentation fault because it attempted to write to inaccessible memory, but only through the stack pointer. None of the undefined behaviors disallow this, which I think is why it’s ok for this Rust program to segfault. What I got out of that is that Rust does not work as advertised if there are still situations where a program could segfault. The entire premise of Rust, as I understood it at least, is that it does things in a safe manner and the programmer does not have to worry about it. Now I learned that there are undefined behaviors. In my view, for a language that bills itself as safe, there should not exist such things as undefined behaviors. As far as I am concerned, then, based on the advertising of Rust, this is false advertising.

wofo 11y ago
Of course there are cases in which you can get segfaults, and not only in Rust. The single fact of having a C FFI is enough to break all safety guarantees of your language. What Rust does promise is that undefined behavior will never happen if you don't use code blocks marked as unsafe (which include the C FFI). In other words, if you are able to trigger undefined behavior without using unsafe code, that is a compiler or library bug. EDIT: as noted by steveklabnik, this is not undefined behavior. Actually you should get a better error message instead of a segmentation fault (see the link to the issue on GitHub in steveklabnik's comment).
- Ono-Sendai 11y ago
  And if you read the article, that is the case. You can get crashes without using blocks marked as unsafe.
  - wofo 11y ago
    I am not denying that. In fact, there is a GitHub issue intended to solve this (https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012).
- jws 11y ago
  What does Rust promise if I infinitely recursively call a function which can not be tail optimized? Eventually the stack will exceed either available memory or available address space, what then?
  - wofo 11y ago
    IIRC Rust will then abort the process with a SIGILL and display a generic error message.
  - kibwen 11y ago
    This is easy to test with a program consisting of `fn main() { main() }`: https://play.rust-lang.org/ https://play.rust-lang.org/ In release mode LLVM seems to be optimizing out the entire program due to dead-code elimination (or maybe sibling-call elimination?), but in debug this is what you get: <anon>:1:1: 3:2 warning: function cannot return without recurring, #[warn(unconditional_recursion)] on by default <anon>:1 fn main() { <anon>:2 main() <anon>:3 } <anon>:2:5: 2:11 note: recursive call site <anon>:2 main() ^~~~~~ <anon>:1:1: 3:2 help: a `loop` may express intention better if this is on purpose thread '<main>' has overflowed its stack fatal runtime error: stack overflow playpen: application terminated abnormally with signal 4 (Illegal instruction) Even though Rust doesn't guarantee stack probes on any OS but Windows at the moment (LLVM patches pending), Rust does guarantee guard pages on all platforms (AFAIK), and assuming that a function's stack frame is always less than a page (which I think should be true), then Rust does indeed seem to guarantee that such an overflow will raise SIGILL.
    - dbaupp 11y ago
      I don't think that example is directly relevant: it's tail recursive, and the code still compiles (so there's still runtime behaviour to consider). Additionally, the warning is emitted in both release and debug modes, but only covers "obvious" cases of infinite recursion: it won't say anything about functions that could recur deeply, or infinite recursion that is tricky to prove is infinite. In any case, the Rust language, when it gets guarantees (i.e. a spec), will at the very least guarantee that stack overflow doesn't result in memory corruption, it may not be too opinionated on how exactly implementations make this guarantee. As you say, the rustc compiler currently handles it by guard pages and aborting but not perfectly (it's not hard to have a large stack frame: `let x = [0; 10000]`).
steveklabnik 11y ago
It's not false advertising; it's a bug. Rust is not perfect. It's also not undefined behavior. https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012 (Basically, stack probes are only implemented on Windows, and we need them on the other platforms, but it hasn't been implemented yet, for various reasons.)
- Annatar 11y ago
  Okay, but such a bug means Rust is not ready for prime time yet, so this situation then ends up being the case of don't believe the hype.
  - steveklabnik 11y ago
    All software has bugs. Of course, you can certainly decide the severity of each bug for your use-case, but you can find stuff that's just as nasty on any compiler's issue tracker.
  - wofo 11y ago
    I think steveklabnik is right. For instance, take a look at this Java bug, which is relatively recent: https://bugs.openjdk.java.net/browse/JDK-8046516 https://bugs.openjdk.java.net/browse/JDK-8046516 On the same grounds you could label Java as a language "not ready for prime time yet".
    - Annatar 11y ago
      From a perspective of an assembler, C, shell, and AWK programmer, Java has never been, nor will it ever be ready for anything. We use it at work (we run thousands of Java applications, written externally and in house), and it is a total piece of shit: 300 GB of RAM consumption on the average(!!!), CPU intensive, slow, not backwards compatible (try changing the Java runtime environment under an application and see how well that works for you). From my experience and point of view, Java is overcomplicated and unintuitive, even for the simplest of tasks. Furthermore, I deeply regret that Java was one of my core computer science courses at the university (way back when Java was all the rage). Personally, I would rather drop dead than use Java, and if they tried to force me to write code in it again, I would quit on the spot! If I had it my way, Java would be a criminal offense carrying a minimum prison sentence of at least 20 years, and if I ever have my own company and I catch someone using Java, I will fire them on the spot with so much gusto! It will be so awesome.
kalmar 11y ago
> In my view, for a language that bills itself as safe, there should not exist such things as undefined behaviors. As far as I am concerned, then, based on the advertising of Rust, this is false advertising. The key thing from the reference [0]: > "Type checking provides the guarantee that these issues are never caused by safe code." It's subtle, but I think the situation is that "some segfaults are caused by undefined behaviour, and some undefined behaviour causes segfaults". Neither fully contains the other. One thing I was trying to get across is that a segmentation fault has a very specific meaning, and that meaning is not "bad thing was done with pointers". [0]: http://doc.rust-lang.org/reference.html#behavior-considered-undefined http://doc.rust-lang.org/reference.html#behavior-considered-...
tatterdemalion 11y ago
It would be better if everyone would refrain from making comments like this about any project ever. You have made an inflammatory, unnuanced, and ill-informed interpretation of a complicated issue and used it to publicly thrash a lot of people's hard works. You are lowering the discourse. I know that Rust in particular tries to be very open about the caveats to its claims, but this is the kind of commentary that causes any ambitious project to try to minimize and hide its weaknesses instead of openly and honestly discussing them. I opened this discussion knowing that there would be a comment just like yours, and it made my heart feel heavy.
- Annatar 11y ago
  > It would be better if everyone would refrain from making comments like this about any project ever. You have made an inflammatory, unnuanced, and ill-informed interpretation of a complicated issue and used it to publicly thrash a lot of people's hard works. Something as core as proper stack handling is to me basic functionality. If the aim is to be a safe language, and there are undefined behaviors, or in this case such bugs, then this is at odds with the Rust public relations effort. And, any project which resents such technical / conceptual criticism leaves one with much to ponder.
  - Manishearth 11y ago
    > Something as core as proper stack handling is to me basic functionality. rustc handles it just as much as other compilers do. It should be safer than that, but it's currently not due to a compiler bug, and features making it safer are not "basic stack handling". This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. This is a deterministic crash that can't be exploited easily. > And, any project which resents such technical / conceptual criticism leaves one with much to ponder. No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is.
    - Annatar 11y ago
      > This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. I wrote: "and there are undefined behaviors, or in this case such bugs". "Whoever can read is clearly at an advantage". > No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is. I'll tell you what: if I had deployed Rust in production and I ran into crap like the article described, I'd be really pissed.

by Annatar 11y ago

wofo 11y ago

Of course there are cases in which you can get segfaults, and not only in Rust. The single fact of having a C FFI is enough to break all safety guarantees of your language. What Rust does promise is that undefined behavior will never happen if you don't use code blocks marked as unsafe (which include the C FFI). In other words, if you are able to trigger undefined behavior without using unsafe code, that is a compiler or library bug. EDIT: as noted by steveklabnik, this is not undefined behavior. Actually you should get a better error message instead of a segmentation fault (see the link to the issue on GitHub in steveklabnik's comment).

Ono-Sendai 11y ago
And if you read the article, that is the case. You can get crashes without using blocks marked as unsafe.
- wofo 11y ago
  I am not denying that. In fact, there is a GitHub issue intended to solve this (https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012).
jws 11y ago
What does Rust promise if I infinitely recursively call a function which can not be tail optimized? Eventually the stack will exceed either available memory or available address space, what then?
- wofo 11y ago
  IIRC Rust will then abort the process with a SIGILL and display a generic error message.
- kibwen 11y ago
  This is easy to test with a program consisting of `fn main() { main() }`: https://play.rust-lang.org/ https://play.rust-lang.org/ In release mode LLVM seems to be optimizing out the entire program due to dead-code elimination (or maybe sibling-call elimination?), but in debug this is what you get: <anon>:1:1: 3:2 warning: function cannot return without recurring, #[warn(unconditional_recursion)] on by default <anon>:1 fn main() { <anon>:2 main() <anon>:3 } <anon>:2:5: 2:11 note: recursive call site <anon>:2 main() ^~~~~~ <anon>:1:1: 3:2 help: a `loop` may express intention better if this is on purpose thread '<main>' has overflowed its stack fatal runtime error: stack overflow playpen: application terminated abnormally with signal 4 (Illegal instruction) Even though Rust doesn't guarantee stack probes on any OS but Windows at the moment (LLVM patches pending), Rust does guarantee guard pages on all platforms (AFAIK), and assuming that a function's stack frame is always less than a page (which I think should be true), then Rust does indeed seem to guarantee that such an overflow will raise SIGILL.
  - dbaupp 11y ago
    I don't think that example is directly relevant: it's tail recursive, and the code still compiles (so there's still runtime behaviour to consider). Additionally, the warning is emitted in both release and debug modes, but only covers "obvious" cases of infinite recursion: it won't say anything about functions that could recur deeply, or infinite recursion that is tricky to prove is infinite. In any case, the Rust language, when it gets guarantees (i.e. a spec), will at the very least guarantee that stack overflow doesn't result in memory corruption, it may not be too opinionated on how exactly implementations make this guarantee. As you say, the rustc compiler currently handles it by guard pages and aborting but not perfectly (it's not hard to have a large stack frame: `let x = [0; 10000]`).

steveklabnik 11y ago

It's not false advertising; it's a bug. Rust is not perfect. It's also not undefined behavior. https://github.com/rust-lang/rust/issues/16012 https://github.com/rust-lang/rust/issues/16012 (Basically, stack probes are only implemented on Windows, and we need them on the other platforms, but it hasn't been implemented yet, for various reasons.)

Annatar 11y ago
Okay, but such a bug means Rust is not ready for prime time yet, so this situation then ends up being the case of don't believe the hype.
- steveklabnik 11y ago
  All software has bugs. Of course, you can certainly decide the severity of each bug for your use-case, but you can find stuff that's just as nasty on any compiler's issue tracker.
- wofo 11y ago
  I think steveklabnik is right. For instance, take a look at this Java bug, which is relatively recent: https://bugs.openjdk.java.net/browse/JDK-8046516 https://bugs.openjdk.java.net/browse/JDK-8046516 On the same grounds you could label Java as a language "not ready for prime time yet".
  - Annatar 11y ago
    From a perspective of an assembler, C, shell, and AWK programmer, Java has never been, nor will it ever be ready for anything. We use it at work (we run thousands of Java applications, written externally and in house), and it is a total piece of shit: 300 GB of RAM consumption on the average(!!!), CPU intensive, slow, not backwards compatible (try changing the Java runtime environment under an application and see how well that works for you). From my experience and point of view, Java is overcomplicated and unintuitive, even for the simplest of tasks. Furthermore, I deeply regret that Java was one of my core computer science courses at the university (way back when Java was all the rage). Personally, I would rather drop dead than use Java, and if they tried to force me to write code in it again, I would quit on the spot! If I had it my way, Java would be a criminal offense carrying a minimum prison sentence of at least 20 years, and if I ever have my own company and I catch someone using Java, I will fire them on the spot with so much gusto! It will be so awesome.

kalmar 11y ago

> In my view, for a language that bills itself as safe, there should not exist such things as undefined behaviors. As far as I am concerned, then, based on the advertising of Rust, this is false advertising. The key thing from the reference [0]: > "Type checking provides the guarantee that these issues are never caused by safe code." It's subtle, but I think the situation is that "some segfaults are caused by undefined behaviour, and some undefined behaviour causes segfaults". Neither fully contains the other. One thing I was trying to get across is that a segmentation fault has a very specific meaning, and that meaning is not "bad thing was done with pointers". [0]: http://doc.rust-lang.org/reference.html#behavior-considered-undefined http://doc.rust-lang.org/reference.html#behavior-considered-...

tatterdemalion 11y ago

It would be better if everyone would refrain from making comments like this about any project ever. You have made an inflammatory, unnuanced, and ill-informed interpretation of a complicated issue and used it to publicly thrash a lot of people's hard works. You are lowering the discourse. I know that Rust in particular tries to be very open about the caveats to its claims, but this is the kind of commentary that causes any ambitious project to try to minimize and hide its weaknesses instead of openly and honestly discussing them. I opened this discussion knowing that there would be a comment just like yours, and it made my heart feel heavy.

Annatar 11y ago
> It would be better if everyone would refrain from making comments like this about any project ever. You have made an inflammatory, unnuanced, and ill-informed interpretation of a complicated issue and used it to publicly thrash a lot of people's hard works. Something as core as proper stack handling is to me basic functionality. If the aim is to be a safe language, and there are undefined behaviors, or in this case such bugs, then this is at odds with the Rust public relations effort. And, any project which resents such technical / conceptual criticism leaves one with much to ponder.
- Manishearth 11y ago
  > Something as core as proper stack handling is to me basic functionality. rustc handles it just as much as other compilers do. It should be safer than that, but it's currently not due to a compiler bug, and features making it safer are not "basic stack handling". This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. This is a deterministic crash that can't be exploited easily. > And, any project which resents such technical / conceptual criticism leaves one with much to ponder. No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is.
  - Annatar 11y ago
    > This is not undefined behavior, as has been said multiple times in this thread; please stop repeating this lie. I wrote: "and there are undefined behaviors, or in this case such bugs". "Whoever can read is clearly at an advantage". > No, their comment said "inflammatory/unnuanced/ill-informed criticism". Which yours is. I'll tell you what: if I had deployed Rust in production and I ran into crap like the article described, I'd be really pissed.