הבנת דוחות HWASan

כאשר הכלי HWASan מזהה באג זיכרון, התהליך מסתיים עם abort(), ודוח מודפס ל-stderr ול-logcat. כמו כל קריסות מקוריות באנדרואיד, ניתן למצוא שגיאות HWASan תחת /data/tombstones .

בהשוואה לקריסות מקומיות רגילות, HWASan נושא מידע נוסף בשדה "הודעת ביטול" ליד החלק העליון של המצבה. ראה התרסקות לדוגמה המבוססת על ערימה למטה (עבור באגים מחסנית, ראה את ההערה למטה עבור הסעיפים הספציפיים לחסימה).

דוח לדוגמה

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'google/flame_hwasan/flame:Tiramisu/MASTER/7956676:userdebug/dev-keys'
Revision: 'DVT1.0'
ABI: 'arm64'
Timestamp: 2019-04-24 01:13:22+0000
pid: 11154, tid: 11154, name: sensors@1.0-ser  >>> /vendor/bin/hw/android.hardware.sensors@1.0-service <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
Abort message: '==9569==ERROR: HWAddressSanitizer: tag-mismatch on address 0x00433ae20045 at pc 0x00623ae2a9cc
READ of size 1 at 0x00433ae20045 tags: 5b/83 (ptr/mem) in thread T0
    #0 0x7240450c68  (/system/lib64/vndk-sp-R/libcutils.so+0x8c68)
    #1 0x723dffd490  (/vendor/lib64/sensors.ssc.so+0x34490)
    #2 0x723e0126e0  (/vendor/lib64/sensors.ssc.so+0x496e0)
[...]

[0x00433ae20040,0x00433ae20060) is a small unallocated heap chunk; size: 32 offset: 5

Cause: use-after-free
0x00433ae20045 is located 5 bytes inside of 10-byte region [0x00433ae20040,0x00433ae2004a)
freed by thread T0 here:
    #0 0x72404d1b18  (/system/lib64/libclang_rt.hwasan-aarch64-android.so+0x10b18)
    #1 0x723af23040  (/vendor/lib64/libgralloccore.so+0x5040)
    #2 0x723af23fa4  (/vendor/lib64/libgralloccore.so+0x5fa4)
[...]

previously allocated here:
    #0 0x72404ce554  (/system/lib64/libclang_rt.hwasan-aarch64-android.so+0xd554)
    #1 0x7240115654  (/apex/com.android.runtime/lib64/bionic/libc.so+0x43654)
    #2 0x7240450ac8  (/system/lib64/vndk-sp-R/libcutils.so+0x8ac8)
[...]

hwasan_dev_note_heap_rb_distance: 1 1023
hwasan_dev_note_num_matching_addrs: 0
hwasan_dev_note_num_matching_addrs_4b: 0
Thread: T0 0x006a00002000 stack: [0x007fc1064000,0x007fc1864000) sz: 8388608 tls: [0x00737702ffc0,0x007377033000)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1f80: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1f90: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1fa0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1fb0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1fc0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1fd0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1fe0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae1ff0: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
=>0x006f33ae2000: 08  00  08  00 [83] 00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2010: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2020: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2030: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2040: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2050: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2060: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2070: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
  0x006f33ae2080: 00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
=>0x006f33ae2000: 72  ..  d0  .. [..] ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
  0x006f33ae2010: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags
Registers where the failure occurred (pc 0x00623ae2a9cc):
    x0  0000007fc18623ec  x1  5b0000433ae20045  x2  0000000000000013  x3  ffffffffffffffff
    x4  ffffffffffffffff  x5  0000007fc1861da3  x6  6f7420676e696f47  x7  45522061206f6420
    x8  0000000000000000  x9  0200006b00000000  x10 00000007fc18623f  x11 5b0000433ae20040
    x12 6f64206f7420676e  x13 0a44414552206120  x14 0000000000000010  x15 ffffffffffffffff
    x16 000000737169ac94  x17 0000000000000007  x18 0000007377bd8000  x19 0000007fc1862498
    x20 0200006b00000000  x21 0000007fc18624a8  x22 0000000000000001  x23 0000000000000000
    x24 0000000000000000  x25 0000000000000000  x26 0000000000000000  x27 0000000000000000
    x28 0000000000000000  x29 0000007fc1862410  x30 000000623ae2a9d0   sp 0000007fc18623d0
SUMMARY: HWAddressSanitizer: tag-mismatch (/system/lib64/vndk-sp-R/libcutils.so+0x8c68)

[ … regular crash dump follows …]

זה דומה מאוד לדוח AddressSnitizer . בניגוד לאלה, כמעט כל הבאגים של HWASan הם "אי-התאמה בתג", כלומר גישה לזיכרון שבה תג מצביע אינו תואם לתג הזיכרון המתאים. זה יכול להיות אחד מהם

