iOS 15 dyld Crash

This is kinda weird. Before you spend too much time on it, consider:

OS Version:          iPhone OS 15.0 (19A5340a)
Release Type:        Beta

This is a beta build of iOS 15. Unless you’re seeing similar crashes coming in from release builds, I’d ignore this.

If you are seeing similar crashes from an iOS 15 release build, post an example here and I’ll take another look.

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

Unluckily I see the crashes also on the release version of iOS 15 and also on iOS 15.0.1. All crash dumps I see look quite similar. So I'll attach 2 of them. I hope you have an idea what the issue could be.

Unluckily I see the crashes also on the release version of iOS 15 and also on iOS 15.0.1.

Bummer.

All crash dumps I see look quite similar. So I'll attach 2 of them.

You’ve redacted them with stars, which limits what I can do with the them. Can you post them again, this time redacting them using the technique described in Posting a Crash Report.

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

I redacted the files, I hope it's okay now.

I hope it's okay now.

Perfect. Thanks!

On the plus side, these crash reports rule out a wide variety of gnarly problems with similar symptoms. On the minus side, they don’t actually suggest what the problem might be.

In both cases we see this:

Exception Type:  EXC_CRASH (SIGKILL)

which suggests that the process was killed from outside. The two crash reports have different backtraces, namely this:

