LLDB crash

Before unlocking device - here understood as caused by device security as first authentication for device yet to be done after restart and device might not have an active network. In our case we can see 4G network symbol is shown on locked device screen. After unlocking device - in this case we can see network symbol 4G is shown on device but still waiting for up to 1/2 minutes App is not receiving VoIP push notification. If User opens App after 1/2 minutes then immediately App is getting VoIP push callback and App showing incoming call popup. In between Caller ends the call and incoming call popup become ghost call. What you're describing above are user level failures. That is, something did not work the way the user thought it should. As a practical matter, that kind of failure doesn't tell you ANYTHING about what's actually going wrong. The next step here is to figure out what actually happened at the system level, then decide how to fix it. Critically, during that process it's very important that you simp

Did you make any changes to CXCallDirectoryProvider or CallKit that may prevent call blocking? No, nothing specific to CXCallDirectory changed. However... (or maybe with the new changes that were introduced with call filtering etc in iOS 26) ...there were lots of changes in this area as part of the introduction of Live Caller ID. I've tried lots of call blocking apps (6 apps) and none of them was able to block a call anymore, so this indicates that this should be an issue on the iOS side. Yes, that sounds reasonably likely. However, I need to jump back and expand on what I said here: There's a crash in callservicesd that might cause what you're describing; however, neither of your bugs has enough diagnostic information to confirm that's the case or whether it's a different issue. Broadly speaking, most developer bugs I look at fall along this spectrum, depending on the level of detail they contain: User bug -> This doesn't work. Developer User bug -> This API/part of my app doesn't work. Minima

I tried removing CoreServices.framework and it didn't work for me, it still crashes. What should I do?

This backtrace is a classic symptom of an over-release bug. Someone has added an object to the autorelease pool and then someone — possible the same code, possibly not — has over released it. When the pool pops, it releases it again, which crashes. I talk about this in depth in Objective-C Memory Management for Swift Programmers. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’d like to clarify your setup. Specifically, I’d like to get a better understanding of the actors involved. You mentioned: Your “client server application” “a file server on the same machine” Copying “using using Finder or terminal using cp” So, is your client/server app one app? Or two? And is the server running locally as well? Or just the client? Is the client/server app related to the file server? Or are you using some standard file server protocol, like SMB? And if it’s a standard file server protocol, are you using the built-in client and server implementations? Or something custom? Also, what version of macOS is this? And do you see any crash reports generated at the time you see this error? Oh, and some random notes… I’m not sure where you got EBROKENPIPE from. The error I’d expect to see when you write to a disconnected socket [1] is EPIPE (32). [quote='794958021, bilbo42, /thread/794958, /profile/bilbo42'] necp_socket_find_policy_match: Marking socket in state 258 as defunct [/quote] NECP

Happening to us as-well. Impossible to do any work when every 2-3min the whole Mac crashes. I can't understand how a company like Apple can release such poor quality software. This is outrageous. Even the smallest of startups working on dev tools, don't release products that crash this often and at this level. What is going on guys?

We got several user complaints about our app that is not working on iOS 26 Public Beta. ... We've filed 2 bug reports with Feedback Assistant: FB19140680 FB19140594 What API are you blocking calls with? Have you looked into what's actually failing (crashing/hanging/etc)? There's a crash in callservicesd that might cause what you're describing, however, neither of your bugs has enough diagnostic to confirm that's the case or whether it's a different issues. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I believe this issue occurs in Swift as well. I’ve seen the crash with Xcode 16.*, and it was resolved by explicitly linking PhotosUI.framework.

I’m glad to hear that Network framework is working for you. Closing the loop on this: I thought [the organiser] had a way to get a JSON crash report, but I don’t have the details. I’m researching that. Apparently there isn’t a way to get JSON crash reports from the organiser (r. 157288005)-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='851050022, Darrilla, /thread/791996?answerId=851050022#851050022, /profile/Darrilla'] Yes, please see my latest responses. [/quote] You mean this post? If so, I see a launchctl load in there but no launchctl start. Those are very different things. Anyway, if you attempted to start the daemon and got no logging, one of two things happened: The daemon failed to start at all. The daemon failed before you got to your log point. I recommend that you rule out the second by creating a ‘first light’ log point, one that runs before any code that could possibly fail. The next step then depends on whether you see that log entry or not. If you do, it’s likely that the daemon crashed and you can look for a crash report. And, failing that, you can march your log point forward until things stop working. If you don’t see the first light log point, I recommend that you look for a crash report. That’s a very common culprit for this. If there’s no crash report, you can deploy launchct

Xcode 26 Beta 4 still crashes the app on iOS 18