blob: d088f57eacea7f66b735a049f5f46d59b95e76cc (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to figure out whether this Java crash caused by SIGSEGV when using QEMU is a user-mode or system-mode issue. Let's break it down.
First, the problem occurs when running a Java program inside a chroot environment on an amd64 host, using the qemu-user-static package for armhf emulation. The user mentioned that version 2.7 works fine but 2.8 causes crashes with SIGSEGV.
Java is crashing with a segmentation fault, which usually points to memory access issues. Since it's happening inside the chroot and not the host system, it's likely related to how QEMU emulates the armhf environment for user space processes.
The Azul Zulu Embedded Java runtime has an arm32 JIT compiler, while OpenJDK doesn't, so this might be relevant. The JIT could be interacting differently with the emulation layer provided by QEMU.
QEMU can run in different modes: system-mode (emulating entire systems) and user-mode (translating binaries for execution). Since the user is using chroot and qemu-user-static, it's definitely user-mode because that's what handles running individual executables of different architectures.
The crash seems random but consistent across runs with the same QEMU version. The fact that it works on an older version suggests a regression in QEMU's user-mode emulation between 2.7 and 2.8. Maybe something changed in how memory is managed or how system calls are handled.
So, putting this together, the issue is within QEMU's user-mode emulation affecting the Java runtime when JIT is enabled. This points to it being a user-mode problem because it's about translating and executing binaries of another architecture.
</think>
user
|