I'm not sure how reply notifications work here, so I will duplicate my reply as a comment – I responded here. Filed a feedback (FB20884404), and put together a sample that repros for me locally: https://github.com/jamieQ/ld-branch-island-nondeterminism

Thanks for the suggestion, however I'm having trouble figuring out how to use the '-debug_snapshot' option appropriately. At the moment I'm debugging by locally running a script to perform the linker invocation (via a call through clang), not using Xcode. When I pass the debug snapshot option as you suggested, I'm unable to locate any resulting files in the /tmp/*.ld-snapshot dir (or the presence of that directory at all). Are there other parameters I should be adding somewhere?

@Polyphonic Could you clarify your point about dispatch_apply's queue parameter? Is the 'target queue' terminology in the 'discussion' section of that method's documentation referring to the 'dispatch object target queue' (i.e. the target queue of the queue parameter, if any) or the queue parameter itself?

@cliffr one of the crashing instances we observed appeared to be due to the use of uppercaseStringWithLocale when returning the section header. The workarounds we found were to either rewrite that code in Swift or to copy the uppercased string before returning it. Assuming that you're using ARC, copying will also autorelease, which appears to be sufficient to make the strings live through whatever internal loop in CoreData that isn't explicitly retaining them long enough.

The solution to 1. is to avoid returning section names in an order that does not match the sort descriptor's ordering. The docs explicitly state that you must do this, though the resulting memory corruption seems like a bug. I'm not certain of a general solution to 2., but you might try adding an additional copy call to the strings returned from sectionNameKeyPath, or converting the implementation to Swift. Both of these seemed to work in the sample project I submitted to Apple.

We had crash reports that were only occurring on the iOS 16.1 betas that pointed in the direction of this issue. Once a reproducible case was found, running with NSZombie detection enabled (edit scheme > diagnostics > zombie objects) revealed that there was a use-after-free bug.