CoreData dyld crash using Xcode 12.5 with macOS 10.12 deployment

Hi, is there any news on this. I have the same problem in a private library which throws the same error on macOS 10.13. What I found so far is, that for a lot of people adding the "CoreData" framework as a library to the target in question fixed the problem.

But for me the problem persists. I just upgraded to Xcode 13.0 and the problem continues to exists there. I have also cocoa pods in use which might change some of the build settings and maybe it has something to do with that also?

Anyone has more details on why this error is happening?

It should be possible to build a CoreData project with a modern version of Xcode and back deploy it to an old version of macOS. I recommend that you create a new Core Data test app from the macOS > App template and see if ti has the same problem. That’ll tell you whether this is a general issue or something specific to your project setup.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So I'm asking myself how does macOS try to find the system provided libraries like CoreData?

That is a complex question in general, but in this case it’s pretty straightforward. When your app links with a framework, the system adds a load command to the app that tells the dynamic linker where to find that framework and what version numbers are acceptable. You can use otool to dump that info. In the case of my trivial test app, I see this:

% otool -L Test685780.app/Contents/MacOS/Test685780 
Test685780.app/Contents/MacOS/Test685780:
    …
    /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData (compatibility version 1.0.0, current version 1048.0.0)
    …

So, what does this show for your test app? And for your real app?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Some updates:

• I have searched my system for CoreData framework versions with the specified version, but found none.
• I have removed a lot of library paths settings to see if this helps, but to now avail.

I have a new clue which I can not investigate right away, but I searched for the version number which according to the comment was and will never be used by the CoreData framework and found the following output on another web page:

/System/Library/Frameworks/Foundation.framework/Foundation (compatibility version: 300.0.0, current version: 1775.118.101) 

which corresponds completely regarding the version number. So I'm now assuming that this might be indicative of a problem with the Foundation Framework for some reason being called "CoreData". For me it looks like it takes the version number of the Foundation Framework but adds it as a dependency called "CoreData". And it might also be that this has something to do with the use of cocoapods, which I use in my project.

When I have time again I will investigate this finding further.

Hi there,

so I guess I figured it out...

After understanding more about the build process I figured that there must be some library that exposes itself something like this:

Load command 4
cmd LC_ID_DYLIB
cmdsize 48
name /System/Library/Frameworks/CoreData.framework/CoreData (offset 24)
time stamp 2 Thu Jan  1 01:00:02 197
current version 1775.118.101
compatibility version 300.0.0

After writing some scripts to find and check all the libraries on my system I couldn't find any libraries that advertised itself fitting the above.

What I instead found was the following library:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd

The library advertised itself like this:

install-name:    '/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation'
current-version: 1775.118.101
compatibility-version: 300

which actually looked fine.

But when I inspected it further one thing caught my eye. There were entries that looked like this:

symbols:         [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$',

So there was a reference to "CoreData.framework" which I was looking for because of the previous findings. The only references in this file to "CoreData.framework" were to this single NSDetailedErrorsKeys symbol.

After fiddling around with the build process and getting some more clues, I looked at my code and it actually used NSDetailedErrorsKey in one place.

When I removed the reference in my code and built the app again I could verify (with otool -L) that indeed, the none-existing reference to

/System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 300.0.0, current version 1775.118.101)

was gone in the built library. And so were the problems getting the app to work on macOS 10.13.

I'm still not sure why this error occurs, but I'm pretty confident that it has to do with the

symbols:         [ '$ld$previous$/System/Library/Frameworks/CoreData.framework/CoreData$$1$10.9$999$_NSDetailedErrorsKey$',

entries inside of the

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.tbd

file. My thought is that if I use NSDetailedErrorsKey that it finds it mentioned in this file and creates this hybrid of a version number from the Foundation framework but by the name of the CoreData framework which results in this linking that is never going to resolve on "normal" systems.

Looking at the file

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData.tbd

I can confirm that the NSDetailedErrorsKey is also defined as a symbol here (which to me seems to be the correct place since it is a CoreData symbol).

So my guess would be that it is an error that the entries are also present in the Foundation.tbd file. I might file a radar about this issue, if nobody can explain why that is happening.

Another option of preventing this issue from occurring might be to change the order of the included frameworks and/or the search paths so that maybe the system would find the correct CoreData.tbd file first, which also might get rid of this problem.

That’s some good spelunking!

My thought is that if I use NSDetailedErrorsKey that it finds it mentioned in this file and creates this hybrid of a version number from the Foundation framework but by the name of the CoreData framework which results in this linking that is never going to resolve on "normal" systems.

Yeah, that’s super weird, and based on the info you provided I was able to reproduce the problem in a new project that I created here in my office. I’ve filed my own bug about this (r. 84254696).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

did you need to mess with the framework search path order to make this misbehave the same way?

No. The trick was:

• Reference NSDetailedErrorsKey in my code

• Turn off auto link

• Link with Foundation but not CoreData

So I guess your radar is enough or should I also create one?

My bug should be sufficient but if you create your own bug and ask it to be dup’d to mine then you’ll be notified when it get fixes.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"