blob: 1a16eee4da2a11ace92f7122d8dfd846bf2b03be (
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 report is about user-mode or system-mode QEMU. Let's break down the information given.
The issue occurs when building software using pbuilder on an amd64 host for an armhf target. The problem arises with automoc4 segfaulting during the build process in the pbuilder environment. When run directly on a Nexus 7 (which is an ARM device), automoc4 works fine, so it's likely not a bug in automoc4 itself but something related to the emulation environment.
The user provided the GDB output from the crash. The key point here is that they're running this in a pbuilder setup which uses QEMU for cross-compilation. Since the problem only occurs when using QEMU (on amd64 host) and not on the actual ARM hardware, it's pointing towards an issue within the user-mode emulation provided by QEMU.
Looking at the packages involved: qemu-user-static is mentioned, which suggests that this is about user-space emulation rather than full system virtualization. In user-mode, QEMU allows running binaries of different architectures natively without a full OS setup, which aligns with how pbuilder works for cross-building.
The crash occurs in automoc4 when it's processing some C++ code, leading to a segmentation fault. The GDB backtrace is not very helpful due to the core file being truncated and memory issues, but that's common in such crashes where the stack might be corrupted or inaccessible.
Considering the context, since this is during cross-compilation using user-mode QEMU-static, it doesn't involve system-level components like hardware devices or full OS virtualization. It's more about how the user-space programs are being emulated and interact with each other.
Therefore, this issue falls under 'user' mode because it's related to executing binaries of a different architecture in a static user-mode environment without a full VM setup.
</think>
user
|