Unfortunately, this is one of those cases where I can tell you "what" happened in terms of the crash log, but I can't really translate that into the specific issue you need to fix.
In terms of the crash log, the basic answer is that the kernel terminated your app over a "code signing issue". That's what this actually means:
Exception Type: EXC_CRASH (SIGKILL - CODESIGNING)
For completeness, this translates to:
Termination Reason: GUARD 5
"GUARD"-> "EXC_GUARD", the mach exception type that the kernel used when it reported the crash to user space.
"5"-> "GUARD_TYPE_VIRT_MEMORY", meaning the issue came from the VM system.
Pulling all those details together, that means that the VM system detected "an issue" with the signing of the executable pages being loaded into memory and then terminated your app. That's the direct description of what happened but it obviously doesn't help much when it comes to actually fixing anything.
However, there are a few other things that might provide insight if you take all of the crash logs you've received and look at them as a full "set". In particular:
- Are you always crashing at the same EXACT point ("Loader.cpp:2112") or is there ANY variance (edited down for clarity)? The question here is whether the crash is directly tied to a specific "moment" in the loading process, or the kernel's activity is more loosely tied to that app:
0 dyld 0x00000001c9210264 ... dyld4::Loader::applyFixupsGeneric...+ 28 (Loader.cpp:2112)
-
Expanding on that, as part of that comparison make sure you look at the library load list, paying attention to both exactly what frameworks are loaded and the order they're in. I suspect you'll find that the lists line up EXACTLY (order and frameworks), which means we can narrow the problem down to either the last framework in the list ("TDMIDFA") or the NEXT framework that woud have been in the list. The easiest way to find that "next" framework is to either look at any more "normal" crash from the same build (assuming you have any). If you don't have any other crash logs (or any other diagnostic log that includes the symbol list), then you can also try creating a modified build that intentionally crashes once the app finishes launching, then look at that log. Just make sure you keep the build configurations the same.
-
What I'm expecting from 1 & 2 is that you'll basically find "the same thing". If that's not the case, then I'd need to see what that variation actually looks like before I could guess more.
-
Look at the entire log, to look for any correlations in the other data, particularly things you'd normally ignore like the time and file path information. It's easy to overlook, but I've had a few different cases where a crash set that looked serious/mysterious turned out be basically "nothing" after a closer look at that metadata. For example, modified devices can sometimes create very low level crashes in dyld and it's generally not worth spending a lot of time investigating an issue that's only occurring on a very small number of modified devices.
-
If you have it, what does the other MetricKit data from the crashing devices show you? Is your app actually "working" in the broader sense? Are the crashes "mixed in" with successful runs, or did your app crash for "awhile" and then suddenly start working fine? Similar to #4, that might indicate that this was actually caused by modifications to the users device, which the user has already resolved.
Finally, please file a bug on this, include as much crash and metric data as possible, then post the feedback number back here once it's filed. The crash here is strange enough that I'd like the engineering team to take a look at it as well.
-Kevin Elliott
