Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abort on panic #1570

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Abort on panic #1570

wants to merge 2 commits into from

Conversation

tmccombs
Copy link
Collaborator

@tmccombs tmccombs commented Jun 7, 2024

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.

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.
From documentation of the tikv-jemallocator project:

> The project is also published as jemallocator for historical reasons. The two crates are the same except names.
> For new projects, it's recommended to use tikv-xxx versions instead.
@sharkdp
Copy link
Owner

sharkdp commented Jun 8, 2024

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

@tavianator
Copy link
Collaborator

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

@sharkdp
Copy link
Owner

sharkdp commented Jun 8, 2024

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

@tmccombs
Copy link
Collaborator Author

tmccombs commented Jun 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants