Crash without stack trace in optimized builds on device (Xcode 16)

Hi,

I'm looking for some advise how to narrow down the location of the crash.

When I run the app with Debug configuration (GCC_OPTIMIZATION_LEVEL=0) everything just works. But in Release configuration with -Os the app crashes. Also need to mention that the crash happens on the device only, but not on the simulator. When the crash happens, there's no stack trace available. The crash happens every time, a couple seconds after I see the first screen. Currently I'm using Xcode Version 16.0 (16A242d), but I have also tried all combinations of:

  • Xcode 16.1 Beta 1
  • Xcode 16.1 Beta 2
  • Device with iOS 18
  • Device with iOS 17.7
  • Device with iOS 17.6.1

The result is always the same.

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=257, address=0x100000002)
  * frame #0: 0x0000000100000002

Is there anything I can do to further narrow down the location of the crash?

Here's a full crash report that I got from the device: crash.md · GitHub

Yikes! That’s not fun.

The crash report shows that you’re crashing trying to access 0x0000000100000002.

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: UNKNOWN_0x101 at 0x0000000100000002
Exception Codes: 0x0000000000000101, 0x0000000100000002

This is the main thread, and the backtrace is completely toast. And the register state explains why:

Thread 0 crashed with ARM Thread State (64-bit):
   …
   …   fp: 0x00000003037075e0   lr: 0x0000000100000002
   …   pc: 0x0000000100000002 cpsr: 0x20001000
   …  esr: 0x8a000000 (PC alignment)

Both the current program counter (PC) and the return address register (LR) point to that crashing address. This typically means that you’ve smashed the return address on the stack, and so copied a bogus value in LR. On returning to it, it gets copied into PC, and you then crash trying to fetch instructions.

It sounds like this is reproducible, which is good. My first bit of advice is that you remove your third-party crash reporter (see thread 15 in your crash report). Third-party crash reporters are a bad idea, as I explain in Implementing Your Own Crash Reporter.

Once you’ve done that, reproduce the problem and see if the resulting crash report has any more useful details. I don’t think it will )-: but it’s important to check that first.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

3 Likes

Thank you for your reply and your guidance. I have removed the custom crash reporter now. Unfortunately the stack trace still looks the same. Here's a new crash report: crash.md · GitHub

I'd be really grateful if you had some more advice for me.

I've managed to get a stack trace and fix the issue. It was some inlined getter. I'm still trying to get a minimal example for you to have a look at, but so far I'm not successful.

Unfortunately I was overly optimistic and wrote this message too soon yesterday. At first it looked like my the crash was gone by one change of mine, but it's still there. Some further guidance would be great.

Unfortunately the stack trace still looks the same.

Yeah, that’s not a big surprise.

Next I’m gonna suggest you try the Debug build configuration with the standard memory debugging tools. Specifically, and separately, zombies and ASan. These can help with problems like this because they details failures earlier.

Beyond that, debugging issues like this gets hard, especially as the problem only occurs in your Release build configuration.

Have you ever tried building your app for arm64e? If you can build and run it that way, it might help with this problem. That’s because the pointer authentication will trap either when the process loads the pointer, or when it calls it, and either of those yield a useful PC.

For info on how to set this up, see Preparing your app to work with pointer authentication. I just tried the process here with Xcode 16.0 on macOS 14.6.1 targeting iOS 17.6.1, so it works (at least for trivial test projects :-).

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

1 Like

Thank you again for your further guidance!

I've tried already ASan, but nothing popped up there.

When I add arm64e to the architectures of my App's target, I get following error when building for my device (iPhone 12 Pro):

KAAppDelegate.swift:6:8: Could not find module 'KAKleinanzeigenKit' for target 'arm64e-apple-ios'; found: arm64-apple-ios, at: ~/Library/Developer/Xcode/DerivedData/Kleinanzeigen-bgfngacholyjnbcqozzilsfcokkt/Build/Products/Release-iphoneos/KAKleinanzeigenKit.swiftmodule

Looks like that ARCHS build setting doesn't get propagated when building Swift Packages that our App target depends on. Is that possible? Our App target has one dependency to KAKleinanzeigenKit, which is a local Swift Package.

Is that possible?

I don’t know. And I don’t have time to research that today )-:

If no one else chimes in here, I recommend that you start a new thread with that specific question.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple