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ỏ.
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] .