4 ms·

https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unrecoverable-errors-with-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable

https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-with-panic.html#unrecoverable-errors-with-panic https://doc.rust-lang.org/book/ch09-01-unrecoverable-errors-... ``` [profile.release] panic = 'abort' ```

rcxdude 2y ago
that just makes the panics unrecoverable. It doesn't statically guarantee no panics.
- lmm 2y ago
  It presumably avoids the linked in 300Kb that was supposedly part of the motivation for doing this though?
- wongarsu 2y ago
  There is no-panic [1] to turn panics in a function into compile errors, or the older no-panics-whatsoever [2] to do the same for the entire binary 1: https://crates.io/crates/no-panic https://crates.io/crates/no-panic 2: https://crates.io/crates/no-panics-whatsoever https://crates.io/crates/no-panics-whatsoever
  - themulticaster 2y ago
    no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)
surajrmal 2y ago
After using rust for several years, I'm shocked this isn't the default. Making panics recoverable leads to them being used incorrectly.
- exDM69 2y ago
  Panics also unwind the stack and run all your Drop destructors. Setting `panic = abort` disables unwinding and this means leaking memory, not closing file descriptors, not unlocking mutexes and not rolling back database transactions on panic. It's fine for some applications to leave this to the operating system on process exit but I would argue that the default unwinding behavior is better for typical userspace applications.
  - ninkendo 2y ago
    All the things you describe are done automatically on program exit, even if the program is SIGKILL’ed. The kernel cleans up file descriptors, database transactions are rolled back automatically when the client disconnects (which it should be observed to be when the program exits and the kernel closes the connection as part of cleanup), and I’m not sure what you mean about mutexes, but if you mean in-memory ones, those don’t matter because the program is gone (if you mean like, file-based ones, those also should be implicitly unlocked by the kernel when the program exits, at least that’s how a good implementation is supposed to work, e.g. by writing the pid to the file or something.) The whole of modern operating systems are already very familiar with the idea of programs not being able to exit gracefully, and there’s already a well understood category of things that happen automatically even if your program crashes ungracefully. Whole systems are designed around this (databases issuing rollbacks when the client disconnects, being a perfect example.) The best thing to do is embrace this and never, ever rely on a Drop trait being executed for correctness. Always assume you could be SIGKILLed at any time (which you always can. Someone can issue a kill -9, or you could get OOM killed, etc.)
    - exDM69 2y ago
      I'm well aware of this and good that the option exists to bail out with abort instead. But there are still cases where you would like to fsync your mmaps, print out a warning message or just make sure your #[should_panic] negative tests don't trigger false positives in your tooling (like leak detectors or GPU validators) or abort the whole test run. It's not perfect by any means but it's better than potentially corrupting your data when a trivial assert fires or making negative tests spew warnings in ci runs. It's very easy to opt out from, and I don't consider the price of panic handlers and unwinding very expensive for most use cases.

rcxdude 2y ago

that just makes the panics unrecoverable. It doesn't statically guarantee no panics.

lmm 2y ago
It presumably avoids the linked in 300Kb that was supposedly part of the motivation for doing this though?
wongarsu 2y ago
There is no-panic [1] to turn panics in a function into compile errors, or the older no-panics-whatsoever [2] to do the same for the entire binary 1: https://crates.io/crates/no-panic https://crates.io/crates/no-panic 2: https://crates.io/crates/no-panics-whatsoever https://crates.io/crates/no-panics-whatsoever
- themulticaster 2y ago
  no-panic uses link-time shenanigans to prevent panics in the compiled binary, but this isn't 100% reliable (as explained in the README, just pointing this out)

surajrmal 2y ago

After using rust for several years, I'm shocked this isn't the default. Making panics recoverable leads to them being used incorrectly.

exDM69 2y ago
Panics also unwind the stack and run all your Drop destructors. Setting `panic = abort` disables unwinding and this means leaking memory, not closing file descriptors, not unlocking mutexes and not rolling back database transactions on panic. It's fine for some applications to leave this to the operating system on process exit but I would argue that the default unwinding behavior is better for typical userspace applications.
- ninkendo 2y ago
  All the things you describe are done automatically on program exit, even if the program is SIGKILL’ed. The kernel cleans up file descriptors, database transactions are rolled back automatically when the client disconnects (which it should be observed to be when the program exits and the kernel closes the connection as part of cleanup), and I’m not sure what you mean about mutexes, but if you mean in-memory ones, those don’t matter because the program is gone (if you mean like, file-based ones, those also should be implicitly unlocked by the kernel when the program exits, at least that’s how a good implementation is supposed to work, e.g. by writing the pid to the file or something.) The whole of modern operating systems are already very familiar with the idea of programs not being able to exit gracefully, and there’s already a well understood category of things that happen automatically even if your program crashes ungracefully. Whole systems are designed around this (databases issuing rollbacks when the client disconnects, being a perfect example.) The best thing to do is embrace this and never, ever rely on a Drop trait being executed for correctness. Always assume you could be SIGKILLed at any time (which you always can. Someone can issue a kill -9, or you could get OOM killed, etc.)
  - exDM69 2y ago
    I'm well aware of this and good that the option exists to bail out with abort instead. But there are still cases where you would like to fsync your mmaps, print out a warning message or just make sure your #[should_panic] negative tests don't trigger false positives in your tooling (like leak detectors or GPU validators) or abort the whole test run. It's not perfect by any means but it's better than potentially corrupting your data when a trivial assert fires or making negative tests spew warnings in ci runs. It's very easy to opt out from, and I don't consider the price of panic handlers and unwinding very expensive for most use cases.