LLDB crash

Our engineering teams need to investigate this issue. We'd greatly appreciate it if you could open a bug report, include crash logs and sample code or models that reproduce the issue, and post the FB number here once you do. Bug Reporting: How and Why? has tips on creating a successful bug report.

@DTS Engineer FYI posted another FB with an issue reported by users when I compile the screen saver with the SDK from Xcode 26 beta4 and beta5 : FB19580645 It's a backward compability issue that's likely only tangentially related to screen saver, I narrowed it down to a crash with trying to call an unavailable hidden SDK function when opening a XIB with a scrollview. Opening the XIB crash on Sequoia and all previous versions of macOS : FAULT: NSInvalidUnarchiveOperationException: ; (user info absent) Could not instantiate class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView because no class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target) (log above is on Sequoia) The bug appeared in with the SDK of Xcode 26 beta4 as far as I can tell and is still there today with the SDK of Xcode 26 beta

@DTS Engineer as an aside for extra info. I'm adding the xcframework via cocoapods and I have tried to modify the signing of the framework via the following script in the podspec. I know Apple might not encourage the usage of Cocoapods but this is needed so we can distribute our library through several platforms s.script_phase = { :name => 'Sign Framework Binary', :execution_position => :before_compile, :script => <<-SCRIPT echo 🟦🟦🟦🟦🟦🟦🟦 Framework Binary Signing Script === # Use BUILT_PRODUCTS_DIR which points to BuildProductsPath FRAMEWORK_DIR=${BUILT_PRODUCTS_DIR}/../XCFrameworkIntermediates/${PRODUCT_NAME}/sdk.framework # Debug: Print the expected path echo Looking for framework at: $FRAMEWORK_DIR if [ -d $FRAMEWORK_DIR ]; then # Try different ways to get signing identity SIGN_IDENTITY=$EXPANDED_CODE_SIGN_IDENTITY if [ -z $SIGN_IDENTITY ] || [ $SIGN_IDENTITY = - ]; then SIGN_IDENTITY=$CODE_SIGN_IDENTITY fi if [ -z $SIGN_IDENTITY ] || [ $SIGN_IDENTITY = - ]; then # Use the first availab

Thanks. So it sounds like the NSImage is getting over-released or being incorrectly deallocated, although it's unclear to me what exactly is trying to form a weak reference, since my code (as shown above) has a strong reference. Unfortunately the higher up function calls are made by AppKit, which is not open source, so I cannot look it up. As far as I understand, the link you posted helps investigating memory issues in Xcode, but since the crash reports are downloaded by Xcode from other users and I cannot reproduce it myself... The Xcode statistics seem to show that it only happens with macOS 15.3 or newer. I don't know if it's because there's not enough space to show older releases, or if it's really a clue that it's a change introduced with macOS 15.3 that causes this issue. From my perspective it would make sense that it's a new issue with macOS 15.3, because I haven't changed the code that generates or assigns that image in a very long time, and this issue didn't happen for a previous version of

Yes, the .env is just for testing purposes. This entire app is just a tester app, so some quirks are fine and indeed the file does not cause any issues. Here is the crash report of my latest build crashlog.crash Here is the output of the file command $ file OpacityPod_Example OpacityPod_Example: Mach-O 64-bit executable arm64 $ file Frameworks/sdk.framework/sdk Frameworks/sdk.framework/sdk: Mach-O 64-bit dynamically linked shared library arm64 I'm sure I have ran the app with the Release config (done via changing the scheme and selecting run → release). I just tried the Isolating Code Signig Problems from Build Problems you shared. The development option is not there in Xcode 26, but I chose debugging that generated an .ipa which I installed in my device by dragging and dropping. The crash persists on that version. @DTS Engineer

Thanks for the @ mention. I wasn’t notified of your earlier reply )-: So your layout looks pretty reasonable. In comparison, here’s what I see when I use Xcode to build a trivial app with an embedded framework: % find Test795348.app Test795348.app Test795348.app/_CodeSignature Test795348.app/_CodeSignature/CodeResources Test795348.app/Test795348 Test795348.app/Base.lproj Test795348.app/Base.lproj/Main.storyboardc … Test795348.app/Base.lproj/LaunchScreen.storyboardc … Test795348.app/Frameworks Test795348.app/Frameworks/FFF.framework Test795348.app/Frameworks/FFF.framework/_CodeSignature Test795348.app/Frameworks/FFF.framework/_CodeSignature/CodeResources Test795348.app/Frameworks/FFF.framework/FFF Test795348.app/Frameworks/FFF.framework/Info.plist Test795348.app/embedded.mobileprovision Test795348.app/Info.plist Test795348.app/PkgInfo The only obviously wonky thing in your set up is that .env file. I suspect you don’t want to ship that. However, that’s unlikely to cause this crash. So, on to other thi

Hi team, can you please address this, we are facing same crash for iOS 26 users.

Our app has also received many reports of this crash recently. Could you please tell us how to solve it?

but I run from debug, simulator run ok preview always failed, Simulator [E9CBC743-2B12-4EA4-BDAD-2BB05291C83D] failed to boot and may have crashed.

The code is called on the main thread. According to the crash report, thread 0 makes that assignment, Looking at the crash log, the abort originates here: 4 libobjc.A.dylib 0x00000001818d7fc0 _objc_fatal(char const*, ...) + 44 (objc-errors.mm:232) 5 libobjc.A.dylib 0x00000001818a6d78 weak_register_no_lock + 396 (objc-weak.mm:423) 6 libobjc.A.dylib 0x00000001818a6b40 objc_storeWeak + 472 (NSObject.mm:408) As it happen, you don't have to guess at why weak_register_no_lock failed, as the project is opensource. Here is the line that's crashing: _objc_fatal(Cannot form weak reference to instance (%p) of class %s. It is possible that this object was over-released, or is in the process of deallocation., (void*)referent, object_getClassName((id)referent)); That leads to here: and at the same time thread 16 is calling [NSImageView asynchronousPreparation:prepareResultUsingParameters:]. Unfortunately, I wouldn't necessarily assume this call is directly involved. From the large context in th

Whenever you encounter an Xcode crash, make sure to either submit the crash report to Apple through the CrashReporter dialog, or by filing a bug report with the original crash report attached.

Moved my feedback ticket to FB19548156 (iOS 16 Simulators crash due to iOS 17 symbols - Xcode 26 beta 5)

@Engineer Thanks for reply. Some more crash info. On simulator (did not test on device at this stage). Here is crash report: Error occurs in #4 notifyMe IBAction @IBAction func notifyMe(_ sender: UIButton) { let center = UNUserNotificationCenter.current() center.delegate = self center.getNotificationSettings(completionHandler: { (settings) in if settings.authorizationStatus == .notDetermined { center.requestAuthorization(options: [.alert, .sound, .badge]) { (granted, error) in DispatchQueue.main.async { if !granted { // Alert user } } } } else if settings.authorizationStatus == .denied { DispatchQueue.main.async { // Alert user } } else if settings.authorizationStatus == .authorized { DispatchQueue.main.async { self.alarmButton.isHidden = self.duree <= 120 } } }) var alertStyle = UIAlertController.Style.alert let alertController = UIAlertController( title: NSLocalizedString(M'avertir, comment: ), message: NSLocalizedString(Attention, comment: ), preferredStyle: alertStyle) var title = NSL