“file uri scheme”

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

File a bug report. I think Apple's bug algorithms won't flag anything unless there are multiple reports on the same bug. Although their Music app still can't properly handle gapless song lists reliably (e.g., Pink Floyd) and yet multiple people have been yelling about this over the years, so I may be off base as to how they prioritize their work. I don't think they have anyone to put the fear of God into them any more like Steve Jobs did when the engineers generated bad code.

Report filed: FB22373888

Could you please suggest the recommended approach? First off, as a clarification, what are you actually trying read here? If this is your apps preference file (meaning, it has your apps bundle ID), then NSUserDefaults (or CFPreference) will read automatically without any special code. Similarly, if this ISN'T your apps data, then what's the relationship between your app and the data you're trying to read? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Part 2: No, not really. Memory exceptions (what a seg fault is) happen because you’re accessing memory that you either never allocated or have already freed, neither of which will happen due to direct lack of memory. Keep in mind that your app can't really run out of memory in the way you're describing. SO, the issue here is that the term memory is commonly used to describe two separate, but distinct, concepts: How much RAM your process is using. How much address space your process has been given by the system. The important thing to understand here is that those two factors are somewhat independent of each other. In simple terms, address space is what you actually use when you call “malloc, but RAM usage doesn't change until you actually touch the memory you've malloc'd. Similarly, the question here: is it possible that memory usage has increased significantly in iOS 26.4 compared to previous OS versions? ...doesn't really make sense in the context of address space. Real RAM usage changes considerably from r

Part 1: Thank you for your reply. I have attached the log file. I apologize for the inconvenience, but please take a look. So, starting with the log, the first thing that jumps out at me is that it's ascribing the crash to this stack in thread 0: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread: 0 libsystem_kernel.dylib 0x24a42ccd4 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x24a43030c mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x24a43022c mach_msg2 + 4 [inlined] 3 libsystem_kernel.dylib 0x24a43022c mach_msg_overwrite + 424 4 libsystem_kernel.dylib 0x24a430078 mach_msg + 24 5 CoreFoundation 0x19b9dfea4 __CFRunLoopServiceMachPort + 160 6 CoreFoundation 0x19b9a9f94 __CFRunLoopRun + 1188 7 CoreFoundation 0x19b9a91d0 _CFRunLoopRunSpecificWithOptions + 532 8 GraphicsServices 0x240eb7498 GSEventRunModal + 120 9 UIKitCore 0x1a166d2cc -[UIApplication _run] + 796 10 UIKitCore 0x1a15d8158 UIApplicationMain + 332 11 UnityFramework 0x11cbfbb08 12 sekai 0x1020bbbb8 13 dyld 0x1985bdc1c start + 6928

Thank you all for filing the feedback reports, which do help. If possible, would you please verify with iOS 26.5 beta (23F5043g) to see if the issue goes away, and update the status here? Thanks again! Best, —— Ziqiao Chen  Worldwide Developer Relations.