After upgrading to iOS 18, crashes caused by calling null function pointers cannot be captured by developers using signal listeners.

Question

Created 1w

Replies 2

Boosts 0

Participants 2

After upgrading to iOS 18, crashes caused by calling null function pointers have changed their crash signal from SIGEGV to SIGKILL, making it impossible for developers to capture crash stacks using third-party components like KSCrash/PLCrashReporter.

Is this a design change in iOS 18's memory protection mechanism? If so, are there any officially recommended crash capture solutions?

- (void)MockCrashOnNullFunctionPointer {
    void (*func)(void) = NULL;
    func();
}

Crash report comparison:

Answered by DTS Engineer in 868805022

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

The screenshot above is the iOS system's crash log

Just clarify what we’re talking about here, this is an Apple crash report from iOS 26.1:

Exception Type:  EXC_BAD_ACCESS (SIGKILL)
Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000
…

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 ???                 0x0 ???
1 Test808813  0x10058c128 -[MainViewController tableView:didSelectRowAtIndexPath:] + 100
2 UIKitCore   0x1a563bc98 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMult…
3 UIKitCore   0x1a563bfbc -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 255
4 UIKitCore   0x1a563c0c8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215
5 UIKitCore   0x1a407d878 -[_UIAfterCACommitBlock run] + 71
…

You’re concern is with that SIGKILL, where prior to iOS 18 this was a SIGSEGV.

That doesn’t strike me as a problem in and of itself. In general, if your program goes off into the weeds, we don’t guarantee the specific mechanism by which it will be killed.

Stepping back, you wrote:

making it impossible for developers to capture crash stacks using third-party components

Right. It seems that, when you jump off into the weeds, the process dies with a SIGKILL due to a code signing error and thus never generates the traditional SIGSEGV or SIGBUS that third-party crash reporters rely on.

Speaking personally, I’m not going to lose a lot of sleep about that. IMO you should not use a third-party crash reporter.

Fortunately, my opinion isn’t the deciding factor |-: If you’d like to see this changed, I recommend that you file a bug about it.

Please post your bug number, just for the record.

Oh, and while you’re there, consider filing an enhancement request for an out-of-process crash reporting mechanism on iOS. The current in-process mechanisms used by third-party crash reporters are unsustainable.

And if you don’t file this ER, don’t forget to also post its bug number.

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

Boost

Answer 1

DTS Engineer OP

Apple

1w

I’m not exactly sure what caused the change you’re reporting here. If you’re having problems with a third-party tool like this, I recommend that you start by escalating them with the tool’s vendor.

Having said that, my general advice is that you not use a third-party crash reporter. For a detailed explanation as to why that’s a bad idea, see Implementing Your Own Crash Reporter.

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

0

Answer 2

DTS Engineer OP

Apple

2d

Recommended

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

The screenshot above is the iOS system's crash log

Just clarify what we’re talking about here, this is an Apple crash report from iOS 26.1:

Exception Type:  EXC_BAD_ACCESS (SIGKILL)
Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000
…

Thread 0 name:   Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 ???                 0x0 ???
1 Test808813  0x10058c128 -[MainViewController tableView:didSelectRowAtIndexPath:] + 100
2 UIKitCore   0x1a563bc98 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMult…
3 UIKitCore   0x1a563bfbc -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 255
4 UIKitCore   0x1a563c0c8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215
5 UIKitCore   0x1a407d878 -[_UIAfterCACommitBlock run] + 71
…

You’re concern is with that SIGKILL, where prior to iOS 18 this was a SIGSEGV.

That doesn’t strike me as a problem in and of itself. In general, if your program goes off into the weeds, we don’t guarantee the specific mechanism by which it will be killed.

Stepping back, you wrote:

making it impossible for developers to capture crash stacks using third-party components

Right. It seems that, when you jump off into the weeds, the process dies with a SIGKILL due to a code signing error and thus never generates the traditional SIGSEGV or SIGBUS that third-party crash reporters rely on.

Speaking personally, I’m not going to lose a lot of sleep about that. IMO you should not use a third-party crash reporter.

Fortunately, my opinion isn’t the deciding factor |-: If you’d like to see this changed, I recommend that you file a bug about it.

Please post your bug number, just for the record.

Oh, and while you’re there, consider filing an enhancement request for an out-of-process crash reporting mechanism on iOS. The current in-process mechanisms used by third-party crash reporters are unsustainable.

And if you don’t file this ER, don’t forget to also post its bug number.

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

1