blob: ccf73eb97355e00cb6d15a11c1015e61e0de53c3 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
|
<think>
Okay, let's see. The user is reporting a crash in QEMU when a program jumps to an invalid address. The code they provided sets a function pointer to 0x12345678 and then calls it. The output shows an assertion failure in QEMU's translate-all.c file, leading to a segmentation fault. The expected output was a different error message about a target signal 11 (segfault), but instead, QEMU itself crashed.
So, the problem is that QEMU is crashing instead of handling the segfault properly. The user-mode emulation is supposed to catch such invalid memory accesses and translate them into the appropriate signals. The assertion failure in tb_lock suggests there's an issue in the translation block handling when the invalid address is executed.
The categories are instruction, syscall, or runtime. The bug isn't directly about a specific instruction, but more about how QEMU handles the execution flow when an invalid address is encountered. It's not a syscall either since the issue is within the emulation runtime. The assertion failure during translation block locking probably indicates a runtime error in QEMU's handling of the invalid address. So the category should be runtime.
</think>
runtime
|