iOS 18 启动崩溃 main_executable_path_missing

Triggered by Thread: 0

Thread 0 Crashed: 0 dyld 0x1a87922b0 lsl::PreallocatedAllocatorLayout<278528ull>::init(char const**, char const**, void*) + 436 1 dyld 0x1a878ba38 start + 1960

Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000004 x3: 0x00000001a87607a9 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d923dfd x11: 0x00000001a87ccf30 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x00000001801d0000 x20: 0x000000016d923b50 x21: 0x000000016d923af8 x22: 0x00000001e6184050 x23: 0x000000016d9237d8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d923870 lr: 0xb0228001a8792130 sp: 0x000000016d9237d0 pc: 0x00000001a87922b0 cpsr: 0x60001000 far: 0x00000001e61840e0 esr: 0x92000047 (Data Abort) byte write Translation fault

Binary Images: 0x1a8758000 - 0x1a87db693 dyld arm64e <77c1eed22ed7396aba34e770120d81d4> /usr/lib/dyld 0x1024dc000 - 0x10594ffff main_executable_path_missing arm64 <b4af5d3d511d3f9e8b5a66245101c348> /main_executable_path_missing 0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ???

Error Formulating Crash Report: dyld_process_snapshot_get_shared_cache failed

EOF

Answered by DTS Engineer in 807095022

App crashes at every run, both AppStore users and running from Xcode debug mode.

Restarting the phone worked, but not ideal for real users... Is this a known issue?

Yes, but it's a bit more complicated than that. The kernel team is aware of the issue and has actually been investigating it for awhile but they still don't really know what the problem actually is. The actual failure is rare enough that we've never been able to directly reproduce the issue and diagnostic data we have gotten doesn't really make very much sense. Here's what I can say at this point:

  1. There isn't any indication that the problem is specifically tied to the app itself or anything your app "did". Note the reason you see "main_executable_path_missing" is that dyld hasn't actually gotten far enough into the loading process that it's actually started interacting with your specific executable:
       0x104784000 -        0x104790000 main_executable_path_missing arm64  <d6c015912aa137f38accbdda1c1671f0> /main_executable_path_missing

  1. The issue appears to be tied to some kind of transient state, so it's expected that rebooting will resolve the issue.

  2. The issue has been very difficult to reproduce and it's still very unclear what factors are able to trigger it.

With an issue like this I'd typically recommend that you file bugs, however, I'm not sure that would help much here. The issue is low level enough that an post-reboot sysdiagnose isn't useful and transient that it's trying to catch it "again" isn't all that useful. Lastly, the issue is low level enough that it's not clear that any sysdiagnose would be also that useful. The team has made some changes in iOS 18.1 to try and get better data (not this this may cause the "same" crash to generate a slightly different crash log), but individual reports on specific failures are unlikely to help much.

However, the one exception to this is if you're able to reliably reproduce the issue (after rebooting the device), particularly if you're able to reproduce the issue across devices. If you have any specific information about what might be triggering the bug, then please file a bug on that and post the bug number here.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Are there any updates on this? We have been experiencing the exact same issue since the release of iOS 18.

We ourselves are unable to reproduce the issue. We have been receiving a ton of negative reviews, emails, screen recordings about this from our users. It seems as if the app crashes once while they are using it and then it always crashes on startup. We saw in the screen recordings that the app closes as soon as you press the app icon, it doesn't even wait to load. It just crashes. It only works if you restart the device. Deleting and reinstalling the app does not work.

We can't see anything on Firebase Crashlytics about this because we think that the app crashes before Firebase can even initialize. We can only see crash logs from XCode and it is only the same 2 lines as people have mentioned above.

Since this issue started to occur our daily average crashes went from 300 to 6000. Our crash rate went from less than 0.5% to now 7% in December 2024. And this is only from users who have opted in.

Most of our replies to user reviews have become "Please restart your device and it should work". Therefore, we are really in need of some help here.

Crash log:

{"app_name":"xxxxx","timestamp":"2024-12-30 07:23:27.00 +0800","app_version":"9.2.25","slice_uuid":"440ba3e9-7543-3336-a1e4-ebd53c9c7b91","adam_id":"590338362","build_version":"5568","platform":0,"bundleID":"com.xxx.xxxx","share_with_app_devs":1,"is_first_party":0,"bug_type":"309","os_version":"iPhone OS 18.1.1 (22B91)","roots_installed":0,"name":"xxxxx","incident_id":"3FE331C2-ADC7-47A6-9A66-3A02EA14C777"}

Incident Identifier: 3FE331C2-ADC7-47A6-9A66-3A02EA14C777

CrashReporter Key: b14e092a060f6e72fda4d46296a96154a430fcd0

Hardware Model: iPhone15,3

Process: xxxxxx [68698]

Path: /private/var/containers/Bundle/Application/7F53D142-60D8-47CB-9616-016ACEB9F7DF/xxxx.app/xxxxx

Identifier: com.xxx.xxxx

Version: 9.2.25 (5568)

AppStoreTools: 16C5031b

AppVariant: 1:iPhone15,3:18

Code Type: ARM-64 (Native)

Role: Foreground

Parent Process: launchd [1]

Coalition: com.xxx.xxxx [17310]

