“LLDB crash”

The challenge we are facing is that certain functionality does not behave correctly when the app resumes the next day without a normal cold start. The primary issue is with the SLM (Sound Level Meter) framework, which relies on audio sessions. In these resumed states, the audio session is not always reinitialized cleanly, causing our calibration process to fail and leading to the core issue we observed. If you haven't already, this sounds like something worth filing a bug about. Have you, and if so, what's the bug number? More recently, we encountered a case where we did not even receive the applicationDidEnterBackground callback. We extended the same force-exit handling to cover this scenario as well. Do you have any more information/context about this case? There are cases where apps aren't formally put into the background (for example, I believe swiping control center down will trigger applicationWillResignActive but NOT applicationDidEnterBackground), but all of these cases should also mean that the app i

It’s hard to offer insight here without a full Apple crash report. Does anyone have one of those? If so, please post it here. See Posting a Crash Report for advice on how to do that. [quote='870052022, brianindeed, /thread/810678?answerId=870052022#870052022, /profile/brianindeed'] Do these [iOS] versions correspond to the RC or the GM? [/quote] You can tell that from the format of the build numbers. For example, in 23C5027f you have: 23 — This maps to the major version number, in this case iOS 26. C — This maps to the minor version number [1], making it iOS 26.2. 50 — This contains the build number prefix; see below for more on that. 27 — This is the actual build number. f — This is something internal that I’m not going to go in to. In seed builds we prefix the build number with a digit indicating the type of build, padding it up to three digits with leading zeroes. So 5027 is build 27 with a build type of 5 [2]. In released builds we don’t do this padding. For example, the release build of

I've been seeing this crash occurring as well in crash reports. Does anyone know what could be causing or possible solution on this?

Hello Allen, Thanks for filing the crash report with the full crash log. Just to confirm, are you overriding viewWillTransitionToSize:withTransitionCoordinator:, and if so, can you please provide the relevant code in the method? Thank you for your patience, Richard Yeh  Developer Technical Support

Here is my work around for UIKit extension UIViewController { @objc func configureAsPopoverWith(sender: Any?) { self.modalPresentationStyle = .popover var enableZoom: Bool = true var source: Any? = sender #if targetEnvironment(macCatalyst) // PopOver with Zoom crashes for macOS 26 if #available(iOS 26.0, *), let view = (sender as? UIBarButtonItem)?.value(forKey: view) as? UIView { source = view } enableZoom = false #endif if let sourceView = source as? UIView { self.popoverPresentationController?.sourceView = sourceView self.popoverPresentationController?.sourceRect = sourceView.bounds if #available(iOS 18.0, *), enableZoom { self.preferredTransition = .zoom { _ in sourceView } } } else if let sourceItem = source as? UIBarButtonItem { self.popoverPresentationController?.barButtonItem = sourceItem } } }

I recommend that you start a new thread about this, making sure to include the details of this crash. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm experiencing the exact same crash in UIKit. With UIBarButtonItems and Popovers. On Mac Catalyst app build with Xcode 26.2 (17C52) on Tahoe 26.2. Same will happen with UIView as a source when presenting the a UIViewController if a zoom transition is set vc.preferredTransition = .zoom { _ in sendingView } Setting the info.plist UIDesignRequiresCompatibility to YES, prevents the default zoom transition and shows the popup with arrows.

Hi, We're able to implement the speech framework. For some reason my app crashes when clicking Allow for the Speech permission pop up. Upon rebuilding it works fine, as the permission appears as granted.

[quote='873184022, iceboy, /thread/811084?answerId=873184022#873184022, /profile/iceboy'] The user previously … [/quote] Well, that’s quite an edge case. Having said that, just because it’s an edge case doesn’t mean it shouldn’t work |-: [quote='873189022, iceboy, /thread/811084?answerId=873189022#873189022, /profile/iceboy'] And what is the basis for generating this value? [/quote] I can’t go into those details. I don’t know off the top of my head but, even if I did, I’m reluctant to discuss implementation details like this unless there’s some specific benefit to it. And I’m not seeing that here. Rather, this is clearly something that you should report as a bug. IMPORTANT For this bug to get any sort of traction, you’ll need a sysdiagnose log. I’m presuming you can’t reproduce that yourself, so you’ll need to ask your user to either send you the sysdiagnose log or file their own bug, attach the log there, and send you the bug number. Ideally they’d trigger this sysdiagnose log immediately after the

crash infomation： *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Feedback generator was deactivated by its client more times than it was activated: <_UIZoomEdgeFeedbackGenerator: 0x33527cdc0>' *** First throw call stack。 stack（main thread）： 1 CoreFoundation ___exceptionPreprocess (in CoreFoundation) 2 libobjc.A.dylib _objc_exception_throw (in libobjc.A.dylib) 3 CoreFoundation +[NSException raise:format:] (in CoreFoundation) 4 UIKitCore -[UIFeedbackGenerator _deactivateWithStyle:] (in UIKitCore) 5 Foundation ___NSFireDelayedPerform (in Foundation) 6 CoreFoundation _CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION (in CoreFoundation) 7 CoreFoundation ___CFRunLoopDoTimer (in CoreFoundation) 8 CoreFoundation ___CFRunLoopDoTimers (in CoreFoundation) 9 CoreFoundation ___CFRunLoopRun (in CoreFoundation) 10 CoreFoundation __CFRunLoopRunSpecificWithOptions (in CoreFoundation) 11 GraphicsServices _GSEventRunModal (in GraphicsServices) 12 UIKitCore -[UIAppl

I got an answer directly from Apple: You've hit upon one of the most common and often confusing limitations in CarPlay development, the template stack depth limit. For most CarPlay apps, the navigation stack depth is limited to two templates. This means you can have a root template, and then push one more template on top of it. Attempting to push a third template will result in the maximum level exception you're seeing. Apple's first-party apps (like Music, Maps, Phone) often have special entitlements and UI paradigms that are not available to third-party developers, my apologies. Third-party apps that qualify for specific categories (e.g., audio, navigation, EV charging, parking, food ordering) can use CPTabBarTemplate, but even then, each tab's stack is still limited to two. Yes, the crash reports and the maximum level exception are clear indicators of exceeding the template stack depth. This is not a bug in your code's logic, but rather a design constraint imposed by CarPlay for safety reasons. Si

SO, I actually think this is what you need to take a much closer look at: Thread 4 (Crashed Thread): Has already received the hardware interrupt for the first command (TEST UNIT READY) and is attempting to invoke the completion API. More specifically, why EXACTLY did that hardware interrupt occur? The assumption you seem to be making is that the system called UserProcessBundledParallelTasks and then wasn't ready to process the completion when your interrupt fired. However, I think what actually happened is slightly different and that UserProcessBundledParallelTasks wasn't actually called at all, and that the interrupt handler fired for other reasons. That leads to my comment here: This also explains why our synchronous test succeeded: within the scope of UserProcessBundledParallelTasks, the system ensures that the target is already fully established and the action pointer is valid. Strictly speaking, that's true but not in the way you're thinking. What's actually going on here is that the system firs

Thanks for the post, hard to see the crash log for developers here to try to give you ideas. Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report. https://developer.apple.com/forums/thread/688669 Thanks Albert Pascual
  Worldwide Developer Relations.