blob: cb783d0015d0f20ab45bd8cde715ce2d33903312 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I'm trying to figure out how to classify this bug report for QEMU. The user provided some code that causes a crash when run under QEMU in user-mode emulation. The code is pretty simple: it defines a function pointer pointing to an invalid address and then tries to call it.
When they run the program using qemu-arm-static, they get an error about a failed assertion related to tb_lock, which stands out because usually you'd expect just a segmentation fault message. They also mention that the expected result is different—it should show a core dump with signal 11 (Segmentation fault) instead of these assertion errors.
Looking at the possible categories: instruction, syscall, runtime. The issue here seems to be happening when QEMU tries to execute an invalid address. That would likely involve how QEMU handles invalid memory accesses or function calls to non-existent addresses.
The error message mentions translate-all.c and tb_lock, which makes me think it's related to the translation block locking mechanism in QEMU. This suggests that during emulation, something is going wrong when trying to lock a translation block because another thread might already hold the lock. But since this is user-mode emulation, perhaps it's not handling the invalid function call correctly.
Since the crash isn't just a simple segmentation fault but involves internal assertions failing, it points more towards an issue in how QEMU handles runtime errors or specific instructions rather than a syscall or an outright instruction fault. The problem arises during execution when trying to jump to an invalid address, which falls under runtime behavior because it's about how the emulator manages such situations at runtime.
So I'm leaning towards 'runtime' as the category because it's about unexpected behavior during the execution of the program rather than a specific instruction being faulty or a syscall issue.
</think>
runtime
|