Chẩn đoán sự cố gốc

Các phần sau đây bao gồm các loại sự cố tự nhiên phổ biến, phân tích kết xuất sự cố mẫu và thảo luận về bia mộ. Mỗi loại sự cố bao gồm đầu ra debuggerd mẫu với bằng chứng chính được đánh dấu để giúp bạn phân biệt loại sự cố cụ thể.

Huỷ bỏ

Việc hủy bỏ rất thú vị vì chúng có chủ ý. Có nhiều cách khác nhau để hủy bỏ (bao gồm gọi abort(3) , không thực hiện được assert(3) , sử dụng một trong các loại ghi nhật ký gây tử vong dành riêng cho Android), nhưng tất cả đều liên quan đến việc gọi abort . Lệnh gọi abort báo hiệu luồng đang gọi bằng SIGABRT, do đó, khung hiển thị "hủy bỏ" trong libc.so cộng với SIGABRT là những thứ cần tìm trong đầu ra của debuggerd để nhận ra trường hợp này.

Có thể có dòng "hủy tin nhắn" rõ ràng. Bạn cũng nên xem đầu ra logcat để xem luồng này đã ghi lại những gì trước khi cố tình tự hủy, vì không giống như assert(3) hoặc các phương tiện ghi nhật ký nghiêm trọng cấp cao, abort(3) không chấp nhận tin nhắn.

Các phiên bản hiện tại của Android nội tuyến lệnh gọi hệ thống tgkill(2) , do đó, ngăn xếp của chúng dễ đọc nhất, với lệnh gọi abort(3) ở trên cùng:

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)

Các phiên bản Android cũ hơn đi theo một đường dẫn phức tạp giữa lệnh gọi hủy ban đầu (khung 4 ở đây) và việc gửi tín hiệu thực tế (khung 0 ở đây). Điều này đặc biệt đúng trên ARM 32-bit, đã thêm __libc_android_abort (khung 3 ở đây) vào chuỗi raise / pthread_kill / tgkill của các nền tảng khác:

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

Bạn có thể tái tạo một trường hợp của loại sự cố này bằng cách sử dụng crasher abort .

Vô hiệu hóa con trỏ null thuần túy

Đây là sự cố bản địa cổ điển, và mặc dù nó chỉ là trường hợp đặc biệt của loại sự cố tiếp theo, nhưng nó đáng được đề cập riêng vì nó thường đòi hỏi ít suy nghĩ nhất.

Trong ví dụ bên dưới, mặc dù hàm gặp sự cố nằm trong libc.so , vì các hàm chuỗi chỉ hoạt động trên các con trỏ mà chúng đưa ra, nên bạn có thể suy ra rằng strlen(3) được gọi bằng một con trỏ null; và sự cố này sẽ chuyển thẳng đến tác giả của mã gọi. Trong trường hợp này, khung số 01 là người gọi không hợp lệ.

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)

Bạn có thể tái tạo một trường hợp của loại sự cố này bằng cách sử dụng crasher strlen-NULL .

Tham chiếu con trỏ null địa chỉ thấp

Trong nhiều trường hợp, địa chỉ lỗi sẽ không phải là 0 mà là một số thấp khác. Đặc biệt, các địa chỉ có hai hoặc ba chữ số là rất phổ biến, trong khi địa chỉ sáu chữ số gần như chắc chắn không phải là một tham chiếu con trỏ null—điều đó sẽ yêu cầu độ lệch 1MiB. Điều này thường xảy ra khi bạn có mã hủy tham chiếu một con trỏ null như thể nó là một cấu trúc hợp lệ. Các hàm phổ biến là fprintf(3) (hoặc bất kỳ hàm nào khác lấy FILE*) và readdir(3) , vì mã thường không kiểm tra được xem lệnh gọi fopen(3) hoặc opendir(3) có thực sự thành công trước tiên hay không.

Đây là một ví dụ về 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)

