截屏2020-01-14下午2.22.57.png
码云地址：https://gitee.com/xgkp/crashLog.git
类似审核被拒，有crashlog直接找到崩溃原因，修改了重新打包即可。
<!DOCTYPE html>
<html lang="en">
<head>
<title>Technical Note TN2151: Understanding and Analyzing Application Crash Reports</title>
<meta http-equiv="X-UA-Compatible" content="IE=7">
<meta charset="utf-8">
<meta id="book-resource-type" name="book-resource-type" content="Technical Note">
<meta scheme="apple_ref" id="identifier" name="identifier" content="//apple_ref/doc/uid/DTS40008184">
<meta id="document-version" name="document-version" content="9.4.0">
<meta id="build" name="build" content="c1e4c7a89af8f899a21cfa81fc33ba42" />
<meta id="chapterId" name="chapterId" content="DTS40008184-CH1">
<meta id="date" name="date" content="2018-01-08">
<meta id="description" name="description" content="TN2151: Essential information for developers explaining how to symbolicate, understand, and interpret crash reports.">
<meta id="book-title" name="book-title" content="Understanding and Analyzing Application Crash Reports">
<meta id="book-root" name="book-root" content="./">
<meta id="book-json" name="book-json" content="book.json">
<meta id="devcenter" name="devcenter" content="Mac Dev Center">
<meta id="devcenter-url" name="devcenter-url" content="http://developer.apple.com/devcenter/mac">
<meta id="reflib" name="reflib" content="Documentation Archive">
<meta id="book-assignments" name="book-assignments" content="{Type/Technical Note}, {Topic/Languages & Utilities}">
<meta id="copyright" name="copyright" content="Copyright 2018 Apple Inc. All Rights Reserved.">
<meta id="xcode-display" name="xcode-display" content="render">
<meta id="IndexTitle" name="IndexTitle" content="Technical Note TN2151">
<meta id="resources-uri" name="resources-uri" content="../../Resources/1282">
<link id="book-index-page" rel="Start" title="Understanding and Analyzing Application Crash Reports" type="text/html" href="index.html">
<link id="next-page" rel="Next" type="text/html" href="">
<link id="previous-page" rel="Prev" type="text/html" href="">
<link rel="stylesheet" type="text/css" href="../../Resources/1282/CSS/screen.css">
<!-- xcode_css -->
<link rel="stylesheet" type="text/css" href="../../Resources/1282/CSS/feedback.css">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<meta id="platforms" name="platforms" content="">
</head>
<body><a name="//apple_ref/doc/uid/DTS40008184" title="Technical Note TN2151"></a>
<div id="_omniture_top">
<!-- SiteCatalyst code version: H.8. Copyright 1997-2006 Omniture, Inc. -->
<script type="text/javascript">
/* RSID: */
var s_account="appleglobal,appleusdeveloper,dappdeveloperlib"
</script>
<script type="text/javascript" src="https://www.apple.com/metrics/scripts/s_code_h.js"></script>
<script type="text/javascript">
s.pageName=AC.Tracking.pageName();
s.channel="www.us.developer"
/************* DO NOT ALTER ANYTHING BELOW THIS LINE ! **************/
var s_code=s.t();if(s_code)document.write(s_code)</script>
<!-- End SiteCatalyst code version: H.8. -->
</div>
<div id="adcHeader" class="hideOnPrint hideInXcode">
<div id='ssi_Header' class="hideInXcode unified">
<a id="ssi_LibraryTitle" href='../../navigation/'>Documentation Archive</a>
<a id="ssi_AppleDeveloperConnection" href='https://developer.apple.com/'>Developer</a>
<div id='ssi_SearchButton' role="button" title="Search">Search</div>
</div>
<form id='ssi_SearchMenu' method='get' action='../../search/' accept-charset='utf-8'>
<label for='adcsearch'>Search Documentation Archive</label>
<input type='search' id='ssi_SearchField' name='q' accesskey='s' results='5' />
</form>
</div>
<header id="header">
<div id="title" role="banner">
<h1>Understanding and Analyzing Application Crash Reports</h1>
<span id="file_links">
<a id="PDF_link" role="button" tabindex='4' rel="alternate" title="Download PDF"><span id="pdf_icon"></span>PDF</a>
<a id="Companion_link" role="button" tabindex='3' title="Download Companion File"><span id="companion_icon"></span>Companion File</a>
</span>
</div>
<ul id="headerButtons" class="hideOnPrint" role="toolbar">
<li id="toc_button" style="display:none">
<button tabindex="5" id="table_of_contents" class="open" role="checkbox" aria-label="Show Table of Contents"><span class="disclosure"></span>Table of Contents</button>
</li>
<li id="jumpto_button" style="display:none" role="navigation"><select tabindex="6" id="jumpTo"><option value="top">Jump To…</option></select></li>
<li id="downloadSample_button" style="display:none">
<a id="Sample_link"><button id="Sample_button">Download Sample Code</button></a>
</li>
</ul>
</header>
<nav id="tocContainer" tabindex="7">
<ul id="toc" role="tree"></ul>
</nav>
<article id="contents" tabindex="0" role="main" class="dts_doc">
<!-- CONTENTS -->
<div id="pageNavigationLinks_top" class="pageNavigationLinks">
</div>
<a id="top" name="top"></a>
<a id="INDEX" href="index.html" style="display:none;"></a>
<a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_2" title="Technical Note TN2151"></a><div class="dtsDocNumber">Technical Note TN2151</div><h1 id="pageTitle">Understanding and Analyzing Application Crash Reports</h1><p>When an application crashes, a crash report is created which is very useful for understanding what caused the crash. This document contains essential information about how to symbolicate, understand, and interpret crash reports.</p>
<div class="outerMiniTOC">
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-INTRODUCTION" data-renderer-version="1">Introduction</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-ACQUIRING_CRASH_AND_LOW_MEMORY_REPORTS" data-renderer-version="1">Acquiring Crash and Low Memory Reports</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION" data-renderer-version="1">Symbolicating Crash Reports</a>
<div class="nestedMiniTOC">
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE" data-renderer-version="1">Bitcode</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-_DETERMINING_WHETHER_A_CRASH_REPORT_IS_SYMBOLICATED" data-renderer-version="1">Determining Whether a Crash Report is Symbolicated</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATEWITHXCODE" data-renderer-version="1">Symbolicating iOS Crash Reports With Xcode</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS" data-renderer-version="1">Symbolicating Crash Reports With atos</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATIONTROUBLESHOOTING" data-renderer-version="1">Symbolication Troubleshooting</a>
</div>
</div>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS" data-renderer-version="1">Analyzing Crash Reports</a>
<div class="nestedMiniTOC">
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-CRASH_HEADER" data-renderer-version="1">Header</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO" data-renderer-version="1">Exception Information</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-APPINFO" data-renderer-version="1">Additional Diagnostic Information</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS-THREAD_STATE" data-renderer-version="1">Thread State</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS-BINARY_IMAGES" data-renderer-version="1">Binary Images</a>
</div>
</div>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-UNDERSTANDING_LOW_MEMORY_REPORTS" data-renderer-version="1">Understanding Low Memory Reports</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-CH1-RELATED_DOCUMENTS" data-renderer-version="1">Related Documents</a>
</div>
<div>
<a href="#//apple_ref/doc/uid/DTS40008184-RevisionHistory-DontLinkElementID_1" data-renderer-version="1">Document Revision History</a>
</div>
</div>
<section><a name="//apple_ref/doc/uid/DTS40008184-CH1-INTRODUCTION" title="Introduction"></a><h2 class="jump">Introduction</h2><p>When an application crashes, a <strong>crash report</strong> is created and stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete backtrace for each executing thread, and are typically very useful for debugging issues in the application. You should look at these crash reports to understand what crashes your application is having, and then try to fix them.</p><p>Crash reports with backtraces need to be <strong>symbolicated</strong> before they can be analyzed. Symbolication replaces memory addresses with human-readable function names and line numbers. If you get crash logs off a device through Xcode's Devices window, then they will be symbolicated for you automatically after a few seconds. Otherwise you will need to symbolicate the <code>.crash</code> file yourself by importing it to the Xcode Devices window. See <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION" data-renderer-version="1">Symbolicating Crash Reports</a></span> for details. </p><p>A <strong> Low Memory report</strong> differs from other crash reports in that there are no backtraces in this type of report. When a low memory crash happens, you must investigate your memory usage patterns and your responses to low memory warnings. This document points to you several memory management references that you might find useful.</p><div class="back_to_top"><a href="#top">Back to Top</a></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-ACQUIRING_CRASH_AND_LOW_MEMORY_REPORTS" title="Acquiring Crash and Low Memory Reports"></a><h2 class="jump">Acquiring Crash and Low Memory Reports</h2><p><span class="content_text"><a href="https://developer.apple.com/library/ios/#qa/qa1747/_index.html" class="urlLink" rel="external">Debugging Deployed iOS Apps</a></span> discusses how to retrieve crash and low memory reports directly from an iOS device. </p><p><span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AnalyzingCrashReports/AnalyzingCrashReports.html" class="urlLink" rel="external">Analyzing Crash Reports</a></span> in the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html" class="urlLink" rel="external">App Distribution Guide</a></span> discusses how to view aggregate crash reports collected from TestFlight beta testers and users who have downloaded your app from the App Store.</p><div class="back_to_top"><a href="#top">Back to Top</a></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION" title="Symbolicating Crash Reports"></a><h2 class="jump">Symbolicating Crash Reports</h2><p>Symbolication is the process of resolving <span class="content_text"><!--a -->backtrace<!--/a--></span> addresses to source code method or function names, known as symbols. Without first symbolicating a crash report it is difficult to determine where the crash occurred.</p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_3" title="Note"></a><p><strong>Note:</strong> Low Memory Reports do not need to be symbolicated.</p><p></p></aside></div><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_4" title="Note"></a><p><strong>Note:</strong> Crash reports from macOS are typically symbolicated, or partially symbolicated, at the time they are generated. This section focuses on symbolicating crash reports from iOS, watchOS, and tvOS, but the overall process is similar for macOS.</p><p></p></aside></div><figure class="figure"><a name="//apple_ref/doc/uid/DTS40008184-CH1-FIGURE1" title="Figure 1Overview of the crash reporting and symbolication process."></a><figcaption><strong class="caption_number">Figure 1</strong> Overview of the crash reporting and symbolication process.</figcaption><img src="Art/tn2151_crash_flow.png" class="wide-image" alt="" width="1024" height="1600"><img src="Art/tn2151_crash_flow.png" class="ipad-scaled-image" alt="" width="670" height="1046"></figure><ol class="ol"><li class="li"><p>As the compiler translates your source code into machine code, it also generates debug symbols which map each machine instruction in the compiled binary back to the line of source code from which it originated. Depending on the <strong>Debug Information Format</strong> (<code>DEBUG_INFORMATION_FORMAT</code>) build setting, these debug symbols are stored inside the binary or in a companion Debug Symbol (<code>dSYM</code>) file. By default, debug builds of an application store the debug symbols inside the compiled binary while release builds of an application store the debug symbols in a companion <code>dSYM</code> file to reduce the binary size.</p><p>The Debug Symbol file and application binary are tied together on a per-build-basis by the build UUID. A new UUID is generated for each build of your application and uniquely identifies that build. Even if a functionally-identical executable is rebuilt from the same source code, with the same compiler settings, it will have a different build UUID. Debug Symbol files from subsequent builds, even from the same source files, will not interoperate with binaries from other builds.</p></li><li class="li"><p>When you archive the application for distribution, Xcode will gather the application binary along with the .<code>dSYM</code> file and store them at a location inside your home folder. You can find all of your archived applications in the Xcode Organizer under the "Archived" section. For more information about creating an archive, refer to the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html" class="urlLink" rel="external">App Distribution Guide</a></span>.</p><div class="importantbox clear"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_5" title="Important"></a><p><strong>Important:</strong> To symbolicate crash reports from testers, app review, and customers, you must retain the archive for each build of your application that you distribute.</p><p></p></aside></div></li><li class="li"><p>If you are distributing your app via the App Store, or conducting a beta test using Test Flight, you will be given the option of including the <code>dSYM</code> file when uploading your archive to iTunes Connect. In the submission dialog, check “Include app symbols for your application…”. Uploading your <code>dSYM</code> file is necessary to receive crash reports collected from TestFlight users and customers who have opted to share diagnostic data. For more information about the crash reporting service, refer to the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AnalyzingCrashReports/AnalyzingCrashReports.html" class="urlLink" rel="external">App Distribution Guide</a></span>.</p><div class="importantbox clear"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_6" title="Important"></a><p><strong>Important:</strong> Crash reports received from App Review will be <span class="content_text"><!--a -->unsymbolicated<!--/a--></span>, even if you included the <code>dSYM</code> file when uploading your archive to iTunes Connect. You will need to symbolicate any crash reports received from App Review using Xcode. See <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATEWITHXCODE" data-renderer-version="1">Symbolicating iOS Crash Reports With Xcode</a></span>.</p><p></p></aside></div></li><li class="li"><p>When your application crashes, an <span class="content_text"><!--a -->unsymbolicated<!--/a--></span> crash report is created and stored on the device. </p></li><li class="li"><p>Users can retrieve crash reports directly from their device by following the steps in <span class="content_text"><a href="https://developer.apple.com/library/ios/#qa/qa1747/_index.html" class="urlLink" rel="external">Debugging Deployed iOS Apps</a></span>. If you have distributed your application via AdHoc or Enterprise distribution, this is the only way to acquire crash reports from your users.</p></li><li class="li"><p>Crash reports retrieved from a device are <span class="content_text"><!--a -->unsymbolicated<!--/a--></span> and will need to be <span class="content_text"><!--a -->symbolicated using Xcode<!--/a--></span>. Xcode uses the <code>dSYM</code> file associated with your application binary to replace each address in the <span class="content_text"><!--a -->backtrace<!--/a--></span> with its originating location in your source code. The result is a symbolicated crash report.</p></li><li class="li"><p>If the user has opted to share diagnostic data with Apple, or if the user has installed a beta version of your application through TestFlight, the crash report is uploaded to the App Store.</p></li><li class="li"><p>The App Store symbolicates the crash report and groups it with similar crash reports. This aggregate of similar crash reports is called a Crash Point.</p></li><li class="li"><p>The symbolicated crash reports are made available to you in Xcode's Crashes organizer.</p></li></ol><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE" title="Bitcode"></a><h3 class="jump">Bitcode</h3><p>Bitcode is an intermediate representation of a compiled program. When you archive an application with bitcode enabled, the compiler produces binaries containing bitcode rather than machine code. Once the binary has been uploaded to the App Store, the bitcode is compiled down to machine code. The App Store may compile the bitcode again in the future, to take advantage of future compiler improvements without any action on your part.</p><figure class="figure"><a name="//apple_ref/doc/uid/DTS40008184-CH1-FIGURE2" title="Figure 2Overview of the Bitcode compilation process."></a><figcaption><strong class="caption_number">Figure 2</strong> Overview of the Bitcode compilation process.</figcaption><img src="Art/tn2151_bitcode_overview.png" class="wide-image" alt="" width="1023" height="207"><img src="Art/tn2151_bitcode_overview.png" class="ipad-scaled-image" alt="" width="670" height="135"></figure><p>Because the final compilation of your binary occurs on the App Store, your Mac will not contain the debug symbol (<code>dSYM</code>) files needed to symbolicate crash reports received from App Review or from users who have sent you crash reports from their devices. Although a <code>dSYM</code> file is produced when you archive your application, it is for the bitcode binary and can not be used to symbolicate crash reports. The App Store makes the <code>dSYM</code> files generated during bitcode compilation available for you to download, from Xcode or from the iTunes Connect website. You must download these <code>dSYM</code> files in order to symbolicate crash reports received from App Review or from users who have sent you crash reports from their devices. Crash reports received through the crash reporting service will be symbolicated automatically.</p><div class="importantbox clear"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_7" title="Important"></a><p><strong>Important:</strong> The binary compiled by the App Store will have different UUIDs than the binary that was originally submitted.</p><p></p></aside></div><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-DOWNLOAD_DSYM" title="Downloading the dSYM files from Xcode"></a><h4 class="jump">Downloading the dSYM files from Xcode</h4><ol class="ol"><li class="li"><p>In the Archives organizer, select the archive that you originally submitted to the App Store.</p></li><li class="li"><p>Click the Download dSYMs button.</p></li></ol><p>Xcode downloads the <code>dSYM</code> files and inserts them into the selected archive.</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION_BITCODE-DOWNLOADING_THE_DSYM_FILES_FROM_THE_ITUNES_CONNECT_WEBSITE" title="Downloading the dSYM files from the iTunes Connect website"></a><h4 class="jump">Downloading the dSYM files from the iTunes Connect website</h4><ol class="ol"><li class="li"><p>Open the App Details page.</p></li><li class="li"><p>Click Activity.</p></li><li class="li"><p>From the list of All Builds, select a version.</p></li><li class="li"><p>Click the <strong>Download dSYM</strong> link.</p></li></ol></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION_BITCODE-TRANSLATING__HIDDEN__SYMBOL_NAMES_BACK_TO_THEIR_ORIGINAL_NAMES" title="Translating 'hidden' symbol names back to their original names"></a><h4 class="jump">Translating 'hidden' symbol names back to their original names</h4><p>When you upload your app with bitcode to the App Store, you may choose not to send your application's symbols by unchecking the "Upload your app's symbols to receive symbolicated reports from Apple" box in the submission dialog. If you choose not to send your app's symbol information to Apple, Xcode will replace the symbols in your app's .<code>dSYM</code> files with obfuscated symbols such as "__hidden#109_" before sending your app to iTunes Connect. Xcode creates a mapping between the original symbols and the "hidden" symbols and stores this mapping in a <code>.bcsymbolmap</code> file inside the application archive. Each .<code>dSYM</code> file will have a corresponding <code>.bcsymbolmap</code> file.</p><p>Before symbolicating crash reports, you will need to de-obfuscate the symbols in the .<code>dSYM</code> files downloaded from iTunes Connect. If you use the Download dSYMs button in Xcode, this de-obfuscation will be performed automatically for you. However, if you use the iTunes Connect website to download the .<code>dSYM</code> files, open Terminal and use the following command to de-obfuscate your symbols (replacing the example paths with your own archive and the dSYMs folder downloaded from iTunes Connect):</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE1"></a><div class="codesample clear"><table><tr><td scope="row"><pre>xcrun dsymutil -symbol-map ~/Library/Developer/Xcode/Archives/2017-11-23/MyGreatApp\ 11-23-17\,\ 12.00\ PM.xcarchive/BCSymbolMaps ~/Downloads/dSYMs/3B15C133-88AA-35B0-B8BA-84AF76826CE0.dSYM<span></span></pre></td></tr></table></div><p>Run this command for each .<code>dSYM</code> file inside the dSYMs folder you downloaded.</p></section></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-_DETERMINING_WHETHER_A_CRASH_REPORT_IS_SYMBOLICATED" title=" Determining Whether a Crash Report is Symbolicated"></a><h3 class="jump"> Determining Whether a Crash Report is Symbolicated</h3><p>A crash report may be unsymbolicated, fully symbolicated, or partially symbolicated. Unsymbolicated crash reports will not contain the method or function names in the <span class="content_text"><!--a -->backtrace<!--/a--></span>. Instead, you have hexadecimal addresses of executable code within the loaded binary images. In a fully symbolicated crash report, the hexadecimal addresses in <strong>every</strong> line of the backtrace are replaced with the corresponding symbol. In a partially symbolicated crash report, only some of the addresses in the backtrace have been replaced with their corresponding symbols.</p><p>Obviously, you should try to fully symbolicate any crash report you receive as it will provide the most insight about the crash. A partially symbolicated crash report may contain enough information to understand the crash, depending upon the type of crash and which parts of the backtraces were successfully symbolicated. An unsymbolicated crash report is rarely useful.</p><figure class="figure"><a name="//apple_ref/doc/uid/DTS40008184-CH1-FIGURE3" title="Figure 3The same backtrace at various levels of symbolication."></a><figcaption><strong class="caption_number">Figure 3</strong> The same backtrace at various levels of symbolication.</figcaption><img src="Art/tn2151_symbolication_levels.png" class="wide-image" alt="" width="920" height="693"><img src="Art/tn2151_symbolication_levels.png" class="ipad-scaled-image" alt="" width="670" height="504"></figure></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATEWITHXCODE" title="Symbolicating iOS Crash Reports With Xcode"></a><h3 class="jump">Symbolicating iOS Crash Reports With Xcode</h3><p>Xcode will automatically attempt to symbolicate all crash reports that it encounters. All you need to do for symbolication is to add the crash report to the Xcode Organizer.</p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_8" title="Note"></a><p><strong>Note:</strong> Xcode will not accept crash reports without a <code>.crash</code> extension. If you have received a crash report without an extension, or with a <code>.txt</code> extension, rename it to have a <code>.crash</code> extension before following the steps listed below.</p><p></p></aside></div><ol class="ol"><li class="li"><p>Connect an iOS device to your Mac</p></li><li class="li"><p>Choose "Devices" from the "Window" menu</p></li><li class="li"><p>Under the "DEVICES" section in the left column, choose a device</p></li><li class="li"><p>Click the "View Device Logs" button under the "Device Information" section on the right hand panel</p></li><li class="li"><p>Drag your crash report onto the left column of the presented panel</p></li><li class="li"><p>Xcode will automatically symbolicate the crash report and display the results</p></li></ol><p>To symbolicate a crash report, Xcode needs to be able to locate the following:</p><ul class="ul"><li class="li"><p>The crashing application's binary and <code>dSYM</code> file.</p></li><li class="li"><p>The binaries and <code>dSYM</code> files for all custom frameworks that the application links against. For frameworks that were built from source with the application, their <code>dSYM</code> files are copied into the archive alongside the application's <code>dSYM</code> file. For frameworks that were built by a third-party, you will need to ask the author for the <code>dSYM</code> file.</p></li><li class="li"><p>Symbols for the OS that the that application was running on when it crashed. These symbols contain debug information for the frameworks included in a specific OS release (e.g. iOS 9.3.3). OS symbols are architecture specific - a release of iOS for 64-bit devices won't include armv7 symbols. Xcode will automatically copy OS symbols from each device that you connect to your Mac.</p></li></ul><p>If any of these are missing Xcode may not be able to symbolicate the crash report, or may only <span class="content_text"><!--a -->partially symbolicate<!--/a--></span> the crash report.</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS" title="Symbolicating Crash Reports With atos"></a><h3 class="jump">Symbolicating Crash Reports With atos</h3><p>The <span class="content_text"><a href="x-man-page://atos" class="urlLink" rel="external"><codeVoice>atos</codeVoice></a></span> command converts numeric addresses to their symbolic equivalents. If full debug symbol information is available then the output of <code>atos</code> will include file name and source line number information. The <code>atos</code> command can be used to symbolicate individual addresses in the backtrace of an unsymbolicated, or partially symbolicated, crash report. To symbolicate a part of a crash report using <code>atos</code>:</p><ol class="ol"><li class="li"><p>Find a line in the <span class="content_text"><!--a -->backtrace<!--/a--></span> which you want to symbolicate. Note the name of the binary image in the second column, and the address in the third column.</p></li><li class="li"><p>Look for a binary image with that name in the list of <span class="content_text"><!--a -->binary images<!--/a--></span> at the bottom of the crash report. Note the architecture and load address of the binary image.</p></li></ol><figure class="figure"><a name="//apple_ref/doc/uid/DTS40008184-CH1-FIGURE4" title="Figure 4Information from the crash report that is needed to use atos."></a><figcaption><strong class="caption_number">Figure 4</strong> Information from the crash report that is needed to use <code>atos</code>.</figcaption><img src="Art/tn2151_atos_info.png" class="wide-image" alt="" width="828" height="238"><img src="Art/tn2151_atos_info.png" class="ipad-scaled-image" alt="" width="670" height="192"></figure><ol class="ol"><li class="li"><p>Locate the <code>dSYM</code> file for the binary. You can use Spotlight to find the matching <code>dSYM</code> file for the UUID of the binary image. See the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATIONTROUBLESHOOTING" data-renderer-version="1">Symbolication Troubleshooting</a></span> section. <code>dSYM</code> files are bundles in which reside a file containing the DWARF debugging information generated by the compiler at build time. You must provide the path to this file, not to the <code>dSYM</code> bundle, when invoking <code>atos</code>.</p></li><li class="li"><p>With the above information you can symbolicate addresses in the backtrace using the <code>atos</code> command. You can specify multiple addresses to symbolicate, separated by a space.</p><p><code>atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate></code></p></li></ol><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE2" title="Listing 1Example usage of the atos command following the steps above, and the resulting output."></a><p class="codesample clear"><strong class="caption_number">Listing 1</strong> Example usage of the <code>atos</code> command following the steps above, and the resulting output.</p><div class="codesample clear"><table><tr><td scope="row"><pre>$ atos -arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc<span></span></pre></td></tr><tr><td scope="row"><pre>-[AtomicElementViewController myTransitionDidStop:finished:context:]<span></span></pre></td></tr></table></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATIONTROUBLESHOOTING" title="Symbolication Troubleshooting"></a><h3 class="jump">Symbolication Troubleshooting</h3><p>If Xcode is failing to fully symbolicate a crash report, it's likely because your Mac is missing the <code>dSYM</code> file for the application binary, the <code>dSYM</code> files for one or more frameworks the application links against, or the device symbols for the OS the application was running on when it crashed. The steps below show how to use Spotlight to determine whether the <code>dSYM</code> file needed to symbolicate a backtrace addresse within a binary image is present on your Mac.</p><figure class="figure"><a name="//apple_ref/doc/uid/DTS40008184-CH1-FIGURE5" title="Figure 5Locating the UUID for a binary image."></a><figcaption><strong class="caption_number">Figure 5</strong> Locating the UUID for a binary image.</figcaption><img src="Art/tn2151_find_uuid.png" class="wide-image" alt="" width="828" height="347"><img src="Art/tn2151_find_uuid.png" class="ipad-scaled-image" alt="" width="670" height="280"></figure><ol class="ol"><li class="li"><p>Find a line in the <span class="content_text"><!--a -->backtrace<!--/a--></span> which Xcode failed to symbolicate. Note the name of the binary image in the second column.</p></li><li class="li"><p>Look for a binary image with that name in the list of <span class="content_text"><!--a -->binary images<!--/a--></span> at the bottom of the crash report. This list contains the UUIDs for each of the binary images that were loaded into the process at the time of the crash.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE3" title="Listing 2You can use the grep command line tool to quickly find the entry in the list of binary images."></a><br/><br/><p class="codesample clear"><strong class="caption_number">Listing 2</strong> You can use the <code>grep</code> command line tool to quickly find the entry in the list of binary images.</p><div class="codesample clear"><table><tr><td scope="row"><pre>$ grep --after-context=1000 "Binary Images:" <Path to Crash Report> | grep <Binary Name><span></span></pre></td></tr></table></div></li><li class="li"><p>Convert the UUID of the binary image to a 32 character string seperated in groups of 8-4-4-4-12 (<code>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</code>). Note that all letters <strong>must</strong> be uppercased.</p></li><li class="li"><p>Search for the UUID using the <code>mdfind</code> command line tool using the query <code>"com_apple_xcode_dsym_uuids == <UUID>"</code> (include the quotation marks).</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE4" title="Listing 3Using the mdfind command line tool to search for dSYM files with a given UUID."></a><br/><br/><p class="codesample clear"><strong class="caption_number">Listing 3</strong> Using the <code>mdfind</code> command line tool to search for <code>dSYM</code> files with a given UUID.</p><div class="codesample clear"><table><tr><td scope="row"><pre>$ mdfind "com_apple_xcode_dsym_uuids == <UUID>"<span></span></pre></td></tr></table></div></li><li class="li"><p>If Spotlight finds a <code>dSYM</code> file for the UUID, <code>mdfind</code> will print the path to the <code>dSYM</code> file and possibly its containing archive. If a <code>dSYM</code> file for the UUID was not found, <code>mdfind</code> will exit without printing anything.</p></li></ol><p>If Spotlight found a <code>dSYM</code> file for the binary but Xcode was not able to symbolicate addresses within that binary image, then you should file a bug. Attach the crash report and the relevant <code>dSYM</code> file(s) to the bug report. As a workaround, you can manually symbolicate the address using <code>atos</code>. See <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS" data-renderer-version="1">Symbolicating Crash Reports With atos</a></span>.</p><p>If Spotlight did not find a <code>dSYM</code> for the binary image, verify that you still have the Xcode archive for the version of your application that crashed and that this archive is located somewhere that Spotlight can find it (any location in your home directory should do). If your application was built with bitcode enabled, make sure you have downloaded the <code>dSYM</code> files for the final compilation from the App Store. See <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-DOWNLOAD_DSYM" data-renderer-version="1">Downloading the dSYM files from Xcode</a></span>.</p><p>If you think that you have the correct <code>dSYM</code> for the binary image, you can use the <code>dwarfdump</code> command to print the matching UUIDs. You can also use the <code>dwarfdump</code> command to print the UUIDs of a binary.</p><p><code>xcrun dwarfdump --uuid <Path to dSYM file></code></p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_9" title="Note"></a><p><strong>Note:</strong> You must have the archive that you originally submitted to the App Store for the version of your application that is crashing. The <code>dSYM</code> file and application binary are specifically tied together on a per-build-basis. Creating a new archive, even from the same sources and build configuration, will not produce a <code>dSYM</code> file that can interoperate with the crashing build. </p><p></p></aside></div><p>If you no longer have this archive, you should submit a new version of your application for which you retain the archive. You will then be able to symbolicate crash reports for this new version.</p></section><div class="back_to_top"><a href="#top">Back to Top</a></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS" title="Analyzing Crash Reports"></a><h2 class="jump">Analyzing Crash Reports</h2><p>This section discusses each of the sections found within a standard crash report.</p><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-CRASH_HEADER" title="Header"></a><h3 class="jump">Header</h3><p>Every crash report begins with a header. </p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE5" title="Listing 4Excerpt of the header from a crash report."></a><p class="codesample clear"><strong class="caption_number">Listing 4</strong> Excerpt of the header from a crash report.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Incident Identifier: B6FD1E8E-B39F-430B-ADDE-FC3A45ED368C<span></span></pre></td></tr><tr><td scope="row"><pre>CrashReporter Key: f04e68ec62d3c66057628c9ba9839e30d55937dc<span></span></pre></td></tr><tr><td scope="row"><pre>Hardware Model: iPad6,8<span></span></pre></td></tr><tr><td scope="row"><pre>Process: TheElements [303]<span></span></pre></td></tr><tr><td scope="row"><pre>Path: /private/var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements<span></span></pre></td></tr><tr><td scope="row"><pre>Identifier: com.example.apple-samplecode.TheElements<span></span></pre></td></tr><tr><td scope="row"><pre>Version: 1.12<span></span></pre></td></tr><tr><td scope="row"><pre>Code Type: ARM-64 (Native)<span></span></pre></td></tr><tr><td scope="row"><pre>Role: Foreground<span></span></pre></td></tr><tr><td scope="row"><pre>Parent Process: launchd [1]<span></span></pre></td></tr><tr><td scope="row"><pre>Coalition: com.example.apple-samplecode.TheElements [402]<span></span></pre></td></tr><tr><td scope="row"><pre> <span></span></pre></td></tr><tr><td scope="row"><pre>Date/Time: 2016-08-22 10:43:07.5806 -0700<span></span></pre></td></tr><tr><td scope="row"><pre>Launch Time: 2016-08-22 10:43:01.0293 -0700<span></span></pre></td></tr><tr><td scope="row"><pre>OS Version: iPhone OS 10.0 (14A5345a)<span></span></pre></td></tr><tr><td scope="row"><pre>Report Version: 104<span></span></pre></td></tr></table></div><p>Most of the fields are self-explanatory but a few deserve special note:</p><ul class="ul"><li class="li"><p><strong>Incident Identifier</strong>: A unique identifier for the report. Two reports will never share the same Incident Identifier.</p></li><li class="li"><p><strong>CrashReporter Key</strong>: An anonymized per-device identifier. Two reports from the same device will contain identical values.</p></li><li class="li"><p><strong>Beta Identifier</strong>: A unique identifier for the combination of the device and vendor of the crashed application. Two reports for applications from the same vendor and from the same device will contain identical values. This field is only present in crash reports generated for applications distributed through TestFlight, and replaces the CrashReporter Key field.</p></li><li class="li"><p><strong>Process</strong>: The executable name for the process that crashed. This matches the value for the <code>CFBundleExecutable</code> key in the application's information property list.</p></li><li class="li"><p><strong>Version</strong>: The version of the process that crashed. The value for this field is a concatenation of the crashed application's <code>CFBundleVersion</code> and <code>CFBundleVersionString</code>.</p></li><li class="li"><p><strong>Code Type</strong>: The target architecture of the process that crashed. This will be one of <code>ARM-64</code>, <code>ARM</code>, <code>x86-64</code>, or <code>x86</code>.</p></li><li class="li"><p><strong>Role</strong>: The <span class="content_text"><a href="http://opensource.apple.com/source/xnu/xnu-3248.60.10/osfmk/mach/task_policy.h" class="urlLink" rel="external">task_role</a></span> assigned to the process at the time of termination.</p></li><li class="li"><p><strong>OS Version</strong>: The OS version, including the build number, on which the crash occurred.</p></li></ul></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO" title="Exception Information"></a><h3 class="jump">Exception Information</h3><p>Not to be confused with Objective-C/C++ exceptions (though one of those may be the cause of the crash), this section lists the Mach <strong>Exception Type</strong> and related fields which provide information about the nature of the crash. Not all fields will be present in every crash report.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE6" title="Listing 5Excerpt of the Exception Codes section from a crash report generated when a process was terminated due to an uncaught Objective-C exception."></a><p class="codesample clear"><strong class="caption_number">Listing 5</strong> Excerpt of the Exception Codes section from a crash report generated when a process was terminated due to an uncaught Objective-C exception.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Exception Type: EXC_CRASH (SIGABRT)<span></span></pre></td></tr><tr><td scope="row"><pre>Exception Codes: 0x0000000000000000, 0x0000000000000000<span></span></pre></td></tr><tr><td scope="row"><pre>Exception Note: EXC_CORPSE_NOTIFY<span></span></pre></td></tr><tr><td scope="row"><pre>Triggered by Thread: 0<span></span></pre></td></tr></table></div><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE7" title="Listing 6Excerpt of the Exception Codes section from a crash report generated when a process was terminated because it dereferenced a NULL pointer."></a><p class="codesample clear"><strong class="caption_number">Listing 6</strong> Excerpt of the Exception Codes section from a crash report generated when a process was terminated because it dereferenced a NULL pointer.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Exception Type: EXC_BAD_ACCESS (SIGSEGV)<span></span></pre></td></tr><tr><td scope="row"><pre>Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000<span></span></pre></td></tr><tr><td scope="row"><pre>Termination Signal: Segmentation fault: 11<span></span></pre></td></tr><tr><td scope="row"><pre>Termination Reason: Namespace SIGNAL, Code 0xb<span></span></pre></td></tr><tr><td scope="row"><pre>Terminating Process: exc handler [0]<span></span></pre></td></tr><tr><td scope="row"><pre>Triggered by Thread: 0<span></span></pre></td></tr></table></div><p>An explanation of the fields that may appear in this section are presented below. </p><ul class="ul"><li class="li"><p><strong>Exception Codes</strong>: Processor specific information about the exception encoded into one or more 64-bit hexadecimal numbers. Typically, this field will not be present because the Crash Reporter parses the exception codes to present them as a human-readable description in the other fields.</p></li><li class="li"><p><strong>Exception Subtype</strong>: The human-readable name of the exception codes.</p></li><li class="li"><p><strong>Exception Message</strong>: Additional human-readable information extracted from the exception codes.</p></li><li class="li"><p><strong>Exception Note</strong>: Additional information that is not specific to one exception type. If this field contains <code>SIMULATED (this is NOT a crash)</code> then the process did not crash, but was killed at the request of the system, typically the watchdog.</p></li><li class="li"><p><strong>Termination Reason</strong>: Exit reason information specified when a process is terminated. Key system components, both inside and outside of a process, will terminate the process upon encountering a fatal error (e.g. a bad code signature, a missing dependent library, or accessing privacy sensitive information without the proper entitlement). macOS Sierra, iOS 10, watchOS 3, and tvOS 10 have adopted new infrastructure to record these errors, and crash reports generated by these operating systems list the error messages in the Termination Reason field.</p></li><li class="li"><p><strong>Triggered by Thread</strong>: The thread on which the exception originated.</p></li></ul><p>The following sections explain some of the most common exception types:</p><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-BAD_MEMORY_ACCESS__EXC_BAD_ACCESS____SIGSEGV____SIGBUS_" title="Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]"></a><h4 class="jump">Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]</h4><p>The process attempted to access invalid memory, or it attempted to access memory in a manner not allowed by the memory's protection level (e.g. writing to read-only memory). The <strong>Exception Subtype</strong> field contains a <code>kern_return_t</code> describing error and the address of the memory that was incorrectly accessed.</p><p>Here are some tips for debugging a bad memory access crash:</p><ul class="ul"><li class="li"><p>If <code>objc_msgSend</code> or <code>objc_release</code> are near the top of the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> for the crashed thread, the process may have attempted to message a deallocated object. You should profile the application with the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/EradicatingZombies.html" class="urlLink" rel="external">Zombies instrument</a></span> to better understand the conditions of this crash.</p></li><li class="li"><p>If <code>gpus_ReturnNotPermittedKillClient</code> is near the top of the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> for the crashed thread, the process was killed because it attempted to do rendering with OpenGL ES or Metal while in the background. See <span class="content_text"><a href="https://developer.apple.com/library/ios/qa/qa1766/_index.html" class="urlLink" rel="external">QA1766: How to fix OpenGL ES application crashes when moving to the background</a></span>.</p></li><li class="li"><p>Run your application with the <span class="content_text"><a href="https://developer.apple.com/videos/play/wwdc2015/413/" class="urlLink" rel="external">Address Sanitizer</a></span> enabled. The address sanitizer adds additional instrumentation around memory access in your compiled code. As your application runs, Xcode will alert you if memory is accessed in a way that could lead to a crash.</p></li></ul></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-ABNORMAL_EXIT__EXC_CRASH____SIGABRT_" title="Abnormal Exit [EXC_CRASH // SIGABRT]"></a><h4 class="jump">Abnormal Exit [EXC_CRASH // SIGABRT]</h4><p>The process exited abnormally. The most common causes of crashes with this exception type are uncaught Objective-C/C++ <span class="content_text"><!--a -->exceptions<!--/a--></span> and calls to <code>abort()</code>.</p><p>App Extensions will be terminated with this exception type if they take too much time to initialize (a watchdog termination). If an extension is killed due to a hang at launch, the <strong>Exception Subtype</strong> of the generated crash report will be <code>LAUNCH_HANG</code>. Because extensions do not have a <code>main</code> function, any time spent initializing occurs within static constructors and <code>+load</code> methods present in your extension and dependent libraries. You should defer as much of this work as possible.</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-TRACE_TRAP__EXC_BREAKPOINT____SIGTRAP_" title="Trace Trap [EXC_BREAKPOINT // SIGTRAP]"></a><h4 class="jump">Trace Trap [EXC_BREAKPOINT // SIGTRAP]</h4><p>Similar to an <span class="content_text"><!--a -->Abnormal Exit<!--/a--></span>, this exception is intended to give an attached debugger the chance to interrupt the process at a specific point in its execution. You can trigger this exception from your own code using the <code>__builtin_trap()</code> function. If no debugger is attached, the process is terminated and a crash report is generated.</p><p>Lower-level libraries (e.g. libdispatch) will trap the process upon encountering a fatal error. Additional information about the error can be found in the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-APPINFO" data-renderer-version="1">Additional Diagnostic Information</a></span> section of the crash report, or in the device's console.</p><p>Swift code will terminate with this exception type if an unexpected condition is encountered at runtime such as:</p><ul class="ul"><li class="li"><p>a non-optional type with a nil value</p></li><li class="li"><p>a failed forced type conversion</p></li></ul><p>Look at the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> to determine where the unexpected condition was encountered. Additional information may have also been logged to the device's console. You should modify the code at the crashing location to gracefully handle the runtime failure. For example, use <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html" class="urlLink" rel="external">Optional Binding</a></span> instead of force unwrapping an optional.</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-ILLEGAL_INSTRUCTION__EXC_BAD_INSTRUCTION____SIGILL_" title="Illegal Instruction [EXC_BAD_INSTRUCTION // SIGILL]"></a><h4 class="jump">Illegal Instruction [EXC_BAD_INSTRUCTION // SIGILL]</h4><p>The process attempted to execute an illegal or undefined instruction. The process may have attempted to jump to an invalid address via a misconfigured function pointer.</p><p>On Intel processors, the <code>ud2</code> opcode causes an <code>EXC_BAD_INSTRUCTION</code> exception but is commonly used to trap the process for debugging purposes. Swift code on Intel processors will terminate with this exception type if an unexpected condition is encountered at runtime. See <span class="content_text"><!--a -->Trace Trap<!--/a--></span> for details.</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-QUIT__SIGQUIT_" title="Quit [SIGQUIT]"></a><h4 class="jump">Quit [SIGQUIT]</h4><p>The process was terminated at the request of another process with privileges to manage its lifetime. <code>SIGQUIT</code> does not mean that the process crashed, but it did likely misbehave in a detectable manner.</p><p>On iOS, keyboard extensions will be quit by the host app if they take too long to load. It's unlikely that the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> shown in the crash report will point to the responsible code. Most likely, some other code along the startup path for the extension has taken a long time to complete but finished before the time limit, and execution moved onto the code shown in the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> when the extension was quit. You should <span class="content_text"><a href="https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/MeasuringCPUUse.html" class="urlLink" rel="external">profile</a></span> the extension to better understand where most of the work during startup is occurring, and move that work to a background thread or defer it until later (after the extension has loaded).</p></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-KILLED__SIGKILL_" title="Killed [SIGKILL]"></a><h4 class="jump">Killed [SIGKILL]</h4><p>The process was terminated at the request of the system. Look at the <strong>Termination Reason</strong> field to better understand the cause of the termination.</p><p>The <strong>Termination Reason</strong> field will contain a namespace followed by a code. The following codes are specific to watchOS:</p><ul class="ul"><li class="li"><p>The termination code <code>0xc51bad01</code> indicates that a watch app was terminated because it used too much CPU time while performing a background task. To address this issue, optimize the code performing the background task to be more CPU efficient, or decrease the amount of work that the app performs while running in the background.</p></li><li class="li"><p>The termination code <code>0xc51bad02</code> indicates that a watch app was terminated because it failed to complete a background task within the allocated time. To address this issue, decrease the amount of work that the app performs while running in the background.</p></li><li class="li"><p>The termination code <code>0xc51bad03</code> indicates that a watch app failed to complete a background task within the allocated time, and the system was sufficiently busy overall that the app may not have received much CPU time with which to perform the background task. Although an app may be able to avoid the issue by reducing the amount of work it performs in the background task, <code>0xc51bad03</code> does not indicate that the app did anything wrong. More likely, the app wasn’t able to complete its work because of overall system load.</p></li></ul></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-GUARDED_RESOURCE_VIOLATION__EXC_GUARD_" title="Guarded Resource Violation [EXC_GUARD]"></a><h4 class="jump">Guarded Resource Violation [EXC_GUARD]</h4><p>The process violated a guarded resource protection. System libraries may mark certain file descriptors as <strong>guarded</strong>, after which normal operations on those descriptors will trigger an <code>EXC_GUARD</code> exception (when it wants to operate on these file descriptors, the system uses special 'guarded' private APIs). This helps you quickly track down issues such as closing a file descriptor that had been opened by a system library. For example, if an app closes the file descriptor used to access the SQLite file backing a Core Data store, Core Data would then crash mysteriously much later on. The guard exception gets these problems noticed sooner, and thus makes them easier to debug.</p><p>Crash reports from newer versions of iOS include human-readable details about the operation that caused the <code>EXC_GUARD</code> exception in the <strong>Exception Subtype</strong> and <strong>Exception Message</strong> fields. In crash reports from macOS or older versions of iOS, this information is encoded into the first <strong>Exception Code</strong> as a bitfield which breaks down as follows:</p><ul class="ul"><li class="li"><p><strong>[63:61] - Guard Type</strong>: The type of the guarded resource. A value of <code>0x2</code> indicates the resource is a file descriptor.</p></li><li class="li"><p><strong>[60:32] - Flavor</strong>: The conditions under which the violation was triggered.</p><ul class="nested"><li class="nested li"><p>If the first <code>(1 << 0)</code> bit is set, the process attempted to invoke <code>close()</code> on a guarded file descriptor.</p></li><li class="nested li"><p>If the second <code>(1 << 1)</code> bit is set, the process attempted to invoke <code>dup()</code>, <code>dup2()</code>, or <code>fcntl()</code> with the <code>F_DUPFD</code> or <code>F_DUPFD_CLOEXEC</code> commands on a guarded file descriptor.</p></li><li class="nested li"><p>If the third <code>(1 << 2)</code> bit is set, the process attempted to send a guarded file descriptor via a socket.</p></li><li class="nested li"><p>If the fifth <code>(1 << 4)</code> bit is set, the process attempted to write to a guarded file descriptor.</p></li></ul></li><li class="li"><p><strong>[31:0] - File Descriptor</strong>: The guarded file descriptor that the process attempted to modify.</p></li></ul></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-RESOURCE_LIMIT__EXC_RESOURCE_" title="Resource Limit [EXC_RESOURCE]"></a><h4 class="jump">Resource Limit [EXC_RESOURCE]</h4><p>The process exceeded a resource consumption limit. This is a notification from the OS that the process is using too many resources. The exact resource is listed in the <strong>Exception Subtype</strong> field. If the <strong>Exception Note</strong> field contains <code>NON-FATAL CONDITION</code>, then the process was not killed even though a crash report was generated.</p><ul class="ul"><li class="li"><p>The exception subtype <code>MEMORY</code> indicates that the process has crossed a memory limit imposed by the system. This may be a precursor to termination for excess memory usage.</p></li><li class="li"><p>The exception subtype <code>WAKEUPS</code> indicates that threads in the process are being woken up too many times per second, which forces the CPU to wake up very often and consumes battery life. </p><p>Typically, this is caused by thread-to-thread communication (generally using <code>peformSelector:onThread:</code> or <code>dispatch_async</code>) that is unwittingly happening far more often than it should be. Because the sort of communication that triggers this exception is happening so frequently, there will usually be multiple background threads with very similar <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" data-renderer-version="1">Backtraces</a></span> - indicating where the communication is originating.</p></li></ul></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-OTHER_EXCEPTION_TYPES" title="Other Exception Types"></a><h4 class="jump">Other Exception Types</h4><p>Some crash reports may contain an un-named <strong>Exception Type</strong>, which will be printed as a hexadecimal value (e.g. 00000020). If you receive one of these crash reports, look directly to the <strong>Exception Codes</strong> field for more information.</p><ul class="ul"><li class="li"><p>The exception code <code>0xbaaaaaad</code> indicates that the log is a stackshot of the entire system, not a crash report. To take a stackshot, press the side button and both volume buttons simultaneously. Often these logs are accidentally created by users, and they do not indicate an error.</p></li><li class="li"><p>The exception code <code>0xbad22222</code> indicates that a VoIP application has been terminated by iOS because it resumed too frequently.</p></li><li class="li"><p>The exception code <code>0x8badf00d</code> indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing <span class="content_text"><a href="http://developer.apple.com/library/ios/qa/qa1693/" class="browserLink" >synchronous networking on the main thread</a></span>. Whatever operation is on <code>Thread 0</code> needs to be moved to a background thread, or processed differently, so that it does not block the main thread.</p></li><li class="li"><p>The exception code <code>0xc00010ff</code> indicates the app was killed by the operating system in response to a thermal event. This may be due to an issue with the particular device that this crash occurred on, or the environment it was operated in. For tips on making your app run more efficiently, see <span class="content_text"><a href="https://developer.apple.com/videos/wwdc/2011/?id=312" class="urlLink" rel="external">iOS Performance and Power Optimization with Instruments</a></span> WWDC session.</p></li><li class="li"><p>The exception code <code>0xdead10cc</code> indicates that an application has been terminated by the OS because it held on to a file lock or sqlite database lock during suspension. If your application is performing operations on a <span class="content_text"><a href="x-man-page://fcntl" class="urlLink" rel="external">locked file</a></span> or sqlite database at suspension time, it must <span class="content_text"><a href="https://developer.apple.com/reference/uikit/uiapplication/1623051-beginbackgroundtask" class="urlLink" rel="external">request additional background execution time</a></span> to complete those operations and relinquish the lock before suspending.</p></li><li class="li"><p>The exception code <code>0x2bad45ec</code> indicates that an application has been terminated by iOS due to a security violation. The termination description "Process detected doing insecure drawing while in secure mode" indicates the app tried to draw to the screen when not permitted to do so, such as when the screen is locked. Users may not notice this termination since the screen is off or the lock screen is displayed when this termination occurs.</p></li></ul><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_10" title="Note"></a><p><strong>Note:</strong> Terminating a suspended app using the app switcher does not generate a crash report. Once an app has suspended, it is eligible for termination by iOS at any time, so no crash report will be generated.</p><p></p></aside></div></section></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-APPINFO" title="Additional Diagnostic Information"></a><h3 class="jump">Additional Diagnostic Information</h3><p>This section includes additional diagnostic information specific to the type of termination, which may include: </p><ul class="ul"><li class="li"><p><strong>Application Specific Information</strong>: framework error messages captured just before the process terminated</p></li><li class="li"><p><strong>Kernel Messages</strong>: details about code-signature problems</p></li><li class="li"><p><strong>Dyld Error Messages</strong>: error messages emitted by the dynamic linker</p></li></ul><p>Starting in macOS Sierra, iOS 10, watchOS 3, and tvOS 10, most of this information is now reported in the <strong>Termination Reason</strong> field under the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO" data-renderer-version="1">Exception Information</a></span>.</p><p>You should read this section to better understand the circumstances under which the process was terminated.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE8" title="Listing 7Excerpt of the Application Specific Information section from a crash report generated when a process was terminated because a framework it links against could not be found."></a><p class="codesample clear"><strong class="caption_number">Listing 7</strong> Excerpt of the Application Specific Information section from a crash report generated when a process was terminated because a framework it links against could not be found.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Dyld Error Message:<span></span></pre></td></tr><tr><td scope="row"><pre>Dyld Message: Library not loaded: @rpath/MyCustomFramework.framework/MyCustomFramework<span></span></pre></td></tr><tr><td scope="row"><pre> Referenced from: /private/var/containers/Bundle/Application/CD9DB546-A449-41A4-A08B-87E57EE11354/TheElements.app/TheElements<span></span></pre></td></tr><tr><td scope="row"><pre> Reason: no suitable image found.<span></span></pre></td></tr></table></div><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE9" title="Listing 8Excerpt of the Application Specific Information section from a crash report generated when a process was terminated because it failed to load its initial view controller quickly."></a><p class="codesample clear"><strong class="caption_number">Listing 8</strong> Excerpt of the Application Specific Information section from a crash report generated when a process was terminated because it failed to load its initial view controller quickly.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Application Specific Information:<span></span></pre></td></tr><tr><td scope="row"><pre>com.example.apple-samplecode.TheElements failed to scene-create after 19.81s (launch took 0.19s of total time limit 20.00s)<span></span></pre></td></tr><tr><td scope="row"><pre> <span></span></pre></td></tr><tr><td scope="row"><pre>Elapsed total CPU time (seconds): 7.690 (user 7.690, system 0.000), 19% CPU<span></span></pre></td></tr><tr><td scope="row"><pre>Elapsed application CPU time (seconds): 0.697, 2% CPU<span></span></pre></td></tr></table></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE" title="Backtraces"></a><h3 class="jump">Backtraces</h3><p>The most interesting part of a crash report is the backtrace for each of the process's threads at the time it terminated. Each of these traces is similar to what you would see when pausing the process with the debugger.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE10" title="Listing 9Excerpt of the Backtrace section from a fully symbolicated crash report."></a><p class="codesample clear"><strong class="caption_number">Listing 9</strong> Excerpt of the Backtrace section from a fully symbolicated crash report.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Thread 0 name: Dispatch queue: com.apple.main-thread<span></span></pre></td></tr><tr><td scope="row"><pre>Thread 0 Crashed:<span></span></pre></td></tr><tr><td scope="row"><pre>0 TheElements 0x000000010006bc20 -[AtomicElementViewController myTransitionDidStop:finished:context:] (AtomicElementViewController.m:203)<span></span></pre></td></tr><tr><td scope="row"><pre>1 UIKit 0x0000000194cef0f0 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312<span></span></pre></td></tr><tr><td scope="row"><pre>2 UIKit 0x0000000194ceef30 -[UIViewAnimationState animationDidStop:finished:] + 160<span></span></pre></td></tr><tr><td scope="row"><pre>3 QuartzCore 0x0000000192178404 CA::Layer::run_animation_callbacks(void*) + 260<span></span></pre></td></tr><tr><td scope="row"><pre>4 libdispatch.dylib 0x000000018dd6d1c0 _dispatch_client_callout + 16<span></span></pre></td></tr><tr><td scope="row"><pre>5 libdispatch.dylib 0x000000018dd71d6c _dispatch_main_queue_callback_4CF + 1000<span></span></pre></td></tr><tr><td scope="row"><pre>6 CoreFoundation 0x000000018ee91f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12<span></span></pre></td></tr><tr><td scope="row"><pre>7 CoreFoundation 0x000000018ee8fb18 __CFRunLoopRun + 1660<span></span></pre></td></tr><tr><td scope="row"><pre>8 CoreFoundation 0x000000018edbe048 CFRunLoopRunSpecific + 444<span></span></pre></td></tr><tr><td scope="row"><pre>9 GraphicsServices 0x000000019083f198 GSEventRunModal + 180<span></span></pre></td></tr><tr><td scope="row"><pre>10 UIKit 0x0000000194d21bd0 -[UIApplication _run] + 684<span></span></pre></td></tr><tr><td scope="row"><pre>11 UIKit 0x0000000194d1c908 UIApplicationMain + 208<span></span></pre></td></tr><tr><td scope="row"><pre>12 TheElements 0x00000001000653c0 main (main.m:55)<span></span></pre></td></tr><tr><td scope="row"><pre>13 libdyld.dylib 0x000000018dda05b8 start + 4<span></span></pre></td></tr><tr><td scope="row"><pre> <span></span></pre></td></tr><tr><td scope="row"><pre>Thread 1:<span></span></pre></td></tr><tr><td scope="row"><pre>0 libsystem_kernel.dylib 0x000000018deb2a88 __workq_kernreturn + 8<span></span></pre></td></tr><tr><td scope="row"><pre>1 libsystem_pthread.dylib 0x000000018df75188 _pthread_wqthread + 968<span></span></pre></td></tr><tr><td scope="row"><pre>2 libsystem_pthread.dylib 0x000000018df74db4 start_wqthread + 4<span></span></pre></td></tr><tr><td scope="row"><pre> <span></span></pre></td></tr><tr><td scope="row"><pre>...<span></span></pre></td></tr></table></div><p>The first line lists the thread number and the identifier of the currently executing dispatch queue. The remaining lines list details about the individual stack frames in the backtrace. From left to right:</p><ul class="ul"><li class="li"><p>The stack frame number. Stack frames are presented in calling order, where frame zero is the function that was executing at the time execution halted. Frame one is the function that called the function in frame zero, and so on.</p></li><li class="li"><p>The name of the binary in which the executing function for the stack frame resides.</p></li><li class="li"><p>For frame zero, the address of the machine instruction that was executing when execution halted. For the remaining stack frames, the address of the machine instruction that will next execute when control returns to the stack frame.</p></li><li class="li"><p>In a <span class="content_text"><!--a -->symbolicated<!--/a--></span> crash report, the method name for the function in the stack frame.</p></li></ul><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-STACKTRACE-EXCEPTIONS" title="Exceptions"></a><h4 class="jump">Exceptions</h4><p>Exceptions in Objective-C are used to indicate programming errors detected at runtime such as accessing an array with an index that is out-of-bounds, attempts to mutate immutable objects, not implementing a required method of a protocol, or sending a message which the receiver does not recognize.</p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_11" title="Note"></a><p><strong>Note:</strong> Messaging a previously deallocated object may raise an <code>NSInvalidArgumentException</code> instead of crashing the program with a memory access violation. This occurs when a new object is allocated in the memory previously occupied by the deallocated object. If your application is crashing due to an uncaught <code>NSInvalidArgumentException</code> (look for <code>-[NSObject(NSObject) doesNotRecognizeSelector:]</code> in the exception backtrace), consider profiling your application with the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/EradicatingZombies.html" class="urlLink" rel="external">Zombies instrument</a></span> to eliminate the possibility that improper memory management is the cause.</p><p></p></aside></div><p>If an exception is not caught, it is intercepted by a function called the uncaught exception handler. The default uncaught exception handler logs the exception message to the device's console then terminates the process. Only the exception backtrace is written to the generated crash report under the <strong>Last Exception Backtrace</strong> section, as shown in <span class="content_text"><!--a -->Listing 10<!--/a--></span>. The exception message is omitted from the crash report. If you receive a crash report with a <strong>Last Exception Backtrace</strong> you should acquire the console logs from the originating device to better understand the conditions which caused the exception.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE11" title="Listing 10Excerpt of the Last Exception Backtrace section from an unsymbolicated crash report."></a><p class="codesample clear"><strong class="caption_number">Listing 10</strong> Excerpt of the Last Exception Backtrace section from an unsymbolicated crash report.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Last Exception Backtrace:<span></span></pre></td></tr><tr><td scope="row"><pre>(0x18eee41c0 0x18d91c55c 0x18eee3e88 0x18f8ea1a0 0x195013fe4 0x1951acf20 0x18ee03dc4 0x1951ab8f4 0x195458128 0x19545fa20 0x19545fc7c 0x19545ff70 0x194de4594 0x194e94e8c 0x194f47d8c 0x194f39b40 0x194ca92ac 0x18ee917dc 0x18ee8f40c 0x18ee8f89c 0x18edbe048 0x19083f198 0x194d21bd0 0x194d1c908 0x1000ad45c 0x18dda05b8)<span></span></pre></td></tr></table></div><p>A crash log with a Last Exception Backtrace containing only hexadecimal addresses must be symbolicated to produce a usable backtrace as shown in <span class="content_text"><!--a -->Listing 11<!--/a--></span>.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE12" title="Listing 11Excerpt of the Last Exception Backtrace section from a symbolicated crash report. This exception was raised when loading a scene in the app's storyboard. The corresponding IBOutlet for a connection to an element in the scene was missing."></a><p class="codesample clear"><strong class="caption_number">Listing 11</strong> Excerpt of the Last Exception Backtrace section from a symbolicated crash report. This exception was raised when loading a scene in the app's storyboard. The corresponding IBOutlet for a connection to an element in the scene was missing.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Last Exception Backtrace:<span></span></pre></td></tr><tr><td scope="row"><pre>0 CoreFoundation 0x18eee41c0 __exceptionPreprocess + 124<span></span></pre></td></tr><tr><td scope="row"><pre>1 libobjc.A.dylib 0x18d91c55c objc_exception_throw + 56<span></span></pre></td></tr><tr><td scope="row"><pre>2 CoreFoundation 0x18eee3e88 -[NSException raise] + 12<span></span></pre></td></tr><tr><td scope="row"><pre>3 Foundation 0x18f8ea1a0 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 272<span></span></pre></td></tr><tr><td scope="row"><pre>4 UIKit 0x195013fe4 -[UIViewController setValue:forKey:] + 104<span></span></pre></td></tr><tr><td scope="row"><pre>5 UIKit 0x1951acf20 -[UIRuntimeOutletConnection connect] + 124<span></span></pre></td></tr><tr><td scope="row"><pre>6 CoreFoundation 0x18ee03dc4 -[NSArray makeObjectsPerformSelector:] + 232<span></span></pre></td></tr><tr><td scope="row"><pre>7 UIKit 0x1951ab8f4 -[UINib instantiateWithOwner:options:] + 1756<span></span></pre></td></tr><tr><td scope="row"><pre>8 UIKit 0x195458128 -[UIStoryboard instantiateViewControllerWithIdentifier:] + 196<span></span></pre></td></tr><tr><td scope="row"><pre>9 UIKit 0x19545fa20 -[UIStoryboardSegueTemplate instantiateOrFindDestinationViewControllerWithSender:] + 92<span></span></pre></td></tr><tr><td scope="row"><pre>10 UIKit 0x19545fc7c -[UIStoryboardSegueTemplate _perform:] + 56<span></span></pre></td></tr><tr><td scope="row"><pre>11 UIKit 0x19545ff70 -[UIStoryboardSegueTemplate perform:] + 160<span></span></pre></td></tr><tr><td scope="row"><pre>12 UIKit 0x194de4594 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1352<span></span></pre></td></tr><tr><td scope="row"><pre>13 UIKit 0x194e94e8c -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268<span></span></pre></td></tr><tr><td scope="row"><pre>14 UIKit 0x194f47d8c _runAfterCACommitDeferredBlocks + 292<span></span></pre></td></tr><tr><td scope="row"><pre>15 UIKit 0x194f39b40 _cleanUpAfterCAFlushAndRunDeferredBlocks + 560<span></span></pre></td></tr><tr><td scope="row"><pre>16 UIKit 0x194ca92ac _afterCACommitHandler + 168<span></span></pre></td></tr><tr><td scope="row"><pre>17 CoreFoundation 0x18ee917dc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32<span></span></pre></td></tr><tr><td scope="row"><pre>18 CoreFoundation 0x18ee8f40c __CFRunLoopDoObservers + 372<span></span></pre></td></tr><tr><td scope="row"><pre>19 CoreFoundation 0x18ee8f89c __CFRunLoopRun + 1024<span></span></pre></td></tr><tr><td scope="row"><pre>20 CoreFoundation 0x18edbe048 CFRunLoopRunSpecific + 444<span></span></pre></td></tr><tr><td scope="row"><pre>21 GraphicsServices 0x19083f198 GSEventRunModal + 180<span></span></pre></td></tr><tr><td scope="row"><pre>22 UIKit 0x194d21bd0 -[UIApplication _run] + 684<span></span></pre></td></tr><tr><td scope="row"><pre>23 UIKit 0x194d1c908 UIApplicationMain + 208<span></span></pre></td></tr><tr><td scope="row"><pre>24 TheElements 0x1000ad45c main (main.m:55)<span></span></pre></td></tr><tr><td scope="row"><pre>25 libdyld.dylib 0x18dda05b8 start + 4<span></span></pre></td></tr></table></div><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_12" title="Note"></a><p><strong>Note:</strong> If you find that exceptions thrown within an exception handling domain setup by your application are not being caught, verify that you are <strong>not</strong> specifying the <code>-no_compact_unwind</code> flag when building your application or libraries.</p><p></p></aside></div><p>64-bit iOS uses a "zero-cost" exception implementation. In a "zero-cost" system, every function has additional data that describes how to unwind the stack if an exception is thrown across the function. If an exception is thrown across a stack frame that has no unwind data then exception handling cannot proceed and the process halts. There might be an exception handler farther up the stack, but if there is no unwind data for a frame then there is no way to get there from the stack frame where the exception was thrown. Specifying the <code>-no_compact_unwind</code> flag means you get no unwind tables for that code, so you can not throw exceptions across those functions. </p><p>Additionally, if you are including plain C code in your application or a library, you may need to specify the <code>-funwind-tables</code> flag to include unwind tables for all functions in that code.</p></section></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS-THREAD_STATE" title="Thread State"></a><h3 class="jump">Thread State</h3><p>This section lists the thread state of the crashed thread. This is a list of registers and their values at the time execution halted. Understanding the thread state is not necessary when reading a crash report but you may be able to use this information to better understand the conditions of the crash.</p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE13" title="Listing 12Excerpt of the Thread State section from a crash report from an ARM64 device."></a><p class="codesample clear"><strong class="caption_number">Listing 12</strong> Excerpt of the Thread State section from a crash report from an ARM64 device.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Thread 0 crashed with ARM Thread State (64-bit):<span></span></pre></td></tr><tr><td scope="row"><pre> x0: 0x0000000000000000 x1: 0x000000019ff776c8 x2: 0x0000000000000000 x3: 0x000000019ff776c8<span></span></pre></td></tr><tr><td scope="row"><pre> x4: 0x0000000000000000 x5: 0x0000000000000001 x6: 0x0000000000000000 x7: 0x00000000000000d0<span></span></pre></td></tr><tr><td scope="row"><pre> x8: 0x0000000100023920 x9: 0x0000000000000000 x10: 0x000000019ff7dff0 x11: 0x0000000c0000000f<span></span></pre></td></tr><tr><td scope="row"><pre> x12: 0x000000013e63b4d0 x13: 0x000001a19ff75009 x14: 0x0000000000000000 x15: 0x0000000000000000<span></span></pre></td></tr><tr><td scope="row"><pre> x16: 0x0000000187b3f1b9 x17: 0x0000000181ed488c x18: 0x0000000000000000 x19: 0x000000013e544780<span></span></pre></td></tr><tr><td scope="row"><pre> x20: 0x000000013fa49560 x21: 0x0000000000000001 x22: 0x000000013fc05f90 x23: 0x000000010001e069<span></span></pre></td></tr><tr><td scope="row"><pre> x24: 0x0000000000000000 x25: 0x000000019ff776c8 x26: 0xee009ec07c8c24c7 x27: 0x0000000000000020<span></span></pre></td></tr><tr><td scope="row"><pre> x28: 0x0000000000000000 fp: 0x000000016fdf29e0 lr: 0x0000000100017cf8<span></span></pre></td></tr><tr><td scope="row"><pre> sp: 0x000000016fdf2980 pc: 0x0000000100017d14 cpsr: 0x60000000<span></span></pre></td></tr></table></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS-BINARY_IMAGES" title="Binary Images"></a><h3 class="jump">Binary Images</h3><p>This section lists the binary images that were loaded in the process at the time of termination. </p><a name="//apple_ref/doc/uid/DTS40008184-CH1-SOURCECODE14" title="Listing 13Excerpt of the application's entry in the binary images section of a crash report."></a><p class="codesample clear"><strong class="caption_number">Listing 13</strong> Excerpt of the application's entry in the binary images section of a crash report.</p><div class="codesample clear"><table><tr><td scope="row"><pre>Binary Images:<span></span></pre></td></tr><tr><td scope="row"><pre>0x100060000 - 0x100073fff TheElements arm64 <2defdbea0c873a52afa458cf14cd169e> /var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements<span></span></pre></td></tr><tr><td scope="row"><pre>...<span></span></pre></td></tr></table></div><p>Each line includes the following details for a single binary image:</p><ul class="ul"><li class="li"><p>The binary image's address space within the process.</p></li><li class="li"><p>The binary name or bundle identifier of the binary (macOS only). In crash reports from macOS, a (+) is prepended if the binary is part of the OS.</p></li><li class="li"><p>(macOS only) The binary's short version string and bundle version, separated by a dash.</p></li><li class="li"><p>(iOS only) The architecture of the binary image. A binary may contain multiple "slices", one for each architecture it supports. Only one of these slices is loaded into the process.</p></li><li class="li"><p>An UUID which uniquely identifies the binary image. This value changes with each build of the binary and is used to locate the corresponding <strong>dSYM</strong> file when symbolicating the crash report.</p></li><li class="li"><p>The path to the binary on disk.</p></li></ul></section><div class="back_to_top"><a href="#top">Back to Top</a></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-UNDERSTANDING_LOW_MEMORY_REPORTS" title="Understanding Low Memory Reports"></a><h2 class="jump">Understanding Low Memory Reports</h2><p>When a low-memory condition is detected, the virtual memory system in iOS relies on the cooperation of applications to release memory. Low-memory notifications are sent to all running applications and processes as a request to free up memory, hoping to reduce the amount of memory in use. If memory pressure still exists, the system may terminate background processes to ease memory pressure. If enough memory can be freed up, your application will continue to run. If not, your application will be terminated by iOS because there isn't enough memory to satisfy the application's demands, and a low memory report will be generated and stored on the device.</p><p>The format of a low memory report differs from other crash reports in that there are no backtraces for the application threads. A low memory report begins with a header similar to the <span class="content_text"><a href="#//apple_ref/doc/uid/DTS40008184-CH1-CRASH_HEADER" data-renderer-version="1">Header</a></span> of a crash report. Following the header are a collection of fields listing system-wide memory statistics. Take note of the value for the <strong>Page Size</strong> field. The memory usage of each process in a low memory report is reported in terms of number of memory pages.</p><p>The most important part of a low memory report is the table of processes. This table lists all running processes, including system daemons, at the time the low memory report was generated. If a process was "jettisoned", the reason will be listed under the <strong>[reason]</strong> column. A process may be jettisoned for a number of reasons:</p><ul class="ul"><li class="li"><p><strong>[per-process-limit]</strong>: The process crossed its system-imposed memory limit. Per-process limits on resident memory are established by the system for all applications. Crossing this limit makes the process eligible for termination.</p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_13" title="Note"></a><p><strong>Note:</strong> Extensions have much lower per-process memory limit. Certain technologies, such as map views and SpriteKit, carry a high baseline memory cost and may be unsuitable for use in an extension.</p><p></p></aside></div></li><li class="li"><p><strong>[vm-pageshortage]/[vm-thrashing]/[vm]</strong>: The process was killed due to memory pressure.</p></li><li class="li"><p><strong>[vnode-limit]</strong>: Too many files are open. </p><div class="notebox"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_14" title="Note"></a><p><strong>Note:</strong> The system avoids killing the frontmost app when vnodes are nearly exhausted. This means that your application, when in the background, may be terminated even if it is not the source of excess vnode usage.</p><p></p></aside></div></li><li class="li"><p><strong>[highwater]</strong>: A system daemon crossed its high water mark for memory usage.</p></li><li class="li"><p><strong>[jettisoned]</strong>: The process was jettisoned for some other reason.</p></li></ul><p>If you do not see a reason listed next to your app/extension process, the cause of the crash was not memory pressure. Look for a <code>.crash</code> file (described in the <span class="content_text"><!--a -->previous section<!--/a--></span>) for more information.</p><p>When you see a low memory crash, rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/MemoryManagementforYourApp/MemoryManagementforYourApp.html" class="urlLink" rel="external">Locating Memory Issues in Your App</a></span> lists detailed steps on how to use the Leaks Instrument to discover memory leaks, and how to use the Allocations Instrument's Mark Heap feature to avoid abandoned memory. <span class="content_text"><a href="https://developer.apple.com/library/mac/#documentation/Performance/Conceptual/ManagingMemory/ManagingMemory.html#//apple_ref/doc/uid/10000160i" class="urlLink" rel="external">Memory Usage Performance Guidelines</a></span> discusses the proper ways to respond to low-memory notifications as well as many tips for using memory effectively. It is also recommended that you check out the WWDC 2010 session, <span class="content_text"><a href="https://developer.apple.com/videos/wwdc/2010/?id=311" class="urlLink" rel="external">Advanced Memory Analysis with Instruments</a></span>.</p><div class="importantbox clear"><aside><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_15" title="Important"></a><p><strong>Important:</strong> The Leaks and Allocations instruments do not track all memory usage. You need to run your application with the VM Tracker instrument (included in the Instruments Allocations template) to see your total memory usage. VM Tracker is disabled by default. To profile your application with VM Tracker, click the instrument, check the "Automatic Snapshotting" flag or press the "Snapshot Now" button manually.</p><p></p></aside></div><div class="back_to_top"><a href="#top">Back to Top</a></div></section><section><a name="//apple_ref/doc/uid/DTS40008184-CH1-RELATED_DOCUMENTS" title="Related Documents"></a><h2 class="jump">Related Documents</h2><p>For information about how to use the Instruments Zombies template to fix memory overrelease crashes, see <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/EradicatingZombies.html" class="urlLink" rel="external">Eradicating Zombies with the Zombies Trace Template</a></span>.</p><p>For more information about application archiving, refer to the the <span class="content_text"><a href="https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html" class="urlLink" rel="external">App Distribution Guide</a></span>.</p><p>For more information about interpreting crash logs, see <span class="content_text"><a href="https://developer.apple.com/videos/wwdc/2010/?id=317" class="urlLink" rel="external">Understanding Crash Reports on iPhone OS WWDC 2010 Session</a></span>.</p><div class="back_to_top"><a href="#top">Back to Top</a></div></section><br/><hr/><a name="//apple_ref/doc/uid/DTS40008184-CH1-DontLinkElementID_1" title="Document Revision History"></a><a name="//apple_ref/doc/uid/DTS40008184-RevisionHistory-DontLinkElementID_1" title="Document Revision History"></a><h4>Document Revision History</h4><br/><table class="graybox revision-history" border="0" cellspacing="0" cellpadding="5"><colgroup span="1"><col width="145" /></colgroup><tr><th scope="col" align="left"><strong>Date</strong></th><th scope="col" align="left"><strong>Notes</strong></th></tr><tr><td scope="row">2018-01-08</td><td><p>Added information about de-obfuscating symbols in dSYMs downloaded using the iTunes Connect website. Also added a description of the exception code 0x2bad45ec.</p></td></tr><tr><td scope="row">2017-04-03</td><td><p>Clarified that crash reports need to be named with a .crash extension to be symbolicated using Xcode. Removed the discussion of the 0xdeadfa11 exception code (force quitting an app no longer generates a crash report).</p></td></tr><tr><td scope="row">2017-02-21</td><td><p>Added information about some termination codes specific to watchOS apps. Added information about why keyboard extensions may receive a SIGQUIT signal. </p></td></tr><tr><td scope="row">2017-01-03</td><td><p>Added additional details and resolution suggestions for the 0xdead10cc exception code.</p></td></tr><tr><td scope="row">2016-09-02</td><td><p>Updated for iOS 10. Expanded the discussion of crash report symbolication.</p></td></tr><tr><td scope="row">2015-07-21</td><td><p>Updated for Xcode 6. Expanded the discussion of crash reports.</p></td></tr><tr><td scope="row">2012-12-13</td><td><p>Added information about more exception codes. </p></td></tr><tr><td scope="row">2012-03-28</td><td><p>Added information about low memory crash reports and more exception codes. Updated for Xcode 4.</p></td></tr><tr><td scope="row">2011-03-01</td><td><p>Updated to reflect changes for iOS 4.0 and later.</p></td></tr><tr><td scope="row">2010-07-06</td><td><p>Fixed bug in the documentation.</p></td></tr><tr><td scope="row">2010-05-18</td><td><p>Updated to reflect changes for the iPhone OS 3.2 SDK and Xcode 3.2.2.</p></td></tr><tr><td scope="row">2009-06-01</td><td><p>Added stronger emphasis about the need to save not only .dSYM files, but application binaries as well.</p></td></tr><tr><td scope="row">2009-04-30</td><td><p>Updated for iTunes Connect crash log service.</p></td></tr><tr><td scope="row">2009-02-18</td><td><p>Updated to include a workaround for an issue that prevents application code from being symbolicated.</p></td></tr><tr><td scope="row">2009-01-29</td><td><p>New document that
essential information for developers explaining how to symbolicate, understand, and interpret crash reports. </p></td></tr></table><br/>
<div id="pageNavigationLinks_bottom" class="pageNavigationLinks">
</div><br/>
<div class="copyright"><br/><hr /><div align="center"><p class="content_text" lang="en" dir="ltr"> Copyright © 2018 Apple Inc. All Rights Reserved. <a href="http://www.apple.com/legal/internet-services/terms/site.html" target="_blank">Terms of Use</a> | <a href="http://www.apple.com/privacy/" target="_blank">Privacy Policy</a> | Updated: 2018-01-08</p></div></div>
<!-- /CONTENTS -->
<div id="pediaWindow">
<div id="pediaHeader"></div>
<div id="pediaBody"></div>
</div>
</article>
<script charset="utf-8" src="../../Resources/1282/JavaScript/lib/prototype.js"></script>
<script src="../../Resources/1282/JavaScript/library.js"></script>
</body>
</html>
网友评论