1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I'm trying to figure out how to classify this bug report about QEMU crashing when an application calls pthread_getattr_np(). Let me go through the information provided step by step.
First, the problem occurs when running a specific program under QEMU's user emulation. The program is using pthread_getattr_np(), which is a non-portable (GNU) extension to get thread attributes. When this function is called, QEMU crashes with a segmentation fault, specifically SIGSEGV at address 0x20.
Looking at the backtrace from GDB, it shows that the crash happens in several functions within QEMU's codebase. The stack trace goes through functions like open_self_maps_2, walk_memory_regions, and eventually into do_syscall1 and do_syscall. These function names suggest that the issue is related to system calls being handled by QEMU.
The user also mentioned that this bug was introduced after a rewrite of the `open_self_maps` function in commit 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb. That indicates that there's something wrong with how QEMU is handling this specific system call or related memory operations.
Now, considering the possible categories: instruction, syscall, runtime.
- **Instruction**: This would be if the issue was caused by a faulty CPU instruction. But here, the problem arises from a system call, not directly from an executed instruction.
- **Syscall**: Since the crash happens during a system call handling in QEMU, specifically when opening `/proc/self/maps`, which is part of process memory management. The error seems to stem from how QEMU processes this syscall, leading to invalid memory access.
- **Runtime**: This would cover other runtime errors not related to instructions or syscalls, but given the stack trace points directly to system call handling functions, it's more specific than a general runtime issue.
Therefore, the bug is likely related to how QEMU handles a particular system call, which fits into the "syscall" category. The crash occurs during the processing of an openat system call (as seen in do_guest_openat), leading to invalid memory access and segmentation fault.
</think>
syscall
|