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

Jump to bottom

[SR-1701] Fatal errors in foundation should report backtraces #4143

Open
phausler opened this issue Jun 7, 2016 · 4 comments
Open

[SR-1701] Fatal errors in foundation should report backtraces #4143

phausler opened this issue Jun 7, 2016 · 4 comments
Labels
bug Foundation StarterBug

Comments

@phausler
Copy link
Member

phausler commented Jun 7, 2016

Previous ID SR-1701
Radar None
Original Reporter @phausler
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Foundation
Labels Bug, StarterBug
Assignee None
Priority Medium

md5: ff5b9e13cf14794077788059c1f04d7d

Issue Description:

Most reasonable linux distributions have the function backtrace_symbols which can produce a sensible backtrace. It would be useful to emit failures with some call stack information (even if it was still mangled)

Likely this API would have to be added as a helper function in CoreFoundation due to it's funky syntax and requirements. But the call for this could encapsulate a fatal error and emit the debug information before terminating.
@ddunbar
Copy link
Member

ddunbar commented Jun 7, 2016

See SR-1700 for an example of where this would have been useful, particularly if we also include a little extra information in the fatalError().

@belkadan
Copy link

belkadan commented Jun 8, 2016

I think we really want backtraces everywhere. @gribozavr?

@phausler
Copy link
Member Author

phausler commented Jun 8, 2016

If at least for the Foundation assertions (we have a number of them) and perhaps if only in debug builds. This will aide in nailing down bugs versus expected behavior

@gribozavr
Copy link
Collaborator

We turn off backtraces in release builds because of security reasons. If the process has requested to stop, we should stop right away. We should not be trying to execute more code, which can increase the attack surface.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Foundation StarterBug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ddunbar @phausler @belkadan @gribozavr