LLDB crash

Hmmm, or maybe not. I tried reproducing this in my office, but couldn’t. Here’s what I did: On macOS 15.5, I opened Xcode 26.0b5 (17A5295f). I downloaded a fresh copy of the Building peer-to-peer apps sample. In Signing & Capabilities, I selected my team in the popup. I chose my test iPhone 16 as the run destination. It’s running iOS 26.0b6 (23A5318c). I chose Product > Run. The app built successfully and ran on the device. I did do a full test here, but it launches just fine, to the point where I see the Host Simulation and View Simulation buttons. Please review my steps to see if I did anything wrong. If not, please repeat them yourself and let me know if you continue to see the crash. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Right. The second file is from a third-party crash reporter, which is rarely helpful [1]. The second is from the Apple crash reporter, but it’s in human readable format (.crash). I’m looking for a crash report in the JSON format (.ips). Do you have one of those? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] For an explanation of why third-party crash reporters are a bad idea, see Implementing Your Own Crash Reporter.

If our sample code is crashing out of the box, it’s always worth filing a bug about that. It’s gotta be either a problem with the sample or a problem with the OS, or maybe a problem with Xcode. Regardless, it’s our issues to fix. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

A crash report is a point-in-time capture of the call stack leading up to the crash. While useful as a starting point to making are you understand the call path that got you to the crash, it doesn't contain the information about how your views were either strongly or weakly referenced in memory, and how those references changed over the lifetime of your view, which then lead to the view being released unexpectedly. You'll need to do further debugging of your code to understand the references you have, according to the rules of strong and weak references and the information I wrote above. The Allocations instrument in Instruments is one tool that is helpful, and the Memory Graph debugger with MallocStackLogging enabled is another useful tool for debugging these types of issues. 24 UIKitCore 0x000000018e76f1cc -[UINib instantiateWithOwner:options:] + [ : 768] 25 UIKitCore 0x000000018e5eda0c -[UICollectionView _dequeueReusableViewOfKind:withIdentifier:forIndexPath:viewCategory:] + [ :

they actually CREATE crashes Thanks, that's what I should have known but didn't fully realize until now. I just tried enabling the Address and Thread Sanitizer (the Main Thread Checker is already enabled), but couldn't reproduce the crash. I'll keep them enabled in the hope that they will create a crash at some point. whatever is going on doesn't involve some simple code flow I could understand that this crash could be caused by multiple threads releasing the image at the same time, but if only the main thread is accessing them, I cannot imagine how they could be over-released. I'm not doing any manual memory management with them or their parent object. If you have any example of how over-releasing could happen without thread contention and manual memory management, I'd be eager to hear it. Otherwise I'll let you know as soon as I'm able to reproduce the crash.

I don't understand. Aren't all these tools you mention (Zombies instrument, ASan, Main Thread Checker etc.) meant to be run in Xcode or Instruments? Or are you saying I should enable some compiler flag in my production build? They're intended to run in your development build. Let me jump back to what you're saying here: since the crash reports are downloaded by Xcode from other users and I cannot reproduce it myself... What you're saying here is testing in Xcode won't help because I can't reproduce the issue. The problem with that statement is that it misunderstands how the tools above actually work. They don't just provide better diagnostic data about a crash that would otherwise occur, they actually CREATE crashes that would otherwise NOT occur. Jumping back to my description here: However, what the Zombies instrument actually does is modify the dealloc method so that freeing an object doesn't ACTUALLY free that object, but instead replaces it with an intentionally invalid object

it works for me (M1 MBA and M1 MBP with M1 Pro). If I were you, I'd file a bug, then delete Xcode 26b5 and everything associated with it, then re-install it. If that doesn't work, and you're on a beta of macOS, wipe the Mac and reinstall everything. If it is still a problem, follow up on the bug with new crash logs. If it is fixed, close the bug with cannot reproduce.

Another point. In DataView, index should not be a State variable. Add a button in ContentView VStack { if showView && (index >= 0) && (index < data.count) { DataView(datum: data[index]) } Spacer() HStack { Text(Index: (index) -> ) Button(Next) { index += 1 if index >= data.count { index = 0 } } } } You will see that text in DataView does not change Text(DataView (datum.str)) always says DataView String 1 Now change DataView as follows to get it updated on index change by button press: struct DataView: View { /*@State*/ var datum: Data2 var body: some View { Text(DataView (datum.str)) } } Note: I renamed data to datum for an array item, to differentiate from the array. Now, I have to update my initial answer. In fact, no need for showView and Dispatch (even though that made it work). Just test index: if (index < data.count) { DataView(datum: data[index]) Without the index test, it crashes… Swift/ContiguousArrayBuffer.swift:691: Fatal error: Index out of range Reason is t

We are glad to receive your reply. The crashes we encountered indeed occurred on iOS 16. Here is the crash report we have collected. 2025-08-11_08-00-36.7327_+0100-8e5932e50fad855083676ed1d14993f8028995a9.crash live.soulchill.ios_issue_978f48b6bc841ec59315428834ff62f3_crash_session_c4ff2e4f47d74f1a84b3b40404880b83_DNE_0_v2_stacktrace.crash

Thanks for the crash report. The standard DTS mantra is “Always ask for a crash report first.” I failed to do that in this case, to my own detriment )-: The crash report snippet in your original post, and the discussion of Rust and so on, confused me into thinking that this problem is more complex than it is. However, your crash report makes it clear as to exactly what’s going on: Thread 3 name: Thread 3 Crashed: 0 ??? 0x0000000000000000 0x0 + 0 1 sdk 0x0000000105931ec0 0x105820000 + 1121984 This isn’t a weird code signing issue. Rather, your code has simply jumped to nil. [quote='853477022, ospfranco, /thread/795348?answerId=853477022#853477022, /profile/ospfranco'] I guess cocoapods masqueraded the issue. [/quote] Possibly. I often see cross-platform code deploy the -undefined linker option, which has a tendency to turn build-time errors into run-time errors. Needless to say, I’m not a fan [1]. If you’re curious about how Mach-O symbols work, I talk about that ex