Thank you Quinn - that fully explains the results I'm seeing. Trust in the source.

I think it's a problem because 4502 is the most frequent ttl returned by mDNSResponder and there is no explanation in the documentation as to why this should be. It looks to me like a hard-coded default response. Maybe it is a maximum allowable ttl or indication of some other network error. When I used libresolv (as I presume is used by dig and host) I did not have this issue. I have attached a debug log from my application to FB23574201 which may help.

That didn't work as expected/hoped for. After flushing the DNS cache (dscacheutil etc..) I checked the kDNSServiceFlagAnsweredFromCache and it does toggle on the second query for the same IP address, indicating a network result for the first query and from the cache in the second case. However in both cases it returns this value of 4502 as the TTL. I was expecting a more reasonable value for the first case where the resolver was clean.

Thanks Quinn. Much appreciated.

I am caching the results of the query until the ttl expires. The application is monitoring network traffic and may see several thousand IP addresses in a short time period. I did read the documentation in the header and it seemed to me that the portion quoted only applies when the async operation is left running. If it applies to all queries then maybe it should be the first line in the documentation, but that's quibbling. This strategy worked well when using libresolv. My workaround for now is to cache the result for 300 seconds if I see the specific value of 4502. Thanks for your input.

Thanks Quinn. I suspected that to be the case but great to have it confirmed.

Thank you Quinn. I always appreciate your help. It's a pity that sfltool doesn't allow removing all traces of a given job to get around these issues, but I take your point about testing on a clean VM. Thanks again

Thanks Quinn I have worked around this by removing the NSMenu.delegate assignment from the .xib and called myMenu.delegate = self after return from the NSAlert.runModal() call.

To help clarify the above, the menuWillOpen() function is declared as an AppDelegate:NSMenuDelegate extension. extension AppDelegate: NSMenuDelegate { func menuWillOpen(_ menu: NSMenu) { if menu == myMenu { // enable/disable menu items } } } @NSApplicationMain class AppDelegate: NSObject, NSApplicationDelegate { @IBOutlet weak var myMenu: NSMenu! // NSApplicationDelegate functions }

Sorry for the noise. I had forgotten to add '.plist' to the id when running launchctl unload. All fixed now. The root process is started from AuthorizationExecuteWithPrivileges and then a setuid(0) before running launchctl. I know that's frowned upon but hopefully by the time the deprecated call disappears any affected users will have already updated :)

I had a similar experience, although I did not see the dialog you posted. In my case it was reported as an ssh failure. Like you, I could do a git push from the command line but Xcode was failing. To get it working I edited ~/.ssh/known_hosts and deleted all entries to do with my git server. I then manually logged into the git server (via ssh) and when prompted accepted the connection, adding the keys to known_hosts. Following that Xcode "push" was working again. I have no idea as to why the failure occurred but I am happy that it is working now.

getifaddrs() will return the IPv4 & IPv6 addresses of each interface. This in most cases, especially for IPv4, will be an address on the users local network. If you're after the users public IP address you will have to use some other method, such as visiting one of the many sites on the internet, via an http(s) request, that will reply with the connecting address.

This problem appears to be fixed in XCode 16 Beta 2. I don't see any mention of the problem in the release notes but I have successfully compiled and run an application on an intel Mac with macOS Sonoma 14.5 and Xcode 16 Beta 2.

I am seeing this same crash when running XCode 16 on a macOS 14.5 (sonoma) host. The minimum deployment for the project is macOS 10.13. There is nothing in the Xcode 16 release notes about macOS 13.0 being a required minimum deployment. so I don't think that is a solution.

Look in the 'More downloads' tab https://download.developer.apple.com/Developer_Tools/Xcode_14.3.1/Xcode_14.3.1.xip