אבחון קריסות מקוריות

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

ביטול

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

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

הגרסאות הנוכחיות של Android כוללות את tgkill(2) אז את המקבצים שלהם הכי קל לקרוא, לבטל(3) בראש הרשימה: 

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

גרסאות ישנות יותר של Android עברו נתיב מפותל בין הגרסה המקורית מבטלים את הקריאה (מסגרת 4 כאן) ואת השליחה בפועל של האות (מסגרת 0 כאן). זה היה נכון במיוחד ב-ARM 32-bit, __libc_android_abort (מסגרת 3 כאן) לפלטפורמות האחרות רצף של raise/pthread_kill/tgkill: 

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

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

ביטול הפניה של מצביע null

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

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

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

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

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

כישלון FORTIFY

כשל FORTIFY הוא מקרה מיוחד של ביטול שמתרחש כאשר ספריית C מזהה בעיה שעשויה להוביל לנקודת חולשה באבטחה. ספריית C רבות פונקציות מבוזרות; הם לוקחים ארגומנט נוסף שאומר להם מה הגודל בפועל של מאגר הנתונים הזמני ובודקים בזמן הריצה אם הפעולה מתבצעת שמנסים לבצע. הנה דוגמה שבה הקוד מנסה ל-read(fd, buf, 32) במאגר נתונים זמני שלמעשה הוא 10 בייטים בלבד ארוך... 

pid: 25579, tid: 25579, name: crasher  >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'FORTIFY: read: prevented 32-byte write into 10-byte buffer'
    r0 00000000  r1 000063eb  r2 00000006  r3 00000008
    r4 ff96f350  r5 000063eb  r6 000063eb  r7 0000010c
    r8 00000000  r9 00000000  sl 00000000  fp ff96f49c
    ip 00000000  sp ff96f340  lr ee83ece3  pc ee86ef0c  cpsr 000d0010

backtrace:
    #00 pc 00049f0c  /system/lib/libc.so (tgkill+12)
    #01 pc 00019cdf  /system/lib/libc.so (abort+50)
    #02 pc 0001e197  /system/lib/libc.so (__fortify_fatal+30)
    #03 pc 0001baf9  /system/lib/libc.so (__read_chk+48)
    #04 pc 0000165b  /system/xbin/crasher (do_action+534)
    #05 pc 000021e5  /system/xbin/crasher (main+100)
    #06 pc 000177a1  /system/lib/libc.so (__libc_init+48)
    #07 pc 00001110  /system/xbin/crasher (_start+96)

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

פגיעה במקבץ זוהתה על ידי -fstack-protector

האפשרות -fstack-protector של המהדר מוסיפה בדיקות פועל עם מאגרי נתונים זמניים בערימה כדי להגן מפני עומס יתר של מאגר הנתונים הזמני. האפשרות הזו מופעלת כברירת מחדל עבור קוד פלטפורמה אך לא עבור אפליקציות. כשאפשרות זו היא מופעלת, המהדר מוסיף הוראות פונקציה פרולוג לכתיבת ערך אקראי ממש מעבר לערך המקומי האחרון בסטאק אל פרק הזמן של הפונקציה כדי לקרוא אותה שוב ולבדוק שהיא לא השתנתה. אם המיקום שהערך הזה השתנה, הוא הוחלף על ידי עומס על מאגר הנתונים הזמני, כך שה קוראת ל-__stack_chk_fail כדי לרשום הודעה ולבטל. 

pid: 26717, tid: 26717, name: crasher  >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
    r0 00000000  r1 0000685d  r2 00000006  r3 00000008
    r4 ffd516d8  r5 0000685d  r6 0000685d  r7 0000010c
    r8 00000000  r9 00000000  sl 00000000  fp ffd518bc
    ip 00000000  sp ffd516c8  lr ee63ece3  pc ee66ef0c  cpsr 000e0010

backtrace:
    #00 pc 00049f0c  /system/lib/libc.so (tgkill+12)
    #01 pc 00019cdf  /system/lib/libc.so (abort+50)
    #02 pc 0001e07d  /system/lib/libc.so (__libc_fatal+24)
    #03 pc 0004863f  /system/lib/libc.so (__stack_chk_fail+6)
    #04 pc 000013ed  /system/xbin/crasher (smash_stack+76)
    #05 pc 00001591  /system/xbin/crasher (do_action+280)
    #06 pc 00002219  /system/xbin/crasher (main+100)
    #07 pc 000177a1  /system/lib/libc.so (__libc_init+48)
    #08 pc 00001144  /system/xbin/crasher (_start+96)

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

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

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

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

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

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

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

המהדר מניח שהקוד והנתונים לא מתערבבים, אבל יכולות להיווצר בעיות כתוצאה מכתיבה ידנית להרכיב. במקרים רבים ניתן לתקן את המצבים על ידי העברת הקבועים אל .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

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

