אבחון קריסות ברמת שפת המכונה

בקטעים הבאים מפורטים סוגים נפוצים של קריסה מקומית, ניתוח של דגימת נתוני גרסת קורסת (dump) ודיון על 'מצבות'. כל סוג של קריסה כולל דוגמה לפלט של debuggerd עם הוכחות מרכזיות מודגשות, כדי לעזור לכם להבחין בין סוגי הקריסות השונים.

ביטול

ביטולים מעניינים כי הם מכוונים. יש הרבה דרכים שונות לבטל את הפעולה (כולל קריאה ל-abort(3), כשל ב-assert(3) או שימוש באחד מסוגי הרישום ביומן הקריטיים שספציפיים ל-Android), אבל כולן כוללות קריאה ל-abort. קריאה ל-abort מאותת לשרשור הקורא באמצעות SIGABRT, כך שצריך לחפש בפלחים של הפלט של debuggerd את הערך 'abort' ב-libc.so ואת הערך SIGABRT כדי לזהות את המקרה הזה.

יכול להיות ששורה 'abort message' תופיע באופן מפורש. כדאי גם לבדוק את הפלט של logcat כדי לראות מה הופיע ביומן של השרשור לפני שהוא הפסיק לפעול בכוונה, כי בניגוד ל-assert(3) או למתקני רישום ביומן ברמה קטלנית גבוהה, abort(3) לא מקבל הודעה.

בגרסאות הנוכחיות של Android, קריאת המערכת tgkill(2) מוטמעת בקוד, כך שקל מאוד לקרוא את הערימות שלהן, והקריאה ל-abort(3) מופיעה בחלק העליון: 

pid: 4637, tid: 4637, name: crasher  >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
    r0  00000000  r1  0000121d  r2  00000006  r3  00000008
    r4  0000121d  r5  0000121d  r6  ffb44a1c  r7  0000010c
    r8  00000000  r9  00000000  r10 00000000  r11 00000000
    ip  ffb44c20  sp  ffb44a08  lr  eace2b0b  pc  eace2b16
backtrace:
    #00 pc 0001cb16  /system/lib/libc.so (abort+57)
    #01 pc 0001cd8f  /system/lib/libc.so (__assert2+22)
    #02 pc 00001531  /system/bin/crasher (do_action+764)
    #03 pc 00002301  /system/bin/crasher (main+68)
    #04 pc 0008a809  /system/lib/libc.so (__libc_init+48)
    #05 pc 00001097  /system/bin/crasher (_start_main+38)

בגרסאות ישנות יותר של Android, הדרך בין הקריאה המקורית לביטול (הפריים הרביעי כאן) לבין השליחה בפועל של האות (הפריים הראשון כאן) הייתה מורכבת. המצב הזה היה נכון במיוחד ב-ARM של 32 ביט, שבו נוספה __libc_android_abort (הפריים השלישי כאן) לרצף של 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.

הפניית מצביע אפס (null pointer dereference) טהורה

זהו קריסה קלאסית של קוד מקורי, וגם אם מדובר רק במקרה מיוחד של סוג הקריסה הבא, כדאי להזכיר אותו בנפרד כי בדרך כלל הוא דורש את המחשבה הכי פחות.

בדוגמה הבאה, למרות שפונקציית הקריסה נמצאת ב-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.

הפניה למצביע null בכתוביות נמוכות

במקרים רבים, כתובת השגיאה לא תהיה 0, אלא מספר נמוך אחר. כתובות של שתי ספרות או שלוש ספרות הן נפוצות במיוחד, ואילו כתובת של שש ספרות היא כמעט בוודאות לא הפניה לאפס של מצביע – הפניה כזו תדרוש הזזה של 1MiB. בדרך כלל, המצב הזה מתרחש כשיש קוד שמבטל את ההפניה של מצביע null כאילו היה מבנה תקין. פונקציות נפוצות הן 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 ב-struct, כלומר ל-pthread_mutex_lock הוקצה המצביע הלא חוקי 0xc. אפשר לראות שבמסגרת 1, הפונקציה readdir העבירה את ההפניה הזו, שמנתחת את השדה mutex_ מה-DIR* שהיא מקבלת. מעיינים במבנה הזה ומבחינים ש-mutex_ נמצא במיקום sizeof(int) + sizeof(size_t) + sizeof(dirent*) ב-struct DIR, שמכשיר 32 ביט הוא 4 + 4 + 4 = 12 = 0xc, כך שמצאתם את הבאג: למבצע הקריאה הועבר למשתנה readdir מצביע null. בשלב הזה אפשר להדביק את הסטאק בכלי הסטאק כדי לבדוק איפה ב-logcat זה קרה. 

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

