“LLDB crash”

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

Logs include: ... The process ID (PID) First off, thank you and congratulations on having the foresight to include that. I've long recommended that developers include that in their logging since, from past experience, I've seen FAR too many weird problems that were not in fact weird once it was clear that the logging was coming from the same or different process. The PID remains the same Then this: Terminate it manually via the multitasking app switcher. ...did not happen. Per standard Unix semantics, process ID's are uniquely assigned at creation. PIDs are reused if/when the process ID space is exhausted and the wraps back around; however, they're a 32-bit value (so exhausting the space isn't trivial) and, more importantly, system process creation is chaotic enough that getting the same PID doesn't really happen. It's difficult to do INTENTIONALLY[1], so this isn't something that’s going to happen by accident. [1] There are a class of security attacks that rely on getting the same PID as a previously/recentl

CrashReportUpdate.txt Hello Justin, Thank you for your reply!!. when i look at the full crash report, in the com.apple.main-thread there is a [_UIKeyboardStateManager updateDelegatePasteSupport] line. i attached the whole crash report to the message. Your help and suggestions would be greatly appreciated.!

Thanks for sharing @Alexander Vasenin! @guillaume-amo asked: This is good news, but why is an update of iOS required? You can think of LLDB as a client-server architecture. In Xcode, your use of the debugger is the client side of the infrastructure involved in enabling the debugger. On the other side of the infrastructure is a server process (called debugserver) that the client is talking to. It's this component that is receiving the debugging commands from the client, managing the Mach task port that allows for a debugger to attach to a running process to inspect and manipulate its state, and sending all of the information and commands back and forth to the LLDB client in Xcode for you to view. While on iOS, the debug server happens to be on a different device than where the debugger client is running, the same architecture is at play if you are working on a macOS app. If you are debugging on the same Mac as where Xcode is running, the client and server components just so happen to be runni

There are indeed many reasons the extension may seem to not run, and you will need to debug this. Among the many causes, the reasons the NSE fails to modify the message could be: it crashes at launch it crashes while modifying or exits early without setting the content and calling contentHandler() it goes over the memory and time limits and is terminated by the system it is trying to access on-disk objects that are not available (perhaps due to security settings) and fails the reentrancy of the NSE causes problems if any global variables/singletons/shared objects are not designed accordingly that the same NSE process could be used for multiple notifications it is unable to be started by the system for some reason (the Console log will show those issues) the extension is not configured or built correctly in your application bundle If you narrow down the issue, we would be able to give some more useful pointers.

Hello Can you post the full, symbolicated crash report? Is the above code snippet your code's only interaction with GCKeyboard? -- Justin

@DTS Engineer Tested with Xcode 26.2 downloaded from the App Store, against iPhone 17 Pro running 26.1 (23B85) Xcode Version 26.2 (17C52) So this property wasn't tested. I haven't touched PermissionKit yet so I wasn't actively testing this, however my wrapper library code still fails for this property too and causes a runtime crash due to symbol not found. AgeRangeService.ParentalControls.significantAppChangeApprovalRequired 55C0A89C-7970-4C69-B5D3-1E6873C6EF2B-diagnostic.json Here is some offending code, assumes iOS 26 minimum target: extension ParentalControls { public init(activeParentalControls: AgeRangeService.ParentalControls) { var value: Int = 0 if activeParentalControls.contains(.communicationLimits) { value |= ParentalControls.communicationLimits.rawValue } if activeParentalControls.contains(.significantAppChangeApprovalRequired) { value |= ParentalControls.significantAppChangeApprovalRequired.rawValue } self.rawValue = value } }