Thread 0 Crashed:
0   dyld … strcmp + 12
1   dyld … objc::StringHashTable::tryGetIndex(char const*) const + 140 (OptimizerObjC.h:114)
2   dyld … dyld4::PrebuiltObjC::ObjCOptimizerImage::visitReferenceToObjCSelector(objc::SelectorHashTable const*, dyld3::Map<char const*, dyld4::Loader::BindTarget, dyld3::HashCString, dyld3::EqualCString> con... + 48 (PrebuiltObjC.cpp:440)
3   dyld … dyld3::MachOAnalyzer::forEachObjCSelectorReference(unsigned long long, unsigned long long, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned long long, unsigned long long, bool&) block_p... + 128 (MachOAnalyzer.cpp:5109)
4   dyld … dyld4::PrebuiltObjC::forEachSelectorReferenceToUnique(dyld4::RuntimeState&, dyld3::MachOAnalyzer const*, unsigned long long, dyld4::ObjCBinaryInfo const&, dyld3::MachOAnalyzer::VMAddrConverter cons... + 144 (PrebuiltObjC.cpp:1013)
5   dyld … dyld4::PrebuiltObjC::make(Diagnostics&, dyld4::RuntimeState&) + 2600 (PrebuiltObjC.cpp:729)
6   dyld … dyld4::PrebuiltLoaderSet::makeLaunchSet(Diagnostics&, dyld4::RuntimeState&, dyld4::MissingPaths const&) + 476 (PrebuiltLoader.cpp:1737)
7   dyld … dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2260 (dyldMain.cpp:680)
8   dyld … start + 412 (dyldMain.cpp:869)

and this:

Thread 0 Crashed:
0 dyld … ___ZNK5dyld46Loader18applyFixupsGenericER11DiagnosticsRNS_12RuntimeStateERKN5dyld35ArrayIPKvEESB_bRKNS6_INS0_21MissingFlatLazySymbolEEE_block_invoke_3 + 24 (Loader.cpp:1192)
1 dyld … dyld3::MachOAnalyzer::forEachRebase_Opcodes(Diagnostics&, dyld3::MachOLoaded::LinkEditInfo const&, dyld3::MachOFile::SegmentInfo const*, void (char const*, dyld3::MachOLoaded::LinkEditInfo const&, ... + 424 (MachOAnalyzer.cpp:6374)
2 dyld … dyld3::MachOAnalyzer::forEachRebaseLocation_Opcodes(Diagnostics&, void (unsigned long long, bool&) block_pointer) const + 324 (MachOAnalyzer.cpp:6310)
3 dyld … dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> co... + 260 (Loader.cpp:1190)
4 dyld … dyld4::JustInTimeLoader::applyFixups(Diagnostics&, dyld4::RuntimeState&, dyld4::DyldCacheDataConstLazyScopedWriter&, bool) const + 440 (JustInTimeLoader.cpp:447)
5 dyld … dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 1404 (dyldMain.cpp:559)
6 dyld … start + 412 (dyldMain.cpp:869)

but they’re both really early in the dynamic linking process, so early that it’s unlikely that any of the code in your app has run yet.

And the fact that the backtraces are different is further evidence that the process was killed from outside, with the code doing the killing running asynchronously with your code inside the process and thus catching your code (well, the dynamic linker’s code :-) at different points.

Earlier you wrote:

I get a lot of crashlogs in the Xcode organizer on iOS 15 all related to dyld.

So, just to clarify, this means that you’ve not seen anything like this on iOS 14, right?

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

| "So, just to clarify, this means that you’ve not seen anything like this on iOS 14, right?" --> I saw some crashes of this type already on iOS 14.6 / 14.7 / 14.8. But the amount was 100 times less than on iOS 15.

Do you have any suggestions what I could try for the next release? Could it be a problem of an external library or some permission (info.plist)?

I see the crashes also on the release version of iOS 15. I hope you have an idea what the issue could be.

boc-sho wrote;

I hope you have an idea what the issue could be.

I’m happy to look at your crash report but I’d appreciate you starting a new thread for that. I’d like to stay focus on And0Austria’s issue here.

Make sure to apply the Debugging tag to your new thread so that I see it go by.

And0Austria wrote:

I saw some crashes of this type already on iOS 14.6 / 14.7 / 14.8. But the amount was 100 times less than on iOS 15.

Interesting. I ran this by a colleague and he pointed out something I missed, namely this:

Date/Time:           2021-09-29 02:48:23.3145 +0700
Launch Time:         2021-09-29 02:47:22.2477 +0700

and this:

Date/Time:           2021-09-30 20:43:40.7094 -0300
Launch Time:         2021-09-30 20:42:40.0637 -0300

In both cases the app crashed almost exactly a minute after it was launched. That is important for two reasons:

• There’s no way that, under normal circumstances, the app would still be in the dynamic linker after a minute, so something has clearly gone wrong on the device.

• The one minute timeout suggests that some sort of watchdog kicked in, which is evidence for my theory that the app is being killed from ‘outside’.

I don’t think that I’ll be able to make further progress on this without a sysdiagnose log taken shortly after the crash occurred. That’s going to be challenging to get )-:

However, I’m also pretty certain that this crash is not your fault. All the evidence suggests that your app is being killed by the OS before any of your code runs. There’s not much you can do about that.

If you’re getting a lot of these crash reports then you should file a bug against the crash reporting system itself. There’s two possibilities here:

• Your app isn’t at fault, in which case there’s no point delivering these crash reports to you.

• Your app has done something wrong, in which case the crash reporter needs to be enhanced to include actionable information.

Please post your bug number, just for the record.

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

any news about it?

i have the same problem more specifically when it goes in the background.

Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Triggered by Thread:  0


Kernel Triage:
VM - pmap_enter failed with resource shortage
VM - pmap_enter failed with resource shortage
VM - pmap_enter failed with resource shortage
VM - pmap_enter failed with resource shortage
VM - pmap_enter failed with resource shortage


Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001ba7b4564 mach_msg_trap + 8
1   libsystem_kernel.dylib        	0x00000001ba7b4bfc mach_msg + 76 (mach_msg.c:119)
2   CoreFoundation                	0x0000000183e35698 __CFRunLoopServiceMachPort + 372 (CFRunLoop.c:2646)
3   CoreFoundation                	0x0000000183e3998c __CFRunLoopRun + 1212 (CFRunLoop.c:3000)
4   CoreFoundation                	0x0000000183e4d3c8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
5   GraphicsServices              	0x000000019f65e38c GSEventRunModal + 164 (GSEvent.c:2200)
6   UIKitCore                     	0x00000001867f3060 -[UIApplication _run] + 1100 (UIApplication.m:3457)
7   UIKitCore                     	0x0000000186570b8c UIApplicationMain + 2124 (UIApplication.m:5013)
8   *****                   	0x0000000104a7ab50 main + 64 (AppDelegate.swift:18)
9   dyld                          	0x000000010667da24 start + 520 (dyldMain.cpp:876)

the very special thing: if I create .ipa and with IOS < 15 it doesn't happen

any news about it?

About what specifically? I don’t see an obvious connection between the backtrace you posted and the issue being covered by this thread. It looks like a completely different issue.

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

hi folks,

do we have any solution regarding this type of crash? seeing this on our app where the crash happens to some of the users using iOS 15.x

for folks who have the similar issue, wondering if you could list down the list of frameworks that you are using? suspect that might be one of the framework that we were using cause this issue

@stlee Do you use Healthkit?

Filed FB10987303 against reporting system. Facing the same issue all year with a peak in october 2021. Now observe a slight rising trend and also reports from iOS 16 devices. For the history

UPD: No HealthKit involved

About PS 99% of all the crashes are coming from iOS 15 devices

@all: Please report this with feedbackassistant.apple.com so that Apple gets aware of this, seems like a lot of developers see this problem since iOS15 (already see it also in iOS16 Beta). You can also refer to my report number FB9645713.