summary refs log tree commit diff stats
path: root/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1416988
blob: c2397bbaaf4829706dc730ee45c1a6e2367828ca (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
The issue arises because the `siginfo` structure size differs between the Linux kernel and QEMU's implementation. This leads to an incorrect handling of signals when running binaries under QEMU that rely on proper signal information, such as during stack unwinding.

To fix this, we need to adjust how `SI_PAD_SIZE` is calculated in QEMU's header file to match the Linux kernel's definition. The correct calculation should account for the preamble size and ensure that the structure padding aligns with what the kernel expects.

Here is the corrected patch:

```diff
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -103,7 +103,8 @@ enum target_si_code {
 #define TARGET_SI_NOINFO	(TARGET_SI_MAX_USER)
 #endif
 
-#define TARGET_SI_PAD_SIZE	((TARGET_SI_MAX_SIZE/sizeof(int)) - 3)
+#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int))
+#define TARGET_SI_PAD_SIZE      ((TARGET_SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int))
 
 #ifndef TARGET_SI_FDSIZE
 #define TARGET_SI_FDSIZE	(TARGET_SI_FBITS/SIZEOF_LONG)
```

This adjustment ensures that the `siginfo` structure within QEMU aligns with the one used by the Linux kernel, resolving the signal handling issues and preventing segmentation faults or infinite loops during stack unwinding operations.

After applying this patch, rebuild QEMU to incorporate these changes.
</think>

The bug report describes an issue related to incorrect signal handling in the QEMU-aarch64 emulator due to a mismatch between the `siginfo` structure sizes used by the Linux kernel and QEMU. Specifically, the size of `struct target_siginfo` in QEMU is larger than that of `struct siginfo` in the kernel, leading to problems such as segmentation faults or infinite loops when running certain applications.

**Category: runtime**

The issue occurs during runtime when handling signals, which is why it falls under the "runtime" category.