blob: e59384c09c02964e557425d97bed343cf1e1ad4b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Alright, I'm trying to figure out how to classify this bug report for QEMU. The user provided a detailed description where running Go applications under qemu-x86_64 on an AARCH64 host causes crashes in the Go garbage collector. They disabled the GC with GOGC=off and it worked, so the issue is related to the GC.
Looking at the stack trace from Go, it points to a problem in `lfstack.push`, which is part of the runtime's memory management. This suggests that something is going wrong with how QEMU handles certain operations that affect the heap or memory management in the Go process.
The user also provided bisected commits in QEMU that seem to be related. One commit splits out `do_munmap`, and another deals with mmap placement for reserved VA space. These changes might have altered how QEMU manages memory mappings, leading to issues when Go's GC tries to handle its own memory structures.
Since the problem arises from Go's runtime interacting with QEMU's handling of certain syscalls or memory operations, it's likely a runtime issue within Go caused by a change in QEMU. However, since the question is about classifying the bug in QEMU, I should consider how QEMU's changes affect the application's runtime.
The crash occurs during memory management tasks (specifically with the garbage collector), which involves system calls like mmap and munmap. The bisected commits involve do_munmap and early mmap placement, indicating that these changes might have introduced a regression affecting applications' runtime environments.
So, the issue seems to stem from QEMU's handling of syscalls related to memory management, which in turn affects Go's garbage collector. Therefore, it falls under the "runtime" category because it's an error occurring during the application's execution due to how QEMU manages certain operations.
</think>
runtime
|