इस पेज का अनुवाद Cloud Translation API से किया गया है.

HWASan की रिपोर्ट को समझना

जब HWASan टूल को किसी मेमोरी गड़बड़ी का पता चलता है, तो प्रोसेस को abort() के साथ खत्म कर दिया जाता है, और एक रिपोर्ट, stderr और Logcat पर प्रिंट की जाती है. Android पर होने वाले सभी नेटिव क्रैश की तरह, 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 …]

यह AddressSanitizer रिपोर्ट से काफ़ी मिलता-जुलता है. उनसे अलग, HWASan की सभी गड़बड़ियां “टैग-मेल न खाने” की होती हैं, यानी मेमोरी का ऐक्सेस जहां पॉइंटर टैग से काम होता है यह संबंधित मेमोरी टैग से मेल नहीं खाता. यह इनमें से एक हो सकता है

स्टैक या हीप पर, सीमाओं से बाहर का ऐक्सेस
हीप पर मुफ़्त में इस्तेमाल करें
स्टैक पर रिटर्न के बाद इस्तेमाल करें

सेक्शन

HWASan रिपोर्ट के हर सेक्शन के बारे में जानकारी यहां दी गई है:

ऐक्सेस में गड़बड़ी

इसमें खराब मेमोरी ऐक्सेस के बारे में जानकारी शामिल होती है. जैसे:

ऐक्सेस टाइप ("READ" बनाम "WRITE")
ऐक्सेस साइज़ (कितने बाइट को ऐक्सेस करने की कोशिश की गई)
ऐक्सेस का थ्रेड नंबर
पॉइंटर और मेमोरी टैग (बेहतर डीबग करने के लिए)

स्टैक ट्रेस को ऐक्सेस करना

खराब मेमोरी ऐक्सेस का स्टैक ट्रेस. निशान लगाने वाला सेक्शन देखें और प्रतीक.

वजह

खराब ऐक्सेस की संभावित वजह. अगर चुनाव में हिस्सा लेने के लिए कई उम्मीदवार हैं, हैं घटने की संभावना के क्रम में दिखाया जाता है. इस बारे में पूरी जानकारी पहले दिखाएं कोई संभावित वजह हो सकती है. 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:
	पते के बारे में नहीं बताया जा सकता	ऐसी बहुत सी मेमोरी मौजूद है जिसमें पहले से कोई वर्ण तय नहीं किया गया है या डबल फ़्री के बाद असाइन की गई मेमोरी को HWASan के फ़्री बफ़र से हटा दिया गया था.
	0x... HWAsan की शैडो मेमोरी है.	यह बेहद आसान है, क्योंकि ऐप्लिकेशन मुफ़्त में डाउनलोड करने की कोशिश कर रहा था वह मेमोरी जो HWASan के ज़रिए

डी-लोकेशन स्टैक ट्रेस

उस जगह का स्टैक ट्रेस जहां मेमोरी असाइन की गई थी. सिर्फ़ बिना किसी शुल्क के इस्तेमाल करने के लिए उपलब्ध अमान्य हो सकता है. सिंबल दिखाने के लिए सिम्बॉलाइज़ेशन सेक्शन देखें.

ऐलोकेशन स्टैक ट्रेस

स्टैक ट्रेस दिखाता है कि मेमोरी को कहां बांटा गया था. सिंबल दिखाने के लिए सिम्बॉलाइज़ेशन सेक्शन देखें.

बेहतर तरीके से डीबग करना जानकारी

HWASan रिपोर्ट में, डीबग करने की बेहतर जानकारी भी शामिल होती है, जैसे कि (क्रम में):

प्रोसेस में शामिल थ्रेड की सूची
प्रोसेस में शामिल थ्रेड की सूची
गड़बड़ी वाली मेमोरी के पास मेमोरी टैग की वैल्यू
मेमोरी ऐक्सेस के समय रजिस्टर का डंप

मेमोरी टैग डंप

टैग मेमोरी डंप का इस्तेमाल, एक ही टैग वाले आस-पास की मेमोरी देखने के लिए किया जा सकता है क्योंकि पॉइंटर टैग के साथ जोड़ा जा सकता है. ये बड़े ऑफ़सेट के साथ सीमा से बाहर के ऐक्सेस की ओर इशारा कर सकते हैं. एक टैग 16 के बराबर है बाइट मेमोरी का; पॉइंटर टैग, पते के टॉप 8 बिट होता है. टैग मेमोरी डंप यह कर सकता है हिंट देते हैं, इसके लिए नीचे दिया गया उदाहरण, दाईं ओर एक बफ़र ओवरफ़्लो है:

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है (नोटर टैग से मेल खाने वाले "विज्ञापन" टैग के बाईं ओर 6 × 16 = 96 बाइट के चलने पर ध्यान दें).

अगर आवंटन का आकार 16 का गुणांक नहीं है, तो शेष आकार होगा संग्रहित क्योंकि मेमोरी टैग और टैग को शॉर्ट वीडियो ग्रैन्यूल टैग का इस्तेमाल करें. ऊपर दिए गए उदाहरण में, बोल्ड किए गए ऐलोकेशन को टैग करने के ठीक बाद विज्ञापन, हम मेरे पास 5 है × 16 + 4 = टैग 5c का 84 बाइट ऐलोकेशन.

शून्य मेमोरी टैग (उदाहरण के लिए, tags: ad/00 (ptr/mem)) आम तौर पर यह दिखाता है कि 'स्टैक-यूज़-एक्सटर्नल' गड़बड़ी ठीक करें.

