App crash on button press

Please provide more detailed information.

My app crashes when a button is pressed

Any button ? A specific one ?

Is it UIKit or SwiftUI ?

If specific, how is it defined ?

• In Storyboard ?
• In code ?

If in code, please show the code.

Also show the action code for the button.

Thanks a bunch for sharing the post and the crash file—they've been incredibly valuable. To make even better use of it, could you please symbolize the crash file? At the moment, we can see that it hits an abort, but symbolic information will greatly enhance our debugging efforts.

There are frames in this crash report that are missing symbol names that identify the code executing at the time of the crash. Adding all of the symbol names to your crash report may help you identify the next step in debugging the crash.

To add the symbol names, follow the advice in Adding identifiable symbol names to a crash report. If you still need help after that, post the symbolicated crash report as an attachment so we can look at it further.

Thanks for the quick replies. I managed to get a symbolicated version to show in XCode, but I can't find a place to export it (the share icon just gives a link that redirects to XCode). How do I export it?

This is the erroring thread

Thanks for the quick replies. I managed to get a symbolicated version to show in XCode, but I can't find a place to export it (the share icon just gives a link that redirects to XCode). How do I export it?

I can tell you exactly why you're getting the crash log you're getting, though I'm afraid it may not be all that helpful when it comes to tracking down the actual problem.

Here is the relevant section from your crash log:

Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001d6c142ec __pthread_kill + 8 (:-1)
1   libsystem_pthread.dylib       	0x00000001eaa07c0c pthread_kill + 268 (pthread.c:1721)
2   libsystem_c.dylib             	0x0000000195f13ba0 abort + 180 (abort.c:118)
3   libc++abi.dylib               	0x00000001ea924ca4 abort_message + 132 (abort_message.cpp:78)
4   libc++abi.dylib               	0x00000001ea914e40 demangling_terminate_handler() + 320 (cxa_default_handlers.cpp:72)
5   libobjc.A.dylib               	0x0000000185e4b15c _objc_terminate() + 160 (objc-exception.mm:499)
6   libc++abi.dylib               	0x00000001ea924068 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
7   libc++abi.dylib               	0x00000001ea92760c __cxa_rethrow + 204 (cxa_exception.cpp:637)
8   libobjc.A.dylib               	0x0000000185e470b4 objc_exception_rethrow + 44 (objc-exception.mm:399)
9   CoreFoundation                	0x000000018df83d88 CFRunLoopRunSpecific + 784 (CFRunLoop.c:3436)
10  GraphicsServices              	0x00000001d29d11a8 GSEventRunModal + 164 (GSEvent.c:2196)

The call to "GSEventRunModal", "CFRunLoopRunSpecific", and everything below them are standard "boilerplate". All of that is simply the machinery the system uses to run your main thread and you'd basically see exactly the same thing up to that point anytime you paused your main thread.

The rest of the crash is fairly standard as well. This sequence here is the standard process used to handle uncaught exceptions:

4   libc++abi.dylib               	0x00000001ea914e40 demangling_terminate_handler() + 320 (cxa_default_handlers.cpp:72)
5   libobjc.A.dylib               	0x0000000185e4b15c _objc_terminate() + 160 (objc-exception.mm:499)
6   libc++abi.dylib               	0x00000001ea924068 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)
7   libc++abi.dylib               	0x00000001ea92760c __cxa_rethrow + 204 (cxa_exception.cpp:637)
8   libobjc.A.dylib               	0x0000000185e470b4 objc_exception_rethrow + 44 (objc-exception.mm:399)

Having processed the exception, it then called "abort()" which actually crashed your app:

0   libsystem_kernel.dylib        	0x00000001d6c142ec __pthread_kill + 8 (:-1)
1   libsystem_pthread.dylib       	0x00000001eaa07c0c pthread_kill + 268 (pthread.c:1721)
2   libsystem_c.dylib             	0x0000000195f13ba0 abort + 180 (abort.c:118)
3   libc++abi.dylib               	0x00000001ea924ca4 abort_message + 132 (abort_message.cpp:78)

What's missing here is a section that would normally be above the main thread which, labeled "Exception Backtrace". That would have shown where the exception was actually thrown "from", which is the information you actually want to investigate an issue like this.

Why it's missing is almost certainly one of two factors:

1. (Less likely) "Something else" interfered with the ObjectiveC exception and intentionally discarded the backtrace data. While this is technically possible, I don't think it's likely. The work required is somewhat tricky and, more importantly, most people interacting with this data understand that it needs to be preserved.

2. (More likely) The exception that was thrown was a C++ exception, NOT an ObjectiveC exception. Many years ago, the ObjectiveC and C++ exception models were integrated so that both languages use the same structures and "process" for exception handling. Note that this integration is why the log jumps between the two libraries:

4   libc++abi.dylib               	0x00000001ea914e40 demangling_terminate_handler() + 320 (cxa_default_handlers.cpp:72)
5   libobjc.A.dylib               	0x0000000185e4b15c _objc_terminate() + 160 (objc-exception.mm:499)
6   libc++abi.dylib               	0x00000001ea924068 std::__terminate(void (*)()) + 16 (cxa_handlers.cpp:59)

However, that integration did not change the actual data contained in the exception. Objective C used the same object ("NSException") for the exception itself and that object is where the missing exception backtrace actually comes from. Unfortunately, C++ doesn't actually HAVE a standards "exception object format", which means it doesn't have a standard way to collect the backtrace the system would normally present. That means that C++ exceptions all inevitably end up looking exactly like the this crash.

The last thing I'll add here is that the exception did NOT come from Apple code. While some of our framework do use C++ and even C++ exceptions, all of those frameworks are VERY careful to ensure that ALL C++ exceptions are caught "inside" the frameworks code and are never allowed to propagate "out" of the frameworks internal implementation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware