LLDB crash

In my case the crash was caused indirectly by animating the viewcontrollers change inside splitViewController(_:collapseSecondary:onto:). Not sure if that's allowed by UIKit, but similarly to your case this code has worked for more than a decade without problems until 26.1. Anyway, after removing the animation the issue disappears.

Sorry for the delay responding. I’m running out of workdays for 2025, so I can’t address everything upthread. Instead, I want to post some general guidelines. If DevForums blocks you from posting reasonable content with the message “This post contains sensitive language”, I’d appreciate you filing a bug about that. For instructions on how to do that, see the end of this post. After that, you’ll need a workaround. Here’s how to use a binary search to find the problematic text: As part of the bug reporting process, you saved a copy of your post to a text file. Make a copy of that file. Open it in your text editor of choice. Select half of the file and delete it. Copy the remaining text and try to post that. If it works, undo the delete, select the other half, delete that, and go back to step 4. Make sure to click the Edit button next to your post rather than posting a second reply. If it fails, go back to step 3 and continue dividing. Eventually you’ll get down to something super small and you can usually find

Whether this entitlement is assigned on a single app or your team account would depend on the entitlement team's evaluation of your use case at the time you have made the request. This would be determined on a case by case basis, and the information you received at the time you made the request and received the entitlement would have explained your usage limitations. Best would be to contact the entitlement team and inquire about the state of your entitlement assignments. White-labelled apps could be different, depending on what you exactly mean by white-labeled. If the apps are being published by your clients directly, they will need tp apply and acquire the entitlement separately. In any case, this sounds like you would be better off contacting the entitlements team and inquire. On the technical side, you could be encountering some other issue, like a build problem not configuring the extension correctly, the extension not being launched, or crashing, etc. Using the Console app and filtering on you

[quote='867322022, DTS Engineer, /thread/808198?answerId=867322022#867322022'] Can you share an example crash report? [/quote] my app was crashing because I was improperly saving the stream I would create like this try await connection.inboundStreams(prepending: { quicStream in TLV { quicStream } }) { stream in await self.receiveMessages(from: stream, connectionID: connectionID) } I learned via Cursor that those streams are one time use and do not need to be saved.

I sincerely apologize for the delayed response! I have also confirmed on my end that the combination of Xcode 26.1.1 and iOS 26.1 works properly without any crashes. Thank you to everyone who provided comments and to those who worked on addressing this issue.

So, let me start with the critical one here: I've seen a few cases where quitting or crashing the FSModule process while a volume is mounted without actually doing a clean unmount causes a lot of disk-related actions (for lack of a better term) to freeze (FB21305906). Can you confirm that this is happening in macOS 15.7.3 (24G416) in upload a new sysdiagnose if it is? The FSKit team believes it should have been fixed in that release. In terms of the other two bugs (FB21287341 & FB21287688), the answer is basically yes, that's what's going on. FSKit is built on top of our standard app extensions infrastructure, which is then terminating your extensions as part of its normal process for handling these cases. That's certainly not ideal for something like volume mounting but changing the behavior is significantly more complicated than simply fixing a bug. However, that does mean you have an option here: Is there a way to prevent the extension's process from terminating in this case and/or another wor

In my practice dealing with CallKit, I came to the conclusion that changing CXProvider configuration during a call is a bad idea. Sometimes this was causing providerDidReset being called, and the first call got dropped. Can you confirm or deny my observation? That's hard to say. On its own, I wouldn't expect it to be an issue or, more specifically, it's much more likely to trigger a pending failure than it is to create one. As background context, the primary cause of providerDidReset is mediaserverd itself crashing, not normal system behavior. I'm sure there are cases where a call to setConfiguration was the direct trigger, but that doesn't mean that NOT calling setConfiguration would have prevented the crash. It's also possible/likely that setConfiguration DID actually cause providerDidReset... because the media system was already in a bad state, and the setConfiguration call is what caused callservicesd to detect a problem. However, having said all that... Do you suggest calling setConfigu

First off, one other question I should have asked earlier— what does the crash log you're getting from the SIGKILL actually show? Is it just random state (whatever your app happened to be doing at the time)? Or does it show a pattern, particularly anything tied to your app’s own quit cycle? One possibility that I didn't cover here is that your app IS getting 'quit', but something is going wrong and stalling things long enough that the system kills you. I see, so quit AppleEvent is kinda like the Windows WM_QUIT message. Yes, except WM_QUIT is like the 'quit', since the AppleEvent came first. Yes, AppleEvents are that old. We definitely will file a bug. Bug number? In the meantime, the documentation for Sudden Termination says it's for shutdown. Unfortunately, the phrasing in our documentation is using trickier wording that it really should. Here's what it actually says: macOS 10.6 and later includes a mechanism that allows the system to log out or shut down more qu

It can be reproduced in AS's lab, Mac M4 crashed after running ATTO Burn-in in 20~40 minutes. And there is an error report pop up on Mac M4 host.