Ở đây nguyên nhân trực tiếp của sự cố là do pthread_mutex_lock(3) đã cố truy cập địa chỉ 0xc (khung 0). Nhưng điều đầu tiên pthread_mutex_lock thực hiện là hủy đăng ký phần tử state của pthread_mutex_t* mà nó đã được cung cấp. Nếu bạn nhìn vào nguồn, bạn có thể thấy phần tử đó ở offset 0 trong cấu trúc, điều này cho bạn biết rằng pthread_mutex_lock đã được cấp con trỏ không hợp lệ 0xc. Từ khung 1, bạn có thể thấy rằng nó được cấp cho con trỏ đó bởi readdir , nó trích xuất trường mutex_ từ DIR* mà nó được cung cấp. Nhìn vào cấu trúc đó, bạn có thể thấy rằng mutex_ nằm ở offset sizeof(int) + sizeof(size_t) + sizeof(dirent*) thành struct DIR , trên thiết bị 32 bit là 4 + 4 + 4 = 12 = 0xc, vậy là bạn đã tìm thấy lỗi: readdir đã được người gọi chuyển một con trỏ rỗng. Tại thời điểm này, bạn có thể dán ngăn xếp vào công cụ ngăn xếp để tìm hiểu xem điều này đã xảy ra ở đâu trong logcat.

  struct DIR {
    int fd_;
    size_t available_bytes_;
    dirent* next_;
    pthread_mutex_t mutex_;
    dirent buff_[15];
    long current_pos_;
  };

Trong hầu hết các trường hợp, bạn thực sự có thể bỏ qua phân tích này. Địa chỉ lỗi đủ thấp thường có nghĩa là bạn có thể bỏ qua bất kỳ khung libc.so nào trong ngăn xếp và trực tiếp buộc tội mã gọi. Nhưng không phải lúc nào cũng vậy, và đây là cách bạn trình bày một trường hợp thuyết phục.

Bạn có thể tái tạo các trường hợp của loại sự cố này bằng cách sử dụng crasher fprintf-NULL hoặc crasher readdir-NULL .

củng cố thất bại

Lỗi FORTIFY là trường hợp hủy bỏ đặc biệt xảy ra khi thư viện C phát hiện sự cố có thể dẫn đến lỗ hổng bảo mật. Nhiều chức năng thư viện C được tăng cường ; họ đưa ra một đối số bổ sung để cho họ biết bộ đệm thực sự lớn đến mức nào và kiểm tra trong thời gian chạy xem thao tác bạn đang cố gắng thực hiện có thực sự phù hợp hay không. Đây là ví dụ trong đó mã cố read(fd, buf, 32) vào bộ đệm thực tế chỉ dài 10 byte...

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)

Bạn có thể tái tạo một trường hợp của loại sự cố này bằng cách sử dụng crasher fortify .

Ngăn xếp bị hỏng được phát hiện bởi -fstack-protector

Tùy chọn -fstack-protector của trình biên dịch sẽ chèn các kiểm tra vào các hàm có bộ đệm trên ngăn xếp để bảo vệ chống lại việc tràn bộ đệm. Tùy chọn này được bật theo mặc định cho mã nền tảng nhưng không bật cho ứng dụng. Khi tùy chọn này được bật, trình biên dịch sẽ thêm các hướng dẫn vào phần mở đầu hàm để ghi một giá trị ngẫu nhiên vừa qua vị trí cuối cùng trên ngăn xếp và vào phần kết của hàm để đọc lại và kiểm tra xem nó có bị thay đổi hay không. Nếu giá trị đó thay đổi, nó sẽ bị ghi đè do lỗi tràn bộ đệm, vì vậy phần kết sẽ gọi __stack_chk_fail để ghi thông báo và hủy bỏ.

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)

Bạn có thể phân biệt điều này với các kiểu hủy bỏ khác bằng sự hiện diện của __stack_chk_fail trong dấu vết quay lại và thông báo hủy bỏ cụ thể.

Bạn có thể tái tạo một trường hợp của loại sự cố này bằng cách sử dụng crasher smash-stack .

Seccomp SIGSYS từ cuộc gọi hệ thống không được phép

