There are multiple report of crashes on URLConnectionLoader::loadWithWhatToDo. The crashed thread in the stack traces pointing to calls inside CFNetwork which seems to be internal library in iOS.
The crash has happened quite a while already (but we cannot detect when the crash started to occur) and impacted multiple iOS versions recorded from iOS 15.4 to 18.4.1 that was recorded in Xcode crash report organizer so far.
Unfortunately, we have no idea on how to reproduce it yet but the crash keeps on increasing and affect more on iOS 18 users (which makes sense because many people updated their iOS to the newer version) and we haven’t found any clue on what actually happened and how to fix it on the crash reports. What we understand is it seems to come from a network request that happened to trigger the crash but we need more information on what (condition) actually cause it and how to solve it.
Hereby, I attach sample crash report for both iOS 15 and 18.
I also have submitted a report (that include more crash reports) with number: FB17775979.
Will appreciate any insight regarding this issue and any resolution that we can do to avoid it.
iOS 15.crash
iOS 18.crash
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Our app uses a 24-hour DeviceActivityMonitor repeating schedule to send users notifications for every hour of screen time they spend on their phone per day. Notifications are sent from eventDidReachThreshold callbacks at 1, 2, 3, etc, hour thresholds to keep them aware of their screen time.
We have recently received an influx of emails from our users that after updating to iOS 17.6.1 their DeviceActivityMonitor notifications are saying their screen time was much higher than what is shown in DeviceActivityReport and their device's Screen Time settings.
These users have disabled "Share Across Devices" - but I suspect the DeviceActivityMonitor is still getting screen time from their other devices even though that setting is turned off.
Has anybody else noticed this, understands what is causing this, or could recommend a fix that we can tell our users to do?
Hi folks, I'm building an iOS companion app to a local hosted server app (hosted on 0.0.0.0). The MacOS app locally connects to this server hosted, and I took the approach of advertising the server using a Daemon and BonjourwithTXT(for port) and then net service to resolve a local name. Unfortunately if there's not enough time given after the iPhone/iPad is plugged in (usb or ethernet), the app will cycle through attempts and disconnects many times before connecting and I'm trying to find a way to only connect when a viable en interface is available.
I've run into a weird thing in which the en interface only becomes seen on the NWMonitor after multiple connection attempts have been made and failed. If I screen for en before connecting it simply never appears. Is there any way to handle this such that my app can intelligently wait for an en connection before trying to connect? Attaching my code although I have tried a few other setups but none has been perfect.
func startMonitoringAndBrowse() {
DebugLogger.shared.append("Starting Bonjour + Ethernet monitoring")
if !browserStarted {
let params = NWParameters.tcp
params.includePeerToPeer = false
params.requiredInterfaceType = .wiredEthernet
browser = NWBrowser(for: .bonjourWithTXTRecord(type: "_mytcpapp._tcp", domain: nil), using: params)
browser?.stateUpdateHandler = { state in
if case .ready = state {
DebugLogger.shared.append("Bonjour browser ready.")
}
}
browser?.browseResultsChangedHandler = { results, _ in
self.handleBrowseResults(results)
}
browser?.start(queue: .main)
browserStarted = true
}
// Start monitoring for wired ethernet
monitor = NWPathMonitor()
monitor?.pathUpdateHandler = { path in
let hasEthernet = path.availableInterfaces.contains { $0.type == .wiredEthernet }
let ethernetInUse = path.usesInterfaceType(.wiredEthernet)
DebugLogger.shared.append("""
NWPathMonitor:
- Status: \(path.status)
- Interfaces: \(path.availableInterfaces.map { "\($0.name)[\($0.type)]" }.joined(separator: ", "))
- Wired Ethernet: \(hasEthernet), In Use: \(ethernetInUse)
""")
self.tryToConnectIfReady()
self.stopMonitoring()
}
monitor?.start(queue: monitorQueue)
}
// MARK: - Internal Logic
private func handleBrowseResults(_ results: Set<NWBrowser.Result>) {
guard !self.isResolving, !self.hasResolvedService else { return }
for result in results {
guard case let .bonjour(txtRecord) = result.metadata,
let portString = txtRecord["actual_port"],
let actualPort = Int(portString),
case let .service(name, type, domain, _) = result.endpoint else {
continue
}
DebugLogger.shared.append("Bonjour result — port: \(actualPort)")
self.resolvedPort = actualPort
self.isResolving = true
self.resolveWithNetService(name: name, type: type, domain: domain)
break
}
}
private func resolveWithNetService(name: String, type: String, domain: String) {
let netService = NetService(domain: domain, type: type, name: name)
netService.delegate = self
netService.includesPeerToPeer = false
netService.resolve(withTimeout: 5.0)
resolvingNetService = netService
DebugLogger.shared.append("Resolving NetService: \(name).\(type)\(domain)")
}
private func tryToConnectIfReady() {
guard hasResolvedService,
let host = resolvedHost, let port = resolvedPort else { return }
DebugLogger.shared.append("Attempting to connect: \(host):\(port)")
discoveredIP = host
discoveredPort = port
connectionPublisher.send(.connecting(ip: host, port: port))
stopBrowsing()
socketManager.connectToServer(ip: host, port: port)
hasResolvedService = false
}
}
// MARK: - NetServiceDelegate
extension BonjourManager: NetServiceDelegate {
func netServiceDidResolveAddress(_ sender: NetService) {
guard let hostname = sender.hostName else {
DebugLogger.shared.append("Resolved service with no hostname")
return
}
DebugLogger.shared.append("Resolved NetService hostname: \(hostname)")
resolvedHost = hostname
isResolving = false
hasResolvedService = true
tryToConnectIfReady()
}
func netService(_ sender: NetService, didNotResolve errorDict: [String : NSNumber]) {
DebugLogger.shared.append("NetService failed to resolve: \(errorDict)")
}
}
When running the currently latest version of macOS (26.1) on a machine with ARM CPU (I could not reproduce the issue with Intel-Based machines) Finder Sync extensions do not work any more in general.
Steps to reproduce the problem:
In Xcode create a new macOS App project with default settings (in my case I chose XIB for the UI and Objective-C as language, and disabled testing, but that should not make any difference)
In Xcode add a new target / "Finder Sync Extension" to the project with default settings, this adds a new Finder Sync Extension with example code to the app.
Run the application and open Finder and navigate to "/Users/Shared/MySyncExtension Documents"
In the system settings ("Login Items & Extensions") enable the extension (Listed as "File Provider").
On systems where it is working, in the context menu of that folder an entry "Example Menu Item" will appear. On systems where it does not work it is missing.
Some findings:
Adding the *.appex with "pluginkit -a" registers the extension as expected, it is then visible in the system settings, removing it with "pluginkit -r" is also reflected in the system settings.
"pluginkit -m -i " returns the extension on systems where it is working (assuming it is registered while this command is executed), on systems wehre it is not working, nothing is returned, regardless of the registration state.
When enabling the extension in the system settings nothing more happens, there is no process started for the extension (unlike as on systems where it is working), and thus no context menu entries and no badges are displayed in Finder.
Restarting Finder or the system does not help.
Any ideas what I could be missing here?
Hi Apple Dev Team & Community,
We’ve encountered an issue with background location updates when using an XCFramework we’ve built from our main app.
Context:
We have a standalone app called TravelSafely that reliably performs background location updates and alerts, even during sleep mode.
From this app, we extracted some core functionality into an XCFramework, including location management, and provided it as an SDK to a client.
We created a demo app to test this SDK in isolation.
Problem:
In the demo app, we notice that location updates work fine in the foreground.
However, in the background or sleep mode, location updates sometimes stop completely.
When we bring the app to the foreground again, location resumes.
This does not happen in the original standalone app.
What We’ve Already Checked:
UIBackgroundModes includes location
Info.plist has the required permissions
Location is started correctly using startUpdatingLocation
We maintain strong references and use background tasks as needed
Question:
Why would an app using a binary XCFramework (with location logic) behave differently from the original app in terms of background execution?
Is there any known issue or recommendation when working with SDKs/XCFrameworks that need to manage background tasks and location updates?
Any insights or recommendations to maintain proper background behavior would be highly appreciated.
Thank you!
Topic:
App & System Services
SubTopic:
Maps & Location
Tags:
Frameworks
Core Location
Background Tasks
I am pretty sure iOS 13.4 (beta and later) did support Coded PHY (Long Range). Tested devices are iPhone SE2 and iPhone 11 Pro.
However, it seems iOS 14 removed the support of Coded PHY, accidentally or on purpose, I don't know?
The same PHY update request returns "1M PHY" in iOS 14, but "Coded PHY" in iOS 13 (13.4 beta and later).
Anyone knows why?
Samson
Hello,
I’m reaching out to gather information regarding the upcoming changes to APNs certificates that are set to be implemented in the beta at the end of January 2025.
Specifically, I would like to understand the following:
What will be the practical impact of these changes on apes apis ?
What actually needed to be done at trust store for this changes, and how will it affect our current setup?
What steps do we need to take to update the certificates on our servers?
it’s crucial for us to address these changes in advance and keep our customers informed.
Thank you for your help!
I have a watchOS app with a connected iOS app using Swift and SwiftUI. The watchOS app should read heart rate date in the background using HKOberserQuery and enableBackgroundDelivery(), send the data to the iPhone app via WCSession. The iPhone app then sends the data to a Firebase project.
The issue I am facing now it that the app with the HKObserverQuery works fine when the app is in the foreground, but when the app runs in the background, the observer query gets triggered for the first time (after one hour), but then always get terminated from the watchdog timeout with the following error message:
CSLHandleBackgroundHealthKitQueryAction scene-create watchdog transgression: app<app.nanacare.nanacare.nanaCareHealthSync.watchkitapp((null))>:14451 exhausted real (wall clock) time allowance of 15.00 seconds
I am using Xcode 16.3 on MacOS 15.4
The App is running on iOS 18.4 and watchOS 11.4
What is the reason for this this issue? I only do a simple SampleQuery to fetch the latest heart rate data inside the HKObserverQuery and then call the completionHandler. The query itself takes less than one second.
Or is there a better approach to read continuously heart rate data from healthKit in the background on watchOS? I don't have an active workout session, and I don't need all heart rate data. Once every 15 minutes or so would be enough.
I am trying to setup a system-wide DNS-over-TLS for iOS that can be turned off and on from within the app, and I'm struggling with the implementation details. I've searched online, searched forums here, used ChatGPT, and I'm getting conflicting information or code that is simply wrong. I can't find example code that is valid and gets me moving forward.
I think I need to use NEDNSProxyProvider via the NetworkExtension. Does that sound correct? I have NetworkExtension -> DNS Proxy Capability set in both the main app and the DNSProxy extension.
Also, I want to make sure this is even possible without an MDM. I see conflicting information, some saying this is opened up, but things like https://developer.apple.com/documentation/Technotes/tn3134-network-extension-provider-deployment saying a device needs to be managed. How do private DNS apps do this without MDM?
From some responses in the forums it sounds like we need to parse the DNS requests that come in to the handleNewFlow function. Is there good sample code for this parsing?
I saw some helpful information from Eskimo (for instance https://developer.apple.com/forums/thread/723831 ) and Matt Eaton ( https://developer.apple.com/forums/thread/665480 )but I'm still confused.
So, if I have a DoT URL, is there good sample code somewhere for what startProxy, stopProxy, and handleNewFlow might look like? And valid code to call it from the main app?
I implemented BGContinuedProcessingTask in my app and it seems to be working well for everyone except one user (so far) who has reached out to report nothing happens when they tap the Start Processing button. They have an iPhone 12 Pro Max running iOS 26.1. Restarting iPhone does not fix it.
When they turn off the background processing feature in the app, it works. In that case my code directly calls the function to start processing instead of waiting for it to be invoked in the register block (or submit catch block).
Is this a bug that's possible to occur, maybe device specific? Or have I done something wrong in the implementation?
func startProcessingTapped(_ sender: UIButton) {
if isBackgroundProcessingEnabled {
startBackgroundContinuedProcessing()
} else {
startProcessing(backgroundTask: nil)
}
}
func startBackgroundContinuedProcessing() {
BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { @Sendable [weak self] task in
guard self != nil else { return }
startProcessing(backgroundTask: task as? BGContinuedProcessingTask)
}
let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: title, subtitle: subtitle)
request.strategy = .fail
if BGTaskScheduler.supportedResources.contains(.gpu) {
request.requiredResources = .gpu
}
do {
try BGTaskScheduler.shared.submit(request)
} catch {
startProcessing(backgroundTask: nil)
}
}
func startProcessing(backgroundTask: BGContinuedProcessingTask?) {
// FIXME: Never called for this user when isBackgroundProcessingEnabled is true
}
On iOS 18, I'm trying to index documents in Spotlight using the new combination of AppIntents+IndexedEntity.
However, I don't seem to be able to index the textContent of the document. Only the displayName seems to be indexed.
As recommended, I start with the defaultAttributeSet:
/// I call this function to index in Spotlight
static func indexInSpotlight(document: Document) async {
do {
if let entity = document.toEntity {
try await CSSearchableIndex.default().indexAppEntities([entity])
}
} catch {
DLog("Spotlight: could not index document: \(document.name ?? "")")
}
}
/// This is the corresponding IndexedEntity with the attributeSet
@available(iOS 18, *)
extension DocumentEntity {
var attributeSet: CSSearchableItemAttributeSet {
let attributeSet = defaultAttributeSet
attributeSet.title = title
attributeSet.displayName = title
attributeSet.textContent = docContent
attributeSet.thumbnailData = thumbnailData
attributeSet.kind = "document"
attributeSet.creator = Constants.APP_NAME
return attributeSet
}
}
How can I have more that the displayName to be indexed? Thanks :-)
I abandoned Mac development back around 10.4 when I departed Apple and am playing catch-up, trying to figure out how to register a privileged helper tool that can execute commands as root in the new world order. I am developing on 13.1 and since some of these APIs debuted in 13, I'm wondering if that's ultimately the root of my problem.
Starting off with the example code provided here:
https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api
Following all build/run instructions in the README to the letter, I've not been successful in getting any part of it to work as documented. When I invoke the register command the test app briefly appears in System Settings for me to enable, but once I slide the switch over, it disappears. Subsequent attempts to invoke the register command are met only with the error message:
`Unable to register Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted}
The app does not re-appear in System Settings on these subsequent invocations. When I invoke the status command the result mysteriously equates to SMAppService.Status.notFound.
The plist is in the right place with the right name and it is using the BundleProgram key exactly as supplied in the sample code project. The executable is also in the right place at Contents/Resources/SampleLaunchAgent relative to the app root.
The error messaging here is extremely disappointing and I'm not seeing any way for me to dig any further without access to the underlying Objective-C (which the Swift header docs reference almost exclusively, making it fairly clear that this was a... Swift... Port... [Pun intended]).
I am developing a background application that acts as a metadata server under MacOS written in Swift. Sandboxed clients prompt the user to select URLs which are passed to the server as security scoped bookmarks via an App Group and the metadata will be passed back. I don't want the I/O overhead of passing the complete image file data to the server. All the variations I have tried of creating security scoped bookmarks in the client and reading them from the server fail with error messages such as "The file couldn’t be opened because it isn’t in the correct format." Can anyone guide me in the right direction or is this just not possible?
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags:
Files and Storage
App Sandbox
XPC
Dear Girls, Guys and Engineers.
I'm currently building a Home Network Scanner App for People which want to know which Bonjour Devices are in her/his Home Network environment. From an older Question I got the answer, that I need an Entitlement to do this.
I started to work on the App and requested the Multicast Entitlement from Apple. They gave me the Entitlement for my App and now I'm trying to discover all devices in my Home Network but I got stuck and need Help.
I only test direct on device, like the recommendation. I also verified that my app is build with the multicast entitlement there where no problems. My problem is now, that is still not possible to discover all Bonjour services in my Home Network with the Help of the NWBrowser.
Can you please help me to make it work ?
I tried to scan for the generic service type:
let browser = NWBrowser(for: .bonjour(type: "_services._dns-sd._udp.", domain: nil), using: .init())
but this is still not working even tough I have the entitlement and the app was verified that the entitlement is correctly enabled
if I scan for this service type, I got the following error:
[browser] nw_browser_fail_on_dns_error_locked [B1] Invalid meta query type specified. nw_browser_start_dns_browser_locked failed: BadParam(-65540)
So what's the correct way now to find all devices in the home network ?
Thank you and best regards
Vinz
Problem description
Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments.
We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested.
Out of the many issues our main app exhibits, the test app showcases some:
The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access.
The app shows a different Local Network Usage Description than in the project's plist.
Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off.
We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings.
Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior?
Related material
Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement.
Local Network FAQ
Technote TN3179
Steps to Reproduce
Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested.
On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1).
We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist.
The app properly shows packets are received from the console on our LAN.
We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed.
We then reboot the machine. After reboot, the same list does not show the app anymore.
We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received.
After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine.
We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version.
The updated version also asks for Local Network access, this time with proper Usage Description.
A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app.
We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off.
We toggle on one of the app, all of them toggle on. All 3 versions have local network access.
Recently, I've noticed that background Bluetooth scanning stops when I move an app to the background on an iPhone 17 device with Bluetooth 6. I'm curious about a solution. Background Bluetooth scanning doesn't stop on devices older than iOS 26, or on devices that were updated from an iPhone 17 or earlier to iOS 26.
Recently, we have observed that after upgrading to OS 15.4.1, some devices are experiencing network issues.
We are using a Network Extension with a transparent app proxy in our product. The user encounters this issue while using our client, but the issue persists even after stopping the client app.
This appears to be an OS issue.
Below is the sytem logs.
In the system logs, it says [C669.1 Hostname#546597df:443 failed transform (unsatisfied (No network route), flow divert agg: 2)] event: transform:children_failed @0.001s
In scutil --dns, it says not reachble.
DNS configuration
resolver #1
flags :
reach : 0x00000000 (Not Reachable)
resolver #2
domain : local
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300200
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300400
resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300600
resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 300800
resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags :
reach : 0x00000000 (Not Reachable)
order : 301000
We need to restart the system to recover from the issue.
I have successfully booted the Linux Kernel with VirtIOFS as the rootfs, but file permission issues render it completely unusable. A file on the macOS host belongs to uid 0, gid 0, but on the Linux guest, this file belongs to uid 1000, gid 10. Why does this happen? How are file permissions directly mapped between the host and the guest? If there is no mapping mechanism in place, why does this discrepancy occur? This leads to errors in Linux, such as:
sudo: /etc/sudo.conf is owned by uid 1000, should be 0
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
bootLoader.commandLine = "console=hvc0 rootfstype=virtiofs root=myfs rw"
let directorySharingDevice = VZVirtioFileSystemDeviceConfiguration(tag: "myfs")
directorySharingDevice.share = VZSingleDirectoryShare(directory: VZSharedDirectory(url: rootURL!, readOnly: false))
The VMM is running as root.
Hi,
I’m looking for guidance on enabling push notifications for new emails in the native iOS Mail app (com.apple.mobilemail).
Currently, I send push notifications using macOS Server (formerly OS X Server) Mail, but since it has been discontinued and renewal is no longer possible, I want to transition to the standard method used by email providers to notify the stock Mail app about new messages.
To achieve this, I need access to the com.apple.mobilemail.push.com.zuplu APNs topic. This follows the same pattern used by other providers:
iCloud: com.apple.mobilemail.push.com.me.mail.castle
Fastmail: com.apple.mobilemail.push.com.fastmail
Since Fastmail (as a third-party provider) has access to this, I assume there is a way for independent mail providers to integrate with XAPPLEPUSHSERVICE.
In the interest of a free market and fair competition, I trust that Apple provides a means for email providers to notify the stock Mail app of IMAP server changes, allowing it to fetch new messages instantly.
Under EU competition law, particularly Article 102 TFEU, dominant companies must not engage in anti-competitive behavior, including restricting access to essential services in a discriminatory manner. Furthermore, the Digital Markets Act (DMA) explicitly prohibits gatekeepers from favoring their own services or restricting interoperability without justification.
Any insights or official guidance would be greatly appreciated!
Thanks,
DragonWork
We have a customer reporting a bunch of problems with our (Transparent Proxy Provider-based) suite. Looking at a sysdiagnose, I see that our GUI applet was killed:
Termination Reason: Namespace PORT_SPACE, Code 14123288431434181290 (Limit 305834 ports) Exceeded system-wide per-process Port Limit
Looking at the top.txt file from it, I see that it has 193,086 ports -- compared to about ~250 on one of my test systems.
Has anyone run into this? Any idea what might be causing it? (I'm still poring over the sysdiagnose, but I don't see any kernel logs around that time -- except that our process does close a dozen or so ports because of cancellation.)