blob: dc6c555cf1f153c24706a484e133f7599b4677a8 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I'm trying to figure out whether this bug is user-mode or system-mode related. Let's break down the information given.
The issue occurs when running locale-gen inside an armv7h chroot on an x86_64 desktop using qemu-arm-static. The error happens during the spawni.c process, which relates to how processes are started. The assertion failure points to a problem with __spawnix, specifically that ec >= 0 isn't holding true.
I remember that user-mode emulation involves running code in a way that doesn't require full system virtualization. Qemu can do both user and system mode. In user-mode, it translates system calls from the guest architecture (armv7h) to the host (x86_64). This means that processes like locale-gen would be executed under qemu's user-mode translation.
The problem arises in the spawn function, which is part of process creation. Since it's using glibc's posix_spawn(), and clone() isn't handling it properly, this suggests an issue with how system calls are being emulated or translated by qemu in user-mode.
Given that the user has been doing this successfully for years but it broke recently, especially after updating to qemu 2.8, it points more towards a regression in qemu's user-mode emulation rather than issues with hardware or higher-level system components.
So, considering all this, the bug is likely related to user-mode.
</think>
user
|