Skip to content

[Backtracing] Add an indication that we're working on a backtrace. #69775

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

Merged
merged 4 commits into from
Nov 13, 2023

Conversation

al45tair
Copy link
Contributor

When we crash, emit a message straight away that says we're working on a backtrace. If starting the backtracer fails, report that also.

Finally, add a duration to the messages output by the backtracer, so that we can see how long it took.

rdar://118055527

When we crash, emit a message straight away that says we're working
on a backtrace.  If starting the backtracer fails, report that also.

Finally, add a duration to the messages output by the backtracer, so
that we can see how long it took.

rdar://118055527
We shouldn't try to erase the message when in non-color mode; mostly
that's intended for redirected output scenarios anyway, and in that case
we don't really want garbage in the output.

Also, improve the failure messages when the backtracer itself goes
wrong or can't be executed.

Finally, change the behaviour slightly so that *if* we're explicitly
enabled, *and* the backtracer path wasn't explicitly specified, *and*
we can't find the backtracer, we print a warning on start-up.  We
don't do that in any other case because we don't want spurious warnings
everywhere.

rdar://118055527
Add tests for the new immediate on-crash message and the backtrace timing
message.

rdar://118055527
@al45tair al45tair added 🍒 release cherry pick Flag: Release branch cherry picks swift 5.10 labels Nov 10, 2023
@al45tair al45tair requested a review from a team as a code owner November 10, 2023 11:13
@al45tair
Copy link
Contributor Author

al45tair commented Nov 10, 2023

Explanation: Generating backtraces can take a significant amount of time, particularly for statically linked binaries on Linux, because it involves scanning through all of the debug information, which means parsing DWARF data, which is just slow. This is particularly problematic in Kubernetes, because pods often have health check timeouts set such that Kubernetes will kill the pod if it doesn't respond within a certain time; if a container crashes, it won't be responding to the health checks, and if the backtrace takes longer than the timeout, it'll be killed before it completes. Previously we output the entire backtrace at the end, so in that case you'd get no useful information about the crash. This PR changes things so that (a) we output the crash location itself straight-away along with a message indicating that we're backtracing, and (b) we say at the end how long it took, to give people something they can use to tell if their timeouts are close to the time it'll take to generate a trace.
Risk: Low. Backtracing is only active on Linux, by default, and this just adds two messages.
Original PR: #69697
Reviewed by: @mikeash
Resolves: rdar://118055527
Tests: Adds new tests for the two new messages.

@al45tair
Copy link
Contributor Author

@swift-ci Please test

@al45tair
Copy link
Contributor Author

@swift-ci Please test

Apparently I forgot to code sign the test binaries.

rdar://118055527
@al45tair al45tair force-pushed the eng/PR-118055527-5.10 branch from 75512a1 to e068482 Compare November 13, 2023 10:24
@al45tair
Copy link
Contributor Author

@swift-ci Please test

@al45tair al45tair merged commit 0079583 into swiftlang:release/5.10 Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍒 release cherry pick Flag: Release branch cherry picks swift 5.10
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants