Các phần sau bao gồm các loại sự cố gốc phổ biến, bản phân tích về
mẫu tệp kết xuất sự cố và nội dung thảo luận về tombstone. Mỗi loại sự cố bao gồm
ví dụ về đầu ra của debuggerd, trong đó có các bằng chứng chính được làm nổi bật để hỗ trợ
bạn có thể phân biệt loại sự cố cụ thể.
Hủy
Việc huỷ bỏ là thú vị vì chúng có chủ ý. Có nhiều giải pháp
cách huỷ (bao gồm cả lệnh gọi
abort(3),
không thành công
assert(3),
sử dụng một trong các loại ghi nhật ký quan trọng dành riêng cho Android), nhưng tất cả đều liên quan đến
đang gọi abort. Lệnh gọi đến abort sẽ báo hiệu lệnh gọi
luồng có SIGABRT, do đó, khung hiển thị "cancel" trong libc.so+
SIGABRT là những thứ cần tìm trong đầu ra debuggerd để
nhận ra trường hợp này.
Có thể có "thông báo huỷ bỏ" rõ ràng . Bạn cũng nên xem trong
Đầu ra logcat để xem luồng này đã ghi lại gì trước khi có chủ ý
tự tử, vì không giống như assert(3) hoặc hành vi gây tử vong cấp cao
cơ sở ghi nhật ký, abort(3) không chấp nhận thông báo.
Các phiên bản hiện tại của Android cùng dòng
tgkill(2)
lệnh gọi hệ thống để ngăn xếp của chúng là dễ đọc nhất, với lệnh gọi đến
huỷ(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 lộ trình phức tạp giữa phiên bản gốc
huỷ lệnh gọi (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, công nghệ
__libc_android_abort (khung hình 3 tại đây) với các nền tảng khác
chuỗi 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
Bạn có thể tái tạo một thực thể của loại sự cố này bằng crasher
abort.
Tham chiếu con trỏ rỗng hoàn toàn
Đây là lỗi gốc cổ điển, mặc dù đây chỉ là một trường hợp đặc biệt loại sự cố tiếp theo, bạn nên đề cập riêng vì loại sự cố này thường yêu cầu ít được suy nghĩ nhất.
Trong ví dụ bên dưới, mặc dù hàm sự cố nằm trong
libc.so, vì các hàm chuỗi chỉ hoạt động trên
con trỏ bạn được cấp, bạn có thể suy luận rằng
strlen(3)
được gọi bằng con trỏ rỗng; và sự cố này sẽ xảy ra ngay
tác giả của mã gọi điện. Trong trường hợp này, khung số 01 là phương thức 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 thực thể của loại sự cố này bằng crasher
strlen-NULL.
Tham chiếu con trỏ rỗng địa chỉ thấp
Trong nhiều trường hợp, địa chỉ lỗi sẽ không bằng 0, nhưng vẫn còn một số số nhỏ khác. Hai hoặc
đặc biệt là địa chỉ gồm ba chữ số rất phổ biến, trong khi địa chỉ gồm sáu chữ số
địa chỉ gần như chắc chắn không phải là việc tham chiếu con trỏ rỗng – điều đó sẽ
yêu cầu độ lệch 1MiB. Điều này thường xảy ra khi bạn có mã
tham chiếu con trỏ rỗng như thể đó là một cấu trúc hợp lệ. Sau đây là các hàm phổ biến
fprintf(3)
(hoặc bất kỳ hàm nào khác lấy TỆP*) và
readdir(3),
vì mã thường không thể kiểm tra xem
fopen(3)
hoặc
opendir(3)
thực sự đã thành công trước tiên.
Dưới đâ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 gây ra sự cố là
pthread_mutex_lock(3)
đã cố truy cập địa chỉ 0xc (khung 0). Nhưng điều đầu tiên
pthread_mutex_lock tham chiếu đến 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ử đó nằm bù trừ 0 trong cấu trúc, giá trị này cho bạn biết
rằng pthread_mutex_lock đã được cấp con trỏ 0xc không hợp lệ. Từ
bạn có thể thấy rằng khung hình 1 đã được readdir cấp cho con trỏ đó,
Thao tác này sẽ trích xuất trường mutex_ từ DIR*.
đã cho. Nhìn vào cấu trúc đó, bạn có thể thấy rằng mutex_ đang ở tại
bù 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ì vậy
bạn phát hiện thấy lỗi: readdir đã được truyền một con trỏ rỗng
người gọi. 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
where (nơi điều này xảy ra) 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 có thể thực sự bỏ qua quá trình phân tích này. Lỗi ở mức vừa phải
thường có nghĩa là bạn có thể bỏ qua bất kỳ khung libc.so nào trong
và trực tiếp cáo buộc mã gọi đó. Nhưng không phải lúc nào cũng vậy, và đây là cách
bạn sẽ trình bày một trường hợp thuyết phục.
Bạn có thể tái tạo các thực thể của loại sự cố này bằng cách sử dụng crasher
fprintf-NULL hoặc crasher readdir-NULL.
Lỗi FORTIFY
Lỗi FORTIFY là một trường hợp huỷ đặc biệt xảy ra khi thư viện C
phát hiện một vấn đề có thể dẫn đến lỗ hổng bảo mật. Thư viện C nhiều
các hàm được củng cố; các em sẽ lấy thêm một lập luận để
kích thước thực sự của bộ đệm và kiểm tra trong thời gian chạy xem thao tác
mà bạn đang cố gắng thực hiện. Sau đây là ví dụ về trường hợp mã cố gắng
vào read(fd, buf, 32) vào một bộ đệm thực ra chỉ 10 byte
dài...
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 thực thể của loại sự cố này bằng crasher
fortify.
Lỗi ngăn xếp do -fstack-protector phát hiện
Tuỳ chọn -fstack-protector của trình biên dịch sẽ chèn các lượt kiểm tra vào
các hàm có vùng đệm trên ngăn xếp để bảo vệ khỏi tình trạng tràn bộ đệm. Lựa 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 lựa chọn này là
bật, trình biên dịch sẽ thêm hướng dẫn vào
hàm
mở đầu để viết một giá trị ngẫu nhiên vừa qua cục bộ 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 nhằm đảm bảo rằng hàm không thay đổi. Nếu
giá trị đó thay đổi, nó bị ghi đè bởi một tình trạng tràn vùng đệm, nên phần kết
gọi __stack_chk_fail để ghi nhật ký thông báo và huỷ.
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 hành vi này với các loại hành vi huỷ bỏ khác bằng sự hiện diện của
__stack_chk_fail trong dấu vết ngược và thông báo huỷ cụ thể.
Bạn có thể tái tạo một thực thể của loại sự cố này bằng crasher
smash-stack.
Bảo vệ SIGSYS khỏi một lệnh gọi hệ thống không được phép
seccomp
hệ thống (cụ thể là seccomp-bpf) hạn chế quyền truy cập vào các lệnh gọi hệ thống. Để biết thêm
thông tin về seccomp dành cho các nhà phát triển nền tảng, hãy xem bài đăng trên blog
Seccomp
trong Android O. Một luồng gọi một lệnh gọi hệ thống bị hạn chế sẽ
nhận tín hiệu SIGSYS có mã SYS_SECCOMP. Số cuộc gọi hệ thống sẽ là
được hiển thị trong dòng nguyên nhân cùng với cấu trúc. Điều quan trọng cần lưu ý
số lệnh gọi hệ thống khác nhau giữa các cấu trúc. Ví dụ:
Lệnh gọi hệ thống readlinkat(2) là số 305 trên x86 nhưng lại là số 267 trên x86-64.
Số cuộc gọi trên cả arm và arm64 lại khác nhau. Vì lệnh gọi hệ thống
số lượng khác nhau giữa các cấu trúc, thường thì cách dễ dàng hơn là sử dụng dấu vết ngăn xếp
để tìm ra lệnh gọi hệ thống nào không được phép thay vì tìm kiếm
số điện thoạ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 lệnh gọi hệ thống không được phép với các sự cố khác qua sự hiện diện của
SYS_SECCOMP trên đường tín hiệu và nội dung mô tả trên đường nguyên nhân.
Bạn có thể tái tạo một thực thể của loại sự cố này bằng crasher
seccomp.
Vi phạm bộ nhớ chỉ thực thi (chỉ dành cho Android 10)
Chỉ đối với arm64 trong Android 10, các phân đoạn có thể thực thi của tệp nhị phân và thư viện đã được ánh xạ vào bộ nhớ – chỉ thực thi (không đọc được) như một kỹ thuật tăng cường bảo vệ chống lại các cuộc tấn công sử dụng lại mã. Giải pháp giảm thiểu này tương tác kém với các giải pháp giảm thiểu khác nên sau đó đã bị xoá.
Việc khiến đoạn mã không thể đọc được sẽ khiến các lượt đọc có chủ đích và ngoài ý muốn vào các phân đoạn bộ nhớ được đánh dấu
chỉ thực thi để gửi một SIGSEGV với 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 kết hợp với mã (chẳng hạn như một nhóm ký tự),
hoặc có chủ ý truy vấn bộ nhớ.
Trình biên dịch giả định mã và dữ liệu không kết hợp với nhau, nhưng các vấn đề có thể phát sinh từ việc viết thủ công
lắp ráp. Trong nhiều trường hợp, bạn chỉ cần di chuyển các hằng số đến .data
.
Nếu thực sự cần phải xem xét mã trong các phần mã có thể thực thi,
mprotect(2)
sẽ được gọi trước để đánh dấu mã có thể đọc được và một lần nữa để đánh dấu mã là không thể đọc sau
đã 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 lỗi 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 thực thể của loại sự cố này bằng crasher xom.
Lỗi do fdsan phát hiện
Trình dọn dẹp mô tả tệp fdsan của Android giúp phát hiện các lỗi phổ biến với chỉ số mô tả tệp như dưới dạng use-after-close và kép đóng. Xem fdsan tài liệu để biết thêm thông tin 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 hành vi này với các loại hành vi huỷ bỏ khác bằng sự hiện diện của
fdsan_error trong dấu vết ngược và thông báo huỷ cụ thể.
Bạn có thể tái tạo một thực thể 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 tệp báo lỗi
Nếu không có sự cố cụ thể nào mà bạn đang điều tra ngay bây giờ,
nguồn nền tảng bao gồm một công cụ để kiểm thử debuggerd có tên là
va chạm. Nếu mm trong system/core/debuggerd/, bạn sẽ
nhận cả crasher và crasher64 trên đường dẫn của bạn (phương thức
cho phép bạn kiểm thử các sự cố 64 bit). Crasher có thể gặp sự cố trong
nhiều cách thú vị dựa trên đối số dòng lệnh mà bạn cung cấp.
Sử dụng crasher --help để xem lựa chọn hiện được hỗ trợ.
Để đưa các phần khác nhau vào tệp kết xuất sự cố, hãy cùng tìm hiểu ví dụ về tệp kết xuất sự cố:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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 rất hữu ích nếu bạn đang tìm kiếm nhật ký cho các trục trặc mã gốc. Chuỗi "*** ***" hiếm khi xuất hiện trong nhật ký khi bắt đầu sự cố gốc.
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Vân tay số này giúp bạn xác định chính xác bản dựng xảy ra sự cố.
Hệ thống này giống hệt như hệ thống ro.build.fingerprint
thuộc tính này.
Revision: '0'
Bản sửa đổi đề cập đến phần cứng chứ không phải phần mềm. Việc này thường
không được sử dụng nhưng có thể hữu ích trong việc giúp bạn tự động bỏ qua các lỗi đã biết
do phần cứng xấu gây ra. Điều 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 arm, arm64, x86 hoặc x86-64. Việc này chủ yếu
hữu ích cho tập lệnh stack nêu trên để tập lệnh 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 luồng cụ thể trong quy trình bị sự cố. Trong phần này đó là một quá trình" luồng chính, vì vậy, mã quy trình và mã luồng sẽ khớp với nhau. Tên đầu tiên là tên luồng và tên được đặt trong dấu >>> và <<< là tên quy 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), tức là hữu ích khi báo lỗi hoặc cố gắng tìm ứng dụng trong Google Play. Pid và txt cũng có thể hữu ích trong việc tìm các dòng nhật ký 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) đã nhận được cùng với thông tin khác về cách tín hiệu đó
đã nhận được (SI_TKILL). Các tín hiệu do debuggerd báo cáo là
SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV và SIGTRAP. Tín hiệu cụ thể
sẽ khác nhau tuỳ theo tín hiệu cụ thể.
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
Không phải sự cố nào cũng có dòng thông báo huỷ bỏ, nhưng sẽ bị huỷ. Đây là tự động được thu thập từ dòng cuối cùng của đầu ra logcat quan trọng cho pid/nghiên cứu và trong trường hợp cố ý phá thai có thể lời giải thích lý do chương trình tự tử.
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
Tệp 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 khác nhau rất nhiều giữa các ABI.) Mức độ hữu ích những vấn đề này sẽ tuỳ thuộc vào sự cố cụ thể.
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 ngược cho bạn biết chúng tôi đã ở đâu trong mã tại thời điểm xảy ra sự cố. Chiến lược phát hành đĩa đơn
cột đầu tiên là số khung (phù hợp với kiểu của gdb trong đó khung sâu nhất
là 0). Các giá trị của PC có liên quan đến vị trí của thư viện dùng chung thay vì
so với địa chỉ tuyệt đối. Cột tiếp theo là tên của khu vực được liên kết
(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, chẳng hạn như
mã được biên dịch JIT). Cuối cùng, nếu có sẵn các biểu tượng, biểu tượng mà máy tính
giá trị tương ứng với được hiển thị, cùng với độ lệch vào biểu tượng đó trong
byte. Bạn có thể sử dụng thuộc tính này cùng với objdump(1) để tìm
hướng dẫn tương ứng dành cho đối tượng tập hợp.
Đọc tombstone
Tombstone written to: /data/tombstones/tombstone_06
Thông tin này cho bạn biết vị trí debuggerd đã viết thêm thông tin.
debuggerd sẽ lưu giữ tối đa 10 bia mộ, đạp xe xuyên suốt
các số từ 00 đến 09 và ghi đè lên những bia mộ hiện có nếu cần.
Tombstone chứa cùng một thông tin với tệp kết xuất sự cố, cộng với một vài thông tin
ứng dụng khác. Ví dụ: Tệp này bao gồm các dấu vết ngược cho tất cả các luồng (không phải
luồng bị sự cố), thanh ghi dấu phẩy động, tệp kết xuất ngăn xếp thô,
và tệp kết xuất bộ nhớ xung quanh địa chỉ trong thanh ghi. Hữu ích nhất là khi
bao gồm một bản đồ bộ nhớ đầy (tương tự như /proc/pid/maps).
Dưới đây là ví dụ có chú thích từ sự cố xử lý 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ố bằng "--->". Các tệp ánh xạ sẽ hữu ích nhất khi sự cố của bạn không chỉ là một giá trị rỗng tham chiếu con trỏ. Nếu địa chỉ lỗi nhỏ, thì có thể là do một số biến thể của tham chiếu con trỏ rỗng. Nếu không, hãy xem bản đồ xung quanh lỗi thường có thể cung cấp 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 nhìn vào bản đồ, bao gồm:
- Đọc/ghi qua phần cuối của khối bộ nhớ.
- Đọc/ghi trước điểm bắt đầu của một khối bộ nhớ.
- Cố gắng thực thi những đoạn mã không phải mã.
- Chạy ra khỏi kết thúc ngăn xếp.
- Cố gắng ghi vào 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 để bạn có thể thấy chính xác
phiên bản mã nào của bạn gặp sự cố. Tệp nhị phân nền tảng bao gồm BuildId theo
mặc định kể từ Android 6.0; NDK r12 trở lên tự động vượt qua
-Wl,--build-id cũng 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 nhớ khối xếp không nhất thiết phải là một khu vực. Vùng nhớ khối xếp 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 chia sẻ có ba mục nhập liền kề. Một mã có thể đọc được và
tệp thực thi (mã), một thuộc tính chỉ đọc (dữ liệu chỉ đọc) và một thuộc tính chỉ đọc-ghi
(dữ liệu có thể biến đổi). Cột đầu tiên hiển thị dải địa chỉ cho liên kết,
cột thứ hai các quyền (theo kiểu Unix ls(1) thông thường),
cột thứ ba giá trị bù trừ vào tệp (theo hệ thập lục phân), cột thứ tư thể hiện kích thước
của khu vực (theo hệ thập lục phân) và cột thứ năm là tệp (hoặc tên khu vực 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 khu vực được ánh xạ ẩn danh để có ít khu vực bí ẩn hơn.
f6fcb000-f6fccfff rw- 0 2000 [stack:5081]
Khu vực có tên [stack:tid] là các ngăn xếp của các khu vực đã cho
luồng.
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] tuỳ thuộc vào
cấu trúc. ARM sử dụng [vector], trong khi tất cả kiến trúc khác đều sử dụng
[vdso].