pid: 32315, tid: 32315, name: crasher64  >>> crasher64 <<<
signal 35 (), code -1 (SI_QUEUE), fault addr --------
Abort message: 'attempted to close file descriptor 3, expected to be unowned, actually owned by FILE* 0x7d8e413018'
    x0  0000000000000000  x1  0000000000007e3b  x2  0000000000000023  x3  0000007fe7300bb0
    x4  3033313465386437  x5  3033313465386437  x6  3033313465386437  x7  3831303331346538
    x8  00000000000000f0  x9  0000000000000000  x10 0000000000000059  x11 0000000000000034
    x12 0000007d8ebc3a49  x13 0000007fe730077a  x14 0000007fe730077a  x15 0000000000000000
    x16 0000007d8ec9a7b8  x17 0000007d8ec779f0  x18 0000007d8f29c000  x19 0000000000007e3b
    x20 0000000000007e3b  x21 0000007d8f023020  x22 0000007d8f3b58dc  x23 0000000000000001
    x24 0000007fe73009a0  x25 0000007fe73008e0  x26 0000007fe7300ca0  x27 0000000000000000
    x28 0000000000000000  x29 0000007fe7300c90
    sp  0000007fe7300860  lr  0000007d8ec2f22c  pc  0000007d8ec2f250

backtrace:
      #00 pc 0000000000088250  /bionic/lib64/libc.so (fdsan_error(char const*, ...)+384)
      #01 pc 0000000000088060  /bionic/lib64/libc.so (android_fdsan_close_with_tag+632)
      #02 pc 00000000000887e8  /bionic/lib64/libc.so (close+16)
      #03 pc 000000000000379c  /system/bin/crasher64 (do_action+1316)
      #04 pc 00000000000049c8  /system/bin/crasher64 (main+96)
      #05 pc 000000000008021c  /bionic/lib64/libc.so (_start_main)

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

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

חקירת קובצי קריסה

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

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

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

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

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

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

Revision: '0'

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

ABI: 'arm'

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

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

השורה הזו מזהה את השרשור הספציפי בתהליך שבו קרס. כאן זה היה התהליך, כך שמזהה התהליך ומזהה ה-thread תואמים. השם הפרטי הוא שם השרשור, והשם מוקף בתחילית >>>. וגם <<< הוא שם התהליך. עבור אפליקציה, שם התהליך הוא בדרך כלל שם החבילה המוגדר במלואו (כגון com.facebook.katana), שהוא שימושי כאשר שולחים באגים או מנסים למצוא את האפליקציה ב-Google Play. ה-PID ו- גם באיתור שורות היומן הרלוונטיות שקדמו לקריסה, 

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

השורה הזו מציינת איזה אות (SIGABRT) התקבל ופרטים נוספים על האופן שבו הוא התקבל (SI_TKILL). האותות שדווחו על ידי debuggerd הם SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV ו-SIGTRAP. הערכים הספציפיים של האות הקודים משתנים בהתאם לאות הספציפי. 

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

לא לכל הקריסות תופיע שורת הודעה, אבל הן יבוטלו. הדבר נאסף אוטומטית מהשורה האחרונה של פלט Logcat חמור ובמקרה של ביטול מכוון, סביר להניח שהדבר יוביל הסבר למה התוכנית הרגה את עצמה. 

r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010

ב-Dump הרישום מוצג התוכן של המעבד (CPU) שנרשם בזמן התקבל אות. (הקטע הזה משתנה באופן כללי בין ממשקי ה-ABI). מידת היעילות הם תלויים בקריסה המדויקת. 

backtrace:
    #00 pc 00042c98 /system/lib/libc.so (tgkill+12)
    #01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
    #02 pc 0001bb87 /system/lib/libc.so (raise+10)
    #03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
    #04 pc 000168e8 /system/lib/libc.so (abort+4)
    #05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
    #06 pc 00018d35 /system/lib/libc.so (__assert2+20)
    #07 pc 00000f21 /system/xbin/crasher
    #08 pc 00016795 /system/lib/libc.so (__libc_init+44)
    #09 pc 00000abc /system/xbin/crasher

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

קריאת מצבות

Tombstone written to: /data/tombstones/tombstone_06

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

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

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

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

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

הדבר השני שיש לציין הוא שקובצי הפעלה וקובצי ספריות משותפות יש להציג את ה-BuildId (אם קיים) ב-Android 6.0 ואילך, כדי שתוכל לראות בדיוק איזו גרסה של הקוד קרסה. הקבצים הבינאריים של הפלטפורמות כוללים BuildId לפי ברירת מחדל החל מ-Android 6.0; NDK r12 ומעלה עובר אוטומטית -Wl,--build-id גם ל-linker. 

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

ב-Android, הערימה היא לא בהכרח אזור אחד. אזורי ערימה (heap) יופיע בתווית [anon:libc_malloc]. 

