Rer Mkv Converter 3 7 6 0419
Chiquita Palafox
Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager by email. When emailing the review manager directly, please include "SE-0419" in the subject line.
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
Address is deliberately opaque, and generally used as any Address. I presume that this is so that backtraces can be portable between platforms (eg. in a distributed actors scenario?), and that (possibly even within a single backtrace?), addresses might vary in their details. Yet Image returns values as some Address, meaning that there can only be a single Address type valid for Image on any given platform. Why are addresses designed for portability, but images aren't? To me it would make sense if Image was generic on Address, for example, but then you'd probably have to make bits of Backtrace generic on Address, and make explicit ranges of frames with different address types? Or maybe Image just needs to return any Address?
Address is designed to be convertible to & from an integer type, but deliberately avoids telling you statically which integer type it's convertible to. This means that everybody who wants to interact numerically with any Address has to do a big switch address.bitWidth and support all the known integral types, as well as have a fallback when none of the known integral types work. Would it not be better to have Address have an associatedtype IntegerRepresentation: BinaryInteger or whatever, and allow the existential to be opened to process the value as an integer? It seems like it would allow for much more concise and reliable code for the consumer. You could still leave the bitWidth in place to allow both options.
I don't love exposing UUID as [UInt8]. Seems like a good sign that UUID should move from Foundation to the stdlib? Or the stdlib could get its own GUID type to avoid the problem... either way, a fixed-size struct, some utility functions to convert to strings in standard formats, etc. would be very welcome.
SharedCacheInfo seems very specific to Apple OSes, and maybe it should be named as such? And why is it both optional, and contains a boolean property to say whether it's present? Surely it can always return nil if absent?
It would be immensely useful to allow initializing an instance of Backtrace from arbitrary sequences of addresses (subject to whatever reasonable constraints might apply, of course.) swift-testing currently needs to capture backtraces and we'd like to take advantage of the symbolication work here, but the backtraces in question may not come from Backtrace.capture().
First, it is often necessary to forge an Address and capture a backtrace from that. This is the case if capturing a backtrace in, say, another thread. This might tie into @grynspan's comments where you can import your own backtrace into Swift's API and have it operate on it as if it were native.
One general question I have is how this plans to fare for "strange" backtraces. What happens when calling through JIT-compiled code, or when frame pointers are not available? Do we consider use of this library undefined, or will it stop early when it doesn't understand what's going on? Does this mean every frame pointer walk will do a check of pointers using vm_region_64 or parsing /proc/self/maps before dereferencing anything?
Some of these APIs definitely need to be a little more general to handle all kinds of crazy things that people actually do. I expect to see a lot more optionals. Here are something things I think might be worth supporting that might be problematic right now, just off the top of my head:
We can definitely decide that we don't want to support every edge case but I would really like to see APIs that can be used piecemeal and with partial information. We shouldn't make something that is like "oh if you have a full frame pointer chain and debugging symbols in this exact location the API works" and if you have any deviation from that then you can't use any functionality at all.
(Final thought since this is mostly just a braindump: this is a Swift API but people are going to use it in apps/programs with multiple languages in it. We should also put at least a little bit of thought into whether we should do anything there. If Google somehow decides they want to bring safety to Android by adopting Swift wholeheartedly, and invent a FFI layer to make this work, should we do a stack walk across Java code? Maybe not, but we should at least go "yeah, that's too wild for us to consider here".)
i understand this type would be very complex to copy and store if it were a struct and not a class. but it is extremely awkward to use non-Sendable types in any application that uses actors or concurrency, even if the Symbols themselves are never being used concurrently.
i think it would be vastly preferable to either make this a struct anyway (anyone who is truly getting weighed down by retaining its fields can just wrap it in a class), or make all the properties immutable so they can be used in actors.
It's a bit tangential, but can you clarify whether this is just hypothetical or a genuine interest? If the latter, is it for architectures like x86-64 and arm64, or are you more just thinking 'embedded' systems and the like?
Note, importantly, that the API presented here is not async-signal-safe , and it is not an appropriate tool with which to build a general purpose crash reporter . The intended use case for this functionality is the programmatic capture of backtraces during normal execution.
I can't wait to see what this new API is going to unlock w.r.t. in-process tooling that we can develop. I would love to see an in-process profiler similar to what Go provides for getting CPU/Memory metrics out of running applications with minimal overhead.
The proposal calls out the ability to cope with backtraces from other platforms. How is this supposed to be possible? Neither Backtrace nor SymbolicateBacktrace conform to Codable. The usage of any Address makes it very hard (without any restrictions actually impossible) to implement a proper Codable conformance.
Is there a reason anyone should be able to conform their own types to Address outside of the Runtime module? If not, we should model the Address type as a non-frozen struct which is backed internally by an enum. This makes it possible to extend the storage in the future and conform to Codable. It also fixes the issue mentioned above with the usage of some Address mentioned above:
There's compiling without establishing normal stack frame, and then there's using the platform frame pointer register as a GPR. The first is very common, and generally doesn't mess with debugging tools--you might be missing some frames, but you can still recover a somewhat useful backtrace. The latter is more niche, and generally one shouldn't expect backtrace tools to do anything useful when doing it. I've definitely done both from time to time, but doing the later was always an explicit tradeoff of "the usual tools will not work once I do this, and I'm OK with that."
It's true that most Linux distributions are not building their system libraries with frame pointers at the moment but this seems to be changing. Fedora has already changed to building everything with frame pointers. Similarly, Ubuntu is enabling frame pointers by default starting with Ubuntu 24.04. Both posts outline the motivation quite strongly in that they aim to enable high performance profiling. Additionally, usage data has shown that enabling frame pointers has negligible performance impacts and the utilities of performance profiling outweigh those easily.
In line with this, we have already enabled building the Swift runtime libraries with frame pointers and we have made Swift PM build with frame pointers by default as well.
Yeah, that's all about what I expected, @scanon & @FranzBusch. I was assuming that from watches to servers these days - and frankly most embedded, since it's mostly ARM - everything has a more modern ISA with sufficiently many GPRs to negate any meaningful benefit from omitting frame pointers.
I suspect it's merely some inertia that's prolonging getting people off of that old crutch. I'm not remotely surprised that some big Linux distros are in this bucket - they tend to be absurdly conservative and slow to change.
At one point there was even an Apple-internal debate about whether to abandon kernel-based profiling in favour of user-space profiling because implementing unwind without frame pointers is possible but incredibly expensive and requires masses of debug metadata, making it highly unpalatable to put in the kernel. Thankfully there were too many obvious problems with user-space profiling, so that notion never really got its legs, and then x86-64 finally arrived and it was mooted.
It's funny how the Intel transition is now heralded as being amazing and how much better Intel Macs were than PPC Macs, but for a while there we lost a lot of things, like a 64-bit architecture, a competent SIMD implementation, or the notion of more than [effectively] six GPRs.
There were at the time already some Apple developer tools that did user-space profiling, most notably Sampler (now a niche feature in Activity Monitor) and early versions of Instruments (in fact Instruments still has the Sampler plug-in which does this, although I can't really fathom why anyone would ever willing use it over the Time Profile plug-in).
It isn't our intention that this should form the basis of a third-party attempt to generate backtraces for actual crashes. Doing that in a way that is robust is very difficult. The API is specifically for cases like testing frameworks where there is a desire to capture a backtrace from the current location.
b37509886e