Hệ thống seccomp (cụ thể là seccomp-bpf) hạn chế quyền truy cập vào các cuộc gọi hệ thống. Để biết thêm thông tin về seccomp dành cho nhà phát triển nền tảng, hãy xem bài đăng trên blog Bộ lọc Seccomp trong Android O . Một luồng gọi cuộc gọi hệ thống bị hạn chế sẽ nhận được tín hiệu SIGSYS có mã SYS_SECCOMP. Số cuộc gọi hệ thống sẽ được hiển thị trong dòng nguyên nhân, cùng với kiến ​​trúc. Điều quan trọng cần lưu ý là số lần gọi hệ thống khác nhau giữa các kiến ​​trúc. Ví dụ: lệnh gọi hệ thống readlinkat(2) là số 305 trên x86 nhưng là 267 trên x86-64. Số cuộc gọi lại khác ở cả cánh tay và cánh tay64. Vì số cuộc gọi hệ thống khác nhau giữa các kiến ​​trúc nên việc sử dụng dấu vết ngăn xếp để tìm ra cuộc gọi hệ thống nào không được phép thường dễ dàng hơn thay vì tìm số cuộc gọi hệ thống trong tiêu đề.

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)

Bạn có thể phân biệt các cuộc gọi hệ thống không được phép với các sự cố khác bằng sự hiện diện của SYS_SECCOMP trên đường tín hiệu và mô tả trên đường nguyên nhân.

Bạn có thể tái tạo một trường hợp của loại sự cố này bằng cách sử dụng crasher seccomp .

Vi phạm bộ nhớ chỉ thực thi (chỉ dành cho Android 10)

Chỉ dành cho arm64 trong Android 10, các phân đoạn nhị phân và thư viện có thể thực thi được ánh xạ vào bộ nhớ chỉ thực thi (không thể đọc được) như một kỹ thuật tăng cường chống lại các cuộc tấn công tái sử dụng mã. Giảm thiểu này tương tác xấu với các giảm nhẹ khác và sau đó đã bị loại bỏ.

Việc làm cho mã không thể đọc được sẽ khiến việc đọc có chủ ý và vô ý vào các phân đoạn bộ nhớ được đánh dấu là chỉ thực thi để ném SIGSEGV có mã SEGV_ACCERR . Điều này có thể xảy ra do lỗi, lỗ hổng bảo mật, dữ liệu bị trộn lẫn với mã (chẳng hạn như nhóm chữ) hoặc việc xem xét nội bộ bộ nhớ có chủ ý.

Trình biên dịch giả định mã và dữ liệu không được trộn lẫn với nhau, nhưng các vấn đề có thể phát sinh từ quá trình lắp ráp viết tay. Trong nhiều trường hợp, những điều này có thể được khắc phục bằng cách di chuyển các hằng số sang phần .data . Nếu việc xem xét nội bộ mã là hoàn toàn cần thiết đối với các phần mã thực thi, thì trước tiên nên gọi mprotect(2) để đánh dấu mã có thể đọc được, sau đó đánh dấu lại là không thể đọc được sau khi thao tác hoàn tất.

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)

Bạn có thể phân biệt các vi phạm bộ nhớ chỉ thực thi với các sự cố khác theo dòng nguyên nhân.

Bạn có thể tái tạo một phiên bản của loại sự cố này bằng cách sử dụng crasher xom .

Lỗi được phát hiện bởi fdsan

Trình khử trùng bộ mô tả tệp fdsan của Android giúp phát hiện các lỗi phổ biến với các bộ mô tả tệp như sử dụng sau khi đóng và đóng kép. Xem tài liệu fdsan để biết thêm chi tiết về cách gỡ lỗi (và tránh) loại lỗi này.

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)

Bạn có thể phân biệt điều này với các kiểu hủy bỏ khác bằng sự hiện diện của fdsan_error trong dấu vết quay lại và thông báo hủy bỏ cụ thể.

Bạn có thể tái tạo một phiên bản của loại sự cố này bằng cách sử dụng crasher fdsan_file hoặc crasher fdsan_dir .

Điều tra các bãi chứa sự cố

Nếu hiện tại bạn không gặp sự cố cụ thể nào mà bạn đang điều tra thì nguồn nền tảng sẽ bao gồm một công cụ để kiểm tra debuggerd được gọi là trình gỡ lỗi. Nếu bạn mm in system/core/debuggerd/ bạn sẽ nhận được cả một crasher và một crasher64 trên đường dẫn của mình (cái sau cho phép bạn kiểm tra các sự cố 64-bit). Crasher có thể gặp sự cố theo nhiều cách thú vị dựa trên các đối số dòng lệnh bạn cung cấp. Sử dụng crasher --help để xem lựa chọn hiện được hỗ trợ.

Để giới thiệu các phần khác nhau trong kết xuất sự cố, chúng ta hãy xem xét kết xuất sự cố ví dụ này:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Dòng dấu hoa thị có dấu cách sẽ hữu ích nếu bạn đang tìm kiếm nhật ký cho các sự cố gốc. Chuỗi "*** ***" hiếm khi xuất hiện trong nhật ký ngoại trừ lúc bắt đầu sự cố gốc.

Build fingerprint:
'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'

Dấu vân tay cho phép bạn xác định chính xác bản dựng nào đã xảy ra sự cố. Điều này hoàn toàn giống với thuộc tính hệ thống ro.build.fingerprint .

Revision: '0'

Bản sửa đổi đề cập đến phần cứng chứ không phải phần mềm. Điều này thường không được sử dụng nhưng có thể hữu ích để giúp bạn tự động bỏ qua các lỗi được xác định là do phần cứng xấu gây ra. Thuộc tính này hoàn toàn giống với thuộc tính hệ thống ro.revision .

ABI: 'arm'

ABI là một trong các nhánh, arm64, x86 hoặc x86-64. Điều này chủ yếu hữu ích cho tập lệnh stack được đề cập ở trên, để nó biết nên sử dụng chuỗi công cụ nào.

pid: 1656, tid: 1656, name: crasher >>> crasher <<<

Dòng này xác định chuỗi cụ thể trong quá trình bị lỗi. Trong trường hợp này, đó là luồng chính của tiến trình, do đó ID tiến trình và ID luồng khớp nhau. Tên đầu tiên là tên luồng và tên được bao quanh bởi >>> và <<< là tên tiến trình. Đối với một ứng dụng, tên quy trình thường là tên gói đủ điều kiện (chẳng hạn như com.facebook.katana), rất hữu ích khi báo cáo lỗi hoặc cố gắng tìm ứng dụng trong Google Play. pid và tid cũng có thể hữu ích trong việc tìm kiếm các dòng nhật ký có liên quan trước sự cố.

signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

Dòng này cho bạn biết tín hiệu nào (SIGABRT) đã được nhận và thông tin khác về cách nhận tín hiệu đó (SI_TKILL). Các tín hiệu được debuggerd báo cáo là SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV và SIGTRAP. Các mã dành riêng cho tín hiệu khác nhau tùy theo tín hiệu cụ thể.

Abort message: 'some_file.c:123: some_function: assertion "false" failed'

Không phải tất cả các sự cố đều có dòng thông báo hủy bỏ, nhưng các dòng thông báo hủy bỏ sẽ có. Điều này được tự động thu thập từ dòng cuối cùng của đầu ra logcat nghiêm trọng cho pid/tid này và trong trường hợp hủy bỏ có chủ ý có thể đưa ra lời giải thích tại sao chương trình tự hủy.

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

Kết xuất thanh ghi hiển thị nội dung của các thanh ghi CPU tại thời điểm nhận được tín hiệu. (Phần này rất khác nhau giữa các ABI.) Mức độ hữu ích của chúng sẽ phụ thuộc vào sự cố chính xác.

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

Dấu vết quay lại cho bạn biết chúng ta đang ở đâu trong mã tại thời điểm xảy ra sự cố. Cột đầu tiên là số khung (khớp với kiểu của gdb trong đó khung sâu nhất là 0). Các giá trị PC liên quan đến vị trí của thư viện dùng chung thay vì địa chỉ tuyệt đối. Cột tiếp theo là tên của vùng được ánh xạ (thường là thư viện dùng chung hoặc tệp thực thi, nhưng có thể không dành cho mã do JIT biên dịch). Cuối cùng, nếu có sẵn các ký hiệu thì ký hiệu mà giá trị PC tương ứng sẽ được hiển thị, cùng với phần bù vào ký hiệu đó theo byte. Bạn có thể sử dụng kết hợp này với objdump(1) để tìm hướng dẫn trình biên dịch mã tương ứng.

