LLDB crash

[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!

We observed the crash rdar53306264 in both Xcode → Organizer → Crashes and our third-party crash monitoring system. It has been occurring on both iOS 16 and iOS 17, and we did not find the r.54802623 bug. Another concern is that this crash appeared in large volumes during a certain period of time. Could you please advise what might have caused this? We are worried that it may happen again in the future.

Hi, this is because you are using an older Xcode (beta 3) with a newer OS (beta 6). During beta, we make changes to the API based on developer feedback, so we do not guarantee the compatibility of runtime symbols (ABI) between beta versions. This crash is unrelated to Intel or not. The best way to resolve this is installing an Xcode that matches your OS.

Thanks for the .ips file. Using that crash report I was able to track down a bunch of different bug reports about crashes with similar signatures. My reading of the ‘lead’ bug (r. 54802623) is that we believe this is fixed by iOS 17 and later. Have you seen any crashes like this after iOS 16? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The NSImageView is in fact in an NSTableView, and I call NSImageView.bind(:to:withKeyPath:options:) in the callback passed to NSObject.observe(:options:changeHandler). The observer is added when the table cell view's objectValue is set, then removed again when it is set to nil. I'll add a call to NSImageView.unbind(.value) and see if that solves the crash. Your code has me a bit confused. How do you modify the contents of the NSImageView? Are you: Modifying the property of MyObject? (going through the binding) Modifying objectValue? (directly modifying the view cell) It feels like you're somewhat awkwardly set up to do both, which seems like an unnecessary complication. In the first case, there's no reason to remove any views, as you're simply doing a one-timing binding to a specific NSImageView. In the second case, you could drop binding entirely and simply directly assign the image whenever it changes. My concern here is that mixing both puts you in an odd situation, since going through #2 will rem

For me this crashes: let session = LanguageModelSession() but this does not: let session = LanguageModelSession(instructions: Some Instructions) Devices: MacBook Pro in Sequoia 15.6, Xcode 26 Beta 4, iPad Pro iOS 26 Beta 6

MyApp-2025-08-07-170843.txt This is an ips crash log

When any image view is being destroyed, make sure you're setting the target image to null and you've torn down any KVO infrastructure you've created that's tied to that object The NSImageView is in fact in a NSTableView, and I call NSImageView.bind(_:to:withKeyPath:options:) in the callback passed to NSObject.observe(_:options:changeHandler). The observer is added when the table cell view's objectValue is set, then removed again when it is set to nil. I'll add a call to NSImageView.unbind(.value) and see if that solves the crash. class MyCellView: NSTableCellView { private var observer: NSKeyValueObservation? override var objectValue: Any? { didSet { if let objectValue = objectValue as? MyObject { observer = objectValue.observe(.property) { [weak self] _, _ in for view in subviews { view.removeFromSuperview() } let imageView = NSImageView(image: nil) imageView.bind(.value, to: objectValue, withKeyPath: keyPath) addSubview(imageView) } } else { observer = nil } } } } That's generally a reasonable stat

I could understand that this crash could be caused by multiple threads releasing the image at the same time, but if only the main thread is accessing them, I cannot imagine how they could be over-released. I'm not doing any manual memory management with them or their parent object. If you have any example of how over-releasing could happen without thread contention and manual memory management, I'd be eager to hear it. Otherwise, I'll let you know as soon as I'm able to reproduce the crash. So, I took another look at your crash log and our code and had a bit more information to share. So, let me start here: 7 AppKit 0x000000018667d860 -[_NSAsynchronousPreparation initWithDelegate:parameters:] + 104 (NSAsynchronousPreparation.m:97) After a second pass through our code, I think the object that's actually at issue here isn't the image, it's the NSImageView. A few things to look at due to that: As a general comment, KVOs’ reputation is extremely... mixed. My own opinion is deeply skewed