以下各節將說明常見的原生當機類型、分析範例當機傾印，以及討論墓碑。每種類型的當機情形都會附上範例 debuggerd 輸出內容，並標示出重要證據，協助您區分特定類型的當機情形。
取消
中止作業很有趣，因為這是有意為之的行為。中止作業的方式有很多種 (包括呼叫 abort(3)、讓 assert(3) 失敗，或使用其中一種 Android 專屬的致命記錄類型)，但都會呼叫 abort。對 abort 的呼叫會以 SIGABRT 信號通知呼叫執行緒，因此在 debuggerd 輸出內容中，您可以透過 libc.so 顯示的「abort」加上 SIGABRT 來辨識此情況。
可能會有明確的「中止訊息」行。您也應查看 logcat 輸出內容，瞭解這個執行緒在故意自行終止前記錄了什麼，因為與 assert(3) 或高層級致命記錄設施不同，abort(3) 不會接受訊息。
目前的 Android 版本會將 tgkill(2) 系統呼叫內嵌，因此其堆疊最容易閱讀，且呼叫 abort(3) 會位於最上方：
pid: 4637, tid: 4637, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 0000121d r2 00000006 r3 00000008
r4 0000121d r5 0000121d r6 ffb44a1c r7 0000010c
r8 00000000 r9 00000000 r10 00000000 r11 00000000
ip ffb44c20 sp ffb44a08 lr eace2b0b pc eace2b16
backtrace:
#00 pc 0001cb16 /system/lib/libc.so (abort+57)
#01 pc 0001cd8f /system/lib/libc.so (__assert2+22)
#02 pc 00001531 /system/bin/crasher (do_action+764)
#03 pc 00002301 /system/bin/crasher (main+68)
#04 pc 0008a809 /system/lib/libc.so (__libc_init+48)
#05 pc 00001097 /system/bin/crasher (_start_main+38)
在舊版 Android 中，在原始中斷呼叫 (此處為影格 4) 和實際傳送信號 (此處為影格 0) 之間，會採用複雜的路徑。這在 32 位元 ARM 上尤其明顯，因為 __libc_android_abort (此處為影格 3) 會新增至其他平台的 raise/pthread_kill/tgkill 序列：
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
您可以使用 crasher
abort 重現這類當機事件的例項。
純空值指標解析
這是經典的原生當機，雖然這只是下一個當機類型的特殊情況，但值得單獨提及，因為這類問題通常需要最少的思考。
在以下範例中，即使發生當機的函式位於 libc.so 中，由於字串函式只會針對所提供的指標運作，因此您可以推斷 strlen(3) 是使用空值指標呼叫的；而這個當機問題應直接歸咎於呼叫程式碼的作者。在本例中，影格 #01 是錯誤的呼叫端。
pid: 25326, tid: 25326, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 00000000 r1 00000000 r2 00004c00 r3 00000000
r4 ab088071 r5 fff92b34 r6 00000002 r7 fff92b40
r8 00000000 r9 00000000 sl 00000000 fp fff92b2c
ip ab08cfc4 sp fff92a08 lr ab087a93 pc efb78988 cpsr 600d0030
backtrace:
#00 pc 00019988 /system/lib/libc.so (strlen+71)
#01 pc 00001a8f /system/xbin/crasher (strlen_null+22)
#02 pc 000017cd /system/xbin/crasher (do_action+948)
#03 pc 000020d5 /system/xbin/crasher (main+100)
#04 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#05 pc 000010e4 /system/xbin/crasher (_start+96)
您可以使用 crasher
strlen-NULL 重現這類當機事件的例項。
低位址空值指標解析
在多數情況下，錯誤位址不會是 0，而是其他較小的數字。特別是兩位或三位數的位址非常常見，而六位數的位址幾乎肯定不是空值指標解析，因為這需要 1 MiB 的偏移量。這通常是因為您有程式碼將空值指標解參照為有效結構體。常見的函式是 fprintf(3) (或任何其他使用 FILE*) 和 readdir(3) 的函式，因為程式碼通常無法檢查 fopen(3) 或 opendir(3) 呼叫是否確實先成功。
以下是 readdir 的範例：
pid: 25405, tid: 25405, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
r0 0000000c r1 00000000 r2 00000000 r3 3d5f0000
r4 00000000 r5 0000000c r6 00000002 r7 ff8618f0
r8 00000000 r9 00000000 sl 00000000 fp ff8618dc
ip edaa6834 sp ff8617a8 lr eda34a1f pc eda618f6 cpsr 600d0030
backtrace:
#00 pc 000478f6 /system/lib/libc.so (pthread_mutex_lock+1)
#01 pc 0001aa1b /system/lib/libc.so (readdir+10)
#02 pc 00001b35 /system/xbin/crasher (readdir_null+20)
#03 pc 00001815 /system/xbin/crasher (do_action+976)
#04 pc 000021e5 /system/xbin/crasher (main+100)
#05 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#06 pc 00001110 /system/xbin/crasher (_start+96)
這裡的當機直接原因是 pthread_mutex_lock(3) 嘗試存取位址 0xc (影格 0)。不過，pthread_mutex_lock 首先會解析所提供 pthread_mutex_t* 的 state 元素。查看來源時，您會發現元素位於結構體中的偏移 0，這表示 pthread_mutex_lock 已獲得無效的指標 0xc。從第 1 個影格，您可以看到 readdir 為該指標提供值，從而從所提供的 DIR* 中擷取 mutex_ 欄位。查看該結構時，您會發現 mutex_ 位於偏移 sizeof(int) + sizeof(size_t) + sizeof(dirent*) 至 struct DIR，在 32 位元裝置上為 4 + 4 + 4 = 12 = 0xc，因此您發現了錯誤：呼叫端將空值指標傳遞至 readdir。此時，您可以將堆疊貼入堆疊工具，找出 Logcat 中發生問題的位置。
struct DIR {
int fd_;
size_t available_bytes_;
dirent* next_;
pthread_mutex_t mutex_;
dirent buff_[15];
long current_pos_;
};
在大多數情況下，您可以略過這項分析。錯誤位址越低，通常就表示您可以直接略過堆疊中的任何 libc.so 影格，並直接指控呼叫程式碼。但並非總是如此，您可以透過以下方式提出有說服力的案例。
您可以使用 crasher
fprintf-NULL 或 crasher readdir-NULL 重現這類當機的例項。
FORTIFY 失敗
FORTIFY 失敗是一種中止的特殊情況，發生時機是 C 程式庫偵測到可能導致安全漏洞的問題。許多 C 程式庫函式都已加固；這些函式會採用額外引數，告知緩衝區實際大小，並在執行期間檢查您要執行的作業是否真的適合。以下範例說明程式碼嘗試將 read(fd, buf, 32) 寫入實際上只有 10 個位元組長度的緩衝區...
pid: 25579, tid: 25579, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'FORTIFY: read: prevented 32-byte write into 10-byte buffer'
r0 00000000 r1 000063eb r2 00000006 r3 00000008
r4 ff96f350 r5 000063eb r6 000063eb r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ff96f49c
ip 00000000 sp ff96f340 lr ee83ece3 pc ee86ef0c cpsr 000d0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e197 /system/lib/libc.so (__fortify_fatal+30)
#03 pc 0001baf9 /system/lib/libc.so (__read_chk+48)
#04 pc 0000165b /system/xbin/crasher (do_action+534)
#05 pc 000021e5 /system/xbin/crasher (main+100)
#06 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#07 pc 00001110 /system/xbin/crasher (_start+96)
您可以使用 crasher
fortify 重現這類當機事件的例項。
使用 -fstack-protector 偵測到堆疊毀損
編譯器的 -fstack-protector 選項會在堆疊上緩衝區的函式中插入檢查，以防緩衝區溢位。這個選項預設為開啟 (適用於平台程式碼)，但不適用於應用程式。啟用這個選項後，編譯器會在函式序曲中加入指示，在堆疊上最後一個本機之後寫入隨機值，並將其讀回至函式尾曲，以便檢查該值是否已變更。如果該值有所變更，則會遭到緩衝區溢位覆寫，因此尾聲會呼叫 __stack_chk_fail 來記錄訊息並中止。
pid: 26717, tid: 26717, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
r0 00000000 r1 0000685d r2 00000006 r3 00000008
r4 ffd516d8 r5 0000685d r6 0000685d r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ffd518bc
ip 00000000 sp ffd516c8 lr ee63ece3 pc ee66ef0c cpsr 000e0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e07d /system/lib/libc.so (__libc_fatal+24)
#03 pc 0004863f /system/lib/libc.so (__stack_chk_fail+6)
#04 pc 000013ed /system/xbin/crasher (smash_stack+76)
#05 pc 00001591 /system/xbin/crasher (do_action+280)
#06 pc 00002219 /system/xbin/crasher (main+100)
#07 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#08 pc 00001144 /system/xbin/crasher (_start+96)
您可以透過回溯追蹤中是否有 __stack_chk_fail 和特定中止訊息，來區分這類中止情形與其他類型的中止情形。
您可以使用 crasher
smash-stack 重現這類當機事件的例項。
來自不允許的系統呼叫的 Seccomp SIGSYS
seccomp 系統 (特別是 seccomp-bpf) 會限制系統呼叫的存取權。如要進一步瞭解平台開發人員的 seccomp，請參閱「Android O 中的 Seccomp 篩選器」網誌文章。呼叫受限系統呼叫的執行緒會收到 SIGSYS 訊號，其中代碼為 SYS_SECCOMP。系統呼叫號碼會與架構一併顯示在原因行中。請注意，系統呼叫號碼會因架構而異。舉例來說，readlinkat(2) 系統呼叫在 x86 上為 305，但在 x86-64 上為 267。arm 和 arm64 的呼叫號碼又不一樣。由於系統呼叫號碼會因架構而異，因此通常比較容易使用堆疊追蹤功能，找出哪個系統呼叫遭到禁止，而不是在標頭中尋找系統呼叫號碼。
pid: 11046, tid: 11046, name: crasher >>> crasher <<<
signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
Cause: seccomp prevented call to disallowed arm system call 99999
r0 cfda0444 r1 00000014 r2 40000000 r3 00000000
r4 00000000 r5 00000000 r6 00000000 r7 0001869f
r8 00000000 r9 00000000 sl 00000000 fp fffefa58
ip fffef898 sp fffef888 lr 00401997 pc f74f3658 cpsr 600f0010
backtrace:
#00 pc 00019658 /system/lib/libc.so (syscall+32)
#01 pc 00001993 /system/bin/crasher (do_action+1474)
#02 pc 00002699 /system/bin/crasher (main+68)
#03 pc 0007c60d /system/lib/libc.so (__libc_init+48)
#04 pc 000011b0 /system/bin/crasher (_start_main+72)
您可以透過信號行上的 SYS_SECCOMP 和原因行上的說明，區分遭禁止的系統呼叫和其他當機情形。
您可以使用 crasher
seccomp 重現這類當機事件的例項。
僅執行記憶體違規 (僅限 Android 10)
僅限 Android 10 的 arm64，二進位檔和程式庫的可執行片段會對應至記憶體執行 (不可讀取)，做為防範程式碼重複使用攻擊的強化技術。這項緩解措施與其他緩解措施互動不良，因此後來已移除。
讓程式碼無法讀取會導致有意或無意讀取標示為「僅限執行」的記憶體區段，進而擲回 SIGSEGV 並顯示程式碼 SEGV_ACCERR。這可能會因錯誤、漏洞、資料與程式碼混用 (例如字面值集區)，或有意記憶體檢視而發生。
編譯器會假設程式碼和資料不會混用，但手寫組合會導致問題。在多數情況下，只要將常數移至 .data 區段，即可修正這些問題。如果在可執行的程式碼區段中，絕對需要進行程式碼檢視，則應先呼叫 mprotect(2)，將程式碼標示為可讀，然後在作業完成後再次標示為不可讀。
pid: 2938, tid: 2940, name: crasher64 >>> crasher64 <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x5f2ced24a8
Cause: execute-only (no-read) memory access error; likely due to data in .text.
x0 0000000000000000 x1 0000005f2cecf21f x2 0000000000000078 x3 0000000000000053
x4 0000000000000074 x5 8000000000000000 x6 ff71646772607162 x7 00000020dcf0d16c
x8 0000005f2ced24a8 x9 000000781251c55e x10 0000000000000000 x11 0000000000000000
x12 0000000000000014 x13 ffffffffffffffff x14 0000000000000002 x15 ffffffffffffffff
x16 0000005f2ced52f0 x17 00000078125c0ed8 x18 0000007810e8e000 x19 00000078119fbd50
x20 00000078125d6020 x21 00000078119fbd50 x22 00000b7a00000b7a x23 00000078119fbdd8
x24 00000078119fbd50 x25 00000078119fbd50 x26 00000078119fc018 x27 00000078128ea020
x28 00000078119fc020 x29 00000078119fbcb0
sp 00000078119fba40 lr 0000005f2ced1b94 pc 0000005f2ced1ba4
backtrace:
#00 pc 0000000000003ba4 /system/bin/crasher64 (do_action+2348)
#01 pc 0000000000003234 /system/bin/crasher64 (thread_callback+44)
#02 pc 00000000000e2044 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#03 pc 0000000000083de0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
您可以根據原因行，將僅執行記憶體違規與其他當機狀況區分開。
您可以使用 crasher xom 重現這類當機事件的例項。
fdsan 偵測到的錯誤
Android 的 fdsan 檔案描述元清理器可協助找出檔案描述元常見的錯誤，例如使用後關閉和重複關閉。如要進一步瞭解如何偵錯 (以及避免) 這類錯誤，請參閱 fdsan 說明文件。
pid: 32315, tid: 32315, name: crasher64 >>> crasher64 <<< signal 35 (), code -1 (SI_QUEUE), fault addr -------- Abort message: 'attempted to close file descriptor 3, expected to be unowned, actually owned by FILE* 0x7d8e413018' x0 0000000000000000 x1 0000000000007e3b x2 0000000000000023 x3 0000007fe7300bb0 x4 3033313465386437 x5 3033313465386437 x6 3033313465386437 x7 3831303331346538 x8 00000000000000f0 x9 0000000000000000 x10 0000000000000059 x11 0000000000000034 x12 0000007d8ebc3a49 x13 0000007fe730077a x14 0000007fe730077a x15 0000000000000000 x16 0000007d8ec9a7b8 x17 0000007d8ec779f0 x18 0000007d8f29c000 x19 0000000000007e3b x20 0000000000007e3b x21 0000007d8f023020 x22 0000007d8f3b58dc x23 0000000000000001 x24 0000007fe73009a0 x25 0000007fe73008e0 x26 0000007fe7300ca0 x27 0000000000000000 x28 0000000000000000 x29 0000007fe7300c90 sp 0000007fe7300860 lr 0000007d8ec2f22c pc 0000007d8ec2f250 backtrace: #00 pc 0000000000088250 /bionic/lib64/libc.so (fdsan_error(char const*, ...)+384) #01 pc 0000000000088060 /bionic/lib64/libc.so (android_fdsan_close_with_tag+632) #02 pc 00000000000887e8 /bionic/lib64/libc.so (close+16) #03 pc 000000000000379c /system/bin/crasher64 (do_action+1316) #04 pc 00000000000049c8 /system/bin/crasher64 (main+96) #05 pc 000000000008021c /bionic/lib64/libc.so (_start_main)
您可以透過回溯追蹤中是否有 fdsan_error 和特定中止訊息，來區分這類中止情形與其他類型的中止情形。
您可以使用 crasher fdsan_file 或 crasher fdsan_dir 重現這類當機事件的例項。
調查當機傾印
如果您目前沒有要調查的特定當機問題，平台來源會提供名為 crasher 的工具，用於測試 debuggerd。如果您在 system/core/debuggerd/ 中 mm，則路徑上會同時出現 crasher 和 crasher64 (後者可讓您測試 64 位元當機情形)。Crasher 可根據您提供的指令列引數，以多種有趣的方式當機。使用 crasher --help 查看目前支援的選項。
為了介紹當機快照中的不同部分，我們將透過以下範例當機快照來說明：
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Tombstone written to: /data/tombstones/tombstone_06
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
如果您要搜尋記錄檔中的原生當機情形，則可使用帶有空格的星號行。除了原生當機事件的開頭，字串「*** ***」很少會出現在記錄中。
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
指紋可讓您精確找出發生當機的版本。這與 ro.build.fingerprint 系統屬性完全相同。
Revision: '0'
修訂版本是指硬體，而非軟體。這項屬性通常不會使用，但可用於自動略過已知由硬體故障造成的錯誤。這與 ro.revision 系統屬性完全相同。
ABI: 'arm'
ABI 為 arm、arm64、x86 或 x86-64 這項功能對上述 stack 指令碼特別有用，可讓指令碼瞭解要使用的工具鍊。
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
這行會指出程序中發生當機的特定執行緒。在本例中，這是程序的主執行緒，因此程序 ID 和執行緒 ID 相符。第一個名稱是執行緒名稱，而以 >>> 和 <<< 包圍的名稱則是程序名稱。對於應用程式而言，程序名稱通常是完整的套件名稱 (例如 com.facebook.katana)，這在回報錯誤或嘗試在 Google Play 中找出應用程式時非常實用。pid 和 tid 也能用於找出發生當機前相關的記錄行。
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
這行會告訴您收到哪個信號 (SIGABRT)，以及收到信號的方式 (SI_TKILL)。debuggerd 回報的信號包括 SIGABRT、SIGBUS、SIGFPE、SIGILL、SIGSEGV 和 SIGTRAP。信號專屬程式碼會因特定信號而異。
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
並非所有當機都會顯示中止訊息行，但中止會顯示。系統會自動從此 pid/tid 的最後一行致命 Logcat 輸出內容收集這項資訊，如果是故意中止的情況，這項資訊可能會說明為何程式會自行終止。
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8 r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
註冊傾印會顯示收到信號時的 CPU 註冊內容。(這個部分會因 ABI 而有極大差異)。這些資訊的實用性取決於實際的當機情形。
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
回溯追蹤會顯示發生當下程式碼所在的位置。第一個欄是影格編號 (與 gdb 的樣式相符，最深的影格編號為 0)。PC 值是相對於共用資料庫的位置，而非絕對位址。下一欄是對應區域的名稱 (通常是共用程式庫或可執行檔，但可能不適用於 JIT 編譯的程式碼)。最後，如果有符號，系統會顯示 PC 值對應的符號，以及該符號的位元組偏移量。您可以將此與 objdump(1) 搭配使用，找出對應的彙整器指令。
讀取墓碑
Tombstone written to: /data/tombstones/tombstone_06
這會告訴您 debuggerd 寫入額外資訊的位置。debuggerd 最多會保留 10 個墓碑，循環使用 00 到 09 的數字，並視需要覆寫現有的墓碑。
墓碑包含與當機傾印相同的資訊，以及一些額外的資訊。舉例來說，這包括所有執行緒的回溯追蹤 (而非僅限於當機執行緒)、浮點暫存器、原始堆疊傾印，以及暫存器中位址周圍的記憶體傾印。最實用的部分是，它還包含完整的記憶體對應表 (類似 /proc/pid/maps)。以下是 32 位元 ARM 程序異常終止的註解範例：
memory map: (fault address prefixed with --->) --->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId: b9527db01b5cf8f5402f899f64b9b121)
這裡有兩點需要注意。首先，這行開頭會加上「--->"。當當機不是單純的空值指標解析時，地圖最實用。如果錯誤位址很小，可能是空值指標解析的某種變化。否則，查看錯誤位址附近的地圖，通常可以讓您瞭解發生了什麼事。從地圖中可辨識的部分可能問題包括：
- 讀取/寫入記憶體區塊的結尾。
- 在記憶體區塊開頭前讀取/寫入。
- 嘗試執行非程式碼。
- 從堆疊結尾執行。
- 嘗試寫入程式碼 (如上例所示)。
其次，在 Android 6.0 以上版本中，可執行檔和共用程式庫檔案會顯示 BuildId (如有)，讓您能確切瞭解哪個版本的程式碼當機。自 Android 6.0 起，平台二進位檔預設會包含 BuildId；NDK r12 以上版本也會自動將 -Wl,--build-id 傳遞至連結器。
ab163000-ab163fff r-- 3000 1000 /system/xbin/crasher ab164000-ab164fff rw- 0 1000 f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc]
在 Android 上，堆積區不一定是單一區域。堆積區域會標示為 [anon:libc_malloc]。
f6d82000-f6da1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6da2000-f6dc1fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6dc2000-f6de1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6de2000-f6de5fff r-x 0 4000 /system/lib/libnetd_client.so (BuildId: 08020aa06ed48cf9f6971861abf06c9d) f6de6000-f6de6fff r-- 3000 1000 /system/lib/libnetd_client.so f6de7000-f6de7fff rw- 4000 1000 /system/lib/libnetd_client.so f6dec000-f6e74fff r-x 0 89000 /system/lib/libc++.so (BuildId: 8f1f2be4b37d7067d366543fafececa2) (load base 0x2000) f6e75000-f6e75fff --- 0 1000 f6e76000-f6e79fff r-- 89000 4000 /system/lib/libc++.so f6e7a000-f6e7afff rw- 8d000 1000 /system/lib/libc++.so f6e7b000-f6e7bfff rw- 0 1000 [anon:.bss] f6e7c000-f6efdfff r-x 0 82000 /system/lib/libc.so (BuildId: d189b369d1aafe11feb7014d411bb9c3) f6efe000-f6f01fff r-- 81000 4000 /system/lib/libc.so f6f02000-f6f03fff rw- 85000 2000 /system/lib/libc.so f6f04000-f6f04fff rw- 0 1000 [anon:.bss] f6f05000-f6f05fff r-- 0 1000 [anon:.bss] f6f06000-f6f0bfff rw- 0 6000 [anon:.bss] f6f0c000-f6f21fff r-x 0 16000 /system/lib/libcutils.so (BuildId: d6d68a419dadd645ca852cd339f89741) f6f22000-f6f22fff r-- 15000 1000 /system/lib/libcutils.so f6f23000-f6f23fff rw- 16000 1000 /system/lib/libcutils.so f6f24000-f6f31fff r-x 0 e000 /system/lib/liblog.so (BuildId: e4d30918d1b1028a1ba23d2ab72536fc) f6f32000-f6f32fff r-- d000 1000 /system/lib/liblog.so f6f33000-f6f33fff rw- e000 1000 /system/lib/liblog.so
共用程式庫通常有三個相鄰的項目。一個是可讀取及可執行的程式碼、一個是唯讀 (唯讀資料)，另一個則是可讀寫 (可變動資料)。第一個欄會顯示對應項目的位址範圍，第二個欄會顯示權限 (以一般 Unix ls(1) 樣式顯示)，第三個欄會顯示檔案偏移量 (以十六進位表示)，第四個欄會顯示區域大小 (以十六進位表示)，第五個欄會顯示檔案 (或其他區域名稱)。
f6f34000-f6f53fff r-x 0 20000 /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b) f6f54000-f6f54fff --- 0 1000 f6f55000-f6f55fff r-- 20000 1000 /system/lib/libm.so f6f56000-f6f56fff rw- 21000 1000 /system/lib/libm.so f6f58000-f6f58fff rw- 0 1000 f6f59000-f6f78fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6f79000-f6f98fff r-- 0 20000 /dev/__properties__/properties_serial f6f99000-f6f99fff rw- 0 1000 [anon:linker_alloc_vector] f6f9a000-f6f9afff r-- 0 1000 [anon:atexit handlers] f6f9b000-f6fbafff r-- 0 20000 /dev/__properties__/properties_serial f6fbb000-f6fbbfff rw- 0 1000 [anon:linker_alloc_vector] f6fbc000-f6fbcfff rw- 0 1000 [anon:linker_alloc_small_objects] f6fbd000-f6fbdfff rw- 0 1000 [anon:linker_alloc_vector] f6fbe000-f6fbffff rw- 0 2000 [anon:linker_alloc] f6fc0000-f6fc0fff r-- 0 1000 [anon:linker_alloc] f6fc1000-f6fc1fff rw- 0 1000 [anon:linker_alloc_lob] f6fc2000-f6fc2fff r-- 0 1000 [anon:linker_alloc] f6fc3000-f6fc3fff rw- 0 1000 [anon:linker_alloc_vector] f6fc4000-f6fc4fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc5000-f6fc5fff rw- 0 1000 [anon:linker_alloc_vector] f6fc6000-f6fc6fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc7000-f6fc7fff rw- 0 1000 [anon:arc4random _rsx structure] f6fc8000-f6fc8fff rw- 0 1000 [anon:arc4random _rs structure] f6fc9000-f6fc9fff r-- 0 1000 [anon:atexit handlers] f6fca000-f6fcafff --- 0 1000 [anon:thread signal stack guard page]
自 Android 5.0 起，C 程式庫會為大部分匿名對應的區域命名，因此神秘區域的數量會減少。
f6fcb000-f6fccfff rw- 0 2000 [stack:5081]
名為 [stack:tid] 的區域是指定執行緒的堆疊。
f6fcd000-f702afff r-x 0 5e000 /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7) f702b000-f702cfff r-- 5d000 2000 /system/bin/linker f702d000-f702dfff rw- 5f000 1000 /system/bin/linker f702e000-f702ffff rw- 0 2000 f7030000-f7030fff r-- 0 1000 f7031000-f7032fff rw- 0 2000 ffcd7000-ffcf7fff rw- 0 21000 ffff0000-ffff0fff r-x 0 1000 [vectors]
您看到 [vector] 或 [vdso] 取決於架構。ARM 使用 [vector]，而所有其他架構則使用 [vdso]。