diff options
Diffstat (limited to 'results/classifier/qwen3:32b/reasoning/runtime/1034')
| -rw-r--r-- | results/classifier/qwen3:32b/reasoning/runtime/1034 | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/results/classifier/qwen3:32b/reasoning/runtime/1034 b/results/classifier/qwen3:32b/reasoning/runtime/1034 new file mode 100644 index 00000000..f974b7e3 --- /dev/null +++ b/results/classifier/qwen3:32b/reasoning/runtime/1034 @@ -0,0 +1,13 @@ +<think> +Okay, let's see. The user provided a bug report about Erlang/OTP 25 failing with a segfault when using QEMU's user mode JIT on AArch64. The problem seems to be related to how QEMU handles code invalidation when the guest (Erlang's JIT) overwrites code. + +The Erlang developers explained that their JIT uses two memory regions: one executable but not writable, and another writable but not executable. They use the same physical memory, so writes to the writable region should reflect in the executable one. They're using IC IVAU and ISB instructions to inform the processor about code changes. + +In QEMU's system mode, the MMU emulation works correctly, invalidating translations when writes happen. But in user mode, QEMU calls mprotect with PROT_READ on code regions and invalidates translations in a signal handler. The issue is that since the writes are to the writable region (not the executable one), QEMU's user mode doesn't detect them, leading to stale translations and a segfault. + +So the core problem is that QEMU's user mode isn't properly handling the code invalidation when the guest modifies code in a non-executable region that's backed by the same memory as an executable region. The user mode relies on trapping writes to the translated code regions, but since the actual writes are to a different region (even though it's the same memory), QEMU doesn't invalidate the translations. + +This seems to be a runtime issue because it's about how QEMU manages translations and invalidations during execution. There's no mention of a specific syscall error here; it's more about the internal handling of code modifications and translation invalidation. The problem isn't with a particular instruction being faulty either, but rather how QEMU's runtime management of translations interacts with the guest's memory layout. So the category should be 'runtime'. +</think> + +runtime \ No newline at end of file |