LLDB crash

[quote='728498021, _anteloper, /thread/728498, /profile/_anteloper'] FamilyActivityPicker freezes and crashes [/quote] Please try again on the latest iOS 26 beta (beta 6 or newer). This should have been addressed by now. At least on my device I can no longer reproduce the crash.

[quote='773601021, _anteloper, /thread/773601, /profile/_anteloper'] the FamilyActivityPicker crashes [/quote] Please try again on iOS 26 beta 6 or newer, this should be addressed now!

Thanks for the additional context. Consider the backtrace in your original post: 3 MyEatApp … specialized Set._Variant.insert(_:) + 4333923052 (:4333923052) 4 MyEatApp … HomeViewModel.hanldeAnnouncementCard(from:) + 293 (HomeViewModel+PersonalizedOffer.swift:293) That makes it clear that you’re failing on this line: handledAnnouncementIds.insert(offer.itemID) handledAnnouncementIds is a Set, so it’s really hard to see how this would be because of a hashing problem. Can you reproduce this in your office? Or are you debugging this based on crash reports coming in from the field? Regardless, please post a full Apple crash report for this. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Xcode version: 26.0 Beta 6 solved the crash for me

I've been pulling my hair out, even after pulling everything out in to a on a simple Multi-platform project, with two demos. ASK and Not ASK. If ASK isn't completely branched it burns BT radios. In the flagship sample project private static let pinkDice: ASPickerDisplayItem = { let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = DiceColor.pink.serviceUUID return ASPickerDisplayItem( name: DiceColor.pink.displayName, productImage: UIImage(named: DiceColor.pink.diceName)!, descriptor: descriptor ) }() I only see bluetoothServiceUUID provided, in the docs however: Each display item’s descriptor, a property of type ASDiscoveryDescriptor, needs to have a bluetoothCompanyIdentifier or bluetoothServiceUUID, and at least one of the following accessory identifiers: bluetoothNameSubstring A bluetoothManufacturerDataBlob and bluetoothManufacturerDataMask set to the same length. A bluetoothServiceDataBlob and > bluetoothServiceDataMask set to the same length. It wasn't until I removed bluetoothN

{imageOffset:4403460,imageIndex:0}, -xamarin_unhandled_exception_handler (in TheApp) (runtime.m:1129) {imageOffset:8159120,imageIndex:0}, -native_to_managed_trampoline_23(objc_object*, objc_selector*, _MonoMethod**, objc_object*, objc_object*, unsigned int) (in TheApp) (registrar.mm:1453) {imageOffset:8169364,imageIndex:0}, -[AppDelegate application:didFinishLaunchingWithOptions:] (in TheApp) (registrar.mm:7895) The system was in the process of launching your app, having reached the didFinishLaunchingWithOptions: method. That method started to call Xamarin code, which threw an exception. Since that's all code specific to Xamarin and not Apple's SDK, you should get in contact with Xamarin's support to figure out how to debug your app's crash from this point. — Ed Ford,  DTS Engineer

I'm seeing this too, it started recently, I guess with an Xcode update. My MacOS app is using CoreImage / NSImage a lot. The stack trace usually ends in: std::__1::__hash_table [..], qosWaiterSignallerInvariantCheck, etc... I haven't seen the crash yet in production, but I see it very easily in a debug build, within a few minutes. Any help would be appreciated.

[quote='854059022, zhenYang, /thread/796647?answerId=854059022#854059022, /profile/zhenYang'] we did not find the r.54802623 bug. [/quote] Right. That was an internal bug and you don’t have access to it. I talk more about why I post such bug numbers in Bug Reporting: How and Why? [quote='854059022, zhenYang, /thread/796647?answerId=854059022#854059022, /profile/zhenYang'] Could you please advise what might have caused this? [/quote] There’s no easy answer to that question. Historically this crash has been triggered by a range of concurrency problems within CFNetwork. However, as I mentioned previously, we believe that those were fixed by iOS 17. So, if you’re seeing this crash in iOS 17 and later, then this is a new bug with similar symptoms. Are you seeing this on iOS 18? That matters because it’s reasonable to file a bug against iOS 18. However, if the problem is limited to iOS 17 then there’s little point filing a bug about this because, even if we were able to find and fix it, there’s no

[quote='797255021, swiftuiforever, /thread/797255, /profile/swiftuiforever'] Is this possible while inserting a String into Set [/quote] I’m not 100% sure. Historically it might’ve been possible to get into this situation if you had a custom subclass of NSString, but I tried that here in my office today and I’m not able to trigger it any more [1]. The most common source of errors like this is folks not maintaining the Hashable invariant. I explain that in detail below. Are you sure that frame 4 is working with Set rather than some custom type? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] For custom NSString subclasses, the compiler seems to eagerly bridge the contents over to a native String. One of the fundamental requirements of Hashable is that, if you values are equal, they must have the same hash [1]. This is what allows containers like Set and Dictionary to use hashing to speed up things up: They put each value in a bucket based

@DTS Engineer no matter what I tried I could not get this to work. I tried a .tbd file, using the -export-symbols-list flag, passing individual functions, etc. They get stripped every time. I ended up injecting the functions into the library at runtime. Functions are declared normally: void ios_prepare_request(const char *url) { ... } Then in my library I created a function that takes the function pointers, which I call when I load it: NSBundle *frameworkBundle = [NSBundle bundleWithIdentifier:@com.opacitylabs.sdk]; [frameworkBundle load]; opacity_core::register_ios_callbacks(ios_prepare_request); It's more verbose on my side but there is no runtime crash anymore. Thanks for the help anyways!