Anyone who works on command line tools written in Swift will know that program crashes can be somewhat tricky to debug — in some cases a crashing program will simply terminate with no output to explain what went wrong. We know that this is a pain point for users both within and outside of Apple.
To those users: there is light at the end of the tunnel. We are actively working on providing first class backtraces when Swift programs crash, without requiring users to make use of any third-party libraries and in a way that will not interfere with any system-wide crash reporting framework. For those interested specifically in Swift on Server, an additional constraint we are placing on our implementation here is that it must work out of the box in a standard non-privileged Docker container, without needing to enable additional capabilities.
There will be further posts about this in due course, including a Swift Evolution proposal for APIs in the standard library that will provide programs with the ability to programmatically capture a backtrace when required.
This is awesome news! Goes without saying that it should support both ARM and x86_64 which is where the shortcomings with the current Backtrace library lie
This is awesome news! Obviously getting backtraces for crashing programs is the most important thing here, but I’m really excited about the standard library API too.
I’ve been working on a small error reporting library for the server usecase recently & this would provide very useful functionality. Something I’d really hope to see (if possible!) from a first-class Swift solution is stacktraces which cross async boundaries, so that useful stacktrace data doesn’t end at the most recent async call. That can be a problem with some more general backtrace tools.
Also would ask an open question: Would it make sense to consider the possible exposure of the Concurrency hooks and backtrace information together (I read "ability to programmatically capture a backtrace" as basically a 'live sample' of the application to introspect current execution state - the related link had a similar request to introspect current state for Tasks etc, perhaps there is some possible synergy in the design space for how to expose it (Runtime Introspection ?, just food for thought).
FWIW, I'm planning on having an API layer that can be used by applications to programmatically capture backtraces, in addition to having Swift generate them when your program crashes. See [Pitch] Swift Backtracing API for more on that.
I ask because I made a PR to swift-backtrace adding a nicer format with colors and all, but as the library is going to be deprecated in favor of "actual" backtraces in Swift itself, I was told to chime in here with my new format.
But if it's already planned to make it nice and pretty then it's great news and I don't have anything more to add :p
I think output from https://github.com/tuist/xcbeautify vs the standard swift test output could be good inspiration - one of the outputs is eminently more readable.
So you don't have to install, piping standard swift test through the tool gives:
- one of the outputs is eminently more readable.
