blob: b8c4efe4469dd1123167d630257db903804dcf07 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to figure out whether this bug is related to user-mode or system-mode in QEMU based on the provided information.
First, the problem occurs when using qemu-user for RISC-V64. The issue happens during forking in processes with multiple threads, like when running 'cargo', which is a Rust tool. The child process hangs because of issues with glib allocations, specifically with g_slice.
The stack traces show that the main thread (Thread 1) is stuck in a syscall, trying to lock a mutex related to glib's memory management. It seems that during forking, some global state managed by glib isn't properly handled, leading to deadlocks in the child process.
The user mentions that setting `G_SLICE=always-malloc` as an environment variable resolves the issue, which suggests that avoiding glib's slice allocator helps. They've also filed a bug upstream with glib regarding this issue.
Now, considering QEMU's modes: system-mode involves simulating a full system with devices and peripherals at a lower level, whereas user-mode (like qemu-user) is for running unmodified applications in a userspace environment without a full OS simulation.
Since the problem occurs in a user-mode setup (qemu-user), it seems to be related to how QEMU handles threading and forking within that context. The issue is more about how user-space processes interact with glib under QEMU's emulation rather than any system-level device or OS interaction.
Therefore, this bug is likely classified as 'user' mode.
</think>
user
|