LLDB crash

Since updating to iOS 16.4.1, our app crashes randomly with the following error message. Exception Codes: 0x0000000000000001, 0x0000000199d542c0 Termination Reason: SIGNAL 5 Trace/BPT trap: 5 Terminating Process: exc handler [499] Triggered by Thread: 2 Thread 2 Crashed: 0 libdispatch.dylib 0x199d542c0 _dispatch_assert_queue_fail + 120 1 libdispatch.dylib 0x199d54248 dispatch_assert_queue + 196 2 UIKitCore 0x1949c870c -[UIImageView _mainQ_beginLoadingIfApplicable] + 88 3 UIKitCore 0x19495db34 -[UIImageView setHidden:] + 68 4 UIKitCore 0x19492f128 -[UIButtonLegacyVisualProvider _updateImageView] + 372 5 UIKitCore 0x19492ed78 -[UIButtonLegacyVisualProvider layoutSubviews] + 116 6 UIKitCore 0x19492ecc4 -[UIButton layoutSubviews] + 40 7 UIKitCore 0x1948fbef4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1920 8 QuartzCore 0x193db64ac CA::Layer::layout_if_needed(CA::Transaction*) + 500 9 QuartzCore 0x193dc9a28 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148 10 QuartzCore 0x1

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive. We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18. Here's our Objective-C code which presents the picker: NSArray* contentTypeArray = @[UTTypeAppleArchive]; UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES]; docPickerVC.delegate = self; docPickerVC.allowsMultipleSelection = NO; docPickerVC.shouldShowFileExtensions = YES; docPickerVC.modalPresentationStyle = UIModalPresentationPopover; docPickerVC.popoverPresentationController.sourceView = self.view; [self presentViewController:docPi

Testing Environment: iOS Version: 26.0 Beta 7 Xcode Version: 17.0 Beta 6 Device: iPhone 16 Pro Description: We are implementing the new BGContinuedProcessingTask API and are using the wildcard identifier notation as described in the official documentation. Our Info.plist is correctly configured with a permitted identifier pattern, such as com.our-bundle.export.*. We then register a single launch handler for this exact wildcard pattern. We are performing this registration within a UIViewController, which is a supported pattern as BGContinuedProcessingTask is explicitly exempt from the register before applicationDidFinishLaunching requirement, according to the BGTaskScheduler.h header file. The register method correctly returns true, indicating the registration was successful. However, when we then try to submit a task with a unique identifier that matches this pattern (e.g., com.our-bundle.export.UUID), the BGTaskScheduler.shared.submit() call throws an NSInternalInconsistencyException and terminates the app.

I'm trying to implement Unwanted SMS and Calls reporting in an app I'm doing in my idle time. If I place a UITextField or UITextView inside a ILClassificationUIExtensionViewController, every time I select on such control the extension crashes without any logs. The closet idea I have on why it crashes it has something to do with iOS requesting the dictation feature. I'm using the latest (beta 8 at the time) iOS 16.0 beta on my iPhone 13 pro. Attaching my code here if you want to try for yourself: github

According to the ARM documentation for the CPU models available in Apple Silicon, the CoreSight implementation includes an Embedded Trace Macrocell which can perform a complete Instruction Trace (https://developer.arm.com/documentation/102119/0200/What-is-trace-). Although other operating systems such as Linux make this easy, we have not been able to find any tools or even a system-level API for accessing this feature of the ETM. In the Instruments window of Xcode 16+, there is a Processor Trace instrument, but this performs sampling and is totally unrelated to the Instruction Trace we need for debugging and analysis purposes. Because it produces a complete, contiguous sequence of branch instructions, the Instruction Trace is essential for identifying precise execution behaviors that are otherwise invisible to the developer. On other platforms, an alternative is debugger scripting, but we have found far too many bugs and reliability issues with the macOS implementation of lldb. Any suggestions would

Hey, We also opened a feedback assistant request, and also opened a ticket with Apple Developer Technical Support a while ago that notice the unmount problem also but it was before we pin point the problem to the Network Extension. After a further investigation, we've found out that the root cause of this problem is cause by having a network filter from the NetworkExtension provider on (Specifically we have tested with the NEFilterDataProvider) while having a Xsan volume. The NEFilterDataProvider causing problems for the Xsan, and is stalling the shutdown until we get a panic from watchdog timeout, and only then the mac is fully shutdown. The problem from what we investigated and also talked with you, is that the Xsan process can't unmount the volume and stuck. We have also noticed that if we install a network extension and allow the popup of the network filters, i.e enabled the NEFilterDataProvider the computer is stuck, and the finder is in a non responsive state until a reboot (Also probably due to the fac

Hi everyone, I’m encountering a memory overflow issue in my visionOS app and I’d like to confirm if this is expected behavior or if I’m missing something in cleanup. App Context The app showcases apartments in real scale using AR. Apartments are heavy USDZ models (hundreds of thousands of triangles, high-resolution textures). Users can walk inside the apartments, and performance is good even close to hardware limits. Flow The app starts in a full immersive space (RealityView) for selecting the apartment. When an apartment is selected, a new ImmersiveSpace opens and the apartment scene loads. The scene includes multiple USDZ models, EnvironmentResources, and dynamic textures for skyboxes. When the user dismisses the experience, we attempt cleanup: Nulling out all entity references. Removing ModelComponents. Clearing cached textures and skyboxes. Forcing dictionaries/collections to empty. Despite this cleanup, memory usage remains very high. Problem After dismissing the ImmersiveSpace, memory does not return to