LLDB crash

When testing with the Endpoint Security Framework for the AUTH_OPEN event, I found that the deadline was 15 seconds, but the actual process termination occurred at 5 or 6 seconds. Is this intended? That depends on what you mean by intended... In terms of why you're seeing that difference, the basic issue here is a disconnect between what the deadline actually means and the information available to your ES client. At a very high level, the deadline describes how long the system will stall that particular syscall. You can visualize that processing sequence as something like this: The in kernel receives the syscall and does its processing The in kernel ES system sets the deadline and calls out to user space. Time passes Your ES client receives the event and does its processing. Your ES client sends its response. Time passes. The in kernel ES system receives your response and completes the syscall. The disconnect here is that what the deadline describes is the time between 2 and 7, but the ONLY part of that proce

It sounds like your launchd job is failing to start. There are two common reasons for that: launchd tries to start it and it crashes. launchd is unable to start it. A good place to… ahem… start is to look for a crash report. In the first case, and many times in the second case as well, a failure will generate a crash report. If that doesn’t show up anything, add a ‘first light’ log point to your job [1]. Then try to communicate with the named XPC endpoint. That’ll divide the problem in half: If you see a log entry, you know that your job started and you can debug your code. If not, you know that your code never got running and you can debug your configuration. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I explain this ‘first light’ concept in Debugging a Network Extension Provider.

@DTS Engineer I think that I got general understanding of the issue that occurs. In our application we still depend on TVML Kit (which is marked as deprecated already). On many screens we use the stackTemplate with collectionList that contains big numer of shelfs (10-20) with lockups that allow to horizontally scroll the rows. Based on investigation of what is going on with memory I see that TVML engine does its best to speedup the process of rendering the lockup elements to provide the best experience while doing the quick scroll through the all shelfs. To handle it, the TVML uses some kind of rasterisation mechanism for TVML elements and display them as a single image in TVStackedImageView. It leads to issues in case of using the first generation of apple TV as rastered elements are kept in memory as long as the template keeps alive. There is a big difference in memory consumptions in case of using 4k display and 1080p. It seems to be related to fact that created images for 4K displays are bigger and in res

Maybe it serves me right that I can't delete the post above! It might make me think thrice before posting here ... Ignore all above: I found a crash log with a clue in it and it turns out this is in fact a bizarre async issue happening during my AU initialisation that wasn't caught before probably because it's in a bit of Objc code.

Your new example doesn't cause a crash in Xcode 26 beta 3 or Xcode 16.4 on my M1 Max Mac Studio with macOS 15.5. I wonder if it's something else. Are you on macOS 26 beta?

@Developer Tools Engineer thanks. The FB you linked is the right one. @darkpaw Here's a simpler repro without bindings that still crashes. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String } struct HelloView: View { let element: MyItem var body: some View { Text(element.label) } } struct ForEachSubView: View { @State var elements: [MyItem] = [ MyItem(label: hello), MyItem(label: world), ] var body: some View { List { ForEach(elements, id: .id) { element in HelloView(element: element) // crash // Works ok: // Text(element.label) } } } } #Preview(ForEachSubViewRepro) { ForEachSubView() } Seems SwiftUI is internally invoking an OutlineList and then crashing when trying to walk a tree, despite the fact that MyItem has no children and no children keypath is specified in the List constructor. Thread 0 Crashed: 0 libswiftCore.dylib 0x1a9b458f0 _assertionFailure(_:_:file:line:flags:) + 176 1 SwiftUI 0x1cab7e9c8 ViewListTree.visitItem(_:force:) + 5232 2

[quote='792781021, retrograde, /thread/792781, /profile/retrograde'] The following repro case results in a previews crash on Xcode 26 beta 3 (report attached). FB18762054 [/quote] Thanks for reporting this. I believe the feedback you meant to reference was FB18792113 which I've made sure has reached the right team for the initial triaging of your issue. If we need more information we will reach out to you via the feedback mechanism.

It also crashes in Xcode 16.4 because what you're doing isn't valid. In your second example, line 28 is wrong. HelloView does not have any Bindings in it; it just takes a label parameter, so line 29 passes in element.label. Correct. Line 28 is treating your elements State var as though it's a binding, by adding the $ in front. And you're also adding the $ to the element part towards the end of the line. elements is a State var and element is a var whose label property is being passed into a view that does not have a Binding. This is why Preview crashes. It will compile if line 13 is this instead: @Binding var label: String, but based on what you're doing with label inside HelloView, i.e. you're not changing it, there's no need for it to be a binding var.

Simpler repro without generics. import SwiftUI struct MyItem: Identifiable { var id = UUID() var label: String init(_ label: String) { self.label = label } } struct HelloView: View { let label: String var body: some View { Text(label) } } struct ForEachBindingRepro: View { @State var elements: [MyItem] = [ MyItem(hello), MyItem(world), ] var body: some View { List { ForEach($elements, id: .id) { $element in HelloView(label: element.label) // crash // Works ok: // Text(element.label) } } } } #Preview(ForEachBindingRepro) { ForEachBindingRepro() }