ברוב המקרים אפשר לדלג על הניתוח הזה. כתובת שגיאה נמוכה מספיק בדרך כלל מאפשרת פשוט לדלג על כל המסגרות של libc.so ב-stack ולהאשים ישירות את הקוד הקורא. אבל לא תמיד, וזו הדרך להציג טענה משכנעת.

אפשר ליצור מחדש מקרים של קריסה מהסוג הזה באמצעות crasher fprintf-NULL או crasher readdir-NULL.

כשל ב-FORTIFY

כשל ב-FORTIFY הוא מקרה מיוחד של ביטול שמתרחש כשספריית C מזהה בעיה שעלולה להוביל לנקודת חולשה באבטחה. פונקציות רבות בספריית C מוגנות. הן מקבלות ארגומנטים נוספים שמספרים להן מהו גודל המאגר בפועל, ובזמן הריצה הן בודקות אם הפעולה שאתם מנסים לבצע מתאימה למאגר. הנה דוגמה שבה הקוד מנסה להעביר read(fd, buf, 32) למאגר (buffer) שאורכו בפועל הוא רק 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.

פגיעה ב-stack זוהתה על ידי -fstack-protector

האפשרות -fstack-protector של המהדר מוסיפה בדיקות לפונקציות עם מאגרים ב-stack כדי למנוע מצב של חריגה ממלאי המאגר. האפשרות הזו מופעלת כברירת מחדל בקוד הפלטפורמה, אבל לא באפליקציות. כשהאפשרות הזו מופעלת, המהדר מוסיף הוראות למבוא הפונקציה כדי לכתוב ערך אקראי ממש אחרי המשתנה המקומי האחרון ב-stack, ולסיומת הפונקציה כדי לקרוא אותו חזרה ולבדוק שהוא לא השתנה. אם הערך הזה השתנה, הוא הוחלף על ידי חריגה ממאגר (buffer overrun), ולכן בחלק האחרון של הקוד מתבצעת קריאה ל-__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 ב-backtrace והודעת הביטול הספציפית.

אפשר ליצור מחדש מקרה של קריסה מסוג זה באמצעות crasher smash-stack.

Seccomp SIGSYS מקריאה לא מורשית למערכת

מערכת seccomp (במיוחד seccomp-bpf) מגבילה את הגישה לקריאות למערכת. למידע נוסף על seccomp למפתחי פלטפורמות, אפשר לקרוא את הפוסט בבלוג מסנן Seccomp ב-Android O. שרשור שמפעיל קריאה מוגבלת למערכת יקבל אות SIGSYS עם הקוד SYS_SECCOMP. מספר הקריאה למערכת יופיע בשורת הסיבה, יחד עם הארכיטקטורה. חשוב לציין שמספרי הקריאות למערכת משתנים בין ארכיטקטורות. לדוגמה, קריאת המערכת readlinkat(2) היא מספר 305 ב-x86, אבל 267 ב-x86-64. מספר הקריאה שונה גם ב-arm וגם ב-arm64. מאחר שמספרי הקריאות למערכת משתנים בין ארכיטקטורות, בדרך כלל קל יותר להשתמש ב-stack trace כדי לברר איזו קריאה למערכת נאסרה, במקום לחפש את מספר הקריאה למערכת בכותרות. 

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 בלבד)

במכשירי arm64 ב-Android 10 בלבד, קטעי קוד הפעלה של ספריות וקבצים בינאריים תואמים למרחב זיכרון לצורך הפעלה בלבד (לא לקריאה), כטכניקה להקשחת האבטחה מפני התקפות של שימוש חוזר בקוד. לפתרון הזה הייתה אינטראקציה שלילית עם פתרונות אחרים, ולכן הוא הוסר מאוחר יותר.

