diff options
Diffstat (limited to 'results/classifier/deepseek-r1:32b/reasoning/runtime/1346769')
| -rw-r--r-- | results/classifier/deepseek-r1:32b/reasoning/runtime/1346769 | 13 |
1 files changed, 13 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:32b/reasoning/runtime/1346769 b/results/classifier/deepseek-r1:32b/reasoning/runtime/1346769 new file mode 100644 index 00000000..4abde323 --- /dev/null +++ b/results/classifier/deepseek-r1:32b/reasoning/runtime/1346769 @@ -0,0 +1,13 @@ +<think> +Alright, let me try to work through this problem step by step. So, the issue is that when running 32-bit binaries with Address Sanitizer (Asan) under a 64-bit QEMU environment, there's a bug occurring. The user provided some output from running their test program which shows an error in Asan during initialization because it can't find stack boundaries. + +Looking at the provided code snippet, I see that in `linux-user/syscall.c`, specifically in the function `open_self_maps()`, there's conditional compilation for certain targets (like ARM, M68K, UNICORE32). For these targets, the code writes a line to `/proc/self/maps` indicating the stack boundaries. However, for other architectures, like x86_64 or i386, this isn't happening. + +The problem arises because Asan relies on certain entries in `/proc/self/maps` to determine stack boundaries during initialization. If these entries are missing, Asan can't correctly identify where the stack is, leading to errors such as the one seen here. + +So, why is QEMU not including the stack mapping for all architectures? It seems that only specific targets have this code enabled, possibly due to historical reasons or because other architectures were overlooked when implementing this feature. For 32-bit x86 guests running under a 64-bit QEMU, this omission causes issues with tools like Asan. + +The bug is essentially about QEMU not providing the necessary stack information in `/proc/self/maps` for all target architectures, which leads to runtime errors in programs that depend on this information. Therefore, it's a runtime issue because it affects the execution of user-space applications and not just instruction-level issues or system calls themselves. +</think> + +runtime \ No newline at end of file |