Đọc bia mộ

Tombstone written to: /data/tombstones/tombstone_06

Điều này cho bạn biết nơi debuggerd đã viết thêm thông tin. debuggerd sẽ giữ tối đa 10 bia mộ, chuyển qua các số từ 00 đến 09 và ghi đè các bia mộ hiện có nếu cần.

Bia mộ chứa thông tin tương tự như bãi chứa vụ tai nạn, cùng với một số thông tin bổ sung. Ví dụ: nó bao gồm các dấu vết ngược cho tất cả các luồng (không chỉ luồng bị lỗi), các thanh ghi dấu phẩy động, các kết xuất ngăn xếp thô và các kết xuất bộ nhớ xung quanh các địa chỉ trong các thanh ghi. Hữu ích nhất là nó cũng bao gồm một bản đồ bộ nhớ đầy đủ (tương tự như /proc/ pid /maps ). Đây là một ví dụ được chú thích từ sự cố quy trình ARM 32 bit:

memory map: (fault address prefixed with --->)
--->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId:
b9527db01b5cf8f5402f899f64b9b121)

Có hai điều cần lưu ý ở đây. Đầu tiên là dòng này có tiền tố là "--->". Các bản đồ này hữu ích nhất khi sự cố của bạn không chỉ là sự vô hiệu hóa con trỏ rỗng. Nếu địa chỉ lỗi nhỏ thì đó có thể là một biến thể nào đó của việc vô hiệu hóa con trỏ null. Nếu không, việc nhìn vào bản đồ xung quanh địa chỉ lỗi thường có thể cho bạn manh mối về điều gì đã xảy ra. Một số vấn đề có thể xảy ra có thể được nhận ra bằng cách xem bản đồ bao gồm:

  • Đọc/ghi đến cuối khối bộ nhớ.
  • Đọc/ghi trước khi bắt đầu một khối bộ nhớ.
  • Nỗ lực thực thi không phải mã.
  • Chạy hết phần cuối của ngăn xếp.
  • Cố gắng viết mã (như trong ví dụ trên).

Điều thứ hai cần lưu ý là các tệp thực thi và tệp thư viện dùng chung sẽ hiển thị BuildId (nếu có) trong Android 6.0 trở lên, do đó bạn có thể biết chính xác phiên bản mã nào của mình bị lỗi. Các tệp nhị phân của nền tảng bao gồm BuildId theo mặc định kể từ Android 6.0; NDK r12 trở lên cũng tự động chuyển -Wl,--build-id cho trình liên kết.

ab163000-ab163fff r--      3000      1000  /system/xbin/crasher
ab164000-ab164fff rw-         0      1000
f6c80000-f6d7ffff rw-         0    100000  [anon:libc_malloc]

Trên Android vùng heap không nhất thiết phải là một vùng duy nhất. Vùng heap sẽ được gắn nhãn [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

Thông thường, một thư viện dùng chung có ba mục liền kề. Một là có thể đọc và thực thi được (mã), một là chỉ đọc (dữ liệu chỉ đọc) và một là đọc-ghi (dữ liệu có thể thay đổi). Cột đầu tiên hiển thị phạm vi địa chỉ cho ánh xạ, cột thứ hai các quyền (theo kiểu Unix ls(1) thông thường), cột thứ ba phần bù vào tệp (ở dạng hex), cột thứ tư kích thước của vùng ( ở dạng hex) và cột thứ năm là tệp (hoặc tên vùng khác).

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]

Kể từ Android 5.0, thư viện C đặt tên cho hầu hết các vùng được ánh xạ ẩn danh nên có ít vùng bí ẩn hơn.

f6fcb000-f6fccfff rw- 0 2000 [stack:5081]

Các vùng có tên [stack: tid ] là các ngăn xếp cho các luồng đã cho.

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]

Việc bạn thấy [vector] hay [vdso] tùy thuộc vào kiến ​​trúc. ARM sử dụng [vector] , trong khi tất cả các kiến ​​trúc khác sử dụng [vdso] .