blob: 2081aed94b1008709966f810d97c3976e813394f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, let's see. The user provided a bug report about QEMU crashing when an application calls pthread_getattr_np(). The problem occurs during user emulation. The example program uses pthread_getattr_np, which is a pthread function. The crash in QEMU is a SIGSEGV, and the backtrace points to code in syscall.c, specifically in the open_self_maps_2 function.
The bug was introduced in a rewrite of open_self_maps in a specific commit. The current master is still affected. The possible categories are instruction, syscall, or runtime.
Looking at the backtrace, the crash happens in a syscall handling function. The function open_self_maps is part of the syscall processing in QEMU's user mode. The error seems to be related to how QEMU handles the syscall for opening /proc/self/maps, which is used to get memory mapping information. The pthread_getattr_np function might be triggering this by requiring some memory mapping data that QEMU can't handle correctly, leading to a segmentation fault in the syscall code.
Since the issue is directly related to a syscall handling function in QEMU, and the backtrace shows it's happening during a syscall (like openat for /proc/self/maps), this would fall under the syscall category. The problem isn't about a wrong instruction (which would be an actual CPU instruction error) but rather how QEMU processes the system call. So the correct category here is syscall.
</think>
syscall
|