אם הקוד לא קריא, קריאות מכוונות ולא מכוונות לקטעי זיכרון שמסומנים כ'לביצוע בלבד' יגרמו להשלכת SIGSEGV עם קוד SEGV_ACCERR. המצב הזה יכול להתרחש כתוצאה מבאג, מנקודת חולשה, מנתונים מעורבבים עם קוד (כמו מאגר לטראליים) או מניתוח פנימי מכוון של זיכרון.

המהדרן מניח שהקוד והנתונים לא מעורבבים, אבל יכולות להתעורר בעיות כתוצאה מ-assembly שנכתב ביד. במקרים רבים אפשר לפתור את הבעיות האלה פשוט על ידי העברת הקבועים לקטע .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) עוזר לזהות שגיאות נפוצות במתארי קבצים, כמו שימוש אחרי סגירה וסגירה כפולה. למידע נוסף על ניפוי באגים (ועל הימנעות) של שגיאות מהסוג הזה, תוכלו לעיין במסמכי העזרה של fsan. 

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 ב-backtrace והודעת הביטול הספציפית.

אפשר ליצור מקרה של קריסה מהסוג הזה באמצעות crasher fdsan_file או crasher fdsan_dir.

בדיקת קובצי dump של קריסות

אם אין לכם כעת קריסה ספציפית שאתם בודקים, מקור הפלטפורמה כולל כלי לבדיקה של debuggerd שנקרא crasher. אם תבצעו את הפקודה mm ב-system/core/debuggerd/, תקבלו גם crasher וגם crasher64 בנתיב (האחרון מאפשר לבדוק קריסות של 64 ביט). Crasher יכול לקרוס במגוון רחב של דרכים מעניינות, בהתאם לארגומנטים של שורת הפקודה שאתם מספקים. אפשר להשתמש ב-crasher --help כדי לראות את האפשרויות הנתמכות כרגע.

כדי להסביר את החלקים השונים בקובץ גרסת תאונה, נבחן את קובץ גרסת התאונה לדוגמה הזה: 

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1656, tid: 1656, name: crasher  >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
    r0 00000000  r1 00000678  r2 00000006  r3 f70b6dc8
    r4 f70b6dd0  r5 f70b6d80  r6 00000002  r7 0000010c
    r8 ffffffed  r9 00000000  sl 00000000  fp ff96ae1c
    ip 00000006  sp ff96ad18  lr f700ced5  pc f700dc98  cpsr 400b0010
backtrace:
    #00 pc 00042c98  /system/lib/libc.so (tgkill+12)
    #01 pc 00041ed1  /system/lib/libc.so (pthread_kill+32)
    #02 pc 0001bb87  /system/lib/libc.so (raise+10)
    #03 pc 00018cad  /system/lib/libc.so (__libc_android_abort+34)
    #04 pc 000168e8  /system/lib/libc.so (abort+4)
    #05 pc 0001a78f  /system/lib/libc.so (__libc_fatal+16)
    #06 pc 00018d35  /system/lib/libc.so (__assert2+20)
    #07 pc 00000f21  /system/xbin/crasher
    #08 pc 00016795  /system/lib/libc.so (__libc_init+44)
    #09 pc 00000abc  /system/xbin/crasher
Tombstone written to: /data/tombstones/tombstone_06
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

השורה של הכוכביות עם הרווחים שימושית אם מחפשים ביומן קריסות מקוריות. המחרוזת '*** ***' מופיעה לעתים נדירות ביומני אירועים, מלבד בתחילת קריסה של קוד מקורי. 

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

טביעת האצבע מאפשרת לזהות בדיוק את גרסת ה-build שבה קרתה הקריסה. הערך הזה זהה לחלוטין למאפיין המערכת ro.build.fingerprint. 

Revision: '0'

הגרסה מתייחסת לחומרה ולא לתוכנה. בדרך כלל לא משתמשים באפשרות הזו, אבל היא יכולה לעזור לכם להתעלם באופן אוטומטי מבאגים שידועים כגורמים לחומרה פגומה. הערך הזה זהה לנכס המערכת ro.revision. 

ABI: 'arm'

ממשק ה-ABI יכול להיות אחד מהערכים הבאים: arm,‏ arm64,‏ x86 או x86-64. האפשרות הזו שימושית בעיקר לסקריפט stack שצוין למעלה, כדי שהוא ידע באיזו ערכת כלים להשתמש. 

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