f6d82000-f6da1fff r--         0     20000  /dev/__properties__/u:object_r:logd_prop:s0
f6da2000-f6dc1fff r--         0     20000  /dev/__properties__/u:object_r:default_prop:s0
f6dc2000-f6de1fff r--         0     20000  /dev/__properties__/u:object_r:logd_prop:s0
f6de2000-f6de5fff r-x         0      4000  /system/lib/libnetd_client.so (BuildId: 08020aa06ed48cf9f6971861abf06c9d)
f6de6000-f6de6fff r--      3000      1000  /system/lib/libnetd_client.so
f6de7000-f6de7fff rw-      4000      1000  /system/lib/libnetd_client.so
f6dec000-f6e74fff r-x         0     89000  /system/lib/libc++.so (BuildId: 8f1f2be4b37d7067d366543fafececa2) (load base 0x2000)
f6e75000-f6e75fff ---         0      1000
f6e76000-f6e79fff r--     89000      4000  /system/lib/libc++.so
f6e7a000-f6e7afff rw-     8d000      1000  /system/lib/libc++.so
f6e7b000-f6e7bfff rw-         0      1000  [anon:.bss]
f6e7c000-f6efdfff r-x         0     82000  /system/lib/libc.so (BuildId: d189b369d1aafe11feb7014d411bb9c3)
f6efe000-f6f01fff r--     81000      4000  /system/lib/libc.so
f6f02000-f6f03fff rw-     85000      2000  /system/lib/libc.so
f6f04000-f6f04fff rw-         0      1000  [anon:.bss]
f6f05000-f6f05fff r--         0      1000  [anon:.bss]
f6f06000-f6f0bfff rw-         0      6000  [anon:.bss]
f6f0c000-f6f21fff r-x         0     16000  /system/lib/libcutils.so (BuildId: d6d68a419dadd645ca852cd339f89741)
f6f22000-f6f22fff r--     15000      1000  /system/lib/libcutils.so
f6f23000-f6f23fff rw-     16000      1000  /system/lib/libcutils.so
f6f24000-f6f31fff r-x         0      e000  /system/lib/liblog.so (BuildId: e4d30918d1b1028a1ba23d2ab72536fc)
f6f32000-f6f32fff r--      d000      1000  /system/lib/liblog.so
f6f33000-f6f33fff rw-      e000      1000  /system/lib/liblog.so

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

f6f34000-f6f53fff r-x         0     20000  /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b)
f6f54000-f6f54fff ---         0      1000
f6f55000-f6f55fff r--     20000      1000  /system/lib/libm.so
f6f56000-f6f56fff rw-     21000      1000  /system/lib/libm.so
f6f58000-f6f58fff rw-         0      1000
f6f59000-f6f78fff r--         0     20000  /dev/__properties__/u:object_r:default_prop:s0
f6f79000-f6f98fff r--         0     20000  /dev/__properties__/properties_serial
f6f99000-f6f99fff rw-         0      1000  [anon:linker_alloc_vector]
f6f9a000-f6f9afff r--         0      1000  [anon:atexit handlers]
f6f9b000-f6fbafff r--         0     20000  /dev/__properties__/properties_serial
f6fbb000-f6fbbfff rw-         0      1000  [anon:linker_alloc_vector]
f6fbc000-f6fbcfff rw-         0      1000  [anon:linker_alloc_small_objects]
f6fbd000-f6fbdfff rw-         0      1000  [anon:linker_alloc_vector]
f6fbe000-f6fbffff rw-         0      2000  [anon:linker_alloc]
f6fc0000-f6fc0fff r--         0      1000  [anon:linker_alloc]
f6fc1000-f6fc1fff rw-         0      1000  [anon:linker_alloc_lob]
f6fc2000-f6fc2fff r--         0      1000  [anon:linker_alloc]
f6fc3000-f6fc3fff rw-         0      1000  [anon:linker_alloc_vector]
f6fc4000-f6fc4fff rw-         0      1000  [anon:linker_alloc_small_objects]
f6fc5000-f6fc5fff rw-         0      1000  [anon:linker_alloc_vector]
f6fc6000-f6fc6fff rw-         0      1000  [anon:linker_alloc_small_objects]
f6fc7000-f6fc7fff rw-         0      1000  [anon:arc4random _rsx structure]
f6fc8000-f6fc8fff rw-         0      1000  [anon:arc4random _rs structure]
f6fc9000-f6fc9fff r--         0      1000  [anon:atexit handlers]
f6fca000-f6fcafff ---         0      1000  [anon:thread signal stack guard page]

החל מ-Android 5.0, ספריית C כוללת את רוב האזורים הממופים האנונימיים שלה יש פחות אזורים מסתוריים. 

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

אזורים בשם [stack:tid] הם הערימות של הערך שצוין שרשורים. 

f6fcd000-f702afff r-x         0     5e000  /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7)
f702b000-f702cfff r--     5d000      2000  /system/bin/linker
f702d000-f702dfff rw-     5f000      1000  /system/bin/linker
f702e000-f702ffff rw-         0      2000
f7030000-f7030fff r--         0      1000
f7031000-f7032fff rw-         0      2000
ffcd7000-ffcf7fff rw-         0     21000
ffff0000-ffff0fff r-x         0      1000  [vectors]

התצוגה של [vector] או [vdso] תלויה של הארכיטקטורה, ARM משתמש ב-[vector], וכל שאר הארכיטקטורות משתמשות [vdso].