1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<think>
Okay, let's see. The user is having a problem where qemu-i386 is causing segfaults on a 32-bit Linux system. They mention that the segfaults disappear when running under gdb or strace. Interesting. The user is asking for help to figure out the cause and wants to classify the bug into one of the given categories: instruction, syscall, or runtime.
First, I need to recall what each category means. Instruction would be something wrong with how the instructions are handled, like incorrect emulation. Syscall would be issues with system calls made by the program. Runtime is other runtime errors not covered by those two.
The key clue here is that the segfaults go away when using gdb or strace. That's a common symptom related to something called the "ptrace" system call. Both gdb and strace use ptrace to attach to processes. When a program is run under ptrace, some behaviors can change. For example, some programs or libraries might detect that they're being traced, or there might be timing differences. However, in the context of QEMU, maybe the problem is related to how QEMU interacts with the host's system calls when not being traced.
Wait, QEMU uses dynamic translation, and when running in user-mode (like qemu-i386), it has to handle system calls from the guest (32-bit) to the host (which might be 64-bit or 32-bit). If there's a problem with how the system calls are being made or handled, that could lead to a segfault. But why would that happen only when not using gdb/strace?
Another angle: sometimes, when a program segfaults, it's because of a race condition or a signal handling issue. When running under gdb or strace, the timing changes, which might prevent the race condition. Alternatively, maybe QEMU is not properly handling signals in certain cases when not being traced. But signals are part of the runtime environment.
Wait, but the user says that qemu-x86_64 works fine. So the problem is specific to the 32-bit emulator. Maybe there's an issue with how the 32-bit system calls are being made on a 64-bit host. For example, if the host is 64-bit and the user is trying to run 32-bit binaries with qemu-i386, there might be some compatibility layers or library issues. However, the user mentions it's a 32-bit Linux, so maybe the host is 32-bit? Wait, the user says "32-bit linux trying to run binaries using qemu-i386 from git". Wait, that's confusing. If the host is 32-bit, why use qemu-i386? Maybe they are trying to run 32-bit binaries natively, but perhaps there's a problem with the QEMU build from git. Or maybe the host is 64-bit, and they're trying to run 32-bit binaries with qemu-i386, but that's a different scenario.
But regardless, the key is that the segfaults disappear under gdb/strace. This is often related to something called the "vfork" system call or other system call handling. When a process is being traced, the kernel might handle certain system calls differently. For example, some programs use vfork, and if the child process does an exec, but there's a bug in how the parent handles it. However, when traced, the parent might not be starved of CPU time, so the issue doesn't occur.
Another possibility is that the QEMU binary itself is not properly handling certain system calls when not being traced. For instance, if there's a missing or incorrect system call handler in the 32-bit QEMU, causing a segfault when the guest program makes that call. But when under strace, the system call is intercepted by strace, so QEMU might not be involved in handling it, thus avoiding the segfault.
Given that, this seems like a system call handling issue. The fact that the problem disappears when using strace (which traces system calls) suggests that the presence of tracing changes the behavior, possibly because the system call is handled by strace instead of QEMU, or because the tracing affects how the system calls are made or handled.
Therefore, the category would be "syscall".
</think>
syscall
|