Finding source of crash

I've been debugging the source of a crash bug (right on app launch!) and it reminded me that some of my old code is sort of a mess.

Do you have luck with static analyzer or other Xcode tools? For starters maybe I'll try to scan some Apple sample code to see how well it does, haha.

  • You'd better focus on your code than trying to point finger to others.

Add a Comment

Accepted Reply

Before jumping to "what tools can I use to investigate?", you should take a step back and figure out the type of crash you have first. For example, the way you investigate a memory smasher is not the same as if something asserted or threw an exception. Diagnosing Issues Using Crash Reports and Device Logs provides a numbered list of the steps you can take in your investigation. Hopefully you already have a crash report, but if not, that's step 2 in that list. Once you have a fully symbolicated crash report, you can figure out the type of crash in step 4 by comparing the overall structure of information to the example in Identifying the Cause of Common Crashes , which will guide you to articles that are targeted to the type of crash, and which go into detail on the techniques and tools you can use for resolving your specific type of crash.

Finally, I'll also add that Analyzing a Crash Report poses questions that you can ask of your app and the specific crash to help guide yourself to an understanding of what's happening, and then resolving it once you understand it better.

  • Thank you. Occurs within a library running on another thread. It's could be the async await I recently added.

    2 libswift_Concurrency.dylib 0x000000020f5397cc swift::runJobInEstablishedExecutorContext(swift::Job*) + 244 (Task.h:282)

    It only crashes for some people in production, so I'll revert my URLSession code to regular callbacks for now.

Add a Comment

Replies

Yes, that's what I'm trying to do with some tools. I didn't intend it the way you mean - even stated mine looks messy. Running static analyzer on the code was pretty clean actually (just a bunch of deprecations and using var instead of let where I should be). A lot more of the warnings are from an SDK I'm using from a major tech company. I can understand why because the code is much more complex than my project, but not finger pointing. I'll look at the SDK repo to see if there were any crash fixes that are reported or updated. Do you have any helpful debugging advice though?

Before jumping to "what tools can I use to investigate?", you should take a step back and figure out the type of crash you have first. For example, the way you investigate a memory smasher is not the same as if something asserted or threw an exception. Diagnosing Issues Using Crash Reports and Device Logs provides a numbered list of the steps you can take in your investigation. Hopefully you already have a crash report, but if not, that's step 2 in that list. Once you have a fully symbolicated crash report, you can figure out the type of crash in step 4 by comparing the overall structure of information to the example in Identifying the Cause of Common Crashes , which will guide you to articles that are targeted to the type of crash, and which go into detail on the techniques and tools you can use for resolving your specific type of crash.

Finally, I'll also add that Analyzing a Crash Report poses questions that you can ask of your app and the specific crash to help guide yourself to an understanding of what's happening, and then resolving it once you understand it better.

  • Thank you. Occurs within a library running on another thread. It's could be the async await I recently added.

    2 libswift_Concurrency.dylib 0x000000020f5397cc swift::runJobInEstablishedExecutorContext(swift::Job*) + 244 (Task.h:282)

    It only crashes for some people in production, so I'll revert my URLSession code to regular callbacks for now.

Add a Comment

Trouble is, I can't duplicate it on my own phone, so all I can use is the crash log from the app from someone else's device.

Exception Type: EXC_BREAKPOINT (SIGTRAP) If the Swift runtime encounters a programming error, the runtime catches the error and intentionally crashes the app. This crash points to Thread 5 - some concurrency library:

Thread 5 Crashed:
0   libswiftCore.dylib            	0x000000019200ab74 _assertionFailure(_:_:file:line:flags:) + 308 (AssertCommon.swift:132)
1   libswiftCore.dylib            	0x000000019207232c swift_unexpectedError + 484 (ErrorType.swift:188)
2   libswift_Concurrency.dylib    	0x000000020f5397cc swift::runJobInEstablishedExecutorContext(swift::Job*) + 244 (Task.h:282)
3   libswift_Concurrency.dylib    	0x000000020f53a1e8 swift_job_runImpl(swift::Job*, swift::ExecutorRef) + 72 (Actor.cpp:1488)
4   libdispatch.dylib             	0x000000018d212164 _dispatch_root_queue_drain + 396 (inline_internal.h:0)
5   libdispatch.dylib             	0x000000018d21296c _dispatch_worker_thread2 + 164 (queue.c:6935)
6   libsystem_pthread.dylib       	0x00000001feefd080 _pthread_wqthread + 228 (pthread.c:2612)
7   libsystem_pthread.dylib       	0x00000001feefce5c start_wqthread + 8 (:-1)

Since this error happened async, how can I find deterministically know what code triggered it? And if the thread was running long enough, maybe the code lines are not even still in the log.

So my advice to myself is to wrap any async calls in its own function call so I can hopefully trace what may have happened.

Me too. And I removed async/await😭

Add a Comment