“LLDB crash”

@DTS Engineer we believe we have found out the problem now... We created a TSI and Apple suggested that we tried find the crashing code by isolation, i.e., pulling our code until the crash disappeared. With some effort we managed to make a small demo app where the crash occurred. We realised that we have a UIView, which is backed by CATiledLayer. But for this view we also had backgroundColor = .clear. Even without the view's draw(rect:) method the app could crash! Apple's TSI engineer explained that if you have a view that implements draw(rect:) then you should not set the background color at the same time! But we needed the background to be transparent, and so we found that setting isOpaque = false instead of setting the background color made the crash disappear! We still believe that UIKit shouldn't crash if you set the background color, which it didn't do prior to iOS 26 :)

Hi Kevin, Thank you for your deep insight. Your theory matches our observed facts perfectly! I have just updated FB21636775 with the latest symbolicated crash log captured today (Jan 19). 1. Evidence of Concurrent Execution Conflict From the symbolicated backtrace, it is clear that at the moment of the crash: Thread 1 (AuxiliaryQueue): Is in the middle of executing UserCreateTargetForID (Frame 12). This RPC call has not yet returned to our DEXT. Thread 4 (Crashed Thread): Has already received the hardware interrupt for the first command (TEST UNIT READY) and is attempting to invoke the completion API. 2. Crash Characteristic Analysis The system encountered an Address size fault (Null dereference) at address 0x0000000000000008. This confirms your deduction: because UserCreateTargetForID is still pending on the AuxiliaryQueue and has not returned, the target-related objects or OSAction metadata in the kernel are not yet fully initialized. Attempting to invoke the action from

Same with me as well, both present in iOS 26.1 and 26.2. One of our top ones at 1,473 crash events total. Our happens on an XPCConnection update.

In a code signature, the certificates act as a chain of trust [1]. The first certificate is the leaf, the next is the one that issued the leaf, and so on until you get to a root. Ah I see, did not realize this before but it makes perfect sense, thank you. ...the next thing to check is whether this is the right type of profile. Turns out it is not a distribution profile and this was the problem all along. The error message Missing code-signing certificate was a red-herring this whole time. What is interesting is that it appears that it used to work even though it shouldn't have, by virtue of the fact that these app builds are present in Testflight and the profile it was using dates from before those builds. Alas am unable to confirm that for certain as CI history is too shallow and we no longer have a copy of the app bundle to verify. At some point altool has stopped returning non-zero exit codes on failure so CI has been blind to the failures for some months now (probably since Xcode 26 I'm guessing). Thanks

I have updated the Bug Report (FB21636775) with a new symbolicated crash log. OK. I have a totally new theory. Is it possible you're having an interrupt fire before you've completed full initialization, so you end up shuffling uninitialized data into the system? The crash log shows that you're in IOUserSCSIParallelInterfaceController::UserCreateTargetForID, so this is still very early in the startup process. I ask this, because an issue like this would explain both of these: (1) I attempted the over-retaining experiment you suggested (adding an extra retain() at the start of the loop and omitting release() in the ISR). Over retaining a valid object shouldn't actually do anything meaningful, as all you're doing is incrementing a simple integer counter. Eventually you might cause the counter to overrun, but that's not something that would happen immediately. It certainly shouldn't cause a kernel panic... The result was critical: it triggered an immediate Kernel Panic / Hard Reset every time. .

Hi Kevin, Thank you for your candid feedback. You are absolutely correct—the crash log I previously shared was from an experimental attempt where we mistakenly used the legacy ParallelTaskCompletion API for bundled commands. I apologize for the confusion. I have now strictly followed your guidance, and here is the latest update: 1. Corrected Bug Report & Logs I have updated the Bug Report (FB21636775) with a new symbolicated crash log. This log definitively captures the failure while invoking the correct BundledParallelTaskCompletion API (as shown in Frame 8 of the trace). Even with the correct API, the system still triggers an __assert_rtn followed by an Address size fault (ESR: 0x56000080). 2. Over-retaining Experiment Results (Hard Reset) I attempted the over-retaining experiment you suggested (adding an extra retain() at the start of the loop and omitting release() in the ISR). The result was critical: it triggered an immediate Kernel Panic / Hard Reset every time. Because the system

Bug Report Filed I have filed a bug report via Feedback Assistant. Clarifying things, what I was specifically looking for here was a bug asking us to document exactly how the action for BundledParallelTaskCompletion should be managed. The issue here is that its usage semantics are somewhat... weird. You're given a single action pointer, but you're expected to use that action pointer multiple times (since individual commands won't complete at the same time), which makes its lifetime somewhat... odd. In practice, I don't think this actually matters. As you've noted, you always receive the same pointer so as long as you don't release it too many times everything will be fine. For maximum correctness, you could do something like this: Retain it once (or a few times) the first time you receive it in UserProcessBundledParallelTasks() Release it at some late point in the teardown process when you know all I/O is done. Add an assert in UserProcessBundledParallelTasks() to validate that it never changes (which would b

SOLUTION: Delete workspace user state files If Xcode crashes when opening the AI Intelligence tab in a specific project, the issue is corrupted UI state data in your workspace. Fix: Close Xcode completely Navigate to your project directory in Terminal and delete UserInterfaceState.xcuserstate: rm YourProject.xcodeproj/project.xcworkspace/xcuserdata/YOUR_USERNAME.xcuserdatad/UserInterfaceState.xcuserstate This resolved the crash for me in Xcode 26.2 on macOS 26.2. What this does: Deletes the corrupted workspace UI state (including Intelligence chat history). Xcode will recreate it fresh. You'll lose panel positions and open tabs, but all your code and project settings remain intact.

Same here: Xcode 26 crashes as soon as Coding Intelligence is enabled or Coding Intelligence tab is opened. Crashes for this particular one project only. Deleting xcuserdata did not help. Can't seem to find where Xcode is storing Coding Intelligence chat history, which seems to be the culprit. Crash report excerpt: exception : {codes:0x0000000000000001, 0x000000016010bfb0,rawCodes:[1,5906677680],type:EXC_BREAKPOINT,signal:SIGTRAP}, termination : {flags:0,code:5,namespace:SIGNAL,indicator:Trace/BPT trap: 5,byProc:exc handler,byPid:2620}, os_fault : {process:Xcode}, extMods : {caller:{thread_create:0,thread_set_state:0,task_for_pid:0},system:{thread_create:0,thread_set_state:0,task_for_pid:0},targeted:{thread_create:0,thread_set_state:0,task_for_pid:0},warnings:0}, faultingThread : 0, threads : [{frames:[{imageOffset:5242800,symbol:closure #1 in SourceEditorDataSource.ideChat_gracefullyApplyChangesToReflect(_:editApplier:),symbolLocation:2292,imageIndex:339},{imageOffset:3689220,symbo