“LLDB crash”

I also encountered this crash. My text is in here. It crashes as soon as this text is set into a UITextView, but UILabel doesn't crash. crash_text.txt

Yes, the crash report you posted shows only one thread accessing SpriteKit. However crash reports don't perfectly capture the state of every other thread at the instant of the crash because control needs to first return to the kernel - via sys call, pre-emption, etc - before thread state can be recorded for the crash report, by which point the other thread may have finished interacting with SpriteKit. My suggestion is to look through other crash reports for the same crash point. In my experience given a sufficiently large enough number of crash reports, one of them will end up capturing the other thread in the act of concurrently mutating whatever data - SpriteKit internals in this case - caused the crashing thread to crash. -- Justin

Thanks for your help. Updating SpriteKit from multiple threads is what I suspected too, but the crash shows only one thread accessing SpriteKit in that moment. Although the code in thread 1 does in fact update the path and fillColor properties of a SKShapeNode 6 lines before the one mentioned in the crash report. Could this still be the issue?

Hello The crash you posted is in SpriteKit code, not SceneKit code. However, I'm not certain this is a SpriteKit bug. A common cause of SpriteKit crashes is accessing/modifying SpriteKit objects outside of SpriteKit's update loop. Even calling methods or accessing properties that look like they don't modify anything (e.g, -frame) can trigger mutation to SpriteKit's internal data structures, which is unsafe if done from multiple threads. Indeed, while looking through past SpriteKit bugs I found one for the exact function shown in your crash report. The resolution of that bug was in the app, which was found to be updating SpriteKit objects from multiple threads. I suggest looking through each of the crash reports in the Xcode organizer. Look for reports where multiple thread backtraces contain SpriteKit methods/functions. That should point to locations your code is accessing/modifying SpriteKit objects where it should not be. -- Justin

Urgh, I think it's a divide by zero bug. So this can apparently crash the Window server: Path { path in path.move(to: pt(qdt.qx * -20, 0)) // DIV BY ZERO path.addLine(to: pt(qdt.qx * -20, qdt.qy * (sH)/cos(angle.radians))) } If cos(angle.radians) is 0, you get a simple but unrecoverable divide by zero error, and hey, that's on me. But I would expect the system to kick my program with a nice EDIVBYZERO, not take out the window server. My solution to this is this function, which works because I don't need perfect accuracy: func cosNZ(_ input: Double) -> Double { let x = cos(input) if x == 0.0 { return Double.leastNonzeroMagnitude } return x }

Thanks for the crash report. I was able to uncover an internal bug that AFAICT is tracking the same issue (r. 154431813) [1]. Sadly, that remains unfixed and doesn’t offer any ideas as to how you might avoid it. My advice is that you file your own bug about this, attaching all the information you have available. Please post your bug number, just for the record. Also, you mentioned that you’re in touch with some users that can reproduce this. If so, could you ask them to file their own report about it in Feedback Assistant. That should capture a sysdiagnose log, which might help with the investigation. If that happens, ask them to send you their bug number and then post those here as well. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Much to my own surprise. Radar is a very big haystack (-:

@DTS Engineer here is a crash report. Let me know if that's ok. Thanks! 2026-01-22_13-22-06.4375_+0100-551bcad6f754cc983f48af050242e4561fb39024.crash

Also CFURL is documented to have different behavior but CFURL and NSURL aren't they 'toll free bridged' so how does that work if you cast a CFURL to a NSURL? So I just did a dumb little test to answer this. I created a CFURLRef and read kCFURLIsHiddenKey and got false (as expected) so it would cache it. Then on another CFURL instance (that points to the same file) I did the same thing (so it was cache the value). After that I set hidden to YES: NSURL *toNSURL = (__bridge NSURL * _Nonnull)cfURL; [toNSURL setResourceValue:@(YES) forKey:NSURLIsHiddenKey error:nil]; Then back to the other instance I cast that one to another NSURL: NSURL *nsCastCopiedVersion = (__bridge NSURL * _Nonnull)aCopiedCFURL; And read isHidden and it is NO. Read aCopiedCFURL hidden and it is also NO. Then dispatch after dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{ [URLPrinter printCF:aCopiedCFURL]; [URLPrinter printNS:nsCastCopiedVersion]; }); And got: Print copied CF Not hidde

Other than what @Tomato said, you can also try to reset the simulator by running the simulator's Device > Restart or Device > Erase all Contents and Settings menu. This helps rule out that the crash is caused due to unintentional changes on the simulator. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Having the same issue, Macos Tahoe 26.2, i tried everything i found on net: deleting caches, all xcode files, reinstalling it, rebooting my computer, deleting all simalator devices, deleting IOS from Xcode => setting components, downloading it again. I tried installing older IOS, no help, when starting emulator i have this error: Unable to boot the Simulator And this error, when i'm trying to do this from terminal == Devices == -- iOS 26.2 -- iPhone 17 Pro (1FC8FFC9-A04D-434B-85F0-F5AE2DB4CDAC) (Shutdown) iPhone 17 Pro Max (71761C54-D406-496E-A552-CD72FACD10DA) (Shutdown) iPhone Air (64607ACA-F580-4A6A-A816-1AD1E8BEBC32) (Shutdown) iPhone 17 (7ECEC4C0-0DC9-4B5A-A9A0-05E4B1038C68) (Shutdown) iPhone 16e (A175B467-438D-41A7-B537-D7E23B4FFF21) (Shutdown) iPad Pro 13-inch (M5) (FA74F9C7-93C9-40D6-86F5-74E46FCCF7EC) (Shutdown) iPad Pro 11-inch (M5) (73A17C77-DBFA-4748-880D-15FBBE43E57E) (Shutdown) iPad mini (A17 Pro) (09BF89D2-640C-4083-937A-4859633BB69E) (Shutdown) iPad (A16) (5FF5869B-042F-4886-A5E3-AD333550F9