“LLDB crash”

We update OS to 26.2 this week, and the M4 max crashed issue has been gone. May we know if there is any fixed solution phased into the new OS version? There isn't really any way to answer that with the information you've provided. There are too many changes in any given release to easily review, and it's often the case that the change that resolves a given issue wasn't actually specific to that particular issue. If you upload the panic log to a bug and post the bug number back here, I might be able to say more, but without that, I can't really determine anything. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I tried to disable swift-tasks-plugin-enabled as you described, but that barely had noticeable effect (<1s difference). With the debugger attached (and iPhone connected with USB) our app becomes responsive after about 6-7 seconds from start, while this time decreases to less than 1s if I turn off Debug executable option in scheme. I collected lldb-rpc-server sample as you described and added it to FB21378487. Hope it would be helpful!

We update OS to 26.2 this week and the M4 max crashed issue has been gone. May we know is there any fixed solution phoased in to the new OS version ? Many thanks for your supporting. cheers, carrie

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