blob: 734f73a6a0059770409e3b52b2afbaad4169edfa (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I'm trying to classify this bug report related to qemu-aarch64 and HWAddressSanitizer. The user is experiencing issues where the simulator isn't reporting tag mismatches as expected but instead throws a SEGV error pointing to an unknown address in the zero page.
First, looking at the output from the test case, it seems that when running bitfield-2.exe under qemu-aarch64, the program crashes with a segmentation fault. The error message indicates that HWAddressSanitizer detected a DEADLYSIGNAL (SEGV) and points to an unknown address 0x0000000000f0. This suggests that the program is trying to access memory it shouldn't be accessing, possibly due to a tag mismatch not being reported correctly.
The user expects a "tag-mismatch" error but instead gets a segmentation fault. This implies that the issue might be related to how QEMU handles MTE (Memory Tagging Extension) instructions or how it interacts with HWAddressSanitizer's instrumentation.
Considering the possible categories:
1. **Instruction**: This relates to faulty CPU instructions. If QEMU misimplements an instruction, especially one related to MTE, it could cause incorrect behavior. However, the error here seems more about memory access rather than a specific instruction fault.
2. **Syscall**: Errors during system calls. The stack trace doesn't show any syscalls being problematic; instead, it's within HWASan and the test code.
3. **Runtime**: Other runtime errors not covered by instructions or syscalls. Since the issue is about improper handling of memory tags leading to an unexpected SEGV, this seems like a runtime problem specific to how QEMU manages memory tagging or interacts with the sanitizer.
The fact that it's in the hwasan testsuite and involves MTE suggests that the problem lies in how QEMU handles these tagged addresses. Perhaps QEMU isn't correctly propagating tag information or misreporting when tags don't match, leading HWASan to not catch the issue and instead causing a crash.
So, this seems like a runtime error because it's about incorrect handling of memory operations during execution rather than a problem with specific instructions or syscalls.
</think>
runtime
|