iOS App crashes only on physical devices at dyld4::prepare after upgrading the deployment target from iOS 13 to iOS 14

Question

Created Jun ’23

Replies 4

Boosts 0

Participants 2

We recently updated our deployment target from iOS 13 to iOS 14 and have no problems running on simulators. However, app would crash right after we tried to launch it and this only happens to our app running on physical devices. The crash would happen before AppDelegate's 'didFinishLaunchingWithOptions' and it happens every time we launch the app on a device.

We tried keeping everything else's, such as Pods dependencies, deployment target in iOS 13 while only having the deployment target of the app in iOS 14 but that didn't help and the crash still happened with the same stack trace. We also tried to check the Console app on Mac to see if there is any useful information but didn't find anything useful besides messages from SpringBoard such as 'application state changed to Terminated'.

I couldn't find articles that are about the same issue so I am posting it here to see if anyone has any idea what might be the causes and how to fix it. Thanks in advance and here's the stack trace:

Termination Reason: SIGNAL 11 Segmentation fault: 11
Terminating Process: exc handler [630]

Triggered by Thread:  0
Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:

0   fieldwire 0x1072455cc exchg_registrar::exchg_registrar() + 36
1   fieldwire 0x1072455cc exchg_registrar::exchg_registrar() + 36
2   dyld      0x1e53e3bdc invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 144
3   dyld      0x1e5432d08 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 332
4   dyld      0x1e53e23d0 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 516
5   dyld      0x1e53e1868 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 280
6   dyld      0x1e53e0d7c dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 164
7   dyld      0x1e53eb94c dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 376
8   dyld      0x1e53e8758 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 148
9   dyld      0x1e53e2100 dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 40
10  dyld      0x1e53e5388 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 212
11  dyld      0x1e53ea0bc dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 176
12  dyld      0x1e5419608 dyld4::APIs::runAllInitializersForMain() + 292
13  dyld      0x1e53f2648 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2876
14  dyld      0x1e53f0d88 start + 1992
```.

Answered by DTS Engineer in 758556022

Keep in mind that I don’t see replies if you add them as comments. See tip 5 in Quinn’s Top Ten DevForums Tips.

I am also curious if you know how to get more details about what exchg_registrar::exchg_registrar() is trying to do

I’m pretty sure that’s your code. Note the small offsets in the backtrace, which suggests that this is the right symbol, even though it’s not properly symbolicated.

I recommend that you use a link map to track down the origin of this code. That’s pretty obscure, so I wrote Using a Link Map to Track Down a Symbol’s Origin with the details.

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

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’23

Frames 2 shows that the dynamic linker is running a library initialiser at the time of the crash. I don’t recognise the fieldwire library. Is that one of yours?

Regardless, you need to symbolicate your crash report to uncover the identity of the code in frames 1 and 0. For info on how to do that, see Adding Identifiable Symbol Names to a Crash Report.

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

0

Answer 2

wchenIOSDeveloper OP

Jul ’23

Hi @eskimo I am following up to see if you have thoughts on my comments to your response?

Also adding more context about the crash

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Codes: 0x0000000000000001, 0x0000000000000000

One more question, based on the exception type, I am also curious if you know how to get more details about what 'exchg_registrar::exchg_registrar()' is trying to do and what arguments it's trying to dereference when it got hit with a KERN_INVALID_ADDRESS. Like I mentioned in my previous comments, even though exchg_registrar() is shown as if it's called from our app 'fieldwire', it's not written by us so I am not able to learn more about 'exchg_registrar::exchg_registrar()'.

Let me know if you need any other details about this issue, thanks!

0

Answer 3

DTS Engineer OP

Apple

Jul ’23

Accepted Answer

Keep in mind that I don’t see replies if you add them as comments. See tip 5 in Quinn’s Top Ten DevForums Tips.

I am also curious if you know how to get more details about what exchg_registrar::exchg_registrar() is trying to do

I’m pretty sure that’s your code. Note the small offsets in the backtrace, which suggests that this is the right symbol, even though it’s not properly symbolicated.

I recommend that you use a link map to track down the origin of this code. That’s pretty obscure, so I wrote Using a Link Map to Track Down a Symbol’s Origin with the details.

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

0

Answer 4

wchenIOSDeveloper OP

Jul ’23

Hi @eskimo thanks for your timely and helpful response! The article you shared led us to our finding which points to a third-party static library that we use. We will contact the owner of the library and see if they can look into the issue since we don't have the source code of the library.

0