Abort on panic

[tmccombs]

This should help both runtime performance and side of the executable.

And I can't think of a reason why we would need unwinding on panic in
release builds.

[sharkdp]

Wouldn't this make bug reports harder to debug, or can we still get stacktraces?

[tavianator]

panic=abort still gives a backtrace, you just can't catch_unwind()

[sharkdp]

Ok, in this case I'm fine with the change. Thank you

[tmccombs]

hmmm, actually it does look like the stack trace is less useful if panic=abort. It shows you where the panic happened, but not.

I added a panic to output.rs and ran with panic=abort and with panic=unwind.

RUST_BACKTRACE=1:

with panic=abort:

thread '<unnamed>' panicked at src/output.rs:131:5:
test
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
zsh: IOT instruction (core dumped)  RUST_BACKTRACE=1 ./fd-abort

with panic=unwind:

thread '<unnamed>' panicked at src/output.rs:131:5:
test
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
CHANGELOG.md
thread 'main' panicked at src/walk.rs:650:29:
called `Result::unwrap()` on an `Err` value: Any { .. }
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Also note that it looks like with "unwind" it flushes stdout before exiting, but with abort it doesn't. I'm not sure how much we care about that.

RUST_BACKTRACE=full

with panic=abort:

thread '<unnamed>' panicked at src/output.rs:131:5:
test
stack backtrace:
   0:     0x5a24936887b1 - <unknown>
   1:     0x5a249358796c - <unknown>
   2:     0x5a24936531be - <unknown>
   3:     0x5a2493689fdf - <unknown>
   4:     0x5a24936898db - <unknown>
   5:     0x5a249368a846 - <unknown>
   6:     0x5a249368a318 - <unknown>
   7:     0x5a249368a2a6 - <unknown>
   8:     0x5a249368a293 - <unknown>
   9:     0x5a2493485934 - <unknown>
  10:     0x5a24934d6bdd - <unknown>
  11:     0x5a24934d705c - <unknown>
  12:     0x5a24934d7f8e - <unknown>
  13:     0x5a24934b9537 - <unknown>
  14:     0x5a24934be150 - <unknown>
  15:     0x5a249368bdb5 - <unknown>
  16:     0x75d2d4971ded - <unknown>
  17:     0x75d2d49f50dc - <unknown>
  18:                0x0 - <unknown>
zsh: IOT instruction (core dumped)  RUST_BACKTRACE=full ./fd-abort

with panic=unwind:

thread '<unnamed>' panicked at src/output.rs:131:5:
test
stack backtrace:
   0:     0x5951b2c9d4d1 - <unknown>
   1:     0x5951b2b9b46c - <unknown>
   2:     0x5951b2c68e8e - <unknown>
   3:     0x5951b2c9ee5f - <unknown>
   4:     0x5951b2c9e75b - <unknown>
   5:     0x5951b2c9f6e4 - <unknown>
   6:     0x5951b2c9f198 - <unknown>
   7:     0x5951b2c9f126 - <unknown>
   8:     0x5951b2c9f113 - <unknown>
   9:     0x5951b2a72fb4 - <unknown>
  10:     0x5951b2ace581 - <unknown>
  11:     0x5951b2aceb34 - <unknown>
  12:     0x5951b2acfa4f - <unknown>
  13:     0x5951b2aad6cb - <unknown>
  14:     0x5951b2ab06f2 - <unknown>
  15:     0x5951b2ca0c85 - <unknown>
  16:     0x71c7e2c5bded - <unknown>
  17:     0x71c7e2cdf0dc - <unknown>
  18:                0x0 - <unknown>
CHANGELOG.md
thread 'main' panicked at src/walk.rs:650:29:
called `Result::unwrap()` on an `Err` value: Any { .. }
stack backtrace:
   0:     0x5951b2c9d4d1 - <unknown>
   1:     0x5951b2b9b46c - <unknown>
   2:     0x5951b2c68e8e - <unknown>
   3:     0x5951b2c9ee5f - <unknown>
   4:     0x5951b2c9e75b - <unknown>
   5:     0x5951b2c9f6e4 - <unknown>
   6:     0x5951b2c9f1d0 - <unknown>
   7:     0x5951b2c9f126 - <unknown>
   8:     0x5951b2c9f113 - <unknown>
   9:     0x5951b2a72fb4 - <unknown>
  10:     0x5951b2a73392 - <unknown>
  11:     0x5951b2ad7ea2 - <unknown>
  12:     0x5951b2ad9ab5 - <unknown>
  13:     0x5951b2add6b5 - <unknown>
  14:     0x5951b2aab1a3 - <unknown>
  15:     0x5951b2affe31 - <unknown>
  16:     0x71c7e2beec88 - <unknown>
  17:     0x71c7e2beed4c - __libc_start_main
  18:     0x5951b2a8a215 - <unknown>
  19:                0x0 - <unknown>

Notice that with panic=abort, it does include the location of the actual panic, but not frames higher in the stack.

So the question is, is it worth the cost in performance to have better stack traces from panics in release builds.

I'm inclined to think that we see panics rarely enough, that it may be worth using abort in release builds, and if someone encounters a panic have them run with a debug build with panic=unwind to get a better stacktrace.