“file uri scheme”

The issue isn't just with CKSyncEngine. I have a custom CloudKit-based syncing setup, which uses CKRecordZoneSubscription to listen and respond to changes in a zone, and the remote notifications aren't working with that either. I filed FB22380044 ... hopefully this can be patched up with a quick update, as it would break so many apps

Thanks Quinn, that was exactly the right pointer. We traced through the disassembly of xzm_main_malloc_zone_init_range_groups on macOS 26.3.1 and correlated it with the open source in rel/libmalloc-792 (xzone_segment.c:1210-1250). Here's what we found: The CONFIG_MACOS_RANGES path computes: ptr_reservation_size = XZM_RANGE_SEPARATION + XZM_POINTER_RANGE_SIZE + XZM_RANGE_SEPARATION = 4G + 16G + 4G = 24 GiB ptr_start = 16GiB + (entropy % 736) * 32MiB It then calls mach_vm_map with VM_FLAGS_FIXED for 24 GiB at ptr_start. The 736 granules cover [16 GiB, 39 GiB), ensuring the reservation fits under the 63 GiB commpage limit. Why dylibs land above 16 GiB: The binary is a Chromium component-build test binary (browser_tests) that loads 516 Chromium dylibs plus system libraries (1543 images total). The main executable alone consumes 5.54 GiB of VA (4 GiB __PAGEZERO, 517 MiB __TEXT, 1.04 GiB __LINKEDIT). The 516 Chromium dylibs add another 10.19 GiB of aggregate VM (2.26 GiB __TEXT, 3.86 GiB __LINKEDIT). Combined with

The latter. I will file a feedback report for user related behaviour change.

[quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] We are actually seeing seeing this happen in practice. [/quote] OK. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] it's not deterministic. [/quote] Right. It’s hard to say what’s going on without more logging, but the most likely cause is a memory pressure exit, and that’s very non-deterministic. [quote='882312022, dopey, /thread/820940?answerId=882312022#882312022, /profile/dopey'] I will open a bug and post the bug number. [/quote] Much appreciated. Ideally this would include a sysdiagnose log taken: On a device with extra CryptoTokenKit logging enabled (see below) Shortly after seeing the problem But that might be hard to get, so you should feel free to file a bug with only your ‘kill ctkd’ step as evidence. On the logging front, our Bug Reporting > Profiles and Logs only has a CryptoTokenKit profile for iOS. However, you can install that profile on macOS, and I think

Hi Quinn, Following up on your earlier advice about using NEAppProxyUDPFlowHandling and the async readDatagrams / writeDatagrams API. I’ve updated my DNS proxy as follows: I now implement NEAppProxyUDPFlowHandling and handle DNS over UDP via the async API. For each flow, I store the Network.NWEndpoint that comes from readDatagrams() and then pass that same endpoint back into writeDatagrams. I no longer use NWHostEndpoint / NetworkExtension.NWEndpoint anywhere in this path. Relevant code (stripped down): private func readFirstDatagrams(from udpFlow: NEAppProxyUDPFlow, into flow: Flow, channel: Channel) { Task { let (pairs, error) = await udpFlow.readDatagrams() if let error = error { // handle error... return } guard let pairs = pairs, !pairs.isEmpty else { // retry... return } let (firstData, firstEndpoint) = pairs[0] let size = firstData.count MainLogger.shared.log(message: UDP recv (pairs.count) datagrams, first size=(size) from=(firstEndpoint) type=(type(of: firstEndpoint)) ) // Force a hostPort endpoint l

The 3 in that error is KERN_NO_SPACE, which is a pretty clear indication that the system memory allocator asked for address space and the kernel refused to give it. However, given all the constraints you’ve described, it’s not at all clear why that would be. Weirdly, the code that traps this way is not on the main branch of the Darwin open source, but I found a copy in the rel/libmalloc-792 branch [1]. Now, I don’t have time today to study that code in depth, but I figured you’d find it interesting (-: AFAICT it tries to allocate address space by using mach_vm_map to map MEMORY_OBJECT_NULL, specifying a start that’s after 16 GiB, such that it fits within 64 GiB, with a randomly applied offset. That random bit probably explains why this shows up so infrequently. It’s hard to say why this is failing. You might be able to learn more by running vmmap against the dying process. It’d also be interested to know what address was passed to mach_vm_map (with reference to the source, that’s the ptr_addr value), somethin

This issue has been filed via Feedback Assistant as FB22377067.

Yeah, the resource fork is just another named fork. For APFS compression, my understanding is that it's using a com.apple.decmpfs named fork, and we see those methods from the APFS kext in the stack. Disassembling revisiond and checking the stack crawl, it appears to be working with com.apple.genstore.* xattrs. We are still trying to identify which file(s) are involved, but so far, any logging messes with the timing to hide the problem and lsof just hangs due to the rwlock, but perhaps it's down in .DocumentRevisions-V100. The underlying xattr access is an implementation detail, though it probably is visible to the ES client. I will check to see if calls to extended attributes and named forks (directly or indirectly) are reported that way to the ES hooks. clone the file yourself and then operate on the clone. That's an interesting thought, especially for the copy-on-write features. I will take it back to the team to consider.

Hello, @andy_nash, @StonedStudio, @tom_krikorian, @Dokug, and @zepsec! I’m happy to report that this issue is now resolved in the OS 26.5 beta 1 simulators that we released today with Xcode 26.5 beta 1. If you still see crashes or errors that mention a “team ID” after updating to the OS 26.5 beta 1 simulators, then please file a new feedback report and reply to this thread with the feedback ID. Note that there’s still a separate known issue that prevents the URL override from working in simulator environments. I’ll post again in this thread when that separate issue is fixed. Thanks!

Hello, @ota.seiji! I’m happy to report that issue with subsequent download cancellations is fixed in OS 26.5 beta 1, which we released to developers today. If you still encounter the issue after updating to OS 26.5 beta 1, then please file a new feedback report and reply to this thread with the feedback ID. Thanks!

You can also kill it by sudo pkill -9 remotepairingd If you encounter an instance where you actually find this necessary, please file a Feedback Assistant Report which includes a devicectl diagnose (and separate mac / phone / watch sysdiagnoses if they're not all collected by it). There are no known issues for which this step should be necessary, so if there are issues, we want to know about them. make sure NOT to un-pair your device If you un-pair or you accidentally tap the button to not trust, the only way to get the prompt to appear again is by physically re-connecting the phone. watch is ON throughout the connecting process Yes, and it needs to remain unlocked throughout the DDI mounting process as well. If the device locks before the DDI mounting completes, you will need to re-attempt mounting the DDI. --Jeremy jeremyhu at apple dot com

I was mostly thinking of its interaction with extended attributes, as we see the target threads touching those as well. Just to clarify something, what's really going on here isn't really xattr access. The resource fork has a bit of a strange history, as it predates general xattr support by ~15 years and doesn't really fit into the same mold as any other xattr. It originally had its own API access path through FSReadFork and the ..namedfork/rsrc suffix to open and, more importantly, is routinely MUCH larger than any other xattr, most of which are measured in “bytes. The resource fork was basically added to the more general xattr implementation, rather than being implemented as a native part of the original implementation. Several years ago, we repurposed the resource fork and used it to implement file system level compression of specific files, which is what's happening here. Critically, these files look like standard data files and are accessed by reading the file