1# Address Sanitizer Detection 2<!--Kit: Performance Analysis Kit--> 3<!--Subsystem: HiviewDFX--> 4<!--Owner: @mlkgeek--> 5<!--SE: @StevenLai1994--> 6<!--TSE: @gcw_KuLfPSbe--> 7 8## Overview 9 10Out-of-bounds address access refers to the access to an invalid address. As a result, the program runs abnormally and the application may crash. Common causes include use after free, double-free, stack-overflow, and heap-overflow. As application crash logs are limited and not the first crash site, it is difficult to locate out-of-bounds address access issues. Typically, you can use detection tools such as Asan, HWAsan, and GWP-Asan to obtain more memory operation information. Since API 13, you are advised to use [HWAsan](https://developer.huawei.com/consumer/en/doc/best-practices/bpta-stability-hwasan-detection#section20672194985111) to analyze out-of-bounds address access issues. 11 12## Common Out-of-bounds Types and Impacts 13 14For details, see [Typical Types of Out-of-bounds Address Access](https://developer.huawei.com/consumer/en/doc/best-practices/bpta-stability-address-sanitizer-catagory). 15 16## Principle of Address Sanitizer Detection 17 18For details, see [Address Sanitizer Detection](https://developer.huawei.com/consumer/en/doc/best-practices/bpta-stability-ram-detection#title53131231). 19 20## How to Obtain Logs 21 22Both address sanitizer logs and process crash logs are managed by the FaultLogger module and can be obtained using any of the following methods: 23 24**Method 1: DevEco Studio** 25 26DevEco Studio collects process crash logs from **/data/log/faultlog/faultlogger/** to FaultLog, where logs are displayed by process name, fault, and time. For details about how to obtain logs, see [Fault Log](https://developer.huawei.com/consumer/en/doc/harmonyos-guides/ide-fault-log). 27 28**Method 2: HiAppEvent APIs** 29 30HiAppEvent provides APIs for subscribing to faults. For details, see [Introduction to HiAppEvent](hiappevent-intro.md). You can subscribe to the address sanitizer event by referring to [Subscribing to Address Sanitizer Events (ArkTS)](hiappevent-watcher-address-sanitizer-events-arkts.md) or [Subscribing to Address Sanitizer Events (C/C++)](hiappevent-watcher-address-sanitizer-events-ndk.md), and read the fault log file using the [external_log](hiappevent-watcher-address-sanitizer-events.md#params) field in the event. 31 32**Method 3: hdc** 33 34In the running state, logs are flushed to **/data/log/faultlog/faultlogger** by default. When **Developer options** is enabled, you can run the **hdc file recv /data/log/faultlog/faultlogger D:\** command to export fault logs to the local host. The fault log file name is in the format of **[Detector type]-[bundleName]-[uid]-[happenedTime].log**. 35 36## Log Specifications 37 38### ASan 39 40In ASan logs, the title contains the device information, fault occurrence time, faulty process, and fault cause. The log content details the out-of-bounds address (**0x007fffd59768**), access size (**WRITE of size 4**), and thread and process information. The call stack displays the function call path that causes the out-of-bounds error, and lists the address, module, and offset of each call layer, helping you quickly locate the code. The log also provides shadow bytes to trace the memory status, helping you determine whether the access is valid. In addition, the log lists the memory space mapping of the process, which helps pinpoint the exact memory region containing the out-of-bounds address. 41 42Example: 43 44``` 45Device info:XXX <- Device information 46Build info:XXX-XXXX x.x.x.xx(xxxxxxx) <- Version information 47Fingerprint:77cdc69cef714391a08c7cb1ceec8b8f9b02900fc6588e4231c2f8750b2bf330 <- Feature information 48Timestamp:xxxx-xx-xx xx:xx:xx.xxx <- Timestamp 49Module name:com.example.sampleapplication <- Module name 50Version:1.0.0 <- Version number 51Pid:62642 <- Process ID 52Uid:20020185 <- User ID 53Reason:stack-buffer-overflow <- Trigger cause 54 55==appspawn==11766==AddressSanitizer: WARNING: unexpected format specifier in printf interceptor: %{ (reported once per process) 56================================================================= 57==appspawn==11766==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x007fffd59768 at pc 0x007c7e718f54 bp 0x007fffd59710 sp 0x007fffd59708 <- Problem overview 58WRITE of size 4 at 0x007fffd59768 thread T0 (e.myapplication) <- Out-of-bounds write size 59 #0 0x7c7e718f50 (/data/storage/el1/bundle/libs/arm64/libentry.so+0x58f50) (BuildId: 5e1d4fe4b589921373e51615051105e455462c5f) <- Call stack information 60 #1 0x7b5710235c (/system/lib64/platformsdk/libace_napi.z.so+0x4235c) (BuildId: e6ee1d59b23d2b0d1e746549da572967) 61 #2 0x7b74ee79a4 (/system/lib64/module/arkcompiler/stub.an+0x4f89a4) 62 #3 0x7b749fa8c0 (/system/lib64/module/arkcompiler/stub.an+0xb8c0) 63 64Address 0x007fffd59768 is located in stack of thread T0 (e.myapplication) at offset 72 in frame 65 #0 0x7c7e718de4 (/data/storage/el1/bundle/libs/arm64/libentry.so+0x58de4) (BuildId: 5e1d4fe4b589921373e51615051105e455462c5f) 66 67 This frame has 1 object(s): 68 [32, 72) 'a' (line 66) <== Memory access at offset 72 overflows this variable 69HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork 70 (longjmp and C++ exceptions *are* supported) 71SUMMARY: AddressSanitizer: stack-buffer-overflow (/data/storage/el1/bundle/libs/arm64/libentry.so+0x58f50) (BuildId: 5e1d4fe4b589921373e51615051105e455462c5f) 72 73Shadow bytes around the buggy address: <- Shadow memory information 74 0x001ffffab290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 75 0x001ffffab2a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 0x001ffffab2b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 0x001ffffab2c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 78 0x001ffffab2d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 79=>0x001ffffab2e0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00[f3]f3 f3 80 0x001ffffab2f0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 81 0x001ffffab300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 0x001ffffab310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 83 0x001ffffab320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 84 0x001ffffab330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85Shadow byte legend (one shadow byte represents 8 application bytes): 86 Addressable: 00 87 Partially addressable: 01 02 03 04 05 06 07 88 Heap left redzone: fa 89 Freed heap region: fd 90 Stack left redzone: f1 91 Stack mid redzone: f2 92 Stack right redzone: f3 93 Stack after return: f5 94 Stack use after scope: f8 95 Global redzone: f9 96 Global init order: f6 97 Poisoned by user: f7 98 Container overflow: fc 99 Array cookie: ac 100 Intra object redzone: bb 101 ASan internal: fe 102 Left alloca redzone: ca 103 Right alloca redzone: cb 104==appspawn==11766==ABORTING 105 106==appspawn==11766==Process memory map follows: <- Memory space of the process when the fault occurs 107 0x000ffffff000-0x001200000000 [anon:low shadow] 108 0x001200000000-0x001400000000 [anon:shadow gap] 109 0x001400000000-0x001f6ccb1000 [anon:high shadow] 110 0x001f6ccb1000-0x001f6cd28000 111 0x001f6cd28000-0x001f6e87c000 [anon:high shadow] 112 0x001f6e87c000-0x001f6e89c000 113 0x001f6e89c000-0x001f6e89d000 [anon:high shadow] 114``` 115 116### HWAsan 117 118HWAsan logs are similar to ASan logs. Its title also displays key information such as device information, fault occurrence time, faulty process, and trigger cause. The log content includes the out-of-bounds address (for example, **0x0002013c0100**), access size (for example, **WRITE of size 4**), and thread and process information. In addition, the call stack displays the execution path of the function that triggers the out-of-bounds error, and lists the address, module, and offset of each layer to help you quickly locate the code. Unlike ASan, HWAsan also outputs the tags of pointers and memory blocks, and compares the tags to determine whether an invalid access exists. 119 120``` 121Device info:XXX <- Device information 122Build info:XXX-XXXX x.x.x.xx(xxxxxxx) <- Version information 123Fingerprint:77cdc69cef714391a08c7cb1ceec8b8f9b02900fc6588e4231c2f8750b2bf330 <- Feature information 124Timestamp:xxxx-xx-xx xx:xx:xx.xxx <- Timestamp 125Module name:com.example.sampleapplication <- Module name 126Version:1.0.0 <- Version number 127Pid:62642 <- Process ID 128Uid:20020185 <- User ID 129Reason:use-after-free <- Trigger Cause 130 131==appspawn==62642==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0002013c0100 at pc 0x00651a5c0fa0 <- Problem overview 132WRITE of size 4 at 0x0002013c0100 tags: d2/11 (ptr/mem) in thread T240 <- Out-of-bounds write size 133 #0 0x651a5c0fa0 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c0fa0) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) <- Call stack information 134 #1 0x651a49bfb0 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x19bfb0) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 135 #2 0x651a49beb8 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x19beb8) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 136 #3 0x651a5c100c (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c100c) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 137 #4 0x651a4eeb60 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x1eeb60) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 138 #5 0x651a4ed864 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x1ed864) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 139 #6 0x651a5c81f8 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c81f8) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 140 #7 0x651a5cc450 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2cc450) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 141 #8 0x651a5c4708 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c4708) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 142 #9 0x651a5c48e8 (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c48e8) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 143 #10 0x5a3e8d0d98 (/lib/ld-musl-aarch64-asan.so.1+0x10ed98) (BuildId: bac03842ac83e537d217a027e9584250) 144 145[0x0002013c0100,0x0002013c0140) is a small allocated heap chunk; size: 64 offset: 0 <- Corrupted memory information 146 147Potential Cause: use-after-free <- Possible cause 1 1480x0002013c0100 (old ptr tags: 5d) is located 0 bytes inside of 48-byte region [0x0002013c0100,0x0002013c0130) 149freed by thread T0 here: <- Released stack 150 #0 0x5a3f868f98 (/system/asan/lib64/libclang_rt.hwasan.so+0x28f98) (BuildId: a6c55e97d9dbc519020b7732890fe5143f80d175) <- Call stack information 151 #1 0x650009d6b4 (/system/asan/lib64/module/file/libfileuri.z.so+0x1d6b4) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 152 #2 0x65000a09ec (/system/asan/lib64/module/file/libfileuri.z.so+0x209ec) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 153 #3 0x5a3e855790 (/lib/ld-musl-aarch64-asan.so.1+0x93790) (BuildId: bac03842ac83e537d217a027e9584250) 154 #4 0x5a3e85801c (/lib/ld-musl-aarch64-asan.so.1+0x9601c) (BuildId: bac03842ac83e537d217a027e9584250) 155 #5 0x5ad738d43c (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4d43c) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 156 #6 0x5ad738c2d0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4c2d0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 157 #7 0x5ad738b9c0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4b9c0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 158 #8 0x5ad73a3b30 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x63b30) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 159 #9 0x5ad6e75f1c (/system/asan/lib64/platformsdk/libark_jsruntime.so+0x8b5f1c) (BuildId: a2f4a88f26244f527994da0cefbab138) 160 #10 0x5af39b2130 (/system/lib64/module/arkcompiler/stub.an+0x332130) 161 #11 0x5af36897d0 (/system/lib64/module/arkcompiler/stub.an+0x97d0) 162 #12 0x212092dc04 ([anon:ArkTS Heap5576local space]+0x2dc04) 163 164previously allocated here: <- Allocation stack 165 #0 0x5a3f868ce8 (/system/asan/lib64/libclang_rt.hwasan.so+0x28ce8) (BuildId: a6c55e97d9dbc519020b7732890fe5143f80d175) 166 #1 0x650009a840 (/system/asan/lib64/module/file/libfileuri.z.so+0x1a840) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 167 #2 0x65000a09ec (/system/asan/lib64/module/file/libfileuri.z.so+0x209ec) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 168 #3 0x5a3e855790 (/lib/ld-musl-aarch64-asan.so.1+0x93790) (BuildId: bac03842ac83e537d217a027e9584250) 169 #4 0x5a3e85801c (/lib/ld-musl-aarch64-asan.so.1+0x9601c) (BuildId: bac03842ac83e537d217a027e9584250) 170 #5 0x5ad738d43c (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4d43c) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 171 #6 0x5ad738c2d0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4c2d0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 172 #7 0x5ad738b9c0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4b9c0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 173 #8 0x5ad73a3b30 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x63b30) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 174 #9 0x5ad6e75f1c (/system/asan/lib64/platformsdk/libark_jsruntime.so+0x8b5f1c) (BuildId: a2f4a88f26244f527994da0cefbab138) 175 #10 0x5af39b2130 (/system/lib64/module/arkcompiler/stub.an+0x332130) 176 #11 0x5af36897d0 (/system/lib64/module/arkcompiler/stub.an+0x97d0) 177 #12 0x212092dc04 ([anon:ArkTS Heap5576local space]+0x2dc04) 178 179Cause: heap-buffer-overflow <- Possible cause 2 1800x0002013c0100 is located 3352 bytes to the right of 40-byte region [0x0002013bf3c0,0x0002013bf3e8) 181allocated here: 182 #0 0x5a3f868ce8 (/system/asan/lib64/libclang_rt.hwasan.so+0x28ce8) (BuildId: a6c55e97d9dbc519020b7732890fe5143f80d175) 183 #1 0x65000a85b8 (/system/asan/lib64/module/file/libfileuri.z.so+0x285b8) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 184 #2 0x65000a09b4 (/system/asan/lib64/module/file/libfileuri.z.so+0x209b4) (BuildId: 7f492df25ba1291065c3cf49b731c56a) 185 #3 0x5a3e855790 (/lib/ld-musl-aarch64-asan.so.1+0x93790) (BuildId: bac03842ac83e537d217a027e9584250) 186 #4 0x5a3e85801c (/lib/ld-musl-aarch64-asan.so.1+0x9601c) (BuildId: bac03842ac83e537d217a027e9584250) 187 #5 0x5ad738d43c (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4d43c) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 188 #6 0x5ad738c2d0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4c2d0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 189 #7 0x5ad738b9c0 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x4b9c0) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 190 #8 0x5ad73a3b30 (/system/asan/lib64/platformsdk/libace_napi.z.so+0x63b30) (BuildId: 90a9e7b85b14f6c805a699672bf8db4a) 191 #9 0x5ad6e75f1c (/system/asan/lib64/platformsdk/libark_jsruntime.so+0x8b5f1c) (BuildId: a2f4a88f26244f527994da0cefbab138) 192 #10 0x5af39b2130 (/system/lib64/module/arkcompiler/stub.an+0x332130) 193 #11 0x5af36897d0 (/system/lib64/module/arkcompiler/stub.an+0x97d0) 194 #12 0x212092dc04 ([anon:ArkTS Heap5576local space]+0x2dc04) 195 196Memory tags around the buggy address (one tag corresponds to 16 bytes): <- Tags stored in the shadow memory for comparison with the pointer tags 197 0x005c2013bf90: b6 b6 08 00 1f 1f 08 00 5a 5a 08 00 45 45 08 00 198 0x005c2013bfa0: bc bc 08 00 3b 3b 08 00 35 35 08 00 9c 9c 08 00 199 0x005c2013bfb0: 9e 9e 08 00 d4 d4 08 00 14 14 08 00 ff ff 08 00 200 0x005c2013bfc0: fe fe 08 00 ec ec 08 00 67 67 08 00 26 26 08 00 201 0x005c2013bfd0: 3e 3e 08 00 5f 5f 08 00 fe fe 08 00 8b 8b 08 00 202 0x005c2013bfe0: 98 98 08 00 c3 c3 08 00 37 37 08 00 87 87 08 00 203 0x005c2013bff0: 3f 3f 08 00 02 02 08 00 b3 b3 08 00 fb fb 08 00 204 0x005c2013c000: 56 56 08 00 ad ad 08 00 02 02 08 00 94 94 08 00 205=>0x005c2013c010:[11] 11 08 00 a5 a5 08 00 13 13 08 00 2e 2e 08 00 206 0x005c2013c020: 09 09 08 00 68 68 08 00 df df 08 00 17 17 08 00 207 0x005c2013c030: 24 24 08 00 5f 5f 08 00 f9 f9 08 00 05 05 08 00 208 0x005c2013c040: 02 02 08 00 78 78 08 00 50 50 08 00 33 33 08 00 209 0x005c2013c050: 57 57 08 63 4a 4a 08 4b a8 a8 08 00 cd cd 08 00 210 0x005c2013c060: e6 e6 08 00 0d 0d 08 00 3c 3c 3c 08 83 83 83 08 211 0x005c2013c070: 62 62 62 08 08 08 08 08 35 35 35 08 b5 b5 b5 08 212 0x005c2013c080: 87 87 87 08 4d 4d 4d 08 46 46 46 08 0e 0e 0e 08 213 0x005c2013c090: 6d 6d 6d 08 7a 7a 7a 08 11 11 11 08 af af af 08 214Tags for short granules around the buggy address (one tag corresponds to 16 bytes): 215 0x005c2013c000: .. .. 56 .. .. .. ad .. 97 00 02 .. .. .. 94 .. 216=>0x005c2013c010:[..] .. 11 .. .. .. a5 .. .. .. 13 .. .. .. 2e .. 217 0x005c2013c020: 13 00 09 .. .. .. 68 .. .. .. df .. .. .. 17 .. 218See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags 219Registers where the failure occurred (pc 0x00651a5c0fa0): 220 x0 ec00000201e4ee88 x1 3c000004004c6b38 x2 0000000000000000 x3 0000000000000000 221 x4 6e0000652737ff79 x5 e600000201f631b9 x6 3e000002016b0d10 x7 0000056d1a495b07 222 x8 0200005bffffffff x9 0000006527380ff0 x10 0000006527380f18 x11 0000000000000000 223 x12 073e000002016b0d x13 000000056d1a495b x14 000000000000006e x15 0000000000000000 224 x16 0000005a3f867ef0 x17 000000651a5c0f64 x18 0000000000000005 x19 d2000002013c0100 225 x20 0200005c00000000 x21 3c000004004c6b38 x22 ec00000201e4ee80 x23 0000000000000000 226 x24 b800000000000000 x25 c8000065273804b0 x26 3e000002016b0d08 x27 b8000065273803a0 227 x28 1700000400263f80 x29 000000652737ffa0 x30 000000651a5c0fa4 sp 000000652737ffa0 228 229SUMMARY: HWAddressSanitizer: tag-mismatch (/data/storage/el1/bundle/libs/arm64/libijk.so+0x2c0fa0) (BuildId: 84383086df874d94fa191ddbbc25091cc14992c5) 230 231Memory near registers: <- Memory near registers 232x0([anon:native_heap:jemalloc]): 233 0000005a2be445f0 0000000000000000 234 0000005a2be445f8 0000000000000000 235 0000005a2be44600 000000599a8d0208 236 0000005a2be44608 0000005a2be44600 237 0000005a2be44610 0000005a2beee520 238 0000005a2be44618 0000000000000021 239 0000005a2be44620 0000005a2be51800 240 0000005a2be44628 0000005a2be48080 241 0000005a2be44630 00004c94000000fc 242 0000005a2be44638 ffffffffffffffff 243 0000005a2be44640 ffffffffffffffff 244 0000005a2be44648 ffffffffffffffff 245 0000005a2be44650 0000ffffffffffff 246 0000005a2be44658 0000005a2be33600 247 248Process memory map follows: <- Process memory space when the fault occurs 249 0x000000010000-0x000100020000 rw-p 00000000 [anon:SizeClassAllocator] 250 0x000100020000-0x000101490000 rw-p 00000000 [anon:SizeClassAllocator: region data] 251 0x000101490000-0x0001df870000 rw-p 00000000 [anon:SizeClassAllocator] 252 0x0001df870000-0x0001e0020000 rw-p 00000000 [anon:SizeClassAllocator: region metadata] 253 0x0001e0020000-0x0001e0140000 rw-p 00000000 [anon:SizeClassAllocator: freearray] 254 0x0001e0140000-0x000200020000 rw-p 00000000 [anon:SizeClassAllocator] 255 0x000200020000-0x000201fd0000 rw-p 00000000 [anon:SizeClassAllocator: region data] 256 0x000201fd0000-0x0002dfa20000 rw-p 00000000 [anon:SizeClassAllocator] 257 0x0002dfa20000-0x0002e0020000 rw-p 00000000 [anon:SizeClassAllocator: region metadata] 258 0x0002e0020000-0x0002e0040000 rw-p 00000000 [anon:SizeClassAllocator: freearray] 259``` 260 261### MemDebug 262 263MemDebug employs an isolation area combined with a poison-fill mechanism and reuses HWAsan's tag-verification detector. Its log format for double-free errors is identical to HWAsan's. 264 265``` 266Device info:XXX <- Device information 267Build info:XXX-XXXX x.x.x.xx(xxxxxxx) <- Version information 268Fingerprint:77cdc69cef714391a08c7cb1ceec8b8f9b02900fc6588e4231c2f8750b2bf330 <- Feature information 269Timestamp:xxxx-xx-xx xx:xx:xx.xxx <- Timestamp 270Module name:com.example.sampleapplication <- Module name 271Version:1.0.0 <- Version number 272Pid:62642 <- Process ID 273Uid:20020185 <- User ID 274Reason:use-after-free <- Trigger Cause 275 276==appspawn==62642==ERROR: HWAddressSanitizer: invalid-free on address 0x000100945e20 at pc 0x005a16a634fc on thread 62642 <- Problem Overview 277tags: 57/e9 (ptr/mem) 278 #0 0x5a16a634fc (/system/lib64/xxxxxxxxx.so+0xxxxxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxxxx) <- Callstack information 279 #1 0x5ac1f47c94 (/data/storage/xxxxxxx.so+0xxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxxxxxxx) 280 ... 281 282[0x000100945e20,0x000100945e40) is a small unallocated heap chunk; size: 32 offset: 0, Allocated By 62642 <- Memory block information overview 283 284Potential Cause: use-after-free <- Possible cause 1 2850x000100945e20 (rb[50] tags:57) is located 0 bytes inside of 16-byte region [0x000100945e20,0x000100945e30) 286freed by thread 62642 here: <- Call stack information 287 #0 0x5a16a6b070 (/system/lib64/xxxxxx.so+0xxxxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 288 #1 0x5ac2fce684 (/system/lib64/xxxxxxxx.so+0xxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 289 ... 290 291previously allocated by thread 62642 here: 292 #0 0x5a16a6b070 (/system/lib64/xxxxxx.so+0xxxxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 293 #1 0x5ac2fce684 (/system/lib64/xxxxxxxx.so+0xxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 294 ... 295 296hwasan_dev_note_heap_rb_distance: 51 1023000 297Thread: T0 0x005b00002000 stack: [0x007fb3025000,0x007fb3824000) sz: 8384512 tls: [0x005a16107a98,0x005a16108279) rb:(1023000/1023000) records(1301994/o:0) tid: 62642 298Searched 1028682 records, find 1 with same addr 0x000100945e20 299 300 301Cause: heap-buffer-overflow <- Possible cause 2 3020x000100945e20 is located 2400 bytes to the left of 24-byte region [0x000100946780,0x000100946798) 303allocated here: 304 #0 0x5a16a6b070 (/system/lib64/xxxxxx.so+0xxxxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 305 #1 0x5ac2fce684 (/system/lib64/xxxxxxxx.so+0xxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxx) 306 ... 307 308Ring-buffer information of each thread 309Thread: T0 0x005b00002000 stack: [0x007fb3025000,0x007fb3824000) sz: 8384512 tls: [0x005a16107a98,0x005a16108279) rb:(1023000/1023000) records(1301994/o:0) tid: 62642 310Thread: T6 0x005b0000a000 stack: [0x005ab7b64000,0x005ab7c64978) sz: 1051000 tls: [0x005ab7c64978,0x005ab7c64bc2) rb:(2/1023) records(2/o:0) tid: 62702 311Thread: T7 0x005b00016000 stack: [0x005abf7b4000,0x005abf8b4978) sz: 1051000 tls: [0x005abf8b4978,0x005abf8b4bc2) rb:(1023/1023) records(1133/o:0) tid: 62703 312Thread: T8 0x005b0000e000 stack: [0x005abf8b7000,0x005abf9b7978) sz: 1051000 tls: [0x005abf9b7978,0x005abf9b7bc2) rb:(123/1023) records(123/o:0) tid: 62704 313... 314 315Tag information 316Memory tags around the buggy address (one tag corresponds to 16 bytes): 317 ... 318 0x005c100945d0: ea 08 fa fa ab ab cb 08 32 c6 64 08 f7 f7 68 68 319=>0x005c100945e0: 96 08 [e9] e7 c9 c9 36 36 18 08 ef d9 80 08 8e 08 320 0x005c100945f0: ba 08 98 98 b6 1b 63 63 08 00 bb 52 74 08 84 08 321 ... 322Tags for short granules around the buggy address (one tag corresponds to 16 bytes): 323 0x005c100945d0: .. ea .. .. .. .. .. cb .. .. .. 64 .. .. .. .. 324=>0x005c100945e0: .. 96 [..] .. .. .. .. .. .. 18 .. .. .. 80 .. 8e 325 0x005c100945f0: .. ba .. .. .. .. .. .. 64 .. .. .. .. 74 .. 84 326See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags 327SUMMARY: HWAddressSanitizer: invalid-free (/system/lib64/xxxxxx.xxxxx.so+0xxxxxx) (BuildId: xxxxxxxxxxxxxxxxxxxxxxxxxxx) 328 329Process maps information 330==appspawn==62642==Process memory map follows: 331 0x000000010000-0x000100020000 332 0x000100020000-0x000100030000 [anon:SizeClassAllocator: region data] 333 0x000100030000-0x000100040000 [anon:SizeClassAllocator: region data] 334 ... 335``` 336 337For Use-After-Free (Write) problems, the logs are different in the problem overview. The following is an example output: 338 339``` 340ptrBeg was re-written after free 0x000100946540[1], 0x000100946548 5555555500000009:5555555555555555 341``` 342 343**0x000100946540** is the start address of the problematic memory block, **[1]** is the 8-byte offset of the detected problematic memory based on the start address, **0x000100946548** is the actual modified address, and **5555555500000009:5555555555555555** indicates the comparison between the actual value and expected value after the memory content is modified. After this line, the log also prints the allocation call stack and the deallocation call stack for the affected memory block. The stack format is identical to that used in HWAsan logs and is therefore omitted here. 344 345### GWP-Asan 346 347GWP-ASan logs are relatively simple. The following is a typical Use-After-Free log, which contains the allocation, release, and violation call stacks of the affected memory block. 348 349``` 350Device info:XXX <- Device information 351Build info:XXX-XXXX x.x.x.xx(xxxxxxx) <- Version information 352Fingerprint:c41391f9c18acc1121ea519ffdba5698bfb5342ae7125e20ebf2865e31249f1a<- Feature information 353Timestamp:xxxx-xx-xx xx:xx:xx.xxx <- Timestamp 354Module name:com.example.sampleapplication <- Module name 355Version:1.0.0 <- Version number 356Pid:13305 <- Process ID 357Uid:20020181 <- User ID 358Reason:GWP-ASAN <- The value of Reason is fixed to GWP-ASAN 359*** GWP-ASan detected a memory error *** 360Use After Free at 0x5b46ddaff0 (0 bytes into a 16-byte allocation at 0x5b46ddaff0) by thread 13305 here: <- Problem overview, which describes a UAF problem 361 #0 0x5c474f049c (/data/storage/xxxxxx.so+0x3049c) <- Call stack information 362 #1 0x5c474fa8c0 (/data/storage/xxxxxx.so+0x3a8c0) 363 #2 0x5c474fa870 (/data/storage/xxxxxx.so+0x3a870) 364 #3 0x5c474fa834 (/data/storage/xxxxxx.so+0x3a834) 365 #4 0x5c474fa7d4 (/data/storage/xxxxxx.so+0x3a7d4) 366 #5 0x5c474fa4a0 (/data/storage/xxxxxx.so+0x3a4a0) 367 #6 0x5b2d444c04 (/system/lib64/platformsdk/libace_napi.z.so+0x44c04) 368 #7 0x5b401d484c 369 #8 0x5b3fc11d7c 370 #9 0xfffffffffffffffe 3710x5b46ddaff0 was deallocated by thread 13305 here: <- Problem overview, which is the deallocation stack 372 #0 0x5aa0c0be2c (/lib/ld-musl-aarch64.so.1+0x13de2c) <- Call stack information 373 #1 0x5aa0c0b97c (/lib/ld-musl-aarch64.so.1+0x13d97c) 374 #2 0x5c474f0494 (/data/storage/xxxxxx.so+0x30494) 375 #3 0x5c474fa8c0 (/data/storage/xxxxxx.so+0x3a8c0) 376 #4 0x5c474fa870 (/data/storage/xxxxxx.so+0x3a870) 377 #5 0x5c474fa834 (/data/storage/xxxxxx.so+0x3a834) 378 #6 0x5c474fa7d4 (/data/storage/xxxxxx.so+0x3a7d4) 379 #7 0x5c474fa4a0 (/data/storage/xxxxxx.so+0x3a4a0) 380 #8 0x5b2d444c04 (/system/lib64/xxxxxx.so+0x44c04) 381 #9 0x5b401d484c 382 #10 0x5b3fc11d7c 383 #11 0xfffffffffffffffe 3840x5b46ddaff0 was allocated by thread 13305 here: <- Problem overview, which is the allocation stack 385 #0 0x5aa0c0be2c (/lib/ld-musl-aarch64.so.1+0x13de2c) <- Call stack information 386 #1 0x5aa0c0b77c (/lib/ld-musl-aarch64.so.1+0x13d77c) 387 #2 0x5aa0c22e5c (/lib/ld-musl-aarch64.so.1+0x154e5c) 388 #3 0x5c474f047c (/data/storage/xxxxxx.so+0x3047c) 389 #4 0x5c474fa8c0 (/data/storage/xxxxxx.so+0x3a8c0) 390 #5 0x5c474fa870 (/data/storage/xxxxxx.so+0x3a870) 391 #6 0x5c474fa834 (/data/storage/xxxxxx.so+0x3a834) 392 #7 0x5c474fa7d4 (/data/storage/xxxxxx.so+0x3a7d4) 393 #8 0x5c474fa4a0 (/data/storage/xxxxxx.so+0x3a4a0) 394 #9 0x5b2d444c04 (/system/lib64/xxxxxx.so+0x44c04) 395 #10 0x5b401d484c 396 #11 0x5b3fc11d7c 397 #12 0xfffffffffffffffe 398* End GWP-ASan report * 399``` 400