LLDB crash

Hello Justin, As you suggested, I have repeated the tests multiple times, but I was not able to reproduce the crash. As mentioned, it appears to be difficult to encounter the issue consistently. I would also like to share an additional observation: we ran the same application on iPads with iPadOS 18.1 for nearly six months without encountering any crashes. However, after updating the devices to iPadOS 18.6.2, the crashes started occurring. Since the only change during this period was the iPadOS update from 18.1 to 18.6.2, I would appreciate your insight on whether any changes in this OS update could potentially contribute to this behavior?

I.e. crash occurs on OD-related queue while another thread fetches users’ data via CSIdentityQueryExecute(). It seems that the query is in progress because the thread waits for a semaphore. Yes, that's true. However, looking at our code, there's no way that could be disrupting the other thread, as it only blocks in dispatch_semaphore_wait once (waiting for the entire query to complete) and doesn't do anything until the query finishes. Regarding the feedback, I think we'll file a report soon. Please do and upload full crash logs, posting the number back here once you've got everything uploaded. I'd like to look at a set of full logs to see if I can see anything. Also, do you have any crash logs without asan? And do they look the same? It's not unusual for asan to shift crash behavior (basically, you end up crashing earlier than you normally would) and it can also mask the real crash cause in your app. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

As an update to my post above, we reactivated the feature and have 5 Organizer crash reports. 2 of them are for: 26.2 (23C5027f) 3 of them are for: 26.2 (23C5033h) Do these IOS versions correspond to the RC or the GM?

While I appreciate the movement in the right direction, this still represents a substantial regression from the prior baseline, ~1s in Xcode 16. Hi LWK, I would appreciate it if you could run an experiment to help us understand where the last bits of performance regression are. Open ~/.lldbinit and add this line: settings set target.experimental.swift-tasks-plugin-enabled false It might be best to do this while Xcode is closed, so that we can be sure the setting is read correctly. (You can confirm the setting worked by looking at the thread navigator while stopped in some async function, if you have any in the code, you should no longer see any threads called Tasks). With this setting, do you still experience a slow launch? (please remember to remove that setting, as keeping it on will make stepping through async functions stop working) If you could also open a terminal, run sample lldb-rpc-server 60 --wait -file sample.txt, and then immediately launch your application, this would be very helpful as

It's known to crash with iOS 26.2 RC and XCode 26.2 RC. I've seen it working in my tests with the released versions of iOS 26.2 and XCode 26.2.

I've looked through several crashes and the only pattern I've noticed is something like this: Thread 30:: thread manager 0 libsystem_kernel.dylib 0x19534dbb0 semaphore_wait_trap + 8 1 libdispatch.dylib 0x1951d9960 _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x1951d9f10 _dispatch_semaphore_wait_slow + 132 3 DirectoryService 0x1aabdb340 _continue_query + 88 4 DirectoryService 0x1aabdae50 dsGetRecordList + 484 5 OSServices 0x1a30f7de4 findRecordsWithNames + 136 6 OSServices 0x1a30e34a0 DSIdentityQuery::performQuery(__CFError**) + 456 7 OSServices 0x1a30e35c8 DSIdentityQuery::execute(unsigned long, __CFError**) + 68 8 OSServices 0x1a30d76f8 CSIdentityQueryExecute + 48 9 libxxx.dylib 0x1032e9450 my::helper::EnumerateUsers(std::__1::function const&, unsigned int) + 1800 ... Thread 42 Crashed:: Dispatch queue: com.apple.opendirectory.odxpc.xpc 0 libsystem_kernel.dylib 0x195356388 __pthread_kill + 8 1 libsystem_pthread.dylib 0x19538f88c pthread_kill + 296 2 libsystem_c.dylib 0x195298a3c abort

Hello, Thank you for the suggestions!!. Below is a simplified structure of our current implementation, SceneDelegate.swift import UIKit class SceneDelegate: UIResponder, UIWindowSceneDelegate, UIApplicationDelegate { var viewController:ViewController! func sceneDidBecomeActive(_ scene: UIScene) { viewController.keyboardStatusHandler() } } ViewController.swift import UIKit import Foundation import GameController class ViewController: UIViewController, WKUIDelegate, UINavigationControllerDelegate, AVAudioPlayerDelegate, WKNavigationDelegate, ConnectWebViewDelegate{ override func viewDidLoad() { super.viewDidLoad() //other code NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow), name: UIResponder.keyboardWillShowNotification, object: nil) } @objc func keyboardWillShow(_ notification: NSNotification) { self.keyboardStatusHandler() } func keyboardStatusHandler(){ let isKeyboardConnected = GCKeyboard.coalesced != nil if(!isKeyboardConnected){ //use webView.evaluateJavaScript to send

Hello I put together a small code example to test the scenario described in your original post. import UIKit import GameController @main class AppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { keyboardStatusHandler() NotificationCenter.default.addObserver(self, selector: #selector(keyboard(willShow:)), name: UIResponder.keyboardWillShowNotification,object: nil) return true } @objc func keyboard(willShow notification: Notification) { keyboardStatusHandler() } func keyboardStatusHandler(){ let isKeyboardConnected = GCKeyboard.coalesced != nil if(!isKeyboardConnected){ NSLog(Keyboard is not connected) } else { NSLog(Keyboard is connected) } } } Running this app on an iPad with iOS 18.6.2 and keyboard connected, I do not encounter any crash when repeatedly backgrounding & foregrounding the application while typing on the keyboard. I suspect there is more app

unique_cfref is just a std::unique_ptr wrapper that calls CFRelease when we go out of scope. Looks like something in OpenDirectory tries to access released data (weak references and delayed processing?). The problem seems to occur on macOS 15. No, that's not what's going on, though I can see why you might have thought that. The key details here are this note in the middle: 0x000166890010 is located 10946 bytes after 789838-byte region ASAN includes information about nearby allocations because there often is a relationship between allocations that are close to each other. However, the problem here is that 10946 bytes is 10KB, which isn't really all that close. It's possible there is some connection, but it's more likely that this was just the closest block ASAN could relate, not that they were actually tied to each other. Similarly, what the code is actually doing is converting raw bytes it received through XPC into plist data (Array/Dictionary/String/etc.), which your larger app wouldn't really have ever had

Hello, I'm sorry, i forgot to mentioned the iPad OS version in the initial post. Crash happen in iPad OS is 18.6.2 tablet. Is the snippet in your original post your code's only interaction with the GCKeyboard API? To this question , Yes this is the only function that called GCKeyboard, For the places we called keyboardStatusHandler() function is like below, In the Scenedelgate , inside sceneDidBecomeActive(_:) Via a NotificationCenter observer registered in the view controller, triggered when the keyboard is shown: NotificationCenter.default.addObserver(self, selector: #selector(XXXXX), name: UIResponder.keyboardWillShowNotification,object: nil)

Thanks for the post. It looks like you're encountering a specific crash related to the SwiftUI instrument in Xcode 26.2, which can be quite frustrating, especially when it interrupts a useful workflow. Given that you've already attempted some common troubleshooting steps like removing derived data, reinstalling, updating Xcode, and restarting devices, and that is a crash on the Instruments app let’s go ahead and file a bug: Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Hello Thank you for sharing the crash report. It appears either your custom crash reporter did not capture the iOS version where the crash occurred, or the iOS version information was redacted before you posted the report. If you can obtain a crash report generated by the Apple crash reporter, that crash report will have the iOS version information. See Posting a Crash Report. Otherwise, can you share the latest iOS version that you have encountered this crash occur on? Would you also answer my other question above: Is the snippet in your original post your code's only interaction with the GCKeyboard API? -- Justin