3 ms·

I don't think that the lesson here is "exceptions are bad", the same kind of bug can be easily made without using exceptions.

by usrnm 2y ago

usrnm 2y ago
Another thing to note is that exactly the same bug can be made in Rust or go, both of which officially don't have exceptions. They both, of course, do have exceptions and just call them a different name.
- LegionMammal978 2y ago
  As it happens, Rust 1.81 recently added a feature where it aborts by default when you attempt to unwind from a function with the "C" ABI [0], which mitigates this issue for most FFI use cases. Of course, it's not uncommon to find unsafe Rust code that misbehaves badly when something panics, which is yet another of its hazards that I wish were better documented. In this case, I'd put down the lesson as "exceptions in C++ are very dangerous if you're coming out of C code", since they can cause undocumented and unexpected behavior that ultimately led to the use-after-return issue here. [0] https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#abort-on-uncaught-panics-in-extern-c-functions https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#abort...
  - ryao 2y ago
    What do you mean by "misbehaves badly when something panics"?
    - LegionMammal978 2y ago
      If some unsafe code gets interrupted by a panic when it's in an intermediate state (before it can clean something up, or make two values consistent), then further operations on that state can result in UB. See https://github.com/becheran/grid/issues/19 https://github.com/becheran/grid/issues/19, https://gitlab.com/tspiteri/rug/-/issues/47 https://gitlab.com/tspiteri/rug/-/issues/47, and https://gitlab.com/tspiteri/rug/-/issues/49 https://gitlab.com/tspiteri/rug/-/issues/49 for a few of the less-contrived issues I've filed. It can also result in logic errors if objects are used after their methods panic, but such usage is generally not expected to work in the first place.
- samatman 2y ago
  Exceptions aren't bad because of the name. Exceptions are bad because lower stack frames unwind higher ones, without giving those frames any opportunity to do something sane with any captured resources. Calling it panic/recover doesn't help anything.
IX-103 2y ago
I'm not so sure. The bug was that when an exception occurred while select was blocked then select did not properly clean up after itself. But no code in select actually dealt with exceptions at all, so handling it doesn't really make sense. Without exceptions the possible control flow is entirely explicit. It would have at least been obvious that cleanup wasn't properly handled in the select function for all cases.
- fc417fc802 2y ago
  > an exception occurred An exception was effectively injected from outside of the code via low level shenanigans. That's not "exceptions bad" that's "low level monkeying with program control flow can blow up in your face".

I don't think that the lesson here is "exceptions are bad", the same kind of bug can be easily made without using exceptions.

by usrnm 2y ago

I don't think that the lesson here is "exceptions are bad", the same kind of bug can be easily made without using exceptions.

usrnm 2y ago

Another thing to note is that exactly the same bug can be made in Rust or go, both of which officially don't have exceptions. They both, of course, do have exceptions and just call them a different name.

LegionMammal978 2y ago
As it happens, Rust 1.81 recently added a feature where it aborts by default when you attempt to unwind from a function with the "C" ABI [0], which mitigates this issue for most FFI use cases. Of course, it's not uncommon to find unsafe Rust code that misbehaves badly when something panics, which is yet another of its hazards that I wish were better documented. In this case, I'd put down the lesson as "exceptions in C++ are very dangerous if you're coming out of C code", since they can cause undocumented and unexpected behavior that ultimately led to the use-after-return issue here. [0] https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#abort-on-uncaught-panics-in-extern-c-functions https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#abort...
- ryao 2y ago
  What do you mean by "misbehaves badly when something panics"?
  - LegionMammal978 2y ago
    If some unsafe code gets interrupted by a panic when it's in an intermediate state (before it can clean something up, or make two values consistent), then further operations on that state can result in UB. See https://github.com/becheran/grid/issues/19 https://github.com/becheran/grid/issues/19, https://gitlab.com/tspiteri/rug/-/issues/47 https://gitlab.com/tspiteri/rug/-/issues/47, and https://gitlab.com/tspiteri/rug/-/issues/49 https://gitlab.com/tspiteri/rug/-/issues/49 for a few of the less-contrived issues I've filed. It can also result in logic errors if objects are used after their methods panic, but such usage is generally not expected to work in the first place.
samatman 2y ago
Exceptions aren't bad because of the name. Exceptions are bad because lower stack frames unwind higher ones, without giving those frames any opportunity to do something sane with any captured resources. Calling it panic/recover doesn't help anything.

IX-103 2y ago

I'm not so sure. The bug was that when an exception occurred while select was blocked then select did not properly clean up after itself. But no code in select actually dealt with exceptions at all, so handling it doesn't really make sense. Without exceptions the possible control flow is entirely explicit. It would have at least been obvious that cleanup wasn't properly handled in the select function for all cases.

fc417fc802 2y ago
> an exception occurred An exception was effectively injected from outside of the code via low level shenanigans. That's not "exceptions bad" that's "low level monkeying with program control flow can blow up in your face".