השורה הזו מזהה את השרשור הספציפי בתהליך שהתרסק. במקרה הזה, זה היה ה-thread הראשי של התהליך, ולכן מזהה התהליך ומזהה ה-thread זהים. השם הראשון הוא שם השרשור, והשם שמוקף בסמלים >>> ו-<<< הוא שם התהליך. שם התהליך של אפליקציה הוא בדרך כלל שם החבילה המלא (למשל, 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 עם השגיאה הקטלנית עבור pid/tid הזה, ובמקרה של ביטול מכוון, סביר להניח שהוא יספק הסבר לכך שהתוכנית הפסיקה לפעול. 

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

בדמפ הרישום מוצג התוכן של הרישומים של המעבד בזמן שהאות התקבל. (החלק הזה משתנה מאוד בין ABIs). מידת התועלת שלהם תלויה בגורם המדויק לקריסה. 

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

ב-backtrace מוצג איפה היינו בקוד בזמן הקריסה. העמודה הראשונה היא מספר הפריים (בהתאם לסגנון של gdb, שבו הפריים העמוק ביותר הוא 0). ערכי ה-PC הם יחסיים למיקום של הספרייה המשותפת, ולא כתובות מוחלטות. העמודה הבאה היא השם של האזור הממופה (בדרך כלל ספרייה משותפת או קובץ הפעלה, אבל יכול להיות שזה לא יקרה, למשל, בקוד שעבר הידור בזמן ריצה). לבסוף, אם יש סמלים זמינים, מוצג הסמל שאליו מתאים הערך של PC, יחד עם ההיסט לסמל הזה בייטים. אפשר להשתמש בזה בשילוב עם objdump(1) כדי למצוא את הוראה האסמבלר המתאימה.

קריאת פריטי Tombstone

Tombstone written to: /data/tombstones/tombstone_06

כאן מצוין איפה debuggerd כתב מידע נוסף. debuggerd ישמור עד 10 tombstones, ויעבור בסבב על המספרים 00 עד 09 וימחוק את ה-tombstones הקיימים לפי הצורך.

המידע ב-tombstone זהה למידע ב-crash dump, בתוספת כמה פרטים נוספים. לדוגמה, הוא כולל מעקב נתיב לאחור (backtrace) של כל השרשראות (לא רק של השרשרת שהתרסקה), הרשומות של הנקודה הצפה, דיווחים גולמיים על סטאק ודוחות על זיכרון סביב הכתובות ברשומות. היתרון הגדול ביותר הוא שהוא כולל גם מפת זיכרון מלאה (בדומה ל-/proc/pid/maps). הנה דוגמה עם הערות לקריסה של תהליך ARM 32 ביט: 

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

יש כאן שני דברים שחשוב לשים לב אליהם. הראשונה היא שהשורה הזו מתחילה ב-"--->". המפות מועילות במיוחד כשהתאונה היא לא רק הפניה לאפס של מצביע. אם כתובת השגיאה קטנה, סביר להניח שמדובר בגרסה כלשהי של הפניה לאפס. לחלופין, לעיתים קרובות אפשר לקבל רמז לגבי מה שקרה על ידי בדיקת המפות באזור הכתובת שבה זוהתה השגיאה. חלק מהבעיות האפשריות שאפשר לזהות במפות כוללות:

  • קריאה/כתיבה מעבר לסוף של בלוק זיכרון.
  • קריאה/כתיבה לפני תחילת בלוק של זיכרון.
  • ניסיונות להריץ קוד שאינו קוד.
  • ריצה לסוף מקבץ.
  • ניסיון לכתוב בקוד (כמו בדוגמה שלמעלה).

הדבר השני שחשוב לזכור הוא שבקבצים של קובצי הפעלה וספריות משותפות יופיע BuildId (אם הוא קיים) ב-Android 6.0 ואילך, כך שתוכלו לראות בדיוק איזו גרסה של הקוד קרסה. קובצי הבינארי של הפלטפורמה כוללים 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)), בעמודה השלישית מוצגת ההיסט בקובץ (בשימוש ב-hex), בעמודה הרביעית מוצג הגודל של האזור (בשימוש ב-hex) ובעמודה החמישית מוצג הקובץ (או שם אזור אחר). 

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]

החל מגרסה 5.0 של Android, ספריית 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].