Post not yet marked as solved
The feeback assistant bug was closed since it's only affecting Mojave. https://feedbackassistant.apple.com/feedback/9462633
Post not yet marked as solved
I tried it a few more times and did manage to get a couple crash reports in the console. It's a bit erratic--it doesn't log a crash every time it's killed.
Anyway, from the crash log it's being killed due to the code signing, as expected: Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)).
Post not yet marked as solved
No, it won't even run on the machine it's built on. And it's not crashing--there's no exception or crash log. Zsh seems to be killing the process before it can even hit main (I can't even get it to print out the usage text).
When I have some free time I'm going to recreate the Xcode project from scratch--it's a few years old and has gone through various Xcode updates so maybe some wires got crossed somewhere. A few other projects I have seem to build and run properly, though they produce app bundles rather than a simple executable.
Post not yet marked as solved
When signed with my development cert, codesign prints the following (with identifying information removed). When signed to run locally, it prints similarly appropriate information. In both cases an Intel-only build will run, but an Apple Silicon or Universal Binary build will not.
Executable=/path/to/executable
Identifier=executable
Format=Mach-O universal (x86_64 arm64)
CodeDirectory v=20400 size=1292 flags=0x0(none) hashes=30+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=d8cfc80142a15236c9fb1c7082746b0f0308685b
CandidateCDHashFull sha256=d8cfc80142a15236c9fb1c7082746b0f0308685b33b47e362df97ebbb28b19f7
Hash choices=sha256
CMSDigest=d8cfc80142a15236c9fb1c7082746b0f0308685b33b47e362df97ebbb28b19f7
CMSDigestType=2
CDHash=d8cfc80142a15236c9fb1c7082746b0f0308685b
Signature size=4779
Authority=Apple Development: My Name (XXXXXXXXXX)
Authority=Apple Worldwide Developer Relations Certification Authority
Authority=Apple Root CA
Signed Time=Jan 11, 2022 at 2:15:25 PM
Info.plist=not bound
TeamIdentifier=XXXXXXXXXX
Sealed Resources=none
Internal requirements count=1 size=168
code-block
I tried building a simple Hello World program from the command line, and it works fine when building for Apple Silicon. So the problem is likely something in the Xcode build settings, but nothing looks unusual to me.
Post not yet marked as solved
I've now confirmed that the crash also happens using the texture loader from MetalKit. I've added a simple test application to the feedback ticket.
Post not yet marked as solved
This is for a game under development.
I can't reproduce the problem on either of my own Macs, but when opening a GPU trace made on one of the affected machines I clearly see that two textures (of ~50) are wrong (one is blue, the other corrupted).
The two textures in question (as well as most others) are PNGs loaded via CGImage, copied to an intermediate MTLStorageModeManaged texture, then blitted to a MTLStorageModePrivate texture. Since I don't have physical access to the machine I haven't (yet) been able to narrow down where in this process the texture data becomes corrupted.
Comparing a GPU trace of the same scene made on my machine I can tell the texture sizes and formats are correct--only the pixel data is wrong.
I'll send off a Feedback Assistant post shortly.
Post not yet marked as solved
I'd like to clarify that restarting the application does not fix the problem--only a full computer reboot does.
Post not yet marked as solved
Thanks for the response.
To be clear, this is my own library so reworking how it builds (even abandoning frameworks) is no huge issue. Frameworks for iOS and MacOS are simply convenient packaging for the resources (and Metal shaders) that go with it.
My main concerns here are to 1) make sure there isn't something wrong in my build settings, and 2) understand what's actually happening with the include paths.
I actually tried a custom framework header, but the warning is triggered not only from the umbrella header, but from any of the headers included by umbrella header. It seems that all public includes are expected to only reference the system search paths.
Regarding /usr/local, since that's kinda the typical place to install stuff on any Unix platform, so when installing as a static/shared library--even on Apple platforms--that's where it goes by default. The fact that an older version is installed somewhere on the system shouldn't break the build.
Anyway, I've disabled the warning for the time being. If frameworks are no longer viable for cross-platform code it's seriously annoying and unfortunate, but not catastrophic.
Post not yet marked as solved
Say the structure for project 'mylib' is:
project/include/mylib.h
project/include/header1.h
project/include/header2.h
project/src/file.c
With the resulting framework structure something like:
mylib/Versions/A/mylib
mylib/Versions/A/Headers/mylib.h
mylib/Versions/A/Headers/header1.h
mylib/Versions/A/Headers/header2.h
The new requirements wants only angle brackets in all framework headers, but that doesn't work for internal dependencies. Say 'header2.h' were to try including 'header1.h" with something like:
#include <mylib/header.h>
That include path will be incorrect when building the project--there is no real 'mylib' directory. Maybe Xcode hacks the include paths to magically work, but other toolchains have no way of doing that.
Also, if there's an installed version of the headers in '/usr/local/include/mylib', a normal C toolchain will try to include 'header1.h' from there instead of from the project directory.
It seems to me that Apple (or the clang devs) have redefined what angle bracket includes mean within the context of a framework, and the new definition is not compatible with non-Xcode toolchains.
I currently have the warning disabled, but if at all possible I'd like to be creating properly structured frameworks.
Post not yet marked as solved
In the past couple days I've apparently done something to fix this. The main thing I've been working on is enabling multisampling support, which has primarily involved some changes to render target setup. I don't see anything obvious that would affect depth/stencil state, but who knows what the validation code is actually doing.
Post not yet marked as solved
I'm running into this as well.Disabling Metal validation in the scheme (as suggested) doesn't work, but the crash only seems to happen when running via XCode. A debug build running without the debugger attached is fine.Also, I only see the problem on iOS--an iPhone 8 and 2nd gen iPad Pro in my case. The same code running on Mac OS doesn't hit it.My project is C/Objective-C and ARC is disabled for the code in question. For what it's worth, autoreleasing the MTLDepthStencilState instead of releasing it immediately after encoding it shows the same behaviour.
Post not yet marked as solved
Of course I found the problem 10 minutes after posting.There's a toggle under File->Workspace Settings that controls this behaviour. I expect the preference default changed in XCode 10 or something.
