Intermittent issue resulting in relocations not being applied to DYLD Shared Cache

[WeiN76LQh]

Version and Platform (required):

• Binary Ninja Version: 5.3.8652-dev Ultimate (f6637a1a)
• Edition: Ultimate
• OS: macOS
• OS Version: 15.6
• CPU Architecture: M1

Bug Description:
Relocations appear to not be being applied but its only happening on the odd occasion. This is resulting in sections looking like this:

Foundation::__DATA_CONST.__objc_superrefs (REGULAR) section started  {0x1e6c0ebf8-0x1e6c0fb60}
1e6c0ebf8  int64_t data_1e6c0ebf8 = 0x1000006e576f20
1e6c0ec00  int64_t data_1e6c0ec00 = 0x1000006e576ef8
1e6c0ec08  int64_t data_1e6c0ec08 = 0x1000006e577ae0
1e6c0ec10  int64_t data_1e6c0ec10 = 0x1000006d64a508
1e6c0ec18  int64_t data_1e6c0ec18 = 0x1000006d646950
1e6c0ec20  int64_t data_1e6c0ec20 = 0x1000006d646658
1e6c0ec28  int64_t data_1e6c0ec28 = 0x1000006e577100
1e6c0ec30  int64_t data_1e6c0ec30 = 0x1000006e578bc0
1e6c0ec38  int64_t data_1e6c0ec38 = 0x1000006e579598
1e6c0ec40  int64_t data_1e6c0ec40 = 0x1000006d646e00
1e6c0ec48  int64_t data_1e6c0ec48 = 0x1000006d647c60
1e6c0ec50  int64_t data_1e6c0ec50 = 0x1000006d6453e0
1e6c0ec58  int64_t data_1e6c0ec58 = 0x1000006d647e20
1e6c0ec60  int64_t data_1e6c0ec60 = 0x1000006d645c20
1e6c0ec68  int64_t data_1e6c0ec68 = 0x1000006e5780f8
1e6c0ec70  int64_t data_1e6c0ec70 = 0x1000006e57a308
1e6c0ec78  int64_t data_1e6c0ec78 = 0x1000006e5760f0
1e6c0ec80  int64_t data_1e6c0ec80 = 0x1000006e578f30
1e6c0ec88  int64_t data_1e6c0ec88 = 0x1000006d649838
1e6c0ec90  int64_t data_1e6c0ec90 = 0x1000006d6497c0

Steps To Reproduce:
I have not been able to reproduce it reliably but I think when it does occur the steps look something like this:

1. Load a copy of the DYLD Shared Cache in Binary Ninja with options and maybe change a default option like one of the Objective-C processing options (in my case I have it inside a folder in a project).
2. Wait for analysis to complete.
3. Right-click in the linear view and select Load Image by Name.
4. Load the Foundation image.
5. Wait at least 5 seconds for the image to load a bit but then close the binary view as it doesn't need to finish analyzing the new image.
6. Repeat steps 1-4 but double click to open DYLD Shared Cache instead of right-click opening with options.
7. Observe that sometimes on loading the image all the sections with relocations end up with unrelocated pointers causing lots of processing errors.

Additional Information:
I've only observed and tested this for iOS 26 23A341 iPhone18,2. It could be an iOS 26 issue but I'm getting the impression its either a race condition or some state is not getting reset between loads of the DYLD Shared Cache.