blob: a8e1a90fbce788c6df5e45ae02c3041cd4fe5edb (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, I need to classify this bug report as either 'user-mode' related or 'system-mode' related. The issue involves qemu-user, which is a user-mode emulator, so my initial thought is that it's a user-mode problem.
The user provided a detailed scenario where running a PIE-compiled bash under qemu-i386-static leads to an allocation failure in bash's internal malloc. They've tried using glibc's malloc instead, which works fine, but the problem persists when using their own implementation based on sbrk(). This suggests that the issue might be with how qemu-user handles certain system calls or memory operations.
The bug report mentions that this was fixed in the kernel for direct execution but reappears under qemu. That implies it's related to how the emulator is handling these low-level memory functions. Since user-mode emulators don't have full kernel privileges and rely on intercepting syscalls, maybe there's an issue with how sbrk() or memory management is being handled in qemu.
The fact that the problem occurs across multiple target architectures but not when using glibc's malloc further points towards a lower-level issue. Glibc might be handling something differently under qemu, perhaps falling back to alternative allocation methods that work around the emulator's limitations.
Considering all this, I think the bug is related to user-mode emulation in qemu. It's about how the emulator interacts with the binary's memory management when running as a PIE, which affects the sbrk() calls and subsequent allocations.
</think>
user
|