डंप को रजिस्टर करें

HWASan रिपोर्ट में रजिस्टर डंप उस असल निर्देश के मुताबिक होता है जिसने ग़लत मेमोरी ऐक्सेस दें. इसके बाद, सामान्य Android सिग्नल हैंडलर से कोई दूसरा रजिस्टर डंप आता है - इसे अनदेखा करें दूसरा विकल्प, यह तब लिया जाता है जब HWASan को abort() कहा जाता है और यह गड़बड़ी को ठीक करें.

प्रतीक

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

स्टैक ट्रेस में फ़ंक्शन के नाम और लाइन नंबर पाने के लिए (और इस्तेमाल के बाद के स्कोप के लिए वैरिएबल के नाम पाना गड़बड़ियां), तो एक ऑफ़लाइन सिम्बॉलाइज़ेशन चरण ज़रूरी है.

पहली बार सेटअप करने की सुविधा: llvm- सिम्बॉलाइज़र इंस्टॉल करें

इसे सिंबल के तौर पर दिखाने के लिए, आपके सिस्टम में llvm-निशान इंस्टॉल करना ज़रूरी है. साथ ही, इसे $PATH से ऐक्सेस किया जा सकता है. Debian पर sudo apt install llvm का इस्तेमाल करके इसे इंस्टॉल करें.

सिंबल वाली फ़ाइलें पाएं

सिम्बॉलिकेशन के लिए, हमें सिंबल वाली अनट्रिपल बाइनरी की ज़रूरत होती है. यह कहां मिल सकता है, यह इस बात पर निर्भर करता है कि बिल्ड के टाइप के बारे में जानकारी:

लोकल बिल्ड के लिए, सिंबल वाली फ़ाइलें यहां मिल सकती हैं out/target/product/<product>/symbols/.

AOSP बिल्ड के लिए (उदाहरण के लिए, फ़्लैशस्टेशन से फ़्लैश किया गया), बिल्ड पाने के लिए, Android CI पर जाएं. "आर्टफ़ैक्ट" में के लिए बिल्ड, ${PRODUCT}-symbols-${BUILDID}.zip फ़ाइल होगी.

अपने संगठन के इंटरनल बिल्ड के बारे में मदद पाने के लिए, अपने संगठन के दस्तावेज़ देखें सिंबल फ़ाइलें पाने के लिए.

प्रतीक बनाएं

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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

ध्यान दें: hwasan_symbolize स्क्रिप्ट, Android एनडीके में toolchains/llvm के नीचे मौजूद हो सकती है.

स्टैक रिपोर्ट को समझना

स्टैक वैरिएबल के साथ आने वाली गड़बड़ियों के लिए, 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, गड़बड़ी की रिपोर्ट में इसे ऐसे कॉन्टेंट में नहीं बदलता जिसे कोई व्यक्ति आसानी से समझ सके और इसके लिए एक और सिम्बॉलाइज़ेशन चरण की ज़रूरत होती है.

ओडीआर के उल्लंघन

HWASan के रिपोर्ट में, इस्तेमाल के बाद कोई गड़बड़ी होने पर, उसे एक परिभाषा नियम (ओडीआर) के उल्लंघन का भी पता चल सकता है. ओडीआर का उल्लंघन तब होता है, जब एक ही प्रोग्राम में एक ही वैरिएबल को कई बार तय किया जाता है. इसका मतलब यह भी है कि वैरिएबल कई बार नष्ट हुआ है. इस वजह से, इस्तेमाल करने के बाद की गड़बड़ी.

सिम्बॉलिकेशन के बाद, ओडीआर के उल्लंघन से पता चलता है कि __cxa_finalize, अमान्य ऐक्सेस स्टैक और "यहां फ़्रीज किया गया", दोनों फ़ॉर्मैट लागू होते हैं स्टैक. "पहले से तय किए गए यहां" स्टैक में __dl__ZN6soinfo17call_constructorsEv है और यह होना चाहिए अपने प्रोग्राम में उस जगह को पॉइंट करें जो स्टैक पर ज़्यादा वैरिएबल को तय करता है.

ओडीआर के उल्लंघन की एक वजह यह भी हो सकती है कि स्टैटिक लाइब्रेरी का इस्तेमाल किया जाए. अगर C++ ग्लोबल को परिभाषित करने वाली स्टैटिक लाइब्रेरी को कई शेयर की गई लाइब्रेरी से लिंक किया गया है या अगर एक ही पते की कई परिभाषाएं एक ही जगह पर दी गई हैं, तो हो सकता है कि एक ही पते पर कई स्पेस की वजह से ओडीआर गड़बड़ी होगी.

समस्या का हल

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. अगर आपके पास कब्र के पत्थर का पूरा ऐक्सेस है, तो सलाह लेने के लिए मेमोरी मैप डंप करती है, जिससे यह पता चलता है कि पता किस मैपिंग (अगर कोई है) से जुड़ा है.

उसी थ्रेड में गड़बड़ी को नेस्ट किया गया

इसका मतलब है कि HWASan की क्रैश-रिपोर्ट जनरेट करते समय कोई गड़बड़ी हुई. ऐसा आम तौर पर साइट में मौजूद किसी गड़बड़ी की वजह से होता है HWASan रनटाइम, कृपया गड़बड़ी की शिकायत करें और अगर हो सके, तो समस्या को ठीक तरीके से समझाने के लिए निर्देश दें.