Skip to content

[Runtime] Add an option to produce non-symbolicated backtraces. #71505

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

Closed
wants to merge 5 commits into from

Conversation

al45tair
Copy link
Contributor

@al45tair al45tair commented Feb 9, 2024

Symbolication can take some time, depending on the binaries involved. In certain contexts it's better for the backtrace to finish quickly, and then symbolication could be done offline.

rdar://122302117

Symbolication can take some time, depending on the binaries involved.
In certain contexts it's better for the backtrace to finish quickly,
and then symbolication could be done offline.

rdar://122302117
Document the new `symbolicate` setting.

rdar://122302117
Rather than just on or off, I've changed it to allow "off", "fast",
or "full".  "fast" means that we'll do symbol lookup, but we won't
try to find inline frames and we won't run line number programs
(those are the things that are taking considerable time in some
cases).

rdar://122302117
@al45tair al45tair requested a review from a team as a code owner February 9, 2024 10:03
@al45tair
Copy link
Contributor Author

al45tair commented Feb 9, 2024

@swift-ci Please test

@al45tair
Copy link
Contributor Author

Explanation: When deploying statically linked programs in Kubernetes, it's better if a crashing program terminates quickly so that Kubernetes restarts the affected pod(s). In some cases, scanning the DWARF data for inline frames and processing line number programs is taking over a minute, which is undesirable in this environment. This PR adds an option to disable symbolication completely, or to just disable inline frame and line number processing (symbol lookup itself is quick).
Risk: Low. Only affects Linux (on Darwin we use Core Symbolication for this).
Original PR: #71386
Reviewed by: @mikeash
Resolves: rdar://122302117
Tests: We don't have explicit tests for this problem at present.

@al45tair
Copy link
Contributor Author

@swift-ci Please test macOS platform

@al45tair
Copy link
Contributor Author

The failing tests are existing, known problems, where the test has been disabled in 5.10 and later. #71609 is a PR to disable them on release/5.9 also.

This failure is being caused by a change in behaviour from libdispatch,
and is not reflective of a Swift bug.  See rdar://112865148.
This is the problem mentioned in swiftlang#70759 (or a variant thereof);
apparently macOS gives warnings when Linux is giving errors.
@al45tair
Copy link
Contributor Author

I've cherry-picked the changes from that PR here, so we could just merge this one once testing is complete.

@al45tair
Copy link
Contributor Author

@swift-ci Please test

@al45tair
Copy link
Contributor Author

@swift-ci Please test macOS platform

@al45tair
Copy link
Contributor Author

al45tair commented Feb 16, 2024

The macOS failure here is nothing to do with this PR; seems like a configuration issue — /private/var versus /var?

using db: /var/folders/bb/hcrjxg1s0b96pfst0ymhmp240000gn/T/lit-tmp-ee5nro1o/build-eb0286.db
/Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-release/5.9/llbuild/unittests/Core/SQLiteBuildDBTest.cpp:53: Failure
Expected equality of these values:
  error
    Which is: "error: accessing build database \"/private/var/folders/bb/hcrjxg1s0b96pfst0ymhmp240000gn/T/lit-tmp-ee5nro1o/build-eb0286.db\": database is locked Possibly there are two concurrent builds running in the same filesystem location."
  out.str()
    Which is: "error: accessing build database \"/var/folders/bb/hcrjxg1s0b96pfst0ymhmp240000gn/T/lit-tmp-ee5nro1o/build-eb0286.db\": database is locked Possibly there are two concurrent builds running in the same filesystem location."

/Users/ec2-user/jenkins/workspace/swift-PR-macos/branch-release/5.9/llbuild/unittests/Core/SQLiteBuildDBTest.cpp:53
Expected equality of these values:
  error
    Which is: "error: accessing build database \"/private/var/folders/bb/hcrjxg1s0b96pfst0ymhmp240000gn/T/lit-tmp-ee5nro1o/build-eb0286.db\": database is locked Possibly there are two concurrent builds running in the same filesystem location."
  out.str()
    Which is: "error: accessing build database \"/var/folders/bb/hcrjxg1s0b96pfst0ymhmp240000gn/T/lit-tmp-ee5nro1o/build-eb0286.db\": database is locked Possibly there are two concurrent builds running in the same filesystem location."

@al45tair
Copy link
Contributor Author

@swift-ci Please smoke test macOS platform

@al45tair
Copy link
Contributor Author

@swift-ci Please test macOS platform

@al45tair
Copy link
Contributor Author

We didn't do another 5.9 release, so closing this.

@al45tair al45tair closed this Apr 22, 2024
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.

2 participants