App crashes on iOS 16 Devices

Question

anonyfountain OP

Created Feb ’24

Replies 3

Boosts 0

Participants 3

Hello,

We are investigating a serious crash impacting users on iOS 16 devices. The crash occurs on app start up. I’ve added the crash report here.

This crash occurs in the dyld step. We believe the crash may be related to the binary size of the app. The crash does not occur on simulator or on debug mode. It only occurs on real devices on release mode.

We recently introduced a new large binary. We believe the introduction of this framework may be causing this issue due to its large size. However, we don't believe the contents of the framework cause the crash. We've previously introduced very similar frameworks to this with no issue.

Our last stable version of the app is 178 MB and our new build is 195 MB.

crashlog.crash

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’24

That crash report is most strange. You’re hitting a memory access exception, but notice this:

--->  STACK GUARD              16da38000-16da3c000 …

That suggests you’ve run off the bottom of your stack. But what’s weird is this:

Thread 0 Crashed:
0   dyld … __chkstk_darwin_probe + 16
1   dyld … dyld4::setUpPageInLinkingRegions(dyld4::RuntimeState&, dyld4::Loader const*, unsigned long, unsigned short, unsigned short, bool, dyld3::Array const&, dyld3::Array const&) const + 536 (Loader.cpp:1712)
4   dyld … dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, unsigned long long, dyld3::Array const&, dyld3::Array const&, bool, dyld3::Array /usr/lib/dyld

Normally I’d expect such a crash to include a long backtrace, but in this case there’s very little.

I had a look at the code for frame 1 in the Darwin open source. Note this line, which it allocates a buffer on the stack. Given that that this failure is correlated with adding a new large binary, it’s possible that something in there is causing this buffer to be big enough to overflow the stack. But that doesn’t really explain why you don’t see the crash on iOS 17.

Also, it’s a bit weird that the backtrace ends at frame 4.

Is this binary built with Apple tools?

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

0

Answer 2

haldun-gh OP

Feb ’24

We later tried adding -Xlinker -no_fixup_chains flag and the issue seems to be resolved. We still don't know the real cause of the crash.

0

Answer 3

haldun-gh OP

Feb ’24

Is this binary built with Apple tools?

Yes.

0