• גישה מחוץ לתחום בערימה או ערימה
• השתמש לאחר חינם בערימה
• שימוש לאחר החזרה על הערימה

מקטעים

להלן הסבר על כל אחד מהסעיפים בדוח HWAsan:

<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:

<address> is located N bytes to the right of M-byte region [<start>, <end>)
  allocated here:

<address> is located N bytes inside of M-byte region [<start>, <end>)
  freed by thread T0 here:

tags: ad/5c (ptr/mem)
[...]
Memory tags around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: 0e  0e  0e  57  20  20  20  20  20  2e  5e  5e  5e  5e  5e  b5
=>0x006f33ae2000: f6  f6  f6  f6  f6  4c  ad  ad  ad  ad  ad  ad [5c] 5c  5c  5c
  0x006f33ae2010: 5c  04  2e  2e  2e  2e  2e  2f  66  66  66  66  66  80  6a  6a
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
  0x006f33ae1ff0: ab  52  eb  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..
=>0x006f33ae2000: ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  .. [..] ..  ..  ..
  0x006f33ae2010: ..  5c  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..  ..

סימבוליזציה

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

התקנה בפעם הראשונה: התקן את llvm-symbolizer

כדי לסמל, על המערכת שלך להיות מותקן llvm-symbolizer ונגיש מ-$PATH. בדביאן, אתה יכול להתקין אותו באמצעות sudo apt install llvm .

השג קבצי סמלים

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

עבור מבנים מקומיים , ניתן למצוא את קובצי הסמלים ב- out/target/product/<product>/symbols/ .

עבור בניית AOSP (למשל, הבזק מ- Flashstation ), ניתן למצוא את ה-buildות ב- Android CI . ב-"Artifacts" עבור ה-build, יהיה קובץ `${PRODUCT}-symbols-${BUILDID}.zip`.

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

לְסַמֵל

hwasan_symbolize –-symbols <DECOMPRESSED_DIR>/out/target/product/*/symbols < crash

הבנת דוחות מחסנית

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

Cause: stack tag-mismatch
Address 0x007d4d251e80 is located in stack of thread T64
Thread: T64 0x0074000b2000 stack: [0x007d4d14c000,0x007d4d255cb0) sz: 1088688 tls: [0x007d4d255fc0,0x007d4d259000)
Previously allocated frames:
  record_addr:0x7df7300c98 record:0x51ef007df3f70fb0  (/apex/com.android.art/lib64/libart.so+0x570fb0)
  record_addr:0x7df7300c90 record:0x5200007df3cdab74  (/apex/com.android.art/lib64/libart.so+0x2dab74)
  [...]
	

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

הפרות ODR

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

לאחר סימבוליזציה, הפרות ODR מציגות שימוש-אחרי-חופשי עם __cxa_finalize , הן בערימת הגישה הלא חוקית והן בערימת "החופשה כאן". המחסנית "קודם לכן הוקצה כאן" מכילה __dl__ZN6soinfo17call_constructorsEv וצריכה להצביע על המיקום בתוכנית שלך שמגדיר את המשתנה הגבוה יותר בערימה.

אחת הסיבות לכך שה-ODR עשוי להיות מופר היא כאשר נעשה שימוש בספריות סטטיות. אם ספרייה סטטית שמגדירה C++ גלובלי מקושרת למספר ספריות משותפות או קובצי הפעלה, הגדרות מרובות של אותו סמל עלולות להתקיים באותו מרחב כתובות, מה שיגרום לשגיאת ODR.

פתרון תקלות

"HWAddressSanitizer לא יכול לתאר כתובת ביתר פירוט."

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

  HWAddressSanitizer can not describe address in more detail.

במקרים מסוימים ניתן לפתור זאת על ידי הפעלת הבדיקה מספר פעמים. אפשרות נוספת היא להגדיל את גודל ההיסטוריה של HWASan. ניתן לעשות זאת באופן גלובלי ב- build/soong/cc/sanitize.go (חפש את hwasanGlobalOptions ), או בסביבת התהליך שלך (נסה adb shell echo $HWASAN_OPTIONS כדי לראות את ההגדרות הנוכחיות).

זה יכול לקרות גם אם הזיכרון שנגיש אליו אינו ממופה, או מוקצה על ידי מקצה שאינו מודע ל-HWASan. במקרה זה, תג mem המופיע בכותרת הקריסה יהיה בדרך כלל 00 . אם יש לך גישה למצבה המלאה, אולי יעזור לך להתייעץ עם dump מפות הזיכרון כדי לגלות לאיזה מיפוי (אם בכלל) שייכת הכתובת.

"באג מקונן באותו שרשור"

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