LLDB crash

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

[quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] it appears to contain 19 certificates [/quote] I agree that that’s strange. A distribution profile should only contain distribution certificates, and most teams only have one or two of those active at any one time. I recommend that you check the type of the profile and also look at the certificates embedded in the profile. [quote='812770021, davertay-j, /thread/812770, /profile/davertay-j'] Is there a way to find out which certificate is missing exactly? [/quote] Yes. TN3125 Inside Code Signing: Provisioning Profiles explains how you can pull apart the profile to work out what it authorises. You combine that with the --extract-certificates option to codesign, which allows you to determine the certificate of the code-signing identity that was used to sign the code. I’ve got some info on how to do that somewhere… Oh, right, here it is… Have a look at the Check the Signing Certificate section of Resolving Code Signing Crashes on Launch

Hi Kevin, Thank you for the suggestion. We have performed the over-retaining experiment by adding an extra retain() to the OSAction at the start of the UserProcessBundledParallelTasks loop. Unfortunately, the result remains the same: the DEXT still triggers a Corpse crash immediately upon calling the completion signal in the asynchronous path. As the legacy mode (UserProcessParallelTask) remains 100% stable under our newly serialized queue configuration, we have decided to revert to the legacy path for now to continue our product development while we wait for investigation on the bug report (FB21636775). Any further insights into why the asynchronous completion fails specifically in Bundled mode would be greatly appreciated. Best Regards, Charles

Hi Kevin, Thank you for your detailed feedback and for spending time looking at your internal driver implementation. I have followed your suggestions and filed a formal bug report. 1. Bug Report Filed I have filed a bug report via Feedback Assistant. Feedback ID: FB21636775 I have attached the original and symbolicated crash logs, along with reduced code snippets showing our implementation. 2. OSAction Pointer Confirmation I have verified the value of the completion pointer received in UserProcessBundledParallelTasks. As you suspected, the pointer address is identical for all commands within a single bundle. 3. Crash Log Insights The symbolicated crash log confirms that the panic is triggered by an __assert_rtn inside OSMetaClassBase::QueueForObject during the call to completion. Specifically, when we attempted the Unified Path (using legacy ParallelTaskCompletion for bundled commands) as a stability test, it triggered an immediate panic, which confirms your point that we MUST use B

Dear xiwek, Can you please attach a fully symbolicated Apple crash report in your reply, as well as any specific steps for replicating this crash? Posting a Crash Report explains how to do so. Thank you for your patience, Richard Yeh  Developer Technical Support

Thanks a lot for responding. Thanks for the post, it’s hard not seeing the code and how you're setting constrains in code. Would you be so kind to provide your code where you setting the constraints so developers here can see it? [..] it is generally not a good idea (and will lead to crashes) to directly modify the frame or bounds of a view that is managed by Auto Layout in my opinion. Initially I did not involve Autolayout at all explicitly. What I had was a small container view controller with something like this (no explicit constraints): @implementation SmallInfoWrapperViewController -(void)viewDidLayout { [super viewDidLayout]; NSRect bounds = self.view.bounds; CGFloat lineHeight = 1.0; self.separator.frame = NSMakeRect(0.0,bounds.size.height-lineHeight,bounds.size.width,lineHeight); BOOL separatorVisible = !self.separator.isHidden; CGFloat wrappedViewHeight = bounds.size.height; if (separatorVisible) { wrappedViewHeight -= lineHeight; } self.wrappedView.frame = NSMakeRect(0.0,0.0,bounds.size.wi

Thanks for the post, it’s hard not seeing the code and how you're setting constrains in code. Would you be so kind to provide your code where you setting the constraints so developers here can see it? What do you mean by legal? it is generally not a good idea (and will lead to crashes) to directly modify the frame or bounds of a view that is managed by Auto Layout in my opinion. In my experience any method that directly or indirectly causes setNeedsLayout() or setNeedsDisplay() or changes the frame or bounds of a view that is managed by Auto Layout, may likely trigger the same infinite loop and exception. I think AppKit's layout cycle (especially with Auto Layout) translatesAutoresizingMaskIntoConstraints creates weird fixed width and height constraints leading to Unable to simultaneously satisfy constraints warnings isn’t? When you then add a view add an explicit Auto Layout constraints to a view hierarchy where translatesAutoresizingMaskIntoConstraints is true for some views, you often end up with

Any help? Anyone else seeing crashes with the AddressBook preview?