本頁面由 Cloud Translation API 翻譯而成。

診斷原生程式碼發生錯誤的問題

以下各節說明常見的原生程式碼錯誤類型，當機傾印範例以及空值討論。每個當機類型都包含 debuggerd 輸出內容範例，其中醒目顯示重要證據您就能區分當機類型

取消

墮胎很有趣，因為這是刻意的。有許多不同的取消方式 (包括撥打電話) abort(3), 無法在 assert(3), 使用其中一種 Android 專屬嚴重記錄類型，但這些都會涉及正在撥打 abort。對 abort 的呼叫會發出來電信號有 SIGABRT 的執行緒，所以框架顯示「取消」於 libc.so+ 在 debuggerd 輸出內容中找出 SIGABRT 辨識這個情況

疑似有明確的「取消訊息」互動此外，您也應該查看 logcat 的輸出內容，用來查看這個執行緒在謹慎處理前的記錄內容自殺，因為與 assert(3) 或高階嚴重死亡不同記錄功能，abort(3) 不接受訊息。

將目前 Android 版本內嵌在 tgkill(2) 系統呼叫，所以其堆疊是最容易閱讀的位置，並呼叫取消(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，而是其他較少的數字。兩個或三位數的位址特別常見，而 6 位數的號碼是幾乎確定不是 null 指標解除參照，需要 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 確實會解除參照 state 所得到的 pthread_mutex_t* 元素查看您可以看到元素位於結構體中的位移 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 中的 where 發生此情況。

  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 選項會將檢查插入至設有內部部署緩衝區的函式，以避免緩衝區過度執行。這個選項平台程式碼預設為開啟，但應用程式不會。這個選項的運作方式為編譯器會將指令新增至功能 Prologue，以便寫入堆疊上最後一個本機之後的隨機值，然後檢查它是否未變更。如果但因緩衝區覆寫而覆寫值呼叫 __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 重現這類當機情況的執行個體。

透過不允許的系統呼叫保護 SIGSYS

seccomp 系統 (具體來說是 seccomp-bpf) 限制存取系統呼叫。如要如要進一步瞭解平台開發人員適用的 seccomp，請參閱這篇網誌文章 Seccomp 篩選功能如果執行緒呼叫受限系統呼叫，收到含有代碼 SYS_SECCOMP 的 SIGSYS 訊號。系統通話號碼會是狀態和架構請務必注意系統呼叫編號會因架構而異舉例來說， readlinkat(2) 系統呼叫的 x86 號碼為 305，x86-64 則為 267。實驗組和 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，這些 Pod 會對應至轉換為僅供執行的記憶體 (不可讀取)，做為防範程式碼重複使用攻擊的強化技術。這種緩解措施與其他因應措施無關，但後來已移除。

將程式碼設為無法讀取會導致蓄意讀取有意且無意中讀取的記憶體區段僅供執行，用於擲回具有 SEGV_ACCERR 程式碼的 SIGSEGV。這可能會是由於錯誤、安全漏洞、資料混和程式碼 (例如常值集區) 所造成。或有意自我檢查

編譯器假設程式碼和資料並未明確指定，但以手寫方式發生問題可能引發問題在多數情況下，只要將常數移至 .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 檔案描述元 Sanitizer 可找出具有檔案描述元的常見錯誤，例如「交易結束後」和「雙關閉」詳情請參閱 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。

調查當機傾印檔

如果沒有正在調查的特定當機問題，平台來源包含一項用於測試 debuggerd 的工具當機。如果你在「system/core/debuggerd/」mm，會在路徑上同時取得 crasher 和 crasher64 ( 後者可讓您測試 64 位元的當機情形)。當機可能導致所有有趣的實際操作方法。使用 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 是 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'

並非所有當機事件都會顯示取消訊息行，但會取消。這是會自動從最後一行的嚴重 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

註冊傾印檔會顯示訊號。(這個部分在 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 值是相對於共用資料庫的位置，而非而非絕對位址下一欄是對應區域的名稱 (這通常是共用程式庫或執行檔，但也可能不。最後，如果有可用的符號，代表電腦使用的符號值，並將偏移量轉換為該符號一個位元組這可以搭配 objdump(1) 使用來尋找對應的組合器指示

讀取空值標記

Tombstone written to: /data/tombstones/tombstone_06

瞭解 debuggerd 在何處撰寫額外資訊。 debuggerd將保存最多 10 座墓碑，在的值從 00 到 09，然後視需要覆寫現有空值。

Tombstone 包含與當機傾印相同的資訊，另外還有一些額外項目。例如，其中包含「所有」執行緒的回溯追蹤 (非例如當機執行緒)、浮點暫存器、原始堆疊傾印以及暫存器中位址周圍的記憶體傾印最有用包含完整的記憶體對應 (與 /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 (如果有的話)，即可查看當機的是哪個版本的程式碼平台二進位檔包括 BuildId 自 Android 6.0 起採用預設設定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]。