LLDB crash

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?

To eliminate potential race conditions, we have also moved our interrupt handling to the Default Dispatch Queue using kIOServiceDefaultQueueName. I'm not sure you want to do this, as I think it might end up causing BundledParallelTaskCompletion() to deadlock itself. As soon as the completion is triggered from the asynchronous interrupt path—even though it is serialized on the same Default Queue—invoking ParallelTaskCompletion (or BundledParallelTaskCompletion) causes the DEXT to crash immediately (Corpse / Address size fault). Can you post the crash log for this? We extracted our core logic into a helper method, DispatchTaskInternal, passing 0xFFFF as a placeholder for the Slot Index. Is your DispatchTaskInternal method just a simple helper method/function or is it actually running on a different queue? If it's on a different queue, then I would strongly suggest that you eliminate that entirely and just do everything on the same thread. The issue here is that, in practice, most of what your

Thanks Quinn, much appreciated. I'll add that I've also tried Soft Mode extensively and I've never seen it do anything. No log messages, no crashes in the debugger, no crash reports in the on-device logs for MTE. I'm open to suggestions! Occasionally I can get a crash in _zxm_xzone_malloc_free_outlined in an unrelated stack but this appears to be regular old corruption rather than MTE kicking in.

So, when running outside of the debug, MIE can run in one of two modes: In soft mode, it generates simulated crash reports for violations. In hard mode, it crashes the process. My understanding is that hard mode is not yet support for third-party apps. The weird part is that I can’t find that documented anywhere. I’m gonna research why that’s not the case and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi all, we do have the same problem. Me and several other colleagues. We just found out the same that iOS Simulator version 18.2 is the latest working for us. We have also tried to clean everything and start the installation from scratch. It did not help. I throw my stack trace here as well in the hope it might be seen and it might help some developer at Apple. Unable to boot the Simulator. Domain: NSPOSIXErrorDomain Code: 4 Failure Reason: Interrupted system call User Info: { DVTErrorCreationDateKey = 2026-01-14 08:42:36 +0000; IDERunOperationFailingWorker = _IDEInstalliPhoneSimulatorWorker; Session = com.apple.CoreSimulator.SimDevice.79733B3C-A5BA-41E8-A88A-6DA408E517D6; } -- Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding Domain: com.apple.SimLaunchHostService.RequestError Code: 4 -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { device_identifier = XXX; device_model = iPhone17,5; device_osBuild = 26.0 (23A339); device_osBuild

For the record, I've made no further progress triggering an MTE crash using only the entitlements. I tried a more extreme pointer manipulation and it still proceeds just fine: // Now guarantee a tag mismatch by modifying p2's tag unsigned old_tag = PTR_TAG(p2); unsigned new_tag = (old_tag + 1) % 16; uintptr_t addr_only = (uintptr_t)p2 & 0x00FFFFFFFFFFFFFF; void *p2_bad_tag = (void *)(addr_only | ((uintptr_t)new_tag << 56)); os_log(OS_LOG_DEFAULT, Original tag: %u, Modified tag: %un, PTR_TAG(p2), PTR_TAG(p2_bad_tag)); os_log(OS_LOG_DEFAULT, Attempting read with guaranteed bad tag...n); volatile char c2 = *(volatile char *)p2_bad_tag; // Should this crash? os_log(OS_LOG_DEFAULT, Read succeeded! Value: %dn, c2); yields Original tag: 14, Modified tag: 15 Attempting read with guaranteed bad tag... Read succeeded! Value: 31

Hi Kevin, Thank you for your valuable insights. Following your advice, we have refactored our driver to use a wrapper pattern where UserProcessBundledParallelTasks serves as a high-performance entry point that forwards commands to our core dispatch logic. To eliminate potential race conditions, we have also moved our interrupt handling to the Default Dispatch Queue using kIOServiceDefaultQueueName. This ensures that command submission and completion are strictly serialized. Here are the key implementation details showing how we unified the dispatch logic: 1. Legacy Entry Point (Single Task): We extracted our core logic into a helper method, DispatchTaskInternal, passing 0xFFFF as a placeholder for the Slot Index. kern_return_t MyDriver::UserProcessParallelTask_Impl( SCSIUserParallelTask parallelRequest, uint32_t *response, OSAction *completion) { // Forward to unified internal dispatcher with no slot index (Legacy Mode) return DispatchTaskInternal(parallelRequest, response, completion, 0xFFFF); } 2. Bundled S