Date/Time: 2024-12-30 07:23:27.2328 +0800

Launch Time: 2024-12-30 07:23:27.2301 +0800

OS Version: iPhone OS 18.1.1 (22B91)

Release Type: User

Baseband Version: 3.10.03

Report Version: 104

Exception Type: EXC_BAD_ACCESS (SIGKILL)

Exception Subtype: KERN_PROTECTION_FAILURE at 0x00000001f8b880e0

Exception Codes: 0x0000000000000002, 0x00000001f8b880e0

Termination Reason: <0x2A> 2

Triggered by Thread: 0

Thread 0 Crashed:

0 dyld 0x00000001baad5500 lsl::PreallocatedAllocatorLayout<278528ull>::init(char const**, char const**, void*) + 436

1 dyld 0x00000001baacebcc start + 1960

Thread 0 crashed with ARM Thread State (64-bit):

   x0: 0x2010003030100000      x1: 0x0000000fffffc0d0      x2: 0x0000000000000003      x3: 0x00000001baaa382a

   x4: 0x0000000000000000      x5: 0x0000000000000000      x6: 0x0000000000000000      x7: 0x0000000000000000

   x8: 0x2010003030100000      x9: 0x2010003030100000     x10: 0x000000016fadbdfc     x11: 0x00000001bab10240

  x12: 0x0000000000000050     x13: 0x0000000000000044     x14: 0x0000000000052010     x15: 0x0000000000000000

  x16: 0x0000000000000000     x17: 0x0000000000000000     x18: 0x0000000000000000     x19: 0x00000001922c8000

  x20: 0x000000016fadbb30     x21: 0x000000016fadbad8     x22: 0x00000001f8b88050     x23: 0x000000016fadb7b8

  x24: 0x0000000fffffc10c     x25: 0x0000000000000000     x26: 0x0000000000000000     x27: 0x0000000000000000

  x28: 0x0000000000000000      fp: 0x000000016fadb850      lr: 0x73590001baad5380

   sp: 0x000000016fadb7b0      pc: 0x00000001baad5500    cpsr: 0x0000000060001000

  far: 0x00000001f8b880e0     esr: 0x0000000092000047 (Data Abort) byte write Translation fault

Binary Images:

   0x1baa9b000 -        0x1bab1e99f dyld arm64e  <3060d36a-16ce-3c3a-9258-3881459f5714> /usr/lib/dyld

   0x100324000 -        0x10bb5ffff main_executable_path_missing arm64  <440ba3e9-7543-3336-a1e4-ebd53c9c7b91> /main_executable_path_missing

   0x000000000 -                ???  <00000000-0000-0000-0000-000000000000> 

EOF

We've encountered a rather troublesome crash issue with one of our test machines. After the initial crash, we took the following steps to troubleshoot: we used the same bundle ID but with an empty project to do an overlaid run, yet it still crashed on startup. Then, we deleted and reinstalled the empty project, but unfortunately, it continued to crash during startup. However, after restarting the device, the empty project could be opened normally. This situation is becoming quite critical as we've been continuously receiving feedback from paid users who are unable to open our App, and we've had to deal with numerous refund requests. We sincerely hope to get a prompt response from you as soon as possible so that we can work together to resolve this issue and minimize the impact on our users and business.

We've encountered a rather troublesome crash issue with one of our test machines. After the initial crash, we took the following steps to troubleshoot: we used the same bundle ID but with an empty project to do an overlaid run, yet it still crashed on startup. Then, we deleted and reinstalled the empty project, but unfortunately, it continued to crash during startup.

I'm not going to try and explain the details of what's going on, but what you're seeing here is basically "expected". In general terms, what's happening here is the following:

  1. Your app independently crashes in "just" the right/wrong way. Note that this crash is NOT the crash you're looking at here, but is some other "normal" app crash that happens to set up the rest of the sequence.

  2. (Bug #1) The processing of that crash ends up "marking" you process and requiring an unusual shared region configuration that only intended to be used with system processes, not apps.

  3. (Bug #2) The next time your app launches, launchd applies the misconfiguration from #2, which ends up triggering the actual crash that started all of this.

  4. The state from #2 is persistent enough that the same state ends up persisting until the device reboots.

Note that #4 is what explains this odd behavior:

we used the same bundle ID but with an empty project to do an overlaid run, yet it still crashed on startup.

The configuration in #2 is associated with your app via bundle ID, so the problem persists even though the app itself is completely different.

Similarly:

However, after restarting the device, the empty project could be opened normally.

...restarting resets launchd. At that point your app should work fine until the next time the #1 occurs, at which point the problem starts over again.

This situation is becoming quite critical as we've been continuously receiving feedback from paid users who are unable to open our App, and we've had to deal with numerous refund requests. We sincerely hope to get a prompt response from you as soon as possible so that we can work together to resolve this issue and minimize the impact on our users and business.

I don't see any way to workaround the issue, however, the issues should be fixed in the current seed releases (iOS 18.3 beta 2 (22D5040d) and corresponding system betas).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

It seems like we are still facing this issue with the full release of iOS 18.3. Can anyone confirm that this issue is fixed?

iOS 18 启动崩溃 main_executable_path_missing
 
 
Q