diff options
Diffstat (limited to 'results/classifier/no-thinking-deepseek-r1:70b/output/runtime')
202 files changed, 8837 insertions, 0 deletions
diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1010484 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1010484 new file mode 100644 index 00000000..d0df2531 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1010484 @@ -0,0 +1,9 @@ + + + +slirp to accept non-local dns server + +current version of slirp doesn't allow feeded dns address to be outside of given network. +in many scenarios you need to provide dns server that isn't local. + +this simple patch removes checking for if dns server isn't in local subnet. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1027 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1027 new file mode 100644 index 00000000..cad3d64f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1027 @@ -0,0 +1,18 @@ + + + +Executables should have embedded plist on macOS +Description of problem: +QEMU binaries on macOS should have an embedded property list (`plist`). + +The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). + +When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier). + +All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary: + +``` +-sectcreate __TEXT __info_plist YourPlistFile.plist +``` + +This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1034 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1034 new file mode 100644 index 00000000..151e0ef8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1034 @@ -0,0 +1,20 @@ + + + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1041 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1041 new file mode 100644 index 00000000..e12e90d4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1041 @@ -0,0 +1,34 @@ + + + +x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel +Description of problem: +Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`. + +This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless +Steps to reproduce: +1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c) + +``` +#include <stdio.h> +#include <elf.h> + +int main(int argc, char** argv, char* envp[]) { + Elf64_auxv_t *auxv; + while(*envp++ != NULL); + + /*from stack diagram above: *envp = NULL marks end of envp*/ + int i = 0 ; + for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) + /* auxv->a_type = AT_NULL marks the end of auxv */ + { + if( auxv->a_type == AT_PLATFORM) + printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val)); + } +} +``` +2. Run with `qemu-x86_64-static` +3. See `AT_PLATFORM is: i686` +4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64` +Additional information: +I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1044 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1044 new file mode 100644 index 00000000..68394603 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1044 @@ -0,0 +1,4 @@ + + + +Warning: libevent-loop-base.a the table of contents is empty diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1052857 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1052857 new file mode 100644 index 00000000..6cf3a439 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1052857 @@ -0,0 +1,18 @@ + + + +qemu-user compiled static for ppc fails on 64bit hosts + +On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce: + +host$ mkdir powerpc +host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian +host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/ +host$ LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash +I have no name!@guest:/# pwd +/ +I have no name!@guest:/# cd home/ +I have no name!@guest:/home# ls +qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed. + +I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1054812 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1054812 new file mode 100644 index 00000000..8b1d033c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1054812 @@ -0,0 +1,8 @@ + + + +Configure uses wrong libtool on Darwin + +On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. + +This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1059 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1059 new file mode 100644 index 00000000..e8a07378 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1059 @@ -0,0 +1,13 @@ + + + +qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Description of problem: +When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Steps to reproduce: +1. https://botfront.io/docs/installation/local-machine install in local machine +2. run bot front run +3. Go to the docker dashboard and open the botfront-rasa. +4.  +Additional information: +Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1068900 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1068900 new file mode 100644 index 00000000..8c4f0457 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1068900 @@ -0,0 +1,8 @@ + + + +Thread cancellation broken in app-level emulation + +Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. + +The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1070 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1070 new file mode 100644 index 00000000..7f24dfa9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1070 @@ -0,0 +1,13 @@ + + + +gdbstub XML generation for ARM is done for every CPU +Description of problem: +- As arm_cpu_register_gdb_regs_for_features is called from the device + realize stage for each vCPU in user mode we end up uselessly + regenerating the XML for every new thread. Once you get up to 100 + threads this starts exceeding the large maps done for QHT and PageDesc +Steps to reproduce: +See above command line, valgrind picks it up +Additional information: +See also #866, #967 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1075 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1075 new file mode 100644 index 00000000..1c45079a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1075 @@ -0,0 +1,19 @@ + + + +Unable to create a cluster using ppc64le specific kind binary on x86 host architecture +Description of problem: + +Steps to reproduce: +1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le +3. chmod u+x kind-linux-ppc64le +4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl +5. chmod +x kubectl +6. sudo cp kubectl /usr/local/bin/ +7. KUBECONFIG="${HOME}/kind-test-config" +8. export KUBECONFIG +9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain +10. ./kind-linux-ppc64le export logs +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1093 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1093 new file mode 100644 index 00000000..a8de95a8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1093 @@ -0,0 +1,36 @@ + + + +RISC-V: signal frame is misaligned in signal handlers +Description of problem: +`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan. +Steps to reproduce: +1. Create a C file with the following contents: +```c +#include <signal.h> +#include <stdio.h> + +void handler(int sig, siginfo_t *info, void *context) { + printf("signal occurred, info: %p, context: %p\n", info, context); +} + +int main() { + struct sigaction act; + act.sa_flags = SA_SIGINFO; + act.sa_sigaction = handler; + sigaction(SIGINT, &act, NULL); + + // Deliberately misalign the stack + asm volatile ("addi sp, sp, -4"); + + while(1); + // Unreachable +} +``` +2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`. +3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned: +``` +signal occurred, info: 0x400080025c, context: 0x40008002dc +``` +Additional information: +This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1098729 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1098729 new file mode 100644 index 00000000..4bae42db --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1098729 @@ -0,0 +1,46 @@ + + + +qemu-user-static for armhf: segfault in threaded code + + +Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian. + +The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot. + +Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs. + +As an example, I've grabbed the threads demo program here: + + https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c + +and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest): + + gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex + +When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever. + +However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output: + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + Thread 0 did 0 to 100000: mysum=100000.000000 global sum=200000.000000 + TCG temporary leak before f6731ca0 + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371: + tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed. + + + (armhf) $ ./dotprod_mutex + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault + + (armhf) $ ./dotprod_mutex + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519: + tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed. + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1102 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1102 new file mode 100644 index 00000000..7399874b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1102 @@ -0,0 +1,41 @@ + + + +qemu-user: zero_bss might raise segfault when segment is not writable +Description of problem: +When a PT_LOAD segment with the following attributes presented in the user program, +* MemSiz > FileSiz +* NOT Writable + +qemu-aarch64 will crash with segment fault running it. + + + + +in [linux-user/elfload.c: bss_zero](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2097), the exceeded part is zero'ed without checking if it is writable +``` + if (host_start < host_map_start) { + memset((void *)host_start, 0, host_map_start - host_start); + } +``` +Steps to reproduce: +1. ./qemu-aarch64 ./X.so +Additional information: +readelf output of X.so +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x0000000000000230 0x0000000000000230 R E 0x8 + LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000110270 0x00000000001c94e0 R E 0x10000 + LOAD 0x0000000000129bd0 0x00000000001d9bd0 0x00000000001d9bd0 0x0000000000000438 0x00000000000004c0 RW 0x10000 + LOAD 0x000000000013a008 0x00000000001ea008 0x00000000001ea008 0x0000000000017bd0 0x0000000000017bd0 RW 0x10000 + LOAD 0x0000000000161bd8 0x0000000000211bd8 0x0000000000211bd8 0x000000000000f740 0x000000000000f740 RW 0x10000 + DYNAMIC 0x0000000000161e60 0x0000000000211e60 0x0000000000211e60 0x00000000000001e0 0x00000000000001e0 RW 0x8 + INTERP 0x0000000000089410 0x0000000000089410 0x0000000000089410 0x0000000000000015 0x0000000000000015 R 0x1 + [Requesting program interpreter: /system/bin/linker64] + NOTE 0x000000000013dbc8 0x00000000001edbc8 0x00000000001edbc8 0x0000000000000011 0x0000000000000011 R 0x1 + GNU_EH_FRAME 0x00000000001c86a4 0x00000000001c86a4 0x00000000001c86a4 0x00000000000002dc 0x00000000000002dc R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 +``` + +X.so: https://drive.google.com/file/d/1A7mkWRcK2BKkpeevt8T6FVLg-t6mWdgi/view?usp=sharing diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1143 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1143 new file mode 100644 index 00000000..12f8fe91 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1143 @@ -0,0 +1,81 @@ + + + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1147 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1147 new file mode 100644 index 00000000..b4e7fe14 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1147 @@ -0,0 +1,12 @@ + + + +x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu) +Description of problem: +Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.` + +No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above. + +Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi. + +These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit). diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1165383 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1165383 new file mode 100644 index 00000000..8571e394 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1165383 @@ -0,0 +1,6 @@ + + + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1172613 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1172613 new file mode 100644 index 00000000..fb402641 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1172613 @@ -0,0 +1,66 @@ + + + +[qemu 1.4.1] inconsistent behavior on different architecture + +Running with qemu 1.4.1 and eglibc 2.17 on Debian Linux 7.0 for amd64 + +---------------- armhf ---------------- +$ arm-linux-gnueabihf-gcc hello.c +$ qemu-arm ./a.out +/lib/ld-linux-armhf.so.3: No such file or directory + +$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so ./a.out +./a.out: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory + +$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so --library-path arm-linux-gnueabihf/lib ./a.out +Hello, world ! + +---------------- powerpc64 ---------------- +$ powerpc64-linux-gcc hello.c + +$ qemu-ppc64 ./a.out +/lib64/ld64.so.1: No such file or directory + +[BAD BEHAVIOR !!!] +$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so ./a.out +Invalid data memory access: 0x00000041988fd008 +NIP 000000400001cb2c LR 000000400001cc30 CTR 0000000000000000 XER 0000000000000000 +MSR 8000000002006000 HID0 0000000060000000 HF 8000000002006000 idx 0 +TB 00000000 00000000 +GPR00 0000000000000000 000000400083a220 0000004000041230 00000043309bd010 +GPR04 0000004000026f12 000000000000000b 000000000000002e 000000000000002e +GPR08 0000000000000030 000000008803fffc 00000041988fcff4 0000000000000037 +GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +GPR16 0000000000000000 000000400003a4d8 000000400083a6d0 000000400083a6d8 +GPR20 000000400003a898 000000000000000a 0000000000000000 00000043309bd010 +GPR24 0000004000037b60 00000000cfe8ced7 000000400003a430 0000000010000261 +GPR28 00000001980bfff4 0000000000000000 000000004401ffff 000000002200ffff +CR 22242224 [ E E E G E E E G ] RES ffffffffffffffff +FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +FPSCR 0000000000000000 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so --library-path powerpc64-linux/lib64 ./a.out +Hello, world ! + +---------------- sparc64 ---------------- +$ sparc64-linux-gcc hello.c + +$ qemu-sparc64 ./a.out +/lib64/ld-linux.so.2: No such file or directory + +[BAD BEHAVIOR !!!] +$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so ./a.out +Segmentation fault + +$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so --library-path sparc64-linux/lib64 ./a.out +Hello, world ! \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1182490 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1182490 new file mode 100644 index 00000000..2fb9375e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1182490 @@ -0,0 +1,79 @@ + + + +[qemu-1.5] coroutine-win32.c broken on NULL pointer + +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 4340.0x163c] +qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 +(gdb) bt +#0 qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, + from_=0x3ba1c80) at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 +#1 coroutine_trampoline (co_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:58 +#2 0x0000000077098fed in ?? () +#3 0x0000000000000000 in ?? () +(gdb) +(gdb) info registers +rax 0x0 0 +rbx 0x3ba1c80 62528640 +rcx 0x0 0 +rdx 0x0 0 +rsi 0x770b28d0 1997220048 +rdi 0x3ba1b38 62528312 +rbp 0x0 0x0 +rsp 0xc0bff60 0xc0bff60 +r8 0x3184c0 3245248 +r9 0x43e31a 4449050 +r10 0x0 0 +r11 0x206 518 +r12 0x0 0 +r13 0x0 0 +r14 0x0 0 +r15 0x0 0 +rip 0x43e2cd 0x43e2cd <coroutine_trampoline+61> +eflags 0x10206 [ PF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +(gdb) disassemble +Dump of assembler code for function coroutine_trampoline: + 0x000000000043e290 <+0>: push %rdi + 0x000000000043e291 <+1>: push %rsi + 0x000000000043e292 <+2>: push %rbx + 0x000000000043e293 <+3>: sub $0x30,%rsp + 0x000000000043e297 <+7>: mov %rcx,%rbx + 0x000000000043e29a <+10>: lea 0x26dc1f(%rip),%rcx # +0x6abec0 <__emutls_v.current> + 0x000000000043e2a1 <+17>: mov 0x6868dd68(%rip),%rax # 0x68acc010 + 0x000000000043e2a8 <+24>: mov %rax,0x28(%rsp) + 0x000000000043e2ad <+29>: xor %eax,%eax + 0x000000000043e2af <+31>: callq 0x695808 <__emutls_get_address> + 0x000000000043e2b4 <+36>: mov 0x9090d9(%rip),%rsi # +0xd47394 <__imp_SwitchToFiber> + 0x000000000043e2bb <+43>: mov %rax,%rdi + 0x000000000043e2be <+46>: xchg %ax,%ax + 0x000000000043e2c0 <+48>: mov 0x8(%rbx),%rcx + 0x000000000043e2c4 <+52>: callq *(%rbx) + 0x000000000043e2c6 <+54>: mov 0x10(%rbx),%rdx + 0x000000000043e2ca <+58>: mov %rdx,(%rdi) +=> 0x000000000043e2cd <+61>: movl $0x2,0x38(%rdx) + 0x000000000043e2d4 <+68>: mov 0x30(%rdx),%rcx + 0x000000000043e2d8 <+72>: callq *%rsi + 0x000000000043e2da <+74>: jmp 0x43e2c0 <coroutine_trampoline+48> +End of assembler dump. +(gdb) + + +From: + +qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80) + at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47 + +We can see qemu_coroutine_switch was call with to_=NULL, then crashed at line 47: + +to->action = action; \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1187319 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1187319 new file mode 100644 index 00000000..7216dc4d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1187319 @@ -0,0 +1,11 @@ + + + +Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL + +The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect. + +I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either. + +Keyboard layout: US int with AltGr dead keys +version: 1.5.0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1207896 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1207896 new file mode 100644 index 00000000..03d4dc72 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1207896 @@ -0,0 +1,6 @@ + + + +binfmt wrapper for argv[0] handling + +Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1209 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1209 new file mode 100644 index 00000000..c7792870 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1209 @@ -0,0 +1,8 @@ + + + +Optionally do not clear the screen when starting a VM +Additional information: +``` +QEMU emulator version 6.2.0 (qemu-6.2.0-14.fc36) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/121 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/121 new file mode 100644 index 00000000..74768dcb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/121 @@ -0,0 +1,4 @@ + + + +multiprocess program gets incorrect results with qemu arm-linux-user diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1211 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1211 new file mode 100644 index 00000000..496c499a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1211 @@ -0,0 +1,10 @@ + + + +Bad fonts in "cirrus" VGA card. +Description of problem: +Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file. +Steps to reproduce: +Similar to #988. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1228 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1228 new file mode 100644 index 00000000..e3d920fa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1228 @@ -0,0 +1,46 @@ + + + +-display curses only recognizes escape characters if pressed very quickly +Description of problem: +The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work. + +I have tried all the ones from here: +https://www.qemu.org/docs/master/system/keys.html +https://www.qemu.org/docs/master/system/mux-chardev.html + +When using the graphical display, the escape characters works as expected but when using -display curses, they do not. +Steps to reproduce: +1. Start qemu with the command provided +2. Try to exit using ctrl + x a - Not working +3. Try to exit using alt + 2 - Not working + +The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. + +I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE). +Additional information: +Linux 0.01 build: +https://github.com/mariuz/linux-0.01 + +**Tests using showkey** + +Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine +``` +^[2 27 0033 0x1b + 50 0062 0x32 +``` + +Option + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +@ 64 0100 0x40 +``` + +Esc + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +^[ 27 0033 0x1b +2 50 0062 0x32 +``` + +**Update** + +It seems to work if I press ESC + 2 at exactly the same time. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1245703 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1245703 new file mode 100644 index 00000000..29fde687 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1245703 @@ -0,0 +1,12 @@ + + + +LD_PREFIX option reads directories recursively in an endless loop + +If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel. + +According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop. + +The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. + +Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1248168 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1248168 new file mode 100644 index 00000000..06b56a32 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1248168 @@ -0,0 +1,27 @@ + + + +MIPS, self-modifying code and uncached memory + +Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. + +For example, when running this code I get unexpected behavior: + + 0: e3000010 b 0x390 + 4: 00000000 nop + ... + 380: 00701f40 mfc0 ra,c0_epc + 384: 0400e0bb swr zero,4(ra) + 388: 18000042 eret + 38c: 00000000 nop + 390: 25500000 move t2,zero + 394: 02000b34 li t3,0x2 + 398: 23504b01 subu t2,t2,t3 + 39c: e9003c0b j 0xcf003a4 + 3a0: 0a004a21 addi t2,t2,10 + 3a4: ffff0010 b 0x3a4 + 3a8: 00000000 nop + 3ac: 00000000 nop + + I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` +This should work because no cache is used for this memory region. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1254828 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1254828 new file mode 100644 index 00000000..b8ef1885 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1254828 @@ -0,0 +1,40 @@ + + + +qemu-sparc64-static: Segmentation Fault during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian Sid (ports) sparc64 + +When attempting the second stage of a debootstrap for a sparc64 Debian Sid guest, a segmentation fault occurs. + +$ sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch sparc64 --foreign --no-check-gpg sid sparc64 http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage +/debootstrap/debootstrap: 22: .: Can't open /usr/share/debootstrap/functions +Segmentation fault (core dumped) + +Running a simple "sudo chroot sparc64" exits silently on amd64, and reports a segfault on i386. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 17:49:34 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1255 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1255 new file mode 100644 index 00000000..bf1cc937 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1255 @@ -0,0 +1,14 @@ + + + +32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory" +Description of problem: +I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory". +Steps to reproduce: +1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz) +2. run "qemu-arm -L ./ systemctl --version" +Additional information: +- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690). +- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error. +- The error still happens when setting vm.mmap_min_addr to 0. +- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1261743 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1261743 new file mode 100644 index 00000000..63b65d98 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1261743 @@ -0,0 +1,8 @@ + + + +trace-backend "simple" doesn't support "disable" property of event + +trace-backend "simple" generates wrong eventid in trace/generated-tracers.c after "disable" property occured in trace-events record. + +Result: missing or mixing logs in trace file. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1285363 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1285363 new file mode 100644 index 00000000..c16a45f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1285363 @@ -0,0 +1,48 @@ + + + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1287195 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1287195 new file mode 100644 index 00000000..c16f930d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1287195 @@ -0,0 +1,6 @@ + + + +validate_guest_space incorrectly enabled on AArch64 + +When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1294898 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1294898 new file mode 100644 index 00000000..ac8e8197 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1294898 @@ -0,0 +1,81 @@ + + + +gtk: menubar visible in fullscreen mode with gtk3 + +Using the gtk UI, compiled with gtk3, the menu bar is fully visible in full screen mode. On gtk2 it's hidden. The set_size_request call isn't abided on gtk3 it seems. + +Simple fix is: + +diff --git a/ui/gtk.c b/ui/gtk.c +index 66e886f..7b3bd3d 100644 +--- a/ui/gtk.c ++++ b/ui/gtk.c +@@ -805,7 +805,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + + if (!s->full_screen) { + gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE); +- gtk_widget_set_size_request(s->menu_bar, 0, 0); ++ gtk_widget_hide(s->menu_bar); + gtk_widget_set_size_request(s->drawing_area, -1, -1); + gtk_window_fullscreen(GTK_WINDOW(s->window)); + if (gd_on_vga(s)) { +@@ -815,7 +815,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + } else { + gtk_window_unfullscreen(GTK_WINDOW(s->window)); + gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s); +- gtk_widget_set_size_request(s->menu_bar, -1, -1); ++ gtk_widget_show(s->menu_bar); + gtk_widget_set_size_request(s->drawing_area, + surface_width(s->ds), + surface_height(s->ds)); + + +The problem with that is that hiding the menu bar means all its associated accelerators are no longer usable, so there's way to exit fullscreen mode. That's kind of a problem :) + +We can install the accelerators on the window, but make sure the menu item still shows the accelerator short cut. Example with the fullscreen accelerator: + +diff --git a/ui/gtk.c b/ui/gtk.c +index 66e886f..fbce2b0 100644 +--- a/ui/gtk.c ++++ b/ui/gtk.c +@@ -799,7 +799,7 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque) + } + } + +-static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) ++static void gd_do_full_screen(void *opaque) + { + GtkDisplayState *s = opaque; + +@@ -828,6 +828,11 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + gd_update_cursor(s, FALSE); + } + ++static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) ++{ ++ gd_do_full_screen(opaque); ++} ++ + static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque) + { + GtkDisplayState *s = opaque; +@@ -1304,10 +1309,11 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s, GtkAccelGroup *accel_g + gtk_menu_set_accel_group(GTK_MENU(view_menu), accel_group); + + s->full_screen_item = gtk_menu_item_new_with_mnemonic(_("_Fullscreen")); +- gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->full_screen_item), +- "<QEMU>/View/Full Screen"); +- gtk_accel_map_add_entry("<QEMU>/View/Full Screen", GDK_KEY_f, +- HOTKEY_MODIFIERS); ++ gtk_accel_group_connect(accel_group, GDK_KEY_f, HOTKEY_MODIFIERS, 0, ++ g_cclosure_new_swap(G_CALLBACK(gd_do_full_screen), s, NULL)); ++ gtk_accel_label_set_accel( ++ GTK_ACCEL_LABEL(gtk_bin_get_child(GTK_BIN(s->full_screen_item))), ++ GDK_KEY_f, HOTKEY_MODIFIERS); + gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->full_screen_item); + + separator = gtk_separator_menu_item_new(); + + +However gtk_accel_label_set_accel, which shows the accel key sequence in the menu, is gtk 3.8+ :/ So older versions wouldn't have any visual indication of the shortcuts. Maybe that's not a problem, SDL didn't have any indication of shortcuts either. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1311614 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1311614 new file mode 100644 index 00000000..35739fc7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1311614 @@ -0,0 +1,50 @@ + + + +qemu-arm segfaults with gcc 4.9.0 + +I have an ARM chroot that working with qemu-arm emulation + +[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm +enabled +interpreter /usr/bin/qemu-arm-binfmt +flags: P +offset 0 +magic 7f454c4601010100000000000000000002002800 +mask ffffffffffffff00fffffffffffffffffeffffff + + +In chroot installed gcc dependencies with 4.9.0 version + +sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0 + +libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl +libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl + + +When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message + + +example: + +[root@filzbach /]# uname -a +Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux + +[root@filzbach /]# rpm +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0. + +When i downgrade it to 4.8.3 all working fine again. +It looks like a qemu bug with gcc. + + +P.S. +I tried to rebuild qemu with gcc 4.9.0 +I tried to build qemu from git sources, from fedora sources, from suse sources etc. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1319100 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1319100 new file mode 100644 index 00000000..65028a4f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1319100 @@ -0,0 +1,72 @@ + + + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +running mono in a chroot environment with qemu-user-static is not posible +because at least one signal used during termination of mono is routed to the +host. + +This can be reproduced by: +debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/usr/bin +mount -t proc none mono-test/proc +mount -o bind /dev mono-test/dev +mount -o bind /sys mono-test/sys +chroot mono-test +../debootstrap/debootstrap --second-stage +exit +mount -t proc none mono-test/proc +mount -o bind /sys mono-test/sys +chroot mono-test +QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--8<-- + +If you use mono within strace on a native x86 box you can see, that signals +between threads are used during termination: + +strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +--8<-- +14075 sched_yield() = 0 +14075 tgkill(14075, 14083, SIGPWR) = 0 +14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> +14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) +14083 --- SIGPWR (Power failure) @ 0 (0) --- +14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1 +14075 <... futex resumed> ) = 0 +14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...> +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--8<-- + +This also blocks the installation of libnunit2.6-cil within a armel chroot, +because it uses mono in its postinst script. +E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch also applies against qemu from backports-wheezy and resolves this +issue. + +As it seems, that this issue is not Debian specific i will also report it to +the qemu project and reference this bug report. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1346784 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1346784 new file mode 100644 index 00000000..2395c80f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1346784 @@ -0,0 +1,70 @@ + + + +qemu internal memory areas visible to a guest via /proc/self/maps + + +Qemu internal memory areas are not suppressed in the output and are visible to a guest via /proc/self/maps. + +$ echo "int main() { return 0; }" > /tmp/test.c +$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c +$ qemu-i386-static -R 0 /tmp/test + +We use -R option because the binary can't be executed under stock version of Qemu with address sanitizer instrumentations (Asan). + +Qemu memory map looks the following way where GUEST valid addresses are marked with ***** and invalid with @@@: + +***** 08048000-08049000 r-xp 00000000 08:01 28835889 /tmp/test +***** 08049000-0804a000 rw-p 00000000 08:01 28835889 /tmp/test +***** 1ffff000-24000000 rw-p 00000000 00:00 0 +***** 24000000-28000000 ---p 00000000 00:00 0 +***** 28000000-40000000 rw-p 00000000 00:00 0 +***** 40000000-40001000 ---p 00000000 00:00 0 +***** 40001000-40801000 rw-p 00000000 00:00 0 [stack] +***** 40801000-40821000 r-xp 00000000 08:01 26738694 /lib32/ld-2.19.so +***** 40821000-40822000 r--p 0001f000 08:01 26738694 /lib32/ld-2.19.so +***** 40822000-40823000 rw-p 00020000 08:01 26738694 /lib32/ld-2.19.so +***** 40823000-40827000 rw-p 00000000 00:00 0 +***** 40827000-408ca000 r-xp 00000000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408ca000-408cc000 rw-p 000a3000 08:01 49424994 /home/michail/build/lib32/libasan.so.1.0.0 +***** 408cc000-40d24000 rw-p 00000000 00:00 0 +***** 40d3c000-40ee2000 r-xp 00000000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee2000-40ee4000 r--p 001a6000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee4000-40ee5000 rw-p 001a8000 08:01 26738695 /lib32/libc-2.19.so +***** 40ee5000-40ee8000 rw-p 00000000 00:00 0 +***** 40ee8000-40f00000 r-xp 00000000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f00000-40f01000 r--p 00017000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f01000-40f02000 rw-p 00018000 08:01 26738711 /lib32/libpthread-2.19.so +***** 40f02000-40f04000 rw-p 00000000 00:00 0 +***** 40f04000-40f07000 r-xp 00000000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f07000-40f08000 r--p 00002000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f08000-40f09000 rw-p 00003000 08:01 26738708 /lib32/libdl-2.19.so +***** 40f09000-40fee000 r-xp 00000000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40fee000-40ff2000 r--p 000e5000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff2000-40ff3000 rw-p 000e9000 08:01 49424965 /home/michail/build/lib32/libstdc++.so.6.0.20 +***** 40ff3000-40ffa000 rw-p 00000000 00:00 0 +***** 40ffa000-4103e000 r-xp 00000000 08:01 26738698 /lib32/libm-2.19.so +***** 4103e000-4103f000 r--p 00043000 08:01 26738698 /lib32/libm-2.19.so +***** 4103f000-41040000 rw-p 00044000 08:01 26738698 /lib32/libm-2.19.so +***** 41040000-41041000 rw-p 00000000 00:00 0 +***** 41041000-4105b000 r-xp 00000000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105b000-4105c000 rw-p 00019000 08:01 49424637 /home/michail/build/lib32/libgcc_s.so.1 +***** 4105c000-4105e000 rw-p 00000000 00:00 0 +***** 4105f000-41061000 rw-p 00000000 00:00 0 +***** 41065000-421ed000 rw-p 00000000 00:00 0 +***** 421ee000-421f1000 rw-p 00000000 00:00 0 +***** 60000000-6033b000 r-xp 00000000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 6053b000-60546000 rw-p 0033b000 08:01 48760980 /home/michail/build/bin/qemu-i386-static +***** 60546000-6059a000 rw-p 00000000 00:00 0 +***** 6059a000-6259b000 rwxp 00000000 00:00 0 +***** 6259b000-625ae000 rw-p 00000000 00:00 0 +***** 62dce000-62e12000 rw-p 00000000 00:00 0 [heap] +@@@ 7f3f5e6a9000 - 7f3f61f28000 rw-p 00000000 00:00 0 +@@@ 7fffad130000 - 7fffad132000 r-xp 00000000 00:00 0 [vdso] +@@@ ffffffffff600000 - ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + +qemu-i386-static and its heap are in ranges which are valid and be reported to guest in case of maps file reading. + +The issue is related to early reported bugs: +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html +http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357206 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357206 new file mode 100644 index 00000000..d9675457 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357206 @@ -0,0 +1,62 @@ + + + +QEMU user mode still crashes in multi-thread code. + +I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode. + +I did a little search and found LP:668799 but it is far from now and it is probably not the problem here. + +I used program below as the test program: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> + +void *print_message_function( void *ptr ); + +main() +{ + pthread_t thread1, thread2; + const char *message1 = "Thread 1"; + const char *message2 = "Thread 2"; + int iret1, iret2; + + /* Create independent threads each of which will execute function */ + + iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1); + if(iret1) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1); + exit(EXIT_FAILURE); + } + + iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2); + if(iret2) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2); + exit(EXIT_FAILURE); + } + + printf("pthread_create() for thread 1 returns: %d\n",iret1); + printf("pthread_create() for thread 2 returns: %d\n",iret2); + + /* Wait till threads are complete before main continues. Unless we */ + /* wait we run the risk of executing an exit which will terminate */ + /* the process and all threads before the threads have completed. */ + + pthread_join( thread1, NULL); + pthread_join( thread2, NULL); + + exit(EXIT_SUCCESS); +} + +void *print_message_function( void *ptr ) +{ + char *message; + message = (char *) ptr; + printf("%s \n", message); +} + +Compiled to i386 and aarch64 object, +and both qemu-i386 and qemu-aarch64 had segmentation faults. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357226 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357226 new file mode 100644 index 00000000..be6c99f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1357226 @@ -0,0 +1,14 @@ + + + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +steps to reproduce: +pbuilder-dist utopic armhf create +pbuilder-dist utopic armhf login +apt-get install imagemagick +convert foo.xpm foo.png +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +(doesn't matter if images are actually there or not) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1362635 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1362635 new file mode 100644 index 00000000..9536b6de --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1362635 @@ -0,0 +1,45 @@ + + + +bdrv_read co-routine re-entered recursively + +calling bdrv_read in a loop leads to the follwing situation: + +bs->drv->bdrv_aio_readv is called, and finally calls bdrv_co_io_em_complete in other thread context. +there is a possibility of calling bdrv_co_io_em_complete before calling qemu_coroutine_yield in bdrv_co_io_em. And qemu fails with "co-routine re-entered recursively". + +static void bdrv_co_io_em_complete(void *opaque, int ret) +{ + CoroutineIOCompletion *co = opaque; + + co->ret = ret; + qemu_coroutine_enter(co->coroutine, NULL); +} + +static int coroutine_fn bdrv_co_io_em(BlockDriverState *bs, int64_t sector_num, + int nb_sectors, QEMUIOVector *iov, + bool is_write) +{ + CoroutineIOCompletion co = { + .coroutine = qemu_coroutine_self(), + }; + BlockDriverAIOCB *acb; + + if (is_write) { + acb = bs->drv->bdrv_aio_writev(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } else { + acb = bs->drv->bdrv_aio_readv(bs, sector_num, iov, nb_sectors, + bdrv_co_io_em_complete, &co); + } + + trace_bdrv_co_io_em(bs, sector_num, nb_sectors, is_write, acb); + if (!acb) { + return -EIO; + } + qemu_coroutine_yield(); + + return co.ret; +} + +is it a bug, or may be I don't understand something? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1388 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1388 new file mode 100644 index 00000000..ef331b07 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1388 @@ -0,0 +1,17 @@ + + + +QEMU 7.2.0 - Update file repository with x86/x64 Windows installer +Description of problem: +In file repository + +https://qemu.weilnetz.de/w32/ +https://qemu.weilnetz.de/w64/ + +are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0. + +The latest version is 7.2.0.RC4 (08.12.2022). + +Thanks. +Steps to reproduce: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1429313 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1429313 new file mode 100644 index 00000000..8313542a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1429313 @@ -0,0 +1,12 @@ + + + +qemu-user doesn't block target signals on entry to signal hanlder. + +Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. + +The attached test case my be run as: + +$ (sleep 2 ; echo) | qemu-i386 ./a.out +.................. Recursion in signal handler! +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1435 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1435 new file mode 100644 index 00000000..b7aa2928 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1435 @@ -0,0 +1,19 @@ + + + +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1478 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1478 new file mode 100644 index 00000000..bdd8513e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1478 @@ -0,0 +1,69 @@ + + + +Qemu 7.2.0 i386: core2: init crash (glibc) +Description of problem: +The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for x86-core2--glibc--bleeding-edge toolchain, see: + +https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337 + +Reverting back to Qemu 7.1.0, the system boot correctly with the same system image. +I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a) + +Here is the boot log obtained with Qemu 7.2.0: + ``` +Run /sbin/init as init process +random: fast init done +EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended +EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled. +Starting syslogd: OK +traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000] +Starting klogd: OK +traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000] +Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000] +Segmentation fault +traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000] +Segmentation fault + +traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000] +Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b +CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014 +Call Trace: + dump_stack_lvl+0x32/0x41 + dump_stack+0xd/0x10 + panic+0x90/0x206 + do_exit.cold+0xa9/0xa9 + do_group_exit+0x2a/0x90 + get_signal+0x115/0x7e0 + arch_do_signal_or_restart+0x90/0x5a0 + ? put_pid+0xc/0x20 + ? kernel_clone+0x10b/0x3d0 + exit_to_user_mode_prepare+0xf8/0x1c0 + syscall_exit_to_user_mode+0x1b/0x40 + do_int80_syscall_32+0x41/0x90 + entry_INT80_32+0xf0/0xf0 +EIP: 0xb7de5d88 +Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e +EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008 +ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20 +DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246 +Kernel Offset: disabled +---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- + ``` +I did a git bisect on qemu sources up to this commit: + +https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44 +Steps to reproduce: +Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually +1. git clone https://gitlab.com/buildroot.org/buildroot.git +2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470 +3. make qemu_x86_defconfig +4. make menuconfig (enable BR2_x86_core2) +5. make +6. ./output/images/start-qemu.sh +Additional information: +System built with gcc options: + ``` +i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro' + ``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1495 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1495 new file mode 100644 index 00000000..705279de --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1495 @@ -0,0 +1,9 @@ + + + +MacOS fails check-unit for test-io-channel-command for some reason +Description of problem: +While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709 +Steps to reproduce: +1. install socat +2. make check-unit diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1512 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1512 new file mode 100644 index 00000000..ff48c090 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1512 @@ -0,0 +1,4 @@ + + + +AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1519037 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1519037 new file mode 100644 index 00000000..73971ba4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1519037 @@ -0,0 +1,10 @@ + + + +qemu-i386 32-bit segfault + +I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? + +In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? + +Thanks! \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1527765 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1527765 new file mode 100644 index 00000000..4fce454c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1527765 @@ -0,0 +1,75 @@ + + + +sh4: ghc randomly segfaults on qemu-sh4-static + +Hello! + +I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source: + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls +Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi + ghc: panic! (the 'impossible' happened) + (GHC version 7.10.3 for sh4-unknown-linux): + getSymtabName:unknown known-key unique +<<details unavailable>> + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Linking Main ... +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# + +As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs. + +I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help). + +> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz + +In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc: + +> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz + +Just extract in the chroot of the sh4 chroot. + +Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186: + +> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 +> https://bugs.launchpad.net/qemu/+bug/1516408 + +The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test. + +Cheers, +Adrian \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528 new file mode 100644 index 00000000..83543fca --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528 @@ -0,0 +1,12 @@ + + + +ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed." +Description of problem: +Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware. +Steps to reproduce: +1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello) +2. Build latest qemu-arm from master +3. Run qemu-arm against hello world binary +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528239 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528239 new file mode 100644 index 00000000..77560ec1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1528239 @@ -0,0 +1,48 @@ + + + +Unable to debug PIE binaries with QEMU gdb stub. + +The issue occurs on current trunk: + +max@max:~/build/qemu$ cat test.c +#include <stdio.h> + +int main() { + printf("Hello, world!\n"); + return 0; +} + +max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x +max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x +............................. + + +max@max:~/build/qemu$ gdb +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 +........................................................................................ +(gdb) file bad.x +Reading symbols from bad.x...(no debugging symbols found)...done. +(gdb) b main +Breakpoint 1 at 0x779 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). + +Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. +done. +Loaded symbols for /lib64/ld-linux-x86-64.so.2 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 +(gdb) c +Continuing. +[Inferior 1 (Remote target) exited normally] +(gdb) + + +max@max:~/build/qemu$ cat config.log +# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' + + +W/O QEMU or -pie flag breakpoint on main works fine. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1531 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1531 new file mode 100644 index 00000000..e6a3bf1f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1531 @@ -0,0 +1,18 @@ + + + +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1533141 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1533141 new file mode 100644 index 00000000..2abc9d08 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1533141 @@ -0,0 +1,18 @@ + + + +qemu/disas/libvixl/vixl/invalset.h: 2 * sanity check after use ? + +1. + +[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. + + while (!IsValid(elements[low]) && (low < high)) ++low; + +2. + +[qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. + + while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; + +Also, binary search is a standard C library routine. Suggest use. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1547 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1547 new file mode 100644 index 00000000..87973015 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1547 @@ -0,0 +1,15 @@ + + + +POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later) +Description of problem: +Comparing two floating point memory operands produces incorrect result +Steps to reproduce: +1. Unpack attached archive and change to test_p64 directory +2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64 +3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt +4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts +Additional information: +The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz) + +The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1568107 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1568107 new file mode 100644 index 00000000..7518d6f0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1568107 @@ -0,0 +1,12 @@ + + + +x86_64 linux-user: setup_rt_frame: not implemented + +Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: + +$ qemu-x86_64 parity --pruning fast + +setup_rt_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1591611 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1591611 new file mode 100644 index 00000000..6d7918b8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1591611 @@ -0,0 +1,26 @@ + + + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1603734 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1603734 new file mode 100644 index 00000000..e542bd20 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1603734 @@ -0,0 +1,10 @@ + + + +Hang in fsqrt + +At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions 2.6.0 and git (2.6.50) for some input values, likely due to an infinite loop at fpu/softfloat.c:6569. + +Steps to reproduce: +1) Compile attached code: gcc -o test test.c -lm +2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1614348 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1614348 new file mode 100644 index 00000000..c9442ce0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1614348 @@ -0,0 +1,42 @@ + + + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1623020 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1623020 new file mode 100644 index 00000000..f33d7ee9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1623020 @@ -0,0 +1,58 @@ + + + +emulate amd64 binary on arm7 host + +I'm trying to run a Go program compiled for amd64 on a Raspberry Pi. Here is an example : + +=== +// main.go +package main + +func main() { + println("hello world") +} +=== + +Then here is the output I'm getting : + +=== +> GOARCH=amd64 go build main.go +> ../qemu/build/x86_64-linux-user/qemu-x86_64 -strace ./main +29213 arch_prctl(4098,4823880,0,0,0,0) = 0 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4622132)bad timediv = 11 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4624923)panic during panic + = 19 +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4627441)stack trace unavailable + = 24 +29213 exit_group(4) +=== + +I'm running the latest qemu (commit 7263da78045dc91cc207f350911efe4259e99b3c), which was compiled with "../configure --target-list=x86_64-linux-user --static". + +The go version is 1.7.1, and the system "Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux". \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1641861 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1641861 new file mode 100644 index 00000000..b1e75a03 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1641861 @@ -0,0 +1,39 @@ + + + +ARM QEMU doesn't enforce that RES0 bits in FPSCR are non-writeable + +Hi all, we systematically tested the QEMU implementation for emulating arm user mode programs. We found that QEMU incorrectly emulate the FPSCR register. The following the proof of code: + +/*********** Beginning of the bug: arm.c **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov r2, %0\n" + "ldr r0, [r2]\n"::"r"((char *)(i0)));; + asm("vmsr fpscr, r0"); + asm("mov r2, %0\n" + "vmrs r4, fpscr\n" + "str r4, [r2]\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} +unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00}; + +/*********** End fo the bug **********/ + +When the program is compiled into arm binary code and running on a real arm machine, and running in qemu, we have the following result + +$ arm-linux-gnueabihf-gcc arm.c -o arm -static +$ ./arm +000000000000000000000000fff7009f +$ qemu-arm arm +000000000000000000000000ffffffff + +According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be reserved as zero. However, arm qemu fails to keep these bits to be zero: these bits can be actually modified in QEMU. + +Thanks! \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1648 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1648 new file mode 100644 index 00000000..e69c4038 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1648 @@ -0,0 +1,61 @@ + + + +linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash +Description of problem: +Corrent Print Result: + +sp: cdd3b4e8 + +SUCCEEDED! + +qemu-x86_64 Print Result: + +sp: 2804170 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Segmentation fault + +Reason of Bug: + +sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) + +For example on x86_64: + +reference to "qemu/linux-user/i386/signal.c" + +``` +# define TARGET_FPSTATE_FXSAVE_OFFSET 0 + +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + struct target_fpstate fpstate QEMU_ALIGNED(16); +}; +#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \ + offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) +``` + +offsetof(struct rt_sigframe, fpstate) align of 16 + +TARGET_FPSTATE_FXSAVE_OFFSET is 0 + +TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 + +so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! + +Fix the bug: + +``` +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + abi_ulong unused QEMU_ALIGNED(16); + struct target_fpstate fpstate; +}; +``` + +offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1654137 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1654137 new file mode 100644 index 00000000..d5672caa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1654137 @@ -0,0 +1,10 @@ + + + +Ctrl-A b not working in 2.8.0 + +With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM. Ctrl-A b is simply ignored. Other Ctrl-A sequences seem to work correctly. + +This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source. + +Reverting to the previous install restores "break" capability. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1659901 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1659901 new file mode 100644 index 00000000..00e73f65 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1659901 @@ -0,0 +1,12 @@ + + + +Regression: SIGSEGV running Java + +I have a build script that bootstraps a Debian armhf image. Part of the process involves running a Java program while inside a chroot. I am using Debian's qemu-user-static package to run the armhf Java binary on an amd64 system. + +qemu-user-static version 1:2.7+dfsg-3~bpo8+2 works fine. Version 1:2.8+dfsg-1~bpo8+1 always causes Java to crash with a SIGSEGV. The location of the crash appears to be random and hasn't been the same twice. + +I am using the Azul Systems Zulu Embedded Java runtime, rather than the regular OpenJDK runtime, because the Zulu runtime has an arm32 JIT whereas OpenJDK is interpreter-only on arm32. + +I can reproduce the problem easily by mounting the image created by my build script and executing "java -XshowSettings -version" in a chroot. I can give you the image if that would help debug the problem. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1661815 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1661815 new file mode 100644 index 00000000..9f7701f6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1661815 @@ -0,0 +1,29 @@ + + + +Stack address is returned from function translate_one + +The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c". + +The code snippet is as following. + +static ExitStatus translate_one(CPUS390XState *env, DisasContext *s) +{ + const DisasInsn *insn; + ExitStatus ret = NO_EXIT; + DisasFields f; + ... + s->fields = &f; + ... + s->pc = s->next_pc; + return ret; +} + +A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect. + +This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations) + +This dangerous defect may lead to an exploitable vulnerability. +We suggest sanitizing "s->fields" as null before return. + +Note that this issue is reported by shqking and Zhenwei Zou together. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1667401 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1667401 new file mode 100644 index 00000000..29692971 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1667401 @@ -0,0 +1,70 @@ + + + +qemu-ppc segfaults(SIGSEGV) on pthread_create + +qemu-ppc running on x86-64 hardware leads to a segfault when running the +attached program (test.c). It simply creates a pthread, joins it and exits. + +It was compiled as follows on a Debian testing system: +> powerpc-linux-gnuspe-gcc-6 -static -Wall -g -o test -pthread test.c + +Sample execution (expected output is "Hello - World!"): +> qemu-ppc -cpu e500 ./test +[...output...] +Hello - qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-ppc: /build/qemu-_M2UL5/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +[1] 25747 segmentation fault qemu-ppc -cpu e500 test +[...end output...] + +The same behavior is observed when running on a PPC 604: + +> powerpc-linux-gnu-gcc -Wall -g -o test -pthread test.c +> qemu-ppc ./test +[... as above ...] + +Version information: +powerpc-linux-gnu-gcc -v => gcc version 6.3.0 20170124 (Debian 6.3.0-5) +qemu-ppc -version => qemu-ppc version 2.8.0(Debian 1:2.8+dfsg-2) + +The same experiment was conducted again using qemu from the git repository (commit: 796b288f7be875045670f963ce99991b3c8e96ac): +~/tools/qemu/build/ppc-linux-user/qemu-ppc -version => qemu-ppc version 2.8.50 (v2.8.0-1417-g796b288f7b-dirty) +[...output...] +Hello - qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-ppc: [...redacted...]/tools/qemu/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +[1] 25996 segmentation fault ~/tools/qemu/build/ppc-linux-user/qemu-ppc -cpu e500 test +[...end output...] + + +Executing with -strace option yields a surprising entry (see second clone() syscall below): +[...] +26007 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = 26009 +26007 clone(0,child_stack=0xf67fde60,parent_tidptr=0xf67fe368,tls=0xf68057d0,child_tidptr=0xf67fe368) = -1 errno=22 (Invalid argument) + + +test.c works just fine if the pthread_create & pthread_join calls are removed +(i.e. when compiled with -DNO_PTHREAD_CREATE). + +At first glance, the issue seems specific to PPC because compiling and running +for x86_64 using qemu-x86_64 works fine. + + +Additional info: +> lddtree =qemu-ppc +qemu-ppc => /usr/bin/qemu-ppc (interpreter => /lib64/ld-linux-x86-64.so.2) + libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 + libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 + ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 + libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 + libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 + librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 + libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 + libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 + libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 + libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 + +> /lib/x86_64-linux-gnu/libc.so.6 +GNU C Library (Debian GLIBC 2.24-9) stable release version 2.24, by Roland McGrath et al. + +> uname -a +Linux [...redacted...] 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1671 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1671 new file mode 100644 index 00000000..12f4d7b2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1671 @@ -0,0 +1,1360 @@ + + + +segfault/errors in gdbstub with linux userspace emulator (qemu-riscv64), from racy behavior with singal handler? +Description of problem: +Often, qemu segfaults, sometimes GDB just spits out a wall of "Ignoring packet error, continuing..." and ~hangs: I don't get a GDB command prompt quickly, if at all, and when I ctrl-c I see "The target is not responding to GDB commands. Stop debugging it? (y or n)". +Steps to reproduce: +1. Run the `testb3` binary from below as described +2. Connect via GDB and `continue` +3. Multiple threads (independently) SIGABRT themselves when they fail their test(s), which happens quickly on my machine (which has 16 physical cores) +Additional information: +From the coredump, it looks like there's a lot of cooks in the gdbstub kitchen: + +``` + Id Target Id Frame +* 1 Thread 0x7febc02ef6c0 (LWP 3922802) gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 + 2 Thread 0x7febc06db6c0 (LWP 3922792) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 3 Thread 0x7febc03b26c0 (LWP 3922799) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 4 Thread 0x7febc0f5d6c0 (LWP 3922751) 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 + 5 Thread 0x7febc0f5ebc0 (LWP 3922750) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 6 Thread 0x7febc01696c0 (LWP 3922808) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 7 Thread 0x7febc04f76c0 (LWP 3922794) 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 + 8 Thread 0x7febc026d6c0 (LWP 3922804) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 9 Thread 0x7febc01aa6c0 (LWP 3922807) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 10 Thread 0x7febc075c6c0 (LWP 3922793) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 11 Thread 0x7febc04756c0 (LWP 3922796) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 12 Thread 0x7febc01eb6c0 (LWP 3922806) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 13 Thread 0x7febc022c6c0 (LWP 3922805) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 14 Thread 0x7febc03f36c0 (LWP 3922798) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 15 Thread 0x7febc04346c0 (LWP 3922797) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 16 Thread 0x7febc03716c0 (LWP 3922800) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 17 Thread 0x7febc04b66c0 (LWP 3922795) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 18 Thread 0x7febc02ae6c0 (LWP 3922803) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 19 Thread 0x7febc03306c0 (LWP 3922801) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +``` + +Each of those `read` and `send` threads look something similar to this one: + +``` +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +``` + +Which, at a guess, seems like there's maybe 20 different concurrent processes fighting over the singular [gdbstub state](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L57)? Specifically, they're all stomping on each other by writing to the same [buffer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/user.c#L136) and advancing the [current CPU list pointer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L1422), which causes the "bad packet" cross-talk and the segfault respectively. + +<details><summary>full backtrace</summary> + +``` +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +(gdb) thread apply all bt + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +``` + +</details> + + + +- coredump + - [core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst](/uploads/071fc96520ca4008941044802c176d6a/core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst) + - [qemu-riscv64](/uploads/f203d5aed8559d80c2d66e439bb4dddf/qemu-riscv64) (the binary the coredump was generated from) + - download both, extract corefile, use `DEBUGINFOD_URLS=https://debuginfod.archlinux.org gdb /path/to/qemu-riscv64 -c /tmp/coredump` to debug +- reproducer + - [testb3.tar.xz](/uploads/84bdbb547e01527c3d804e0d88c6c9fe/testb3.tar.xz) (includes testb3 + sysroot to work with command line above) + - This binary is a cross-compiled `testb3` from [WebKit](https://github.com/WebKit/WebKit/blob/9755847ab1d40841374b2467b3036d943b723183/Source/JavaScriptCore/b3/testb3_1.cpp#L927) ; sorry, that's about all I know about it so far + - A GDB you might use to connect is [SiFive's](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14.tar.gz). I got more consistent segfaults with a more recent gdb (12.1), but I'm not sure how to tell you how to get that `gdb` besides "creating a riscv64 poky distribution" (what I did), which is likely not helpful. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1697 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1697 new file mode 100644 index 00000000..eb55b093 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1697 @@ -0,0 +1,22 @@ + + + +qemu-arm -cpu cortex-m55 dummy_test qemu-arm: ../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed. +Description of problem: +Basic testing failed for cortex m55 +Steps to reproduce: +1.Pulled the newest qemu 8.0.50 + +2.Create a Dummy test with only return 0 in main function + +3.run ` arm-none-eabi-gcc -o dummy_test -O2 -g -mcpu=cortex-m55 dummy_test.cc --specs=rdimon.specs` and then `qemu-arm -cpu cortex-m55 dummy_test` + +`arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.` + +`qemu-arm version 8.0.50 (v8.0.0-1739-g5f9dd6a8ce) +Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers` +Additional information: +It is a known problem in another issues: https://gitlab.com/qemu-project/qemu/-/issues/1528#note_1389268261. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1704638 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1704638 new file mode 100644 index 00000000..97f7a9eb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1704638 @@ -0,0 +1,68 @@ + + + +weak symbol access makes qemu in user mode hang for mips, mips64 + +A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL). + +With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9". + +How to reproduce for mips: +- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread +- Set environment variables for running qemu-mips. +- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips + +How to reproduce for mips64: +- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread +- Set environment variables for running qemu-mips64. +- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64 + +When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code': + +$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726 +... +Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done. +Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726 +... +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 2 Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +(gdb) where +#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) + at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60 +#3 0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167 +#4 cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350 +#5 0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124 +#6 cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229 +#7 0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646 +#8 <signal handler called> +#9 __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47 +#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21 +#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434 +#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68 +#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58) + at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962 +#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, + cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295 +#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365 +#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673 +#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236 +#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860 +(gdb) thread 2 +[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))] +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden. +(gdb) where +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333 +#5 0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1715162 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1715162 new file mode 100644 index 00000000..9dbb3446 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1715162 @@ -0,0 +1,75 @@ + + + +qemu-user crashing when writing core dump + +I've a binary I'm running in qemux86-64 but it is segfaulting. Whilst qemu writes the core dump for that, qemu itself is segfaulting. + +(gdb) bt full +#0 0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6 +No symbol table info available. +#1 0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598 + cpu = <optimized out> + env = <optimized out> + ts = 0x55917a42d160 + core_dumped = <optimized out> + act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647, + 18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010} +#2 0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11, + k=k@entry=0x55917a42d190) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596 + handler = <optimized out> + set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104, + 94083255852784, 94083309703424, 3351315493}} + target_old_set = {sig = {0}} + sa = <optimized out> + ts = 0x55917a42d160 +#3 0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674 + sig = 11 + ts = 0x55917a42d160 + set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}} + blocked_set = <optimized out> +#4 0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369 + trapnr = 14 + pc = <optimized out> + ret = <optimized out> + info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509, + 842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0, + 12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877}, + _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = { + _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}}, + _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792}, + _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}} +#5 0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862 + regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0, + rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0, + rsp = 274888401360, ss = 0} + regs = 0x7ffda5b29fc0 + info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944, + end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0, + brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576, + entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256, + auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408, + arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0, + personality = 0} + info = 0x7ffda5b2a070 + bprm = { + buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3, + e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0, + filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>} + ts = <optimized out> + env = 0x55917a41c2a0 + cpu = 0x55917a414010 + target_environ = 0x55917a42a8f0 + wrk = 0x55917a42ac30 + target_argv = 0x55917a42d120 + target_argc = 5 + i = <optimized out> + ret = <optimized out> + execfd = <optimized out> + +(I'll reproduce this with glibc debug symbols shortly) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1724485 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1724485 new file mode 100644 index 00000000..6c668c40 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1724485 @@ -0,0 +1,21 @@ + + + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1735384 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1735384 new file mode 100644 index 00000000..69d4ee82 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1735384 @@ -0,0 +1,23 @@ + + + +OpenJDK JVM segfaults on qemu-sh4 (regression) + +Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: + +(sid-sh4-sbuild)root@nofan:/# java -version +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/# + +An older version works fine: + +(sid-sh4-sbuild)root@nofan:/# java -version +openjdk version "9.0.1" +OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + +Haven't had time for bisecting this yet. + +Adrian \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1736 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1736 new file mode 100644 index 00000000..4b20e244 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1736 @@ -0,0 +1,70 @@ + + + +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1737444 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1737444 new file mode 100644 index 00000000..dd7ef2fd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1737444 @@ -0,0 +1,96 @@ + + + +gccgo setcontext conftest crashes qemu-sh4 + +While testing gccgo on sh4 to add SH platform definitions to libgo, I discovered that the following conftest program which is part of the libgo configure script crashes on qemu-sh4: + +(sid-sh4-sbuild)root@z6:/# cat setcontext.c +#include <pthread.h> +#include <stdlib.h> +#include <ucontext.h> +#include <unistd.h> + +__thread int tls; + +static char stack[10 * 1024 * 1024]; +static ucontext_t c; + +/* Called via makecontext/setcontext. */ + +static void +cfn (void) +{ + exit (tls); +} + +/* Called via pthread_create. */ + +static void * +tfn (void *dummy) +{ + /* The thread should still see this value after calling + setcontext. */ + tls = 0; + + setcontext (&c); + + /* The call to setcontext should not return. */ + abort (); +} + +int +main () +{ + pthread_t tid; + + /* The thread should not see this value. */ + tls = 1; + + if (getcontext (&c) < 0) + abort (); + + c.uc_stack.ss_sp = stack; +#ifdef MAKECONTEXT_STACK_TOP + c.uc_stack.ss_sp += sizeof stack; +#endif + c.uc_stack.ss_flags = 0; + c.uc_stack.ss_size = sizeof stack; + c.uc_link = NULL; + makecontext (&c, cfn, 0); + + if (pthread_create (&tid, NULL, tfn, NULL) != 0) + abort (); + + if (pthread_join (tid, NULL) != 0) + abort (); + + /* The thread should have called exit. */ + abort (); +} + +(sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c +(sid-sh4-sbuild)root@z6:/# ./setcontext +Unhandled trap: 0x180 +pc=0x7f69235e sr=0x00000000 pr=0x00400710 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0x7f658478 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7f692320 fpul=0x00000000 +r0=0x00e11158 r1=0x00000000 r2=0x00000001 r3=0x7ffff2e0 +r4=0x00e11068 r5=0x7ffff314 r6=0x7ffff31c r7=0x00000000 +r8=0x004007b0 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0x7f79ac54 r13=0x00000000 r14=0x7ffff288 r15=0x7ffff288 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@z6:/# + +The same code works fine on my Renesas SH7785LCR evaluation board: + +root@tirpitz:~> uname -a +Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a GNU/Linux +root@tirpitz:~> gcc -o setcontext setcontext.c -lpthread +root@tirpitz:~> ./setcontext +root@tirpitz:~> echo $? +0 +root@tirpitz:~> + +Due to this bug, it is not possible to compile gcc-7 with the Go frontend enabled on qemu-sh4. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1740219 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1740219 new file mode 100644 index 00000000..9517dedf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1740219 @@ -0,0 +1,62 @@ + + + +static linux-user ARM emulation has several-second startup time + +static linux-user emulation has several-second startup time + +My problem: I'm a Parabola packager, and I'm updating our +qemu-user-static package from 2.8 to 2.11. With my new +statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` +went from taking 0.006s to 3s! This does not happen with the normal +dynamically linked 2.11, or the old static 2.8. + +What happens is it gets stuck in +`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` +does is map 2 parts of the address space: `[base, base+guest_size]` +and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find +an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, +...)` decide where the first range is, and then check if that ++0xffff0000 is also available. If it isn't, then it starts trying +`mmap(base, ...)` for the entire address space from low-address to +high-address. + +"Normally," it finds an accaptable `base` within the first 2 tries. +With a static 2.11, it's taking thousands of tries. + +---- + +Now, from my understanding, there are 2 factors working together to +cause that in static 2.11 but not the other builds: + + - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 + - PIE (and thus ASLR) is disabled for static builds + +For some reason that I don't understand, with the smaller +`guest_size` the initial `mmap(NULL, guest_size, ...)` usually +returns an acceptable address range; but larger `guest_size` makes it +consistently return a block of memory that butts right up against +another already mapped chunk of memory. This isn't just true on the +older builds, it's true with the 2.11 builds if I use the `-R` flag to +shrink the `guest_size` back down to 0xf7000000. That is with +linux-hardened 4.13.13 on x86-64. + +So then, it it falls back to crawling the entire address space; so it +tries base=0x00001000. With ASLR, that probably succeeds. But with +ASLR being disabled on static builds, the text segment is at +0x60000000; which is does not leave room for the needed +0xffff1000-size block before it. So then it tries base=0x00002000. +And so on, more than 6000 times until it finally gets to and passes +the text segment; calling mmap more than 12000 times. + +---- + +I'm not sure what the fix is. Perhaps try to mmap a continuous chunk +of size 0xffff1000, then munmap it and then mmap the 2 chunks that we +actually need. The disadvantage to that is that it does not support +the sparse address space that the current algorithm supports for +`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big +mmap fails, then it could fall back to a sparse search; though I'm not +sure the current algorithm is a good choice for it, as we see in this +bug. Perhaps it should inspect /proc/self/maps to try to find a +suitable range before ever calling mmap? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1741 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1741 new file mode 100644 index 00000000..64d3f1c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1741 @@ -0,0 +1,4 @@ + + + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1748612 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1748612 new file mode 100644 index 00000000..3b01e016 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1748612 @@ -0,0 +1,18 @@ + + + +qemu-user option -strace -D <file> doesn't work + +I have been trying to access qemu -strace output from a script +The main problem was it was on stderr, the strace output was merged with my program's stderr output. +Then I tried to use the -D option, to log the output to a file. +This didn't work even if the log file was created, but it was empty. + +I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) + + +I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. + +removed declaration here and here: +https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 +https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1755 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1755 new file mode 100644 index 00000000..09f12d8e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1755 @@ -0,0 +1,23 @@ + + + +qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.) +Description of problem: +I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit +"Make the commpage executable". +Steps to reproduce: +1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host) + +2.# compile for cortex-m3: + +3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs + +4.qemu-arm -cpu cortex-m3 hello.exe.m3 +.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed. + +5. # compile for cortex-a9: + +6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs + +7. qemu-arm -cpu cortex-a9 hello.exe.a9 +Hello diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756519 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756519 new file mode 100644 index 00000000..d6a31f73 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756519 @@ -0,0 +1,49 @@ + + + +qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create + +qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: + +(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed +** +ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 + + +Backtrace obtained via gdb: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x0000000060139b21 in abort () at abort.c:79 +#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, + func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") + at gtestutils.c:2430 +#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, + func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453 +#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 +#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 +#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874 +#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68) + at qom/object.c:1926 +#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122 +#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68) + at qom/qom-qobject.c:27 +#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191 +#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 +#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 +#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881 +#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, + child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 +#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, + arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 +#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600 +#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311 +#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463 +#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +Attached is a test case source code extracted from libgomp test suite. + +Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. + +I will attach statically linked riscv64 binary executable if size limits permit. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756807 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756807 new file mode 100644 index 00000000..3ab52016 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1756807 @@ -0,0 +1,70 @@ + + + +performance regression in qemu-user + proot + +To reproduce: + +1. Install qemu-user-static and proot +2. Enter some arm chroot using them: + + proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash + +3. Run a command which normally takes a short but measurable amount of time: + + cd /usr/share/doc && time grep -R hello + +Result: + +This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. + +Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. + +If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. + +Logs: + + + +System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 +qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) +proot 5.1.0 + +al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-desktop:/# cd /usr/share/doc +root@al-desktop:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m0.066s +user 0m0.040s +sys 0m0.008s + + + + + +System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) +proot 5.1.0 + +al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-thinkpad:/# cd /usr/share/doc +root@al-thinkpad:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m24.176s +user 0m0.366s +sys 0m11.352s + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu (not installed) +ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 +Uname: Linux 4.15.0-12-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +Date: Mon Mar 19 07:13:25 2018 +InstallationDate: Installed on 2018-03-18 (0 days ago) +InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1761535 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1761535 new file mode 100644 index 00000000..38a8d1bb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1761535 @@ -0,0 +1,39 @@ + + + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip> \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763 new file mode 100644 index 00000000..ed6bf63e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763 @@ -0,0 +1,15 @@ + + + +ldd fails with qemu-aarch64 +Description of problem: +see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172 +Steps to reproduce: +1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls + +Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries. +Additional information: +``` +WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested +ldd: exited with unknown exit code (139) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763536 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763536 new file mode 100644 index 00000000..d18dcbcc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1763536 @@ -0,0 +1,86 @@ + + + +go build fails under qemu-ppc64le-static (qemu-user) + +I am using qemu-user (built static) in a docker container environment. When running multi-threaded go commands in the container (go build for example) the process may hang, report segfaults or other errors. I built qemu-ppc64le from the upstream git (master). + +I see the problem running on a multi core system with Intel i7 processors. +# cat /proc/cpuinfo | grep "model name" +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz + +Steps to reproduce: +1) Build qemu-ppc64le as static and copy into docker build directory named it qemu-ppc64le-static. + +2) Add hello.go to docker build dir. + +package main +import "fmt" +func main() { + fmt.Println("hello world") +} + +3) Create the Dockerfile from below: + +FROM ppc64le/golang:1.10.1-alpine3. +COPY qemu-ppc64le-static /usr/bin/ +COPY hello.go /go + +4) Build container +$ docker build -t qemutest -f Dockerfile ./go + +5) Run test +$ docker run -it qemutest + +/go # /usr/bin/qemu-ppc64le-static --version +qemu-ppc64le version 2.11.93 (v2.12.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +/go # go version +go version go1.10.1 linux/ppc64le + +/go # go build hello.go +fatal error: fatal error: stopm holding locksunexpected signal during runtime execution + +panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1003528c] + +runtime stack: +runtime: unexpected return pc for syscall.Syscall6 called from 0xc42007f500 +stack: frame={sp:0xc4203be840, fp:0xc4203be860} stack=[0x4000b7ecf0,0x4000b928f0) + +syscall.Syscall6(0x100744e8, 0x3d, 0xc42050c140, 0x20, 0x18, 0x10422b80, 0xc4203be968[signal , 0x10012d88SIGSEGV: segmentation violation, 0xc420594000 code=, 0x00x1 addr=0x0 pc=0x1003528c) +] + +runtime stack: + /usr/local/go/src/syscall/asm_linux_ppc64x.s:61runtime.throw(0x10472d19, 0x13) + + /usr/local/go/src/runtime/panic.go:0x6c616 +0x68 + + +runtime.stopm() + /usr/local/go/src/runtime/proc.go:1939goroutine +10x158 + [runtime.exitsyscall0semacquire(0xc42007f500) + /usr/local/go/src/runtime/proc.go:3129 +]: +0x130 +runtime.mcall(0xc42007f500) + /usr/local/go/src/runtime/asm_ppc64x.s:183 +0x58sync.runtime_Semacquire +(0xc4201fab1c) + /usr/local/go/src/runtime/sema.go:56 +0x38 + +---- +Note the results may differ between attempts, hangs and other faults sometimes happen. +---- +If I run "go: single threaded I don't see the problem, for example: + +/go # GOMAXPROCS=1 go build -p 1 hello.go +/go # ./hello +hello world + +I see the same issue with arm64. I don't think this is a go issue, but don't have a real evidence to prove that. This problem looks similar to other problem I have seen reported against qemu running multi-threaded applications. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1765970 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1765970 new file mode 100644 index 00000000..627353f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1765970 @@ -0,0 +1,64 @@ + + + +qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x + +I use a qemu-user chroot + binfmt to build software targetting a raspberry pi. After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host), I noticed that on my uclibc-ng chroot qemu-arm will segfault when running python and importing the portage module. + +I have bisected qemu down to this commit: + +https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 + +If I recompile and change MAX_RESERVED_VA (from the above commit) back to 0x77000000 the problem goes away. NB I have no idea what that does, I just thought I'd see. + + +Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the uclibc-ng one. Not sure why. + + +The following backtrace was generated from running qemu-arm in gdb and recreating the segfault: + +(gdb) where +#0 0x0000000060726046 in static_code_gen_buffer () +#1 0x0000000060048789 in cpu_tb_exec (cpu=0x6278e310, + itb=0x60725f80 <static_code_gen_buffer+314624>) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167 +#2 0x000000006004937f in cpu_loop_exec_tb (cpu=0x6278e310, + tb=0x60725f80 <static_code_gen_buffer+314624>, last_tb=0x7fffffffd138, + tb_exit=0x7fffffffd130) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627 +#3 0x0000000060049600 in cpu_exec (cpu=0x6278e310) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736 +#4 0x00000000600511c3 in cpu_loop (env=0x627965b0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585 +#5 0x00000000600534eb in main (argc=4, argv=0x7fffffffd9b8, + envp=0x7fffffffd9e0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882 + + + +(gdb) info reg +rax 0x627965b0 1652123056 +rbx 0x62717870 1651603568 +rcx 0x606da000 1617797120 +rdx 0x60726000 1618108416 +rsi 0x60726000 1618108416 +rdi 0x627965b0 1652123056 +rbp 0x7fffffffd0c0 0x7fffffffd0c0 +rsp 0x7fffffffd080 0x7fffffffd080 +r8 0x0 0 +r9 0x2 2 +r10 0x0 0 +r11 0x629280a0 1653768352 +r12 0x60260e40 1613106752 +r13 0x0 0 +r14 0x606a5018 1617580056 +r15 0x0 0 +rip 0x60048789 0x60048789 <cpu_tb_exec+266> +eflags 0x10282 [ SF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +(gdb) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768 new file mode 100644 index 00000000..3b1bd619 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768 @@ -0,0 +1,35 @@ + + + +Could not allocate more than ~2GB with qemu-user +Description of problem: +On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.) +Steps to reproduce: +1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");] +2. Only 1 64MB chunck is allocated in the upper 2GB memory space +3. Failed to allocate after about 2GB. +Additional information: +The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t). +The testing program is the following: +``` +#include <stdio.h> +#include <stdlib.h> + +int main(int argc,char *argv[]) { + unsigned int a; + unsigned int i; + char *al; + unsigned int sss=1U*1024*1024*64; + for(a=0;a<128;a++) { + al=malloc(sss); + if(al!=NULL) { + printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al); + } + else { + printf("Cannot alloc %d\n",(a+1)*sss); + perror("Cannot alloc"); + exit(1); + } + } +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768246 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768246 new file mode 100644 index 00000000..70b9b923 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1768246 @@ -0,0 +1,16 @@ + + + +cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. + +OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed. + +Crash indicates an assertion failure: + +(sid-sh4-sbuild)root@nofan:/# java --version +qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted +(sid-sh4-sbuild)root@nofan:/# + +Haven't bi-sected the issue yet, but will do so later. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1773743 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1773743 new file mode 100644 index 00000000..d98167cc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1773743 @@ -0,0 +1,24 @@ + + + +qemu-user -g xxx -E LD_PROFILE=xxx segfault + +Here is two simple steps to reproduce the bug: + +$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls + +(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) + +In a other window launch: + +$ gdb +(gdb) target remote :12345 +(gdb) c + +At this point qemu will segfault. + +It seems this problem is appends when sigprof passed to gdb. +One way I have found to bypass this: +patch gdbstub.c gdb_handlesig and ignore sig if +sig == TARGET_SIGPROF +(which means now I can't catch sigprof on gdb anymore) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1774149 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1774149 new file mode 100644 index 00000000..55ffb334 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1774149 @@ -0,0 +1,79 @@ + + + +qemu-user x86_64 x86 gdb call function from gdb doesn't work + +While running qemu user x86_64 x86 with gdb server, calling functions are not working. + +Here is how to reproduce it: + +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +Could not fetch register "fs_base"; remote failure reply 'E14' + +In other cases we also got the error: +Could not fetch register "orig_rax"; remote failure reply 'E14' + +Here is how I patched it (it is only a workaround): + +diff --git a/gdbstub.c b/gdbstub.c +index 2a94030..5749efe 100644 +--- a/gdbstub.c ++++ b/gdbstub.c +@@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t *mem_buf, int reg) + return r->get_reg(env, mem_buf, reg - r->base_reg); + } + } ++#ifdef TARGET_X86_64 ++ return 8; ++#elif TARGET_I386 ++ return 4; ++#endif + return 0; + } + +(Our guess for this issue was, gdb is requesting for 'fake' registers to know register size) + +Once we patched that, we got another problem while calling functions from gdb: We could call functions, but only once. + +Here is how to reproduce it: +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +$1 = (void *) 0x620010 +(gdb) call malloc(1) +Cannot access memory at address 0x40007ffb8f + +Here is how we patched it to make it work: + +diff --git a/exec.c b/exec.c +index 03238a3..d303922 100644 +--- a/exec.c ++++ b/exec.c +@@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (!(flags & PAGE_VALID)) + return -1; + if (is_write) { +- if (!(flags & PAGE_WRITE)) ++ if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG))) + return -1; + /* XXX: this code should not depend on lock_user */ + if (!(p = lock_user(VERIFY_WRITE, addr, l, 0))) + +From what we saw, there is a page which is passed to read-only after first execution, and gdb need to write on that page to put a breakpoint. (on the stack) + +We suspect this is linked to this: +https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1793539 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1793539 new file mode 100644 index 00000000..9b541f40 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1793539 @@ -0,0 +1,12 @@ + + + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 + +During the build of gedit for RISC-V this error occurs: + +$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 + +https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1798 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1798 new file mode 100644 index 00000000..4d67e493 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1798 @@ -0,0 +1,4 @@ + + + +conversions of malloc/calloc/free to g_malloc/g_new/g_free etc diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1799200 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1799200 new file mode 100644 index 00000000..4048274d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1799200 @@ -0,0 +1,43 @@ + + + +null pointer dereference in tcg_emit_op + +I am insert a custom tcg helper function in i386_tr_insn_start for trace the instructions. + +most of time the qemu runed ok ,but when execute some special software will lead to crash. + + +the below is the insert code: +======================================================================================= + + 8514 static void i386_tr_insn_start(DisasContextBase *dcbase, CPUState *cpu) + 8515 { + 8516 DisasContext *dc = container_of(dcbase, DisasContext, base); + 8517 TCGv_ptr ptr= tcg_const_ptr((void*)cpu); // inserted hepler code + 8518 gen_helper_mad_exec(ptr);// insert helper code + 8519 tcg_gen_insn_start(dc->base.pc_next, dc->cc_op); + 8520 } +====================================================================================== + +below is the callstack + +#0 0x000055555581df5e in tcg_emit_op (opc=opc@entry=INDEX_op_movi_i64) at /root/qemu/tcg/tcg.c:2205 +#1 0x0000555555825911 in tcg_gen_op2 (opc=opc@entry=INDEX_op_movi_i64, a1=140734736923704, a2=a2@entry=792) at /root/qemu/tcg/tcg-op.c:53 +#2 0x000055555581d713 in tcg_const_i64 (opc=INDEX_op_movi_i64, a2=792, a1=0x7378) at /root/qemu/tcg/tcg-op.h:109 +#3 0x000055555581d713 in tcg_const_i64 (arg=792, ret=<optimized out>) at /root/qemu/tcg/tcg-op.h:579 +#4 0x000055555581d713 in tcg_const_i64 (val=val@entry=792) at /root/qemu/tcg/tcg.c:1314 +#5 0x000055555582732d in tcg_gen_addi_i64 (ret=0xd18, arg1=0x378, arg2=arg2@entry=792) at /root/qemu/tcg/tcg-op.c:1200 +#6 0x000055555590ffaf in gen_sse (b=792, a=<optimized out>, r=<optimized out>) at /root/qemu/tcg/tcg-op.h:1258 +#7 0x000055555590ffaf in gen_sse (env=env@entry=0x5555567424d0, s=s@entry=0x7fffea99a610, b=b@entry=366, pc_start=pc_start@entry=4513509698, rex_r=rex_r@entry=0) at /root/qemu/target/i386/translate.c:3150 +#8 0x0000555555911d7f in disas_insn (s=s@entry=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8336 +#9 0x00005555559207a0 in i386_tr_translate_insn (dcbase=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8543 +#10 0x0000555555892649 in translator_loop (ops=0x55555622dee0 <i386_tr_ops>, db=0x7fffea99a610, cpu=0x55555673a220, tb=<optimized out>) at /root/qemu/accel/tcg/translator.c:110 +#11 0x00005555559209ef in gen_intermediate_code (cpu=cpu@entry=0x55555673a220, tb=tb@entry=0x7fff70682040 <code_gen_buffer+208150547>) at /root/qemu/target/i386/translate.c:8605 +#12 0x0000555555891437 in tb_gen_code (cpu=cpu@entry=0x55555673a220, pc=pc@entry=4513506448, cs_base=cs_base@entry=0, flags=flags@entry=4244147, cflags=cflags@entry=0) at /root/qemu/accel/tcg/translate-all.c:1728 +#13 0x000055555588f97b in cpu_exec (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /root/qemu/accel/tcg/cpu-exec.c:410 +#14 0x000055555588f97b in cpu_exec (cpu=cpu@entry=0x55555673a220) at /root/qemu/accel/tcg/cpu-exec.c:734 +#15 0x000055555584b152 in tcg_cpu_exec (cpu=0x55555673a220) at /root/qemu/cpus.c:1405 +#16 0x000055555584d1b8 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /root/qemu/cpus.c:1505 +#17 0x00007ffff2585e25 in start_thread () at /lib64/libpthread.so.0 +#18 0x00007ffff22afbad in clone () at /lib64/libc.so.6 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1805 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1805 new file mode 100644 index 00000000..970804b2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1805 @@ -0,0 +1,69 @@ + + + +build-user-hexagon CI job is not actually testing hexagon +Description of problem: +Look at the output from the `build-user-hexagon` CI job and see what compiler meson reports it is using: + + https://gitlab.com/qemu-project/qemu/-/jobs/4790457871 + +``` +Project name: qemu +Project version: 8.0.91 +C compiler for the host machine: cc -m64 -mcx16 (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") +C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2 +Host machine cpu family: x86_64 +Host machine cpu: x86_64 +``` + +What is 'cc' resolving to ? + +``` +$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross cc -v | grep Target +Target: x86_64-linux-gnu +``` + +That is a x86_64 target native compiler, not a hexagon target cross compiler. + +The ``tests/docker/dockerfiles/debian-hexagon-cross.docker`` file installs the hexagon toolchain under ``/opt`` and adds the dir to ``$PATH`` with: + +``` +ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin +``` + +This toolchain just installs a `clang` binary, not ``cc`` + +So when ``configure`` runs it looks for ``cc`` first and finds the naitve x86_64 GCC install from the container, not the clang cross compiler + +It is also not possible to merely set ``CC=clang`` because meson will assume it is a native compiler and crash and burn when unable to run binaries + +``` +# CC=clang ./configure --target-list=x86_64-softmmu +Using './build' as the directory for build output +...snip... +Sphinx not found/usable, disabling docs. +Disabling PIE due to missing toolchain support +The Meson build system +Version: 1.2.0 +Source dir: /qemu +Build dir: /qemu/build +Build type: native build +Project name: qemu +Project version: 8.0.92 + +../meson.build:1:0: ERROR: Executables created by c compiler clang -m64 -mcx16 are not runnable. +``` + +AFAICT, the root problem here is that the hexagon container is not setup in the same way as the other cross compiler containers. + +We need the toolchain binaries to be named after the target triplet - ie not ``clang`` but ``hexagon-unknown-linux-musl-clang`` + +This used to be done but was thrown away when switching to a pre-built toolchain in b9052d36342c947b36447558ed0a0dd3fb3fb8f4 + +Then the container also needs to set the configure args for the cross target + +``` +ENV QEMU_CONFIGURE_OPTS --cross-prefix=hexagon-unknown-linux-musl- +``` + +AFAICT, this was never done, so even before switching to the pre-built toolchain, I think the `build-user-hexagon` CI job was running a native built not hexagon build. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1808565 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1808565 new file mode 100644 index 00000000..e7558e3b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1808565 @@ -0,0 +1,10 @@ + + + +Reading /proc/self/task/<pid>/maps is not remapped to the target + +Seeing this in qemu-user 3.1.0 + +The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly. + +These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1809546 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1809546 new file mode 100644 index 00000000..50b50bdd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1809546 @@ -0,0 +1,46 @@ + + +Writing a byte to a pl011 SFR overwrites the whole SFR + +The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. + +I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. + +Given: + +pl011_addr: .word 0x10009000 + +The following snippet will be problematic: + + ldr r3, pl011_addr + ldrb r2, [r3, #0x38] // IMSC + mov r2, #0 + orr r2, r2, #0x10 // R2 == 0x10 + strb r2, [r3, #0x38] // Whole word reads correctly after this + ldrb r2, [r3, #0x39] + mov r2, #0 + strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well + +After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000010 + +After the second strb instruction, the write to 0x10009039 clears the entire word: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000000 + +QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: + +qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio + +Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: + + ldr r3, pl011_addr + mov r2, #0x10 + str r2, [r3, #0x38] + +Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. + +I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1812 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1812 new file mode 100644 index 00000000..014e2dbf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1812 @@ -0,0 +1,28 @@ + + + +older programs running under qemu-aarch64 segfaults +Description of problem: +Numerous aarch64 programs segfaults when run under qemu-aarch64. +Steps to reproduce: +1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup): +``` +debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian +or +debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/ +``` +2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/ +3. chroot /tmp/jessie-arm64/ +4. ./qemu-aarch64 /bin/ls +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +Additional information: +Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 . My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange. + +Not all programs segfaults. dash works, ls or bash does not. + +A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information. To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed. + +Reverting the mentioned commit makes everything work again. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1813398 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1813398 new file mode 100644 index 00000000..cf95330d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1813398 @@ -0,0 +1,44 @@ + + + +qemu user calls malloc after fork in multi-threaded process + +qemu user may hang in malloc on a musl based system because +it calls malloc after fork (in a pthread_atfork handler) +in the child process. + +this is undefined behaviour since the parent process is +multi-threaded and only as-safe functions may be called +in the child then. (if malloc/free is called concurrently +with fork the malloc state will be corrupted in the child, +it works on glibc because glibc takes the malloc locks +before the fork syscall, but that breaks the as-safety of +fork and thus non-conforming to posix) + +discussed at +https://www.openwall.com/lists/musl/2019/01/26/1 + +the bug is hard to reproduce (requires the call_rcu thread +to call free concurrently with do_fork in the main thread), +this one is observed with qemu-arm 3.1.0 running on x86_64 +executing an arm busybox sh: + +(gdb) bt +#0 malloc (n=<optimized out>, n@entry=9) at src/malloc/malloc.c:306 +#1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@entry=9) at gmem.c:99 +#2 0x000000006018bcab in g_strdup (str=<optimized out>, str@entry=0x60200abf "call_rcu") at gstrfuncs.c:363 +#3 0x000000006016e31d in qemu_thread_create (thread=thread@entry=0x7ffe367d1870, name=name@entry=0x60200abf "call_rcu", + start_routine=start_routine@entry=0x60174c00 <call_rcu_thread>, arg=arg@entry=0x0, mode=mode@entry=1) + at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526 +#4 0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327 +#5 0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26 +#6 0x00000000601be8db in fork () at src/process/fork.c:33 +#7 0x000000006009d191 in do_fork (env=0x627aaed0, flags=flags@entry=17, newsp=newsp@entry=0, parent_tidptr=parent_tidptr@entry=0, + newtls=newtls@entry=0, child_tidptr=child_tidptr@entry=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:5528 +#8 0x00000000600af894 in do_syscall1 (cpu_env=cpu_env@entry=0x627aaed0, num=num@entry=2, arg1=arg1@entry=0, arg2=arg2@entry=-8700192, + arg3=<optimized out>, arg4=8, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:7042 +#9 0x00000000600a835c in do_syscall (cpu_env=cpu_env@entry=0x627aaed0, num=2, arg1=0, arg2=-8700192, arg3=<optimized out>, + arg4=<optimized out>, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:11533 +#10 0x00000000600c265f in cpu_loop (env=env@entry=0x627aaed0) at /home/pmos/build/src/qemu-3.1.0/linux-user/arm/cpu_loop.c:360 +#11 0x00000000600417a2 in main (argc=<optimized out>, argv=0x7ffe367d57b8, envp=<optimized out>) + at /home/pmos/build/src/qemu-3.1.0/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1814128 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1814128 new file mode 100644 index 00000000..7b23ecb0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1814128 @@ -0,0 +1,158 @@ + + + +qemu-user fails to set up a reasonable brk for static-pie + +static pie binaries may not get a reasonable brk, +with glibc this means they crash in early tls setup code: +https://sourceware.org/bugzilla/show_bug.cgi?id=24152 + +qemu seems to put brk at the end of the data segment, +but if the stack starts (ends) right next to it then +allocation with brk fails. + +in such situation i think qemu should arrange the +stack or brk to be elsewhere so there is plenty +space to grow (in case of glibc it's enough if tls +setup works: later allocations can fall back to mmap). + +(ubuntu bionic x86_64 ldconfig.real from libc-bin package) +$ qemu-x86_64 -strace -d page /sbin/ldconfig.real +host mmap_min_addr=0x8000 +guest_base 0x0 +start end size prot +0000004000000000-00000040000f2000 00000000000f2000 r-x +00000040000f2000-00000040002f2000 0000000000200000 --- +00000040002f2000-00000040002fa000 0000000000008000 rw- +00000040002fa000-00000040002fb000 0000000000001000 --- +00000040002fb000-0000004000afb000 0000000000800000 rw- +start_brk 0x0000000000000000 +end_code 0x00000040000f1ee8 +start_code 0x0000004000000000 +start_data 0x00000040002f2838 +end_data 0x00000040002f8518 +start_stack 0x0000004000afa130 +brk 0x00000040002f9dd8 +entry 0x0000004000009bc0 +argv_start 0x0000004000afa138 +env_start 0x0000004000afa148 +auxv_start 0x0000004000afa280 +28561 brk(NULL) = 0x00000040002fa000 +28561 brk(0x00000040002fb1c0) = 0x00000040002fa000 +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0xffffffffffffffc0} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ readelf -hldSW /tmp/ldconfig.real +ELF Header: + Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 + Class: ELF64 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - GNU + ABI Version: 0 + Type: DYN (Shared object file) + Machine: Advanced Micro Devices X86-64 + Version: 0x1 + Entry point address: 0x9bc0 + Start of program headers: 64 (bytes into file) + Start of section headers: 1022920 (bytes into file) + Flags: 0x0 + Size of this header: 64 (bytes) + Size of program headers: 56 (bytes) + Number of program headers: 8 + Size of section headers: 64 (bytes) + Number of section headers: 38 + Section header string table index: 37 + +Section Headers: + [Nr] Name Type Address Off Size ES Flg Lk Inf Al + [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 + [ 1] .note.ABI-tag NOTE 0000000000000200 000200 000020 00 A 0 0 4 + [ 2] .note.gnu.build-id NOTE 0000000000000220 000220 000024 00 A 0 0 4 + [ 3] .gnu.hash GNU_HASH 0000000000000248 000248 00001c 00 A 4 0 8 + [ 4] .dynsym DYNSYM 0000000000000268 000268 000018 18 A 5 1 8 + [ 5] .dynstr STRTAB 0000000000000280 000280 000001 00 A 0 0 1 + [ 6] .rela.dyn RELA 0000000000000288 000288 008748 18 A 4 0 8 + [ 7] .rela.plt RELA 00000000000089d0 0089d0 000318 18 AI 4 27 8 + [ 8] .init PROGBITS 0000000000008ce8 008ce8 000017 00 AX 0 0 4 + [ 9] .plt PROGBITS 0000000000008d00 008d00 000270 10 AX 0 0 16 + [10] .plt.got PROGBITS 0000000000008f70 008f70 000060 08 AX 0 0 8 + [11] .text PROGBITS 0000000000008fd0 008fd0 0bd29c 00 AX 0 0 16 + [12] __libc_freeres_fn PROGBITS 00000000000c6270 0c6270 0016b3 00 AX 0 0 16 + [13] __libc_thread_freeres_fn PROGBITS 00000000000c7930 0c7930 00108f 00 AX 0 0 16 + [14] .fini PROGBITS 00000000000c89c0 0c89c0 000009 00 AX 0 0 4 + [15] .rodata PROGBITS 00000000000c89e0 0c89e0 01af08 00 A 0 0 32 + [16] .stapsdt.base PROGBITS 00000000000e38e8 0e38e8 000001 00 A 0 0 1 + [17] .eh_frame_hdr PROGBITS 00000000000e38ec 0e38ec 001f94 00 A 0 0 4 + [18] .eh_frame PROGBITS 00000000000e5880 0e5880 00c5b8 00 A 0 0 8 + [19] .gcc_except_table PROGBITS 00000000000f1e38 0f1e38 0000b0 00 A 0 0 1 + [20] .tdata PROGBITS 00000000002f2838 0f2838 000028 00 WAT 0 0 8 + [21] .tbss NOBITS 00000000002f2860 0f2860 000040 00 WAT 0 0 8 + [22] .init_array INIT_ARRAY 00000000002f2860 0f2860 000010 08 WA 0 0 8 + [23] .fini_array FINI_ARRAY 00000000002f2870 0f2870 000010 08 WA 0 0 8 + [24] .data.rel.ro PROGBITS 00000000002f2880 0f2880 0034c4 00 WA 0 0 32 + [25] .dynamic DYNAMIC 00000000002f5d48 0f5d48 0001a0 10 WA 5 0 8 + [26] .got PROGBITS 00000000002f5ee8 0f5ee8 000110 08 WA 0 0 8 + [27] .got.plt PROGBITS 00000000002f6000 0f6000 000148 08 WA 0 0 8 + [28] .data PROGBITS 00000000002f6160 0f6160 001bd4 00 WA 0 0 32 + [29] __libc_subfreeres PROGBITS 00000000002f7d38 0f7d38 000060 00 WA 0 0 8 + [30] __libc_IO_vtables PROGBITS 00000000002f7da0 0f7da0 000768 00 WA 0 0 32 + [31] __libc_atexit PROGBITS 00000000002f8508 0f8508 000008 00 WA 0 0 8 + [32] __libc_thread_subfreeres PROGBITS 00000000002f8510 0f8510 000008 00 WA 0 0 8 + [33] .bss NOBITS 00000000002f8520 0f8518 001890 00 WA 0 0 32 + [34] __libc_freeres_ptrs NOBITS 00000000002f9db0 0f8518 000028 00 WA 0 0 8 + [35] .note.stapsdt NOTE 0000000000000000 0f8518 0014cc 00 0 0 4 + [36] .gnu_debuglink PROGBITS 0000000000000000 0f99e4 000034 00 0 0 4 + [37] .shstrtab STRTAB 0000000000000000 0f9a18 0001ab 00 0 0 1 +Key to Flags: + W (write), A (alloc), X (execute), M (merge), S (strings), I (info), + L (link order), O (extra OS processing required), G (group), T (TLS), + C (compressed), x (unknown), o (OS specific), E (exclude), + l (large), p (processor specific) + +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x0f1ee8 0x0f1ee8 R E 0x200000 + LOAD 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x005ce0 0x0075a0 RW 0x200000 + DYNAMIC 0x0f5d48 0x00000000002f5d48 0x00000000002f5d48 0x0001a0 0x0001a0 RW 0x8 + NOTE 0x000200 0x0000000000000200 0x0000000000000200 0x000044 0x000044 R 0x4 + TLS 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x000028 0x000068 R 0x8 + GNU_EH_FRAME 0x0e38ec 0x00000000000e38ec 0x00000000000e38ec 0x001f94 0x001f94 R 0x4 + GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 + GNU_RELRO 0x0f2838 0x00000000002f2838 0x00000000002f2838 0x0037c8 0x0037c8 R 0x1 + + Section to Segment mapping: + Segment Sections... + 00 .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.dyn .rela.plt .init .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table + 01 .tdata .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .bss __libc_freeres_ptrs + 02 .dynamic + 03 .note.ABI-tag .note.gnu.build-id + 04 .tdata .tbss + 05 .eh_frame_hdr + 06 + 07 .tdata .init_array .fini_array .data.rel.ro .dynamic .got + +Dynamic section at offset 0xf5d48 contains 22 entries: + Tag Type Name/Value + 0x000000000000000c (INIT) 0x8ce8 + 0x000000000000000d (FINI) 0xc89c0 + 0x0000000000000019 (INIT_ARRAY) 0x2f2860 + 0x000000000000001b (INIT_ARRAYSZ) 16 (bytes) + 0x000000000000001a (FINI_ARRAY) 0x2f2870 + 0x000000000000001c (FINI_ARRAYSZ) 16 (bytes) + 0x000000006ffffef5 (GNU_HASH) 0x248 + 0x0000000000000005 (STRTAB) 0x280 + 0x0000000000000006 (SYMTAB) 0x268 + 0x000000000000000a (STRSZ) 1 (bytes) + 0x000000000000000b (SYMENT) 24 (bytes) + 0x0000000000000015 (DEBUG) 0x0 + 0x0000000000000003 (PLTGOT) 0x2f6000 + 0x0000000000000002 (PLTRELSZ) 792 (bytes) + 0x0000000000000014 (PLTREL) RELA + 0x0000000000000017 (JMPREL) 0x89d0 + 0x0000000000000007 (RELA) 0x288 + 0x0000000000000008 (RELASZ) 34632 (bytes) + 0x0000000000000009 (RELAENT) 24 (bytes) + 0x000000006ffffffb (FLAGS_1) Flags: PIE + 0x000000006ffffff9 (RELACOUNT) 1443 + 0x0000000000000000 (NULL) 0x0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1818483 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1818483 new file mode 100644 index 00000000..a05053f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1818483 @@ -0,0 +1,45 @@ + + + +qemu user mode does not support binfmt_misc config with flags include "P" + +Hi Sir: +During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. +For example in test module "Devscripts" +the test item for broken tarball expected the warning info: +<tar: This does not look like a tar archive +tar: ******* > +but the output was: +</bin/tar: This does not look like a tar archive +/bin/tar: ******> +the cause is the config file of binfmt_misc was set not to send argv0, for example: +type command "tar" after chroot: +========================== +lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . +[sudo] password for lpeng: +root@lpeng-VirtualBox:/# tar +/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options +Try '/bin/tar --help' or '/bin/tar --usage' for more information. +root@lpeng-VirtualBox:/# +=========================== + +by adding output log in main()@qemu/Linux-user/main.c +we found the original input command was changed, and qemu do not know that, we got the input args: +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----NULL--- + +Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. +But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" + + +After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----tar--- + +We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? +looking forward your suggestions. + +Thanks +luyou \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1819 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1819 new file mode 100644 index 00000000..a1740d8e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1819 @@ -0,0 +1,13 @@ + + + +segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell. +Description of problem: + +Steps to reproduce: +1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag +2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image +3. on shell run command -\> rpm -qa. +4. docker run -it b22fdcc90005 + + WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832353 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832353 new file mode 100644 index 00000000..8840513f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832353 @@ -0,0 +1,23 @@ + + + +cpu_exec: Assertion !have_mmap_lock() failed + +Hi, + +I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: + +qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. + +including with master qemu as of today. + +I'm attaching a tarball containing: +qemu-assert: +cmd lib proc_ptr_51.exe + +qemu-assert/lib: +ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 + +where cmd is the basic command used to launch the test & reproduce the failure. + +Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832916 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832916 new file mode 100644 index 00000000..fd8f7301 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1832916 @@ -0,0 +1,8 @@ + + + +linux-user does not check PROT_EXEC + +At no point do we actually verify that a page is PROT_EXEC before translating. All we end up verifying is that the page is readable. Not the same thing, obviously. + +The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1833668 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1833668 new file mode 100644 index 00000000..c6a88da6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1833668 @@ -0,0 +1,30 @@ + + + +linux-user: Unable to run ARM binaries on Aarch64 + +Download a ARM package from https://packages.debian.org/sid/busybox-static + +Here tested with: busybox-static_1.30.1-4_armel.deb + +$ file busybox.armel +busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14) + +$ qemu-aarch64 busybox.armel +busybox.armel: Invalid ELF image for this architecture + +$ qemu-aarch64 -cpu cortex-a7 busybox.armel +unable to find CPU model 'cortex-a7' + +Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1, +while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty: + +$ gdb -q aarch64-linux-user/qemu-aarch64 +(gdb) p aarch64_cpus +$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", + initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}} +(gdb) p arm_cpus +$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1834496 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1834496 new file mode 100644 index 00000000..5d976716 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1834496 @@ -0,0 +1,30 @@ + + + +Regressions on arm target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +I found several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash: + +qemu: uncaught target signal 6 (Aborted) - core dumped + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-mode arm +--with-cpu cortex-a9 + +and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference). + +I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later. + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835693 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835693 new file mode 100644 index 00000000..1ccfe970 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835693 @@ -0,0 +1,20 @@ + + + +s390x binaries segfault + +Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. + +$ cat hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ s390x-linux-gnu-g++ -o hello hello.cpp + +$ qemu-s390x-static hello +Segmentation fault \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835839 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835839 new file mode 100644 index 00000000..c863d3fa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1835839 @@ -0,0 +1,24 @@ + + + +qemu-user: $0 incorrectly always reports absolute path + +We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. + +The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. + +A simple reproducer is this: + +On normal system (no emulation): + +root@nofan:~> sh -c 'echo $0' +sh +root@nofan:~> + +On qemu-user: + +(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' +/bin/sh +(sid-m68k-sbuild)root@nofan:/# + +> [1] https://lists.debian.org/debian-68k/2019/07/msg00007.html \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836078 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836078 new file mode 100644 index 00000000..506e6e58 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836078 @@ -0,0 +1,25 @@ + + + +Regressions on arm-linux-gnueabihf target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabihf +--with-cpu cortex-a57 +--with-fpu crypto-neon-fp-armv8 + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836192 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836192 new file mode 100644 index 00000000..935aefbc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836192 @@ -0,0 +1,24 @@ + + + +Regressions on arm926 target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926. + +I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabi +--with-cpu arm10tdmi +--with-fpu vfp + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836558 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836558 new file mode 100644 index 00000000..3fc7acaf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1836558 @@ -0,0 +1,51 @@ + + + +Qemu-ppc Memory leak creating threads + +When creating c++ threads (with c++ std::thread), the resulting binary has memory leaks when running with qemu-ppc. + +Eg the following c++ program, when compiled with gcc, consumes more and more memory while running at qemu-ppc. (does not have memory leaks when compiling for Intel, when running same binary on real powerpc CPU hardware also no memory leaks). + +(Note I used function getCurrentRSS to show available memory, see https://stackoverflow.com/questions/669438/how-to-get-memory-usage-at-runtime-using-c; calls commented out here) + +Compiler: powerpc-linux-gnu-g++ (Debian 8.3.0-2) 8.3.0 (but same problem with older g++ compilers even 4.9) +Os: Debian 10.0 ( Buster) (but same problem seen on Debian 9/stetch) +qemu: qemu-ppc version 3.1.50 + + + +--- + +#include <iostream> +#include <thread> +#include <chrono> + + +using namespace std::chrono_literals; + +// Create/run and join a 100 threads. +void Fun100() +{ +// auto b4 = getCurrentRSS(); +// std::cout << getCurrentRSS() << std::endl; + for(int n = 0; n < 100; n++) + { + std::thread t([] + { + std::this_thread::sleep_for( 10ms ); + }); +// std::cout << n << ' ' << getCurrentRSS() << std::endl; + t.join(); + } + std::this_thread::sleep_for( 500ms ); // to give OS some time to wipe memory... +// auto after = getCurrentRSS(); + std::cout << b4 << ' ' << after << std::endl; +} + + +int main(int, char **) +{ + Fun100(); + Fun100(); // memory used keeps increasing +} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1840922 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1840922 new file mode 100644 index 00000000..79a8d0f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1840922 @@ -0,0 +1,24 @@ + + + +qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8 + +Hi, + +While experimenting with running the GCC testsuite with cortex-m33 as target (to exercise v8-m code), I came across this failure: +qemu: unhandled CPU exception 0x8 - aborting +R00=fffeaf58 R01=fffeaf58 R02=00000000 R03=fffeaf5d +R04=fffeaf5c R05=fffeaf9c R06=00000000 R07=fffeaf80 +R08=00000000 R09=00000000 R10=00019dbc R11=00000000 +R12=000000f0 R13=fffeaf58 R14=000081f3 R15=fffeaf5c +XPSR=61000000 -ZC- T NS priv-thread +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6033c908 + +I'm using arm-eabi-gcc, so it targets bare-metal, not linux. + +The testcase is GCC's gcc/testsuite/gcc.c-torture/execute/20000822-1.c; it works when compiled at -O2, but crashes when compiled at -Os. The test uses nested functions, so it creates a trampoline on the stack, whose address may be a problem. But since the stack address seems to be in the same range in the O2 and Os cases, it's not that clear. + +I'm attaching the C source, asm, binary executables and qemu traces with in_asm,cpu. + +I execute the binaries with: +qemu-arm --cpu cortex-m33 ./20000822-1.exe.Os \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1854 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1854 new file mode 100644 index 00000000..fd165c9e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1854 @@ -0,0 +1,21 @@ + + + +s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Description of problem: +The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 . +Reverting that commit fixes the issue. +Steps to reproduce: +1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below. +2. Run it under qemu-s390x. + +``` + ./qemu-s390x nolibc-test +** +ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Aborted (core dumped) + +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1857 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1857 new file mode 100644 index 00000000..64840da4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1857 @@ -0,0 +1,55 @@ + + + +Major qemu-aarch64 performance slowdown since commit 59b6b42cd3 +Description of problem: +I have observed a major performance slowdown between qemu 8.0.0 and 8.1.0: + + +qemu 8.0.0: 0.8s + +qemu 8.1.0: 6.8s + + +After bisecting the commits between 8.0.0 and 8.1.0, the offending commit is 59b6b42cd3: + + +commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jun 6 10:19:39 2023 +0100 + + target/arm: Enable FEAT_LSE2 for -cpu max + + Reviewed-by: Peter Maydell <peter.maydell@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + Message-id: 20230530191438.411344-21-richard.henderson@linaro.org + Signed-off-by: Peter Maydell <peter.maydell@linaro.org> + + +Reverting the commit in latest master fixes the problem: + +qemu 8.0.0: 0.8s + +qemu 8.1.0: 6.8s + +qemu master + revert 59b6b42cd3: 0.8s + +Alternatively, specify `-cpu cortex-a35` to disable LSE2: + +`time ./qemu-aarch64 -cpu cortex-a35`: 0.8s + +`time ./qemu-aarch64`: 6.77s + +The slowdown is also observed when running qemu-aarch64 on aarch64 machine: + +`time ./qemu-aarch64 /usr/bin/node -e 1`: 2.91s + +`time ./qemu-aarch64 -cpu cortex-a35 /usr/bin/node -e 1`: 1.77s + +The slowdown on x86_64 machine is small: 362ms -> 378ms. +Steps to reproduce: +1. Run `time ./qemu-aarch64 node-aarch64 -e 1` (node-aarch64 is NodeJS v16 built for AArch64) +2. Using qemu master, the output says `0.8s` +3. Using qemu master with commit 59b6b42cd3 reverted, the output says `6.77s` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1860610 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1860610 new file mode 100644 index 00000000..aafd772c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1860610 @@ -0,0 +1,10 @@ + + + +cap_disas_plugin leaks memory + +Looking at origin/master head, the function cap_disas_plugin leaks memory. + +per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close. + +I discovered this running qemu under valgrind. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1861605 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1861605 new file mode 100644 index 00000000..09ddfa40 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1861605 @@ -0,0 +1,19 @@ + + + +LL/SC broken for MIPS after 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f + +In that commit the env->llval value is loaded as an unsigned value (instead of sign-extended as before and therefore the CMPXCHG in gen_st_cond() in translate.c fails. + +I have committed a fix for this issue as https://github.com/CTSRD-CHERI/qemu/commit/a18d80c629989d002794f558968e1561edaf3dfd + +An alternative solution would be to change the cmpxchg line to perform a non-sign-extended compare, i.e. replace + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo); +with + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo & ~MO_SIGN); + + +I cannot send this patch to the QEMU mailing list as I am not able to setup git-send-email. +Feel free to apply this commit or the alternative solution. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862167 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862167 new file mode 100644 index 00000000..512a54b7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862167 @@ -0,0 +1,6 @@ + + + +Variation of SVE register size (qemu-user-aarch64) + +Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862986 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862986 new file mode 100644 index 00000000..354df31c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1862986 @@ -0,0 +1,67 @@ + + + +qemu-s390x segfaults + +All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault when run on an aarch64 odroid Ubuntu. + +Steps to reproduce: + +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version +qemu-s390x version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version +qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +qemu-arm does work on the same machine: + +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected + + +What kind of debug information would be helpful for this issue report? + + +GDB for the self-compiled latest release is not particularly helpful: + +(gdb) run +Starting program: /usr/local/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a2a140 (LWP 28264)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x000000555596b218 in __bss_start__ () +(gdb) bt +#0 0x000000555596b218 in __bss_start__ () +#1 0x00000055556120a8 in ?? () +#2 0x00000055579904b0 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) + +A bit more information is available in the version shipped by Ubuntu: + +(gdb) run +Starting program: /usr/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a01180 (LWP 28271)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x0000005555738f98 in code_gen_buffer () +(gdb) bt +#0 0x0000005555738f98 in code_gen_buffer () +#1 0x00000055555e96c8 in cpu_exec () +#2 0x00000055555ee430 in cpu_loop () +#3 0x00000055555c3328 in main () \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1863445 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1863445 new file mode 100644 index 00000000..699fc350 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1863445 @@ -0,0 +1,19 @@ + + + +assertion failed at translate-all.c:2523 with version 3.1.1 + +I was trying to debug a userspace binary with radare2 and met the following assertion in qemu: + +``` +qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987 +``` + +``` +# qemu-mipsel --version +qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +``` + +not much to add. seems like qemu is not properly checking for valid addresses \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1869073 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1869073 new file mode 100644 index 00000000..37f73332 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1869073 @@ -0,0 +1,10 @@ + + + +qemu-arm-static crashes "segmentation fault" when running "git clone -s" + +I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". + +The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". + +I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1878501 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1878501 new file mode 100644 index 00000000..960a0916 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1878501 @@ -0,0 +1,34 @@ + + + +qemu-i386 does not define AT_SYSINFO + +qemu-i386 does not define the AT_SYSINFO auxval when running i386 Linux binaries. + +On most libcs, this is properly handled, but this is mandatory for the i686 Bionic (Android) libc or it will segfault. + +This is due to a blind assumption that getauxval(AT_SYSINFO) will return a valid function pointer: + +The code varies from version to version, but it looks like this: + +void *__libc_sysinfo; +// mangled as _Z19__libc_init_sysinfov +void __libc_init_sysinfo() { + bool dummy; + // __bionic_getauxval = getauxval + __libc_sysinfo = reinterpret_cast<void *>(__bionic_getauxval(AT_SYSINFO, dummy)); +} + +A simple way to reproduce is to compile a basic C program against the NDK: + +int main(void) { return 0; } + +$ i686-linux-android-clang -static empty.c -o empty +$ qemu-i386 -cpu max ./empty +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +The place where it segfaults is misleading: It will, at least on the current NDK, crash on __set_thread_area, this is due to it calling a function pointer to __libc_sysinfo returned by __kernel_syscall. + +QEMU 4.1.1 (aarch64) +Pixel 2 XL via Termux \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880225 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880225 new file mode 100644 index 00000000..8223b607 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880225 @@ -0,0 +1,140 @@ + + + +Emulation of some arm programs fail with "Assertion `have_guest_base' failed." + +This issue is observer with QEMU ToT, checked out around May 15th (but I believe it is present in current master too), and wasn't present in QEMU v5.0.0. + +I am using 32-bit Intel(R) Pentium(R) M processor 1.73GHz host. + +Arm cross-compiler is a standard cross-compiler that comes with Debian-based distributions, and gcc version is: + +$ arm-linux-gnueabi-gcc --version +arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 + +Compile this program with cross compiler: + +$ arm-linux-gnueabi-gcc -O2 -static toupper_string.c -o toupper_string-arm + +Emulation with QEMU v5.0.0 is correct, and gives expected output: + +$ ~/Build/qemu-5.0.0/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +CONTROL RESULT: (toupper_string) + nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq + NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ + +While, in case of QEMU master it fails: + +$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: probe_guest_base: Assertion `have_guest_base' failed. +Aborted + +There are many other programs that exibit the same behavior. The failure is arm-sprecific. + + +----------------------------------------------------- + +source code: (let's call this file toupper_string.c) (similar file is also in attachment) + + +#include <stdlib.h> +#include <string.h> +#include <stdio.h> +#include <unistd.h> + + +#define MAX_STRING_LENGHT 15 +#define NUMBER_OF_RANDOM_STRINGS 100 +#define DEFAULT_NUMBER_OF_REPETITIONS 30000 +#define MAX_NUMBER_OF_REPETITIONS 1000000000 +#define NUMBER_OF_CONTROL_PRINT_ITEMS 5 + +/* Structure for keeping an array of strings */ +struct StringStruct { + char chars[MAX_STRING_LENGHT + 1]; +}; + +/** + * Sets characters of the given string to random small letters a-z. + * @param s String to get random characters. + * @len Length of the input string. + */ +static void gen_random_string(char *chars, const int len) +{ + static const char letters[] = "abcdefghijklmnopqrstuvwxyz"; + + for (size_t i = 0; i < len; i++) { + chars[i] = letters[rand() % (sizeof(letters) - 1)]; + } + chars[len] = 0; +} + +void main (int argc, char* argv[]) +{ + struct StringStruct random_strings[NUMBER_OF_RANDOM_STRINGS]; + struct StringStruct strings_to_be_uppercased[NUMBER_OF_RANDOM_STRINGS]; + int32_t number_of_repetitions = DEFAULT_NUMBER_OF_REPETITIONS; + int32_t option; + + /* Parse command line options */ + while ((option = getopt(argc, argv, "n:")) != -1) { + if (option == 'n') { + int32_t user_number_of_repetitions = atoi(optarg); + /* Check if the value is a negative number */ + if (user_number_of_repetitions < 1) { + fprintf(stderr, "Error ... Value for option '-n' cannot be a " + "negative number.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is a string or zero */ + if (user_number_of_repetitions == 0) { + fprintf(stderr, "Error ... Invalid value for option '-n'.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is too large */ + if (user_number_of_repetitions > MAX_NUMBER_OF_REPETITIONS) { + fprintf(stderr, "Error ... Value for option '-n' cannot be " + "more than %d.\n", MAX_NUMBER_OF_REPETITIONS); + exit(EXIT_FAILURE); + } + number_of_repetitions = user_number_of_repetitions; + } else { + exit(EXIT_FAILURE); + } + } + + /* Create an array of strings with random content */ + srand(1); + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + gen_random_string(random_strings[i].chars, MAX_STRING_LENGHT); + } + + /* Perform uppercasing of a set of random strings multiple times */ + for (size_t j = 0; j < number_of_repetitions; j++) { + /* Copy initial set of random strings to the set to be uppercased */ + memcpy(strings_to_be_uppercased, random_strings, + NUMBER_OF_RANDOM_STRINGS * (MAX_STRING_LENGHT + 1)); + /* Do actual changing case to uppercase */ + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + int k = 0; + + while (strings_to_be_uppercased[i].chars[k]) { + char ch = strings_to_be_uppercased[i].chars[k] - 32; + memcpy((void *)strings_to_be_uppercased[i].chars + k, + &ch, 1); + k++; + } + } + } + + /* Control printing */ + printf("CONTROL RESULT: (toupper_string)\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", random_strings[i].chars); + } + printf("\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", strings_to_be_uppercased[i].chars); + } + printf("\n"); +} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880332 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880332 new file mode 100644 index 00000000..7bbdf974 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880332 @@ -0,0 +1,10 @@ + + + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880722 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880722 new file mode 100644 index 00000000..c4c29c70 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1880722 @@ -0,0 +1,17 @@ + + + +Problems related to checking page crossing in use_goto_tb() + +The discussion that led to this bug discovery can be found in this +mailing list thread: +https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html + +A workaround for this problem would be to check for page crossings for +both the user and system modes in the use_goto_tb() function across +targets. Some targets like "hppa" already implement this fix but others +don't. + +To solve the root cause of this problem, the linux-user/mmap.c should +be fixed to do all the invalidations required. By doing so, up to 6.93% +performance improvements will be achieved. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1881450 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1881450 new file mode 100644 index 00000000..37d7e0e6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1881450 @@ -0,0 +1,26 @@ + + + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1883268 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1883268 new file mode 100644 index 00000000..97be215b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1883268 @@ -0,0 +1,40 @@ + + + +random errors on aarch64 when executing __aarch64_cas8_acq_rel + +Hello, + +Since I upgraded to qemu-5.0 when executing the GCC testsuite, +I've noticed random failures of g++.dg/ext/sync-4.C. + +I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain) + +The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI. + +In seems the problem occurs in f13, which leads to a call to abort() + +The preprocessed version of f13/t13 are as follows: +static bool f13 (void *p) __attribute__ ((noinline)); +static bool f13 (void *p) +{ + return (__sync_bool_compare_and_swap((ditype*)p, 1, 2)); +} +static void t13 () +{ + try { + f13(0); + } + catch (...) { + return; + } + abort(); +} + + +When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084) +__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0) + +I'm not quite sure what's wrong :-( + +I've not noticed such random problems with native aarch64 hardware. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888303 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888303 new file mode 100644 index 00000000..a6c3d6e8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888303 @@ -0,0 +1,23 @@ + + + +Intermittent buggines with user mode emulation of x86-64 on aarch64 + +QEMU Version: 5.0.0 +./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static + +Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm + +aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. + +On aarch64 machine, invoke: + +./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile + +Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. + +But, about once every 10 times, it will not sefault and will continue working just fine forever. + +The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. + +This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888728 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888728 new file mode 100644 index 00000000..68b6cce8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1888728 @@ -0,0 +1,22 @@ + + + +Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. + +Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: + +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. +Aborted +root@nofan:~/qemu> + +The problem can be worked around by bind-mounting /proc from the host system into the target chroot: + +root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +(sid-m68k-sbuild)root@nofan:/# + +Host system is an up-to-date Debian unstable (2020-07-23). + +I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1889411 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1889411 new file mode 100644 index 00000000..fae0a101 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1889411 @@ -0,0 +1,66 @@ + + + +RISC-V: Unable to unwind the stack upon signals + +Consider the following program: + +=============================================================== +#include <stdio.h> +#include <stdlib.h> + +#define NOINLINE __attribute__ ((noinline)) + +void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } + +void NOINLINE level1(void) { abort_me(); } + +void NOINLINE level2(void) { level1(); } + +void NOINLINE level3(void) { level2(); } + +void NOINLINE level4(void) { level3();} + +int main(void) { + level4(); + return 0; +} +=============================================================== + +$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c +$ qemu-riscv64 -g 31337 ./c & +$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c +Reading symbols from c... +Remote debugging using localhost:31337 +Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... +0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 +Breakpoint 1 at 0x4000000632: file c.c, line 7. +Continuing. + +Breakpoint 1, abort_me () at c.c:7 +7 abort(); /* trigger SIGABRT */ +#0 abort_me () at c.c:7 +#1 0x0000004000000642 in level1 () at c.c:11 +#2 0x0000004000000658 in level2 () at c.c:15 +#3 0x000000400000066e in level3 () at c.c:19 +#4 0x0000004000000684 in level4 () at c.c:23 +#5 0x000000400000069a in main () at c.c:27 +=============================================================== + +So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0x0000004000858074 in ?? () +(gdb) bt +#0 0x0000004000858074 in ?? () + + + +I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. + + +Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b +RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1890 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1890 new file mode 100644 index 00000000..bacc2dcb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1890 @@ -0,0 +1,28 @@ + + + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1894029 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1894029 new file mode 100644 index 00000000..dbb691fe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1894029 @@ -0,0 +1,42 @@ + + + +qemu-i386 malloc error + +Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. +This is my test program: + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, char **argv) +{ + void *pa=0,*pb=0,*pc=0,*pd=0; + pa = malloc(sizeof(uint32_t)); + pb = malloc(sizeof(uint32_t)); + pc = malloc(4); + pd = malloc(4); + printf("pa: 0x%x\n",pa); + printf("pb: 0x%x\n",pb); + printf("pc: 0x%x\n",pc); + printf("pd: 0x%x\n",pd); + printf("uint32_t:%d\n",sizeof(uint32_t)); + free(pa); + free(pb); + free(pc); + free(pd); + return 0; +} + +And it is wrong: + +pa: 0x400051a0 +pb: 0x400051b0 +pc: 0x400051c0 +pd: 0x400051d0 +uint32_t:4 + +Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? +Is it a BUG?? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895080 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895080 new file mode 100644 index 00000000..eb26fb5f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895080 @@ -0,0 +1,39 @@ + + + +pgb_reserved_va: Assertion `addr == test' failed + +This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-user. + +Firstly, compile fails: +Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) + FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), + +I have to add below include to linux-user/strace.c +diff --git a/linux-user/strace.c b/linux-user/strace.c +index 11fea14fba..22e51d4a8a 100644 +--- a/linux-user/strace.c ++++ b/linux-user/strace.c +@@ -7,6 +7,7 @@ + #include <sys/mount.h> + #include <arpa/inet.h> + #include <netinet/tcp.h> ++#include <linux/falloc.h> + #include <linux/if_packet.h> + #include <linux/netlink.h> + #include <sched.h> + +Then trying qemu-riscv32 with a simple ELF, I get: +linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. + +strace shows that: +mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +) = 103 + +The source code is in the function pgb_reserved_va (linux-user/elfload.c). I think mmap cannot guarantee that the returned pointer (test) equals to the parameter of addr. So is this a bug to assert (addr == test)? + +Attached configure script and test ELF file. + +Thanks. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895305 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895305 new file mode 100644 index 00000000..7776d39c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895305 @@ -0,0 +1,51 @@ + + + +pthread_cancel fails with "RT33" with musl libc + +From my testing it seems that QEMU built against musl libc crashes on pthread_cancel cancel calls - if the binary is also built with musl libc. + +Minimal sample: + +#include <pthread.h> +#include <stdio.h> +#include <unistd.h> +void* threadfunc(void* ignored) { + while (1) { + pause(); + } + return NULL; +} +int main() { + pthread_t thread; + pthread_create(&thread, NULL, &threadfunc, NULL); + sleep(1); + pthread_cancel(thread); + printf("OK, alive\n"); +} + +In an Alpine Linux aarch64 chroot (on an x86_64 host) the binary will just output RT33 and has exit code 161. + +Using qemu-aarch64 on an x86_64 host results in the output (fish shell) + fish: “qemu-aarch64-static ./musl-stat…” terminated by signal Unknown (Unknown) +or (bash) + Real-time signal 2 + +and exit code 164. + +It doesn't matter whether the binary is linked dynamically or static. You can see my test results in the following table: + +| | QEMU glibc | QEMU musl | +|----------------------|------------|-----------| +| binary glibc dynamic | ✓ | ✓ | +| binary glibc static | ✓ | ✓ | +| binary musl dynamic | ✓ | ✗ | +| binary musl static | ✓ | ✗ | + +Both QEMU builds are v5.1.0 (glibc v2.32 / musl v1.2.1) + +I've uploaded all my compile and test commands (plus a script to conveniently run them all) to https://github.com/z3ntu/qemu-pthread_cancel . It also includes the built binaries if needed. The test script output can be found at https://github.com/z3ntu/qemu-pthread_cancel/blob/master/results.txt + +Further links: +- https://gitlab.com/postmarketOS/pmaports/-/issues/190#note_141902075 +- https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1970 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895703 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895703 new file mode 100644 index 00000000..d32f52a0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1895703 @@ -0,0 +1,21 @@ + + + +performance degradation in tcg since Meson switch + +The buildsys conversion to Meson (1d806cef0e3..7fd51e68c34) +introduced a degradation in performance in some TCG targets: + +-------------------------------------------------------- +Test Program: matmult_double +-------------------------------------------------------- +Target Instructions Previous Latest + 1d806cef 7fd51e68 +---------- -------------------- ---------- ---------- +alpha 3 233 957 639 ----- +7.472% +m68k 3 919 110 506 ----- +18.433% +-------------------------------------------------------- + +Original report from Ahmed Karaman with further testing done +by Aleksandar Markovic: +https://<email address hidden>/msg740279.html \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1904259 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1904259 new file mode 100644 index 00000000..df07207a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1904259 @@ -0,0 +1,32 @@ + + + +include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686) + +Hello. +I haven't found any "official" executables, for emulating RISC-V (32bit; 64bit) so I had to compile those myself. + +I found that auto-generated build scripts, for Ninja, contained some warnings interpreted as errors: + + +oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1 +[2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o +FAILED: libqemuutil.a.p/util_qsp.c.o +clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers -iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote /home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg -iquote /home/oceanfish81/Desktop/qemu/include -iquote /home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function -fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d -o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c +In file included from ../util/qsp.c:62: +In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4: +In file included from /home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10: +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] + qatomic_set__nocheck(ptr, val); + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded from macro 'qatomic_set__nocheck' + __atomic_store_n(ptr, i, __ATOMIC_RELAXED) + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] + return qatomic_read__nocheck(ptr); + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded from macro 'qatomic_read__nocheck' + __atomic_load_n(ptr, __ATOMIC_RELAXED) + ^ +2 errors generated. +ninja: build stopped: subcommand failed. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1906536 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1906536 new file mode 100644 index 00000000..ce49bf0b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1906536 @@ -0,0 +1,33 @@ + + + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 + +Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. + +To reproduce the issue: + +$ cat rdvl.s +.global _start +_start: + rdvl x0, #1 + asr x0, x0, #4 + mov x8, #93 // exit + svc #0 +$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o +$ aarch64-linux-gnu-ld rdvl.o +$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done +1 +2 +4 +4 +4 + +For a QEMU built prior to the above revision, we get the output: +1 +2 +4 +8 +16 + +as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1907817 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1907817 new file mode 100644 index 00000000..dc04f7b7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1907817 @@ -0,0 +1,46 @@ + + + +qemu-aarch64 tcg assertion v5.2.0 + +After updating to 5.2 I am getting following assertion error: +qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed. + +I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762 + +Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following: + +max_align = maxsz >= 16 ? 15 : 7; +tcg_debug_assert((maxsz & max_align) == 0); <--- here assertion happens + +in my case maxsz=56. + + +Whole backtrace: +#4 0x0000004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54 +#5 0x0000004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89 +#6 0x0000004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630 +#7 0x00000040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679 +#8 0x0000004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538 +#9 0x0000004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592 +#10 0x0000004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600 +--Type <RET> for more, q to quit, c to continue without paging-- +#11 0x0000004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608 +#12 0x0000004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0) + at ../target/arm/translate-a64.c:6988 +#13 0x0000004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299 +#14 0x0000004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389 +#15 0x000000400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494 +#16 0x000000400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663 +#17 0x000000400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823 +#18 0x00000040002e8630 in translator_loop (ops=0x4000902e00 <aarch64_translator_ops>, db=0x40021a8180, cpu=0x7fac59b63150, + tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103 +#19 0x00000040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512) + at ../target/arm/translate.c:9283 +#20 0x00000040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216) + at ../accel/tcg/translate-all.c:1744 +#21 0x000000400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414 +--Type <RET> for more, q to quit, c to continue without paging-- +#22 0x000000400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770 +#23 0x0000004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84 +#24 0x00000040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1908551 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1908551 new file mode 100644 index 00000000..42a66cbf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1908551 @@ -0,0 +1,57 @@ + + + +aarch64 SVE emulation breaks strnlen and strrchr + +arm optimized-routines have sve string functions with test code. + +the test worked up until recently: with qemu-5.2.0 i see + +$ qemu-aarch64 build/bin/test/strnlen +PASS strnlen +PASS __strnlen_aarch64 +__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80" +__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c" +__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00" +__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +FAIL __strnlen_aarch64_sve + +however the test passes with + +qemu-aarch64 -cpu max,sve-max-vq=2 + +there should be nothing vector length specific in the code. + +i haven't debugged it further, to reproduce the issue clone +https://github.com/ARM-software/optimized-routines + +and run 'make build/bin/test/strnlen' with a config.mk like + +SUBS = string +ARCH = aarch64 +CROSS_COMPILE = aarch64-none-linux-gnu- +CC = $(CROSS_COMPILE)gcc +CFLAGS = -std=c99 -pipe -O3 +CFLAGS += -march=armv8.2-a+sve +EMULATOR = qemu-aarch64 + +(native compilation works too, and you can run 'make check' to +run all string tests) this will build a static linked executable +into build/bin/test. if you want a smaller test case edit +string/test/strnlen.c \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1909921 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1909921 new file mode 100644 index 00000000..ed041b77 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1909921 @@ -0,0 +1,25 @@ + + + + Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e + +Hello, + +I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). +I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. + +This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. +The error given by qemu is the following : + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e + +(The pc= value is always different, I guess it is randomly generated). + +My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) + +Could you please help me? Why am I facing this error? + +Feel free to ask any questions regarding this matter in order to find a solution to it! + +Regards \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913 new file mode 100644 index 00000000..155199be --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913 @@ -0,0 +1,22 @@ + + + +Regression in 8.1.1: qemu-aarch64-static running ldconfig +Description of problem: +Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) +Steps to reproduce: +1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ +2. Extract it +3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 + +```bash +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.0 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<works> +$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.1 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<segfault> +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913913 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913913 new file mode 100644 index 00000000..65ce919d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1913913 @@ -0,0 +1,21 @@ + + + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1914870 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1914870 new file mode 100644 index 00000000..9a7c055b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1914870 @@ -0,0 +1,60 @@ + + + +libvixl compilation failure on Debian unstable + +As of commit 0e324626306: + +$ lsb_release -d +Description: Debian GNU/Linux bullseye/sid + +Project version: 5.2.50 +C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") +C linker for the host machine: cc ld.bfd 2.35.1 +C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 10.2.1 20210110") +C++ linker for the host machine: c++ ld.bfd 2.35.1 + +[6/79] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +c++ -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -Werror -std=gnu++11 -O2 -g -isystem /home/philmd/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/philmd/qemu -iquote /home/philmd/qemu/include -iquote /home/philmd/qemu/disas/libvixl -iquote /home/philmd/qemu/tcg/hppa -iquote /home/philmd/qemu/accel/tcg -pthread -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fPIE -MD -MQ libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:36:43: error: missing binary operator before token "(" + 36 | #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \ + | ^ +/usr/include/string.h:53:62: error: missing binary operator before token "(" + 53 | #if defined __USE_MISC || defined __USE_XOPEN || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:165:21: error: missing binary operator before token "(" + 165 | || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X)) + | ^ +/usr/include/string.h:174:43: error: missing binary operator before token "(" + 174 | #if defined __USE_XOPEN2K8 || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:492:19: error: missing binary operator before token "(" + 492 | #if __GNUC_PREREQ (3,4) + | ^ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:28:1: error: ‘__BEGIN_DECLS’ does not name a type + 28 | __BEGIN_DECLS + | ^~~~~~~~~~~~~ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:44:8: error: ‘size_t’ has not been declared + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~ +/usr/include/string.h:44:20: error: expected initializer before ‘__THROW’ + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:47:56: error: ‘size_t’ has not been declared + 47 | extern void *memmove (void *__dest, const void *__src, size_t __n) + | ^~~~~~ +/usr/include/string.h:48:6: error: expected initializer before ‘__THROW’ + 48 | __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:61:42: error: ‘size_t’ has not been declared + 61 | extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1)); + | ^~~~~~ + +Is there a package dependency missing? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1915531 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1915531 new file mode 100644 index 00000000..dc0a16e5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1915531 @@ -0,0 +1,57 @@ + + + +qemu-user child process hangs when forking due to glib allocation + +I and others have recently been using qemu-user for RISCV64 extensively. We have had many hangs. We have found that hangs happen in process with multiple threads and forking. For example +`cargo` (a tool for the Rust compiler). + +It does not matter if there are a lot of calls to fork. What seems to matter most is that there are many threads running. So this happens more often on a CPU with a massive number of cores, and if nothing else is really running. The hang happens in the child process of the fork. + +To reproduce the problem, I have attached an example of C++ program to run through qemu-user. + +Here are the stacks of the child processes that hanged. This is for qemu c973f06521b07af0f82893b75a1d55562fffb4b5 with glib 2.66.4 + +------- +Thread 1: +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x00007f54e190c77c in g_mutex_lock_slowpath (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1462 +#2 0x00007f54e190d222 in g_mutex_lock (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1486 +#3 0x00007f54e18e39f2 in magazine_cache_pop_magazine (countp=0x7f54280e6638, ix=2) at ../glib/gslice.c:769 +#4 thread_memory_magazine1_reload (ix=2, tmem=0x7f54280e6600) at ../glib/gslice.c:845 +#5 g_slice_alloc (mem_size=mem_size@entry=40) at ../glib/gslice.c:1058 +#6 0x00007f54e18f06fa in g_tree_node_new (value=0x7f54d4066540 <code_gen_buffer+419091>, key=0x7f54d4066560 <code_gen_buffer+419123>) at ../glib/gtree.c:517 +#7 g_tree_insert_internal (tree=0x555556aed800, key=0x7f54d4066560 <code_gen_buffer+419123>, value=0x7f54d4066540 <code_gen_buffer+419091>, replace=0) at ../glib/gtree.c:517 +#8 0x00007f54e186b755 in tcg_tb_insert (tb=0x7f54d4066540 <code_gen_buffer+419091>) at ../tcg/tcg.c:534 +#9 0x00007f54e1820545 in tb_gen_code (cpu=0x7f54980b4b60, pc=274906407438, cs_base=0, flags=24832, cflags=-16252928) at ../accel/tcg/translate-all.c:2118 +#10 0x00007f54e18034a5 in tb_find (cpu=0x7f54980b4b60, last_tb=0x7f54d4066440 <code_gen_buffer+418835>, tb_exit=0, cf_mask=524288) at ../accel/tcg/cpu-exec.c:462 +#11 0x00007f54e1803bd9 in cpu_exec (cpu=0x7f54980b4b60) at ../accel/tcg/cpu-exec.c:818 +#12 0x00007f54e1735a4c in cpu_loop (env=0x7f54980bce40) at ../linux-user/riscv/cpu_loop.c:37 +#13 0x00007f54e1844b22 in clone_func (arg=0x7f5402f3b080) at ../linux-user/syscall.c:6422 +#14 0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477 +#15 0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2: +#1 0x00007f54e18a8d6e in qemu_futex_wait (f=0x7f54e1dc7038 <rcu_call_ready_event>, val=4294967295) at /var/home/valentin/repos/qemu/include/qemu/futex.h:29 +#2 0x00007f54e18a8f32 in qemu_event_wait (ev=0x7f54e1dc7038 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:460 +#3 0x00007f54e18c0196 in call_rcu_thread (opaque=0x0) at ../util/rcu.c:258 +#4 0x00007f54e18a90eb in qemu_thread_start (args=0x7f5428244930) at ../util/qemu-thread-posix.c:521 +#5 0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +------- + +Thread 1 seems to be the really hanged process. + +The problem is that glib is used in many places. Allocations are done through g_slice. g_slice has a global state that is not fork safe. + +So even though the cpu thread is set to exclusive before forking, it is not enough. Because there are other uses of glib data structures that are not part of the cpu loop (I think). So it seems not to be synchronized by `start_exclusive`, `end_exclusive`. + +So if one of the use of glib data structure is used during the fork, an allocation might lock a mutex in g_slice. + +When the cpu loop resumes in forked process, then the use of any glib data structure might just hang on a locked mutex in g_slice. + +So as a work-around we have starting using is setting environment `G_SLICE=always-malloc`. This resolves the hangs. + +I have opened an issue upstream: https://gitlab.gnome.org/GNOME/glib/-/issues/2326 + +As fork documentation says, the child should be async-signal-safe. However, glibc's malloc is safe in fork child even though it is not async-signal-safe. So it is not that obvious where the responsability is. Should glib handle this case like malloc does? Or should qemu not use glib in the fork child? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1916344 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1916344 new file mode 100644 index 00000000..5d13405e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1916344 @@ -0,0 +1,27 @@ + + + +User mode networking not working properly on QEMU on Mac OS X host + +Steps to reproduce: + +1. Install QEMU using homebrew on Mac OS X (I used Big Sur) +2. Spin up a guest VM (say) Cent OS8 using user mode networking. +3. Install podman inside the guest +4. Run podman pull alpine + +The result is: + +[root@localhost ~]# podman pull alpine +Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) +Trying to pull docker.io/library/alpine:latest... +Getting image source signatures +Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB + unexpected EOF +Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF + +This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. + +This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. + +This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1917184 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1917184 new file mode 100644 index 00000000..f7314da8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1917184 @@ -0,0 +1,8 @@ + + + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1926202 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1926202 new file mode 100644 index 00000000..8a2a96e8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1926202 @@ -0,0 +1,21 @@ + + + +qemu-user can't run some ppc binaries + +qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. + +The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: + +$ uname -m +x86_64 +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t qemu-bug:centos -f Dockerfile.centos . +$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . +$ qemu-ppc version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-ppc-static ./helloworld-centos.static.ppc +emu: uncaught target signal 4 (Illegal instruction) - core dumped +[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc + +I can also provide the binary if necessary. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1930 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1930 new file mode 100644 index 00000000..65a18ca7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1930 @@ -0,0 +1,49 @@ + + + +qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX +Description of problem: +We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` + +We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error. +Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated. +Steps to reproduce: +1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178. +2. Write a simple hello world program. + +``` + #include <stdio.h> + + int main(void) { + return printf("Hello World!"); + } +``` + +3. Source QNX SDP to set some environment variables. + + `$ source ./qnx710/qnxsdp-env.sh` + +4. Compile using the QNX compiler. + + `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c` + +5. Running the binary as it is results to: + +``` + $ ./hello-world + aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory +``` + +5. Running using QEMU emulator results to segmentation fault. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1936977 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1936977 new file mode 100644 index 00000000..50182117 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1936977 @@ -0,0 +1,10 @@ + + + + qemu-arm-static crashes "segmentation fault" when running "git clone" + +This is a reopen of #1869073 for `qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.17 amd64`. + +`git clone` reproducably segfaults in `qemu-arm-static` chroot. + +#1869073 mentions this should have been fixed for newer versions of QEMU, but for `focal` there's no newer version available, even in `focal-backports`. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1952 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1952 new file mode 100644 index 00000000..b08e1312 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1952 @@ -0,0 +1,99 @@ + + + +elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader +Description of problem: +Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this + +``` +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Steps to reproduce: +1. Obtain latest Zig nightly +2. Compile simple static C program using Zig's ELF linker: + +``` +$ echo "int main() { return 0 };" > simple.c +$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000 +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Additional information: +Note that running `simple` directly it's correctly mmaped and executed by the kernel: + +``` +$ ./simple +$ echo $status +0 +``` + +The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely: + +``` +vaddr2 - vaddr1 >= off2 - off1 +``` + +Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault: + +```diff +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index f21e2e0c3d..eabb4fed03 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd, + for (i = 0; i < ehdr->e_phnum; ++i) { + struct elf_phdr *eppnt = phdr + i; + if (eppnt->p_type == PT_LOAD) { +- abi_ulong a = eppnt->p_vaddr - eppnt->p_offset; ++ abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1); + if (a < loaddr) { + loaddr = a; + } +``` + +The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig: + +``` +$ readelf -l simple + +Elf file type is EXEC (Executable file) +Entry point 0x1002000 +There are 7 program headers, starting at offset 64 + +Program Headers: + Type Offset VirtAddr PhysAddr + FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000001000040 0x0000000001000040 + 0x0000000000000188 0x0000000000000188 R 0x8 + LOAD 0x0000000000000000 0x0000000001000000 0x0000000001000000 + 0x00000000000001c8 0x00000000000001c8 R 0x1000 + LOAD 0x0000000000021000 0x0000000001001000 0x0000000001001000 + 0x0000000000000078 0x0000000000000078 R 0x1000 + LOAD 0x0000000000022000 0x0000000001002000 0x0000000001002000 + 0x000000000000065a 0x000000000000065a R E 0x1000 + LOAD 0x0000000000023000 0x0000000001003000 0x0000000001003000 + 0x0000000000000060 0x0000000000000278 RW 0x1000 + GNU_EH_FRAME 0x0000000000021064 0x0000000001001064 0x0000000001001064 + 0x0000000000000014 0x0000000000000014 R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 + 0x0000000000000000 0x0000000000000000 RW 0x1 + + Section to Segment mapping: + Segment Sections... + 00 + 01 + 02 .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr + 03 .text .init .fini + 04 .data .got .bss + 05 .eh_frame_hdr + 06 +``` + +As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get + +``` +a := 0x1001000 - 0x21000 = 0xfe000 +``` + +and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1953 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1953 new file mode 100644 index 00000000..700d78cd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/1953 @@ -0,0 +1,149 @@ + + + +Segmentation fault when compiling elixir app on qemu aarch64 on x86_64 host +Description of problem: +When I try to install an elixir escript using + +``` +mix escript.install github upmaru/pakman --force +``` + +I run into a segfault with the following output + +``` + + +Build and Deploy +failed Oct 22, 2023 in 1m 27s +2s +2s +22s +56s +remote: Compressing objects: 86% (144/167) +remote: Compressing objects: 87% (146/167) +remote: Compressing objects: 88% (147/167) +remote: Compressing objects: 89% (149/167) +remote: Compressing objects: 90% (151/167) +remote: Compressing objects: 91% (152/167) +remote: Compressing objects: 92% (154/167) +remote: Compressing objects: 93% (156/167) +remote: Compressing objects: 94% (157/167) +remote: Compressing objects: 95% (159/167) +remote: Compressing objects: 96% (161/167) +remote: Compressing objects: 97% (162/167) +remote: Compressing objects: 98% (164/167) +remote: Compressing objects: 99% (166/167) +remote: Compressing objects: 100% (167/167) +remote: Compressing objects: 100% (167/167), done. +remote: Total 2568 (delta 86), reused 188 (delta 58), pack-reused 2341 +origin/HEAD set to develop +Resolving Hex dependencies... +Resolution completed in 0.872s +New: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +* Getting tesla (Hex package) +* Getting jason (Hex package) +* Getting yaml_elixir (Hex package) +* Getting slugger (Hex package) +* Getting finch (Hex package) +* Getting mint (Hex package) +* Getting castore (Hex package) +* Getting hpax (Hex package) +* Getting mime (Hex package) +* Getting nimble_options (Hex package) +* Getting nimble_pool (Hex package) +* Getting telemetry (Hex package) +* Getting yamerl (Hex package) +Resolving Hex dependencies... +Resolution completed in 0.413s +Unchanged: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +All dependencies are up to date +==> mime +Compiling 1 file (.ex) +Generated mime app +==> nimble_options +Compiling 3 files (.ex) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Create a repo using the github action zacksiri/setup-alpine +2. Install elixir +3. run `mix escript.install github upmaru/pakman --force` +Additional information: +You can use the following github action config as an example / starting point. + + +```yml +name: 'Deployment' + +on: + push: + branches: + - main + - master + - develop + +jobs: + build_and_deploy: + name: Build and Deploy + runs-on: ubuntu-latest + steps: + - name: 'Checkout' + uses: actions/checkout@v3 + with: + ref: ${{ github.event.workflow_run.head_branch }} + fetch-depth: 0 + + - name: 'Setup Alpine' + uses: zacksiri/setup-alpine@master + with: + branch: v3.18 + arch: aarch64 + qemu-repo: edge + packages: | + zip + tar + sudo + alpine-sdk + coreutils + cmake + elixir + + - name: 'Setup PAKman' + run: | + export MIX_ENV=prod + + mix local.rebar --force + mix local.hex --force + mix escript.install github upmaru/pakman --force + shell: alpine.sh {0} +``` + +I'm using alpine 3.18 which has otp25 with jit enabled so I suspect this is something to do with https://gitlab.com/qemu-project/qemu/-/issues/1034 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2027 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2027 new file mode 100644 index 00000000..f9fb7e78 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2027 @@ -0,0 +1,236 @@ + + + +Go runtime panic with qemu-x86_64-static on aarch64 (bisected) +Description of problem: +I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0: + +``` +first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h +``` +Steps to reproduce: +1. Build example Go program `GOARCH=amd64 go build -o crashing .` +2. Run it with `qemu-x86_64-static ./crashing` + +<details><summary>Go program to reproduce</summary> + +```go +package main + +import "crypto/x509" + +func main() { + x509.SystemCertPool() +} +``` + +</details> +Additional information: +<details><summary>Go program stacktrace</summary> + +``` +runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0x52cb61?, 0x2ce5?}) + /usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c +runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?) + /usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25 +runtime.(*spanSetBlockAlloc).free(...) + /usr/lib/golang/src/runtime/mspanset.go:322 +runtime.(*spanSet).reset(0x64d220) + /usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79 +runtime.finishsweep_m() + /usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455 +runtime.gcStart.func2() + /usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f +traceback: unexpected SPWRITE function runtime.systemstack +runtime.systemstack() + /usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108 +runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?}) + /usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05 +runtime.mallocgc(0x98370, 0x50bb80, 0x1) + /usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf +runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?) + /usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729 +os.ReadFile({0xc00035a0f0?, 0x52dcd6?}) + /usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25 +crypto/x509.loadSystemRoots() + /usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4 +crypto/x509.initSystemRoots() + /usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc +sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?) + /usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff +sync.(*Once).Do(...) + /usr/lib/golang/src/sync/once.go:65 +crypto/x509.systemRootsPool() + /usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5 +crypto/x509.SystemCertPool() + /usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705 +main.main() + /home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f +runtime.main() + /usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.forcegchelper() + /usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61 +created by runtime.init.6 in goroutine 1 + /usr/lib/golang/src/runtime/proc.go:310 +0x1a + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.bgsweep(0x0?) + /usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf +runtime.gcenable.func1() + /usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61 +created by runtime.gcenable in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:200 +0x66 + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e +runtime.goparkunlock(...) + /usr/lib/golang/src/runtime/proc.go:404 +runtime.(*scavengerState).park(0x625680) + /usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49 +runtime.bgscavenge(0x0?) + /usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9 +runtime.gcenable.func2() + /usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61 +created by runtime.gcenable in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:201 +0xa5 + +goroutine 17 [finalizer wait]: +runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e +runtime.runfinq() + /usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61 +created by runtime.createfing in goroutine 1 + /usr/lib/golang/src/runtime/mfinal.go:163 +0x3d + +goroutine 18 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 19 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 33 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 20 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 49 [GC worker (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 21 [GC worker (idle)]: +runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 22 [GC worker (idle)]: +runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 23 [GC worker (idle)]: +runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 24 [GC worker (idle)]: +runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c + +goroutine 34 [GC worker (idle)]: +runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?) + /usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e +runtime.gcBgMarkWorker() + /usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5 +runtime.goexit() + /usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61 +created by runtime.gcBgMarkStartWorkers in goroutine 1 + /usr/lib/golang/src/runtime/mgc.go:1217 +0x1c +exit status 2 +``` + +</details> diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2035 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2035 new file mode 100644 index 00000000..11a2bf38 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2035 @@ -0,0 +1,57 @@ + + + +TCG Plugin exit callback not executing +Description of problem: +I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success. + +**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?** +Steps to reproduce: +1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system` +2. Compiled plugin with +``` +gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0` +``` +3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu` +4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu +Additional information: +test_plugin.c +``` +#include <inttypes.h> +#include <assert.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <stdio.h> +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + int n_insns = qemu_plugin_tb_n_insns(tb); + printf("> New TB of size %d\n", n_insns); + + for (int i = 0; i < n_insns; i++) { + struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i); + char * disassembly = qemu_plugin_insn_disas(insn); + printf(" > Instruciton: %s\n", disassembly); + } +} + +static void plugin_exit(qemu_plugin_id_t id, void *p) +{ + printf("> Goodbye from plugin. %d\n", id); +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, + int argc, char **argv) +{ + printf("> Hello From Plugin!\n"); + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); + printf("> Everything was registered\n"); + return 0; +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2072564 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2072564 new file mode 100644 index 00000000..3a9c3be0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2072564 @@ -0,0 +1,48 @@ + + + +qemu-aarch64-static segfaults running ldconfig.real (amd64 host) + +This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host. + +When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example: + +$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@8861ff640a1c:/# /sbin/ldconfig.real +Segmentation fault + +If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static: + +$ gdb --args qemu-aarch64-static ./ldconfig.real +GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git +Copyright (C) 2024 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-aarch64-static... +Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo... +(gdb) r +Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff76006c0 (LWP 28378)] + +Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault. +0x00007fffe801645b in ?? () +(gdb) disassemble +No function contains program counter for selected frame. + +It looks like this is a known qemu regression after v8.1.1: +https://gitlab.com/qemu-project/qemu/-/issues/1913 + +Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2082 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2082 new file mode 100644 index 00000000..33b0f7a9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2082 @@ -0,0 +1,47 @@ + + + +"Unable to find a guest_base to satisfy all guest address mapping requirements" running certain x86_64 binaries on aarch64 host +Description of problem: +Copying from: + + https://bugzilla.redhat.com/show_bug.cgi?id=2256916 + +With ``qemu-x86_64-static`` from ``qemu-8.1.3-1.fc39``, I can no longer run on the m1 the ``x86_64`` binary created by https://github.com/containers/PodmanHello + +If I try with ``qemu-x86_64-static`` from ``qemu-7.2.7-1.fc38`` then this works. + +If I build the binary manually on a fc39 x86 system with ``gcc -O2 -static -o podman_hello_world podman_hello_world.c``, then I can also run it successfully with ``qemu-8.1.3-1.fc39``. +It's only the static binary built inside the alpine container which cannot be run on the M1. + + +Misc tests I ran: + +``` +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.alpine +qemu-x86_64-static-8.1.3: /var/roothome/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef + +$ ./qemu-x86_64-static-7.2.7 podman_hello_world.alpine +!... Hello Podman World ...! +[...] + +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.fc39 +!... Hello Podman World ...! +[...] +``` + +The issue is still present with ``qemu-8.2.0-0.3.rc2.fc40`` + +I also could not reproduce on ``x86_64`` machines. I just tried it on fc39 installed on non-Apple ``aarch64`` hardware, and I'm seeing the same issue: + +``` +# rpm -qf /usr/bin/qemu-x86_64-static +qemu-user-static-x86-8.1.3-1.fc39.aarch64 + +# qemu-x86_64-static ./podman_hello_world.alpine +qemu-x86_64-static: /root/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2101 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2101 new file mode 100644 index 00000000..eefe4805 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2101 @@ -0,0 +1,20 @@ + + + +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2119 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2119 new file mode 100644 index 00000000..c2d7b188 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2119 @@ -0,0 +1,4 @@ + + + +target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed when the single-letter V is enabled diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2127 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2127 new file mode 100644 index 00000000..083ec4b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2127 @@ -0,0 +1,4 @@ + + + +test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2156 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2156 new file mode 100644 index 00000000..4e1504da --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2156 @@ -0,0 +1,18 @@ + + + +Userland QEMU segfaults when emulating itself thrice +Description of problem: +See title. +``` +$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0} +[1] 15705 segmentation fault (core dumped) qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +``` +Steps to reproduce: +1. Execute command above +Additional information: +Coredump (~322MB uncompressed) +[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz) + +SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2157 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2157 new file mode 100644 index 00000000..0223b0aa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2157 @@ -0,0 +1,46 @@ + + + +qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB +Description of problem: +`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB +(such as LoongArch, ppc64le, arm64 with 3 level page tables). +Steps to reproduce: +1. Compile x86 binary which makes a single exit(0) syscall: + ``` + cat > exit0.S << EOF + #include <sys/syscall.h> + .text + .global _start + _start: + movl $__NR_exit, %eax + movl $0, %ebx + int $0x80 + EOF + i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S + ``` + Alternatively one might compile it on a x86 host: + ``` + gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S + ``` + and transfer the `exit0` binary to ppc64/LoongArch/arm64 system + + 2. Run the `exit0` binary with `qemu-i386` + ``` + qemu-i386-static ./exit0 + ``` + + # +Additional information: +`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 + LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 + NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 + GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 +``` + +Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) +alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2208 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2208 new file mode 100644 index 00000000..aceb5eff --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2208 @@ -0,0 +1,91 @@ + + + +PC is not updated for each instruction in TCG plugins +Description of problem: +I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. + +I am using a simple hello-world binary for ARM for my tests: + +```bash +% ./qemu-aarch64 hello-world.out +Hello World! +``` + +I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: + +```bash +% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out +``` + +Here is the end of the execution: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c +0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 +0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 +0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 +0, 0x418e28, 0xd4000001, "svc #0" +``` + +Now, here is the same part of the execution but without the `-one-insn-per-tb` option: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478" +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1" +0, 0x40d39c, 0xd2800001, "movz x1, #0" +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19" +0, 0x405d84, 0x91000694, "add x20, x20, #1" +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23" +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0" +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" +0, 0x418e20, 0xaa0203e0, "mov x0, x2" +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" +0, 0x418e28, 0xd4000001, "svc #0" +``` + +The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: + +> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. + +The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. +Additional information: +The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2223 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2223 new file mode 100644 index 00000000..3331178e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2223 @@ -0,0 +1,38 @@ + + + +Weird behavior on RISC-V code running on QEMU +Description of problem: +I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. + +This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: + +```c +for(int i=0; i < NUMBER_OF_ITEMS; i++){ + createAndPushItem(i); + + // the function above does the exact same thing as the commented code below + // yet, the commented code does not work and will crash the program. but why?? + + // int index = priorities[i]; + // void *value = (void *) getValue(i + 1); + // LinkedListItem_t *item = createItem(index, value); + // if(item){ + // push(item, &list); + // } +} +``` + +The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. +Steps to reproduce: +1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) +2. follow the readme to install the toolchain +3. follow the readme to compile the program and run it +Additional information: +The expected output is supposed to be: + + + +but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: + + diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2304 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2304 new file mode 100644 index 00000000..98b4e73d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2304 @@ -0,0 +1,41 @@ + + + +Disabling SVE via `-cpu max,sve=off` leaves SVE2 advertised by `getauxval` +Description of problem: +The documentation on https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html suggests that it should be possible to disable SVE support by passing `-cpu max,sve=off` on the command line, however this appears to only disable the SVE support advertised in the return value from `getauxval(AT_HWCAP)`. In particular it leaves SVE2 reported as enabled. This leaves the feature set advertised by `getauxval` in an inconsistent state since SVE is mandatory if SVE2 is available. + +This may also affect other feature dependencies for example FEAT_SVE_BITPerm also requiring SVE2 to be available, I've not checked exhaustively. + +For example, given the following code: + + #include <sys/auxv.h> + #include <stdio.h> + + int main() { + unsigned long hwcap = getauxval(AT_HWCAP); + unsigned long hwcap2 = getauxval(AT_HWCAP2); + + if (hwcap & HWCAP_SVE) { + printf("have sve!\n"); + } else { + printf("don't have sve!\n"); + } + if (hwcap2 & HWCAP2_SVE2) { + printf("have sve2!\n"); + } else { + printf("don't have sve2!\n"); + } + } + +We can observe the following: + + $ aarch64-linux-gnu-gcc test.c -static + $ ../qemu-aarch64 -cpu max ./a.out + have sve! + have sve2! + $ ../qemu-aarch64 -cpu max,sve=off ./a.out + don't have sve! + have sve2! + +I don't believe that there is a `-cpu ...,sve2=off` option, so I would expect that disabling SVE also prevents SVE2 from being advertised as available. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2309 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2309 new file mode 100644 index 00000000..41394ee5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2309 @@ -0,0 +1,34 @@ + + + +qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6 +Description of problem: +qemu-aarch64 seems to hang with 100% cpu usage without any indication. +with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c. +Steps to reproduce: +1. Ensure the test env has 2.36-9+deb12u6 +2. Install the latest rust toolchain. +3. mkdir test_test && cargo init +4. ensure src/main.rs has +``` +fn main() { + println!("Hello, world!"); +} + +#[test] +fn test() { + println!("hAAA!"); +} +``` +5. create .cargo/config.toml +``` +[target.aarch64-unknown-linux-gnu] +linker = "aarch64-linux-gnu-gcc" +runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu" +rustflags = ["-C", "target-cpu=neoverse-n1"] +``` +6. cargo test --target aarch64-unknown-linux-gnu +Additional information: +The issue does not seem to occur with libc6:2.36-9+deb12u4 + +The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2460 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2460 new file mode 100644 index 00000000..19cfd6dc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2460 @@ -0,0 +1,11 @@ + + + +Significant performance degradation of qemu-x86_64 starting from version 3 on aarch64 +Description of problem: +When I ran CoreMark with different qemu user-mode versions，guest x86-64-> host arm64, I found that the performance was highest with QEMU 2.x versions, and there was a significant performance degradation starting from QEMU version 3. What is the reason? + +| | | | | | | | | | | | | +|------------------------------------------|-------------|-------------|-------------|-------------|-------------|-------------|------------|-------------|-------------|-------------|-------------| +| qemu version | 2.5.1 | 2.8.0 | 2.9.0 | 2.9.1 | 3.0.0 | 4.0.0 | 5.2.0 | 6.2.0 | 7.2.13 | 8.2.6 | 9.0.1 | +| coremark score | 3905.995703 | 4465.947153 | 4534.119247 | 4538.577912 | 1167.337886 | 1163.399453 | 928.348384 | 1327.051954 | 1301.659616 | 1034.714677 | 1085.304971 | diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2485 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2485 new file mode 100644 index 00000000..31508fdf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2485 @@ -0,0 +1,50 @@ + + + +getifaddrs linked with musl libc hangs on big-endian targets +Description of problem: +When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success. + +```c +#include <stdlib.h> +#include <ifaddrs.h> + +int +main (void) +{ + + struct ifaddrs *ifa = 0; + int error; + + error = getifaddrs(&ifa); + if (error || !ifa) + exit(1); + else + exit(0); + + return 0; +} +``` +Steps to reproduce: +1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/)) +2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`) +3. Observe that the process hangs. +Additional information: +This has come up elsewhere: + +* https://bugs.gentoo.org/914256 +* https://www.openwall.com/lists/musl/2018/05/30/4 +* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain) +* Likely affects sparc but that port/toolchain is also a WIP + +Here are some static sample binaries for the above program: + +* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later) + +GitLab labels seem to be missing: + +* ~"kind::Bug" +* ~"linux-user" +* ~"target: ppc" +* ~"target: m68k" +* ~"target: s390x" diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2486 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2486 new file mode 100644 index 00000000..6cd7e064 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2486 @@ -0,0 +1,15 @@ + + + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2505 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2505 new file mode 100644 index 00000000..3eaa737f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2505 @@ -0,0 +1,4 @@ + + + +Interpreter ELF flags ignored when selecting CPU diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2525 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2525 new file mode 100644 index 00000000..5ba0def1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2525 @@ -0,0 +1,4 @@ + + + +bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2569 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2569 new file mode 100644 index 00000000..2d07cccc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2569 @@ -0,0 +1,8 @@ + + + +The alpha target doesn't support tcg plugin register tracking due to missing XML +Description of problem: +There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this. +Steps to reproduce: +1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2580 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2580 new file mode 100644 index 00000000..cdc12b61 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2580 @@ -0,0 +1,15 @@ + + + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2590 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2590 new file mode 100644 index 00000000..94fcd1b8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2590 @@ -0,0 +1,26 @@ + + + +qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. +Description of problem: +GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. +Steps to reproduce: +1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +``` +Additional information: +This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2596 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2596 new file mode 100644 index 00000000..153a9d45 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2596 @@ -0,0 +1,4 @@ + + + +linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2598 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2598 new file mode 100644 index 00000000..0a978ad0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2598 @@ -0,0 +1,4 @@ + + + +linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2604 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2604 new file mode 100644 index 00000000..eaa3a538 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2604 @@ -0,0 +1,47 @@ + + + +qemu-user-static crash when executing generated NEON code due to failure to detect invalidation +Description of problem: +`qemu-arm-static` crashes 100% of times when attempting to run NEON code. The same executable, when run in `system` emulation mode, works without issue. + +I experience this particular issue when attempting to test GStreamer's Orc library with NEON codegen with QEMU user emulation. +Steps to reproduce: +1. Clone https://gitlab.freedesktop.org/gstreamer/orc.git +2. Build with `meson setup build -Ddefault_library=static; meson compile -C build` +3. Run `qemu-arm-static ./build/tools/orc-bugreport` +Additional information: +The crash always happens inside the same JIT code. It is not a memory access, so there is no reason for QEMU to report SIGSEGV: + +``` +Program received signal SIGSEGV, Segmentation fault. +0x409e503c in ?? () +(gdb) bt +#0 0x409e503c in ?? () +#1 0x00408bc6 in orc_executor_run (ex=0x51cfc0) at ../orc/orcexecutor.c:51 +#2 0x00489692 in orc_test_compare_output_full_for_target (program=0x4bcd90, flags=0, + target_name=0x0) at ../orc-test/orctest.c:800 +#3 0x00489004 in orc_test_compare_output_full (program=0x4bcd90, flags=0) + at ../orc-test/orctest.c:664 +#4 0x00404826 in test_opcode_src (opcode=0x4b098c <opcodes+2400>) + at ../tools/orc-bugreport.c:252 +#5 0x004045d8 in test_opcodes () at ../tools/orc-bugreport.c:188 +#6 0x004043f2 in main (argc=1, argv=0x40800704) at ../tools/orc-bugreport.c:118 +(gdb) disas 0x409e5030 +No function contains specified address. +(gdb) disas 0x409e5030, +10 +Dump of assembler code from 0x409e5030 to 0x409e503a: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +End of assembler dump. +(gdb) disas 0x409e5030, +20 +Dump of assembler code from 0x409e5030 to 0x409e5044: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +=> 0x409e503c: add r3, r3, #16 + 0x409e5040: subs r12, r12, #1 +End of assembler dump. +(gdb) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/261 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/261 new file mode 100644 index 00000000..5e5ce90d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/261 @@ -0,0 +1,4 @@ + + + +broken signal handling in nios2 user-mode emulation diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2619 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2619 new file mode 100644 index 00000000..785f3844 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2619 @@ -0,0 +1,4 @@ + + + +INTEGER_OVERFLOW in nios2.c diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2628 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2628 new file mode 100644 index 00000000..3a92fac0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2628 @@ -0,0 +1,23 @@ + + + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines +Description of problem: +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version + +dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped +Steps to reproduce: +1. debootstrap --arch=arm64 stable /scratch/debian-stable +2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version +Additional information: +Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU + +chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2655 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2655 new file mode 100644 index 00000000..eb6cecce --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2655 @@ -0,0 +1,42 @@ + + + +A problem in target/riscv/vector_helper.c: vext_ldff() +Description of problem: +I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: +``` +static inline void +vext_ldff(...) +{ +... + for (i = env->vstart; i < env->vl; i++) { +... + if (i == 0) { + probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); + } else { +... + flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, + mmu_index, true, &host, 0); +... + if (flags & ~TLB_WATCHPOINT) { + vl = i; + goto ProbeSuccess; + } +... + } + } +ProbeSuccess: +... +} +``` +If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. + +In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? + +This problem occurred in both linux-user mode and full-system mode. + +Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. +Steps to reproduce: +1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. +2. Write a plugin to add memory callbacks. +3. Observe the behavior of the function. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2683 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2683 new file mode 100644 index 00000000..d39a01af --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2683 @@ -0,0 +1,42 @@ + + + +TCG: probe_access() has inconsistent behavior +Description of problem: +In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO. + +accel/tcg/cputlb.c: probe_access_internal() +``` + if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED)) + || (access_type != MMU_INST_FETCH && force_mmio)) { + *phost = NULL; + return TLB_MMIO; + } +``` +But in linux-user mode, it will return correct address when the flag is TLB_MMIO. + +accel/tcg/user-exec.c: probe_access() +``` + return size ? g2h(env_cpu(env), addr) : NULL; +``` +This will lead to some different behaviors, like cbo.zero in RISC-V. + +target/riscv/op_helper.c: helper_cbo_zero() +``` + mem = probe_write(env, address, cbozlen, mmu_idx, ra); + + if (likely(mem)) { + memset(mem, 0, cbozlen); + } else { + for (int i = 0; i < cbozlen; i++) { + cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra); + } + } +``` +When the current instruction has memory callback by plugin: + +Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly. + +Linux-user mode uses fast-path(memset) and doesn't inject callbacks. + +To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2761 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2761 new file mode 100644 index 00000000..83689da6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2761 @@ -0,0 +1,11 @@ + + + +Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements" +Description of problem: +Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements" + +``` +file /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash +/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2775 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2775 new file mode 100644 index 00000000..d4fa3fbd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2775 @@ -0,0 +1,137 @@ + + + +internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached +Description of problem: +qemu crashes with internal assertion: + +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +Steps to reproduce: +1. boot emulated NetBSD/sparc64 system +2. cd /usr/tests && atf-run|atf-report + +not 100% reproducable, but happens often +Additional information: +last output: +``` +IN: +0x4102ce80: sethi %hi(0x29e0000), %g1 +0x4102ce84: b,a 0x40d78220 + +---------------- +IN: +0x41029fc0: sethi %hi(0x1e30000), %g1 +0x41029fc4: b,a 0x40e9ccc0 + +---------------- +IN: +0x4102b5e0: sethi %hi(0x23b8000), %g1 +0x4102b5e4: b,a 0x40e9dc20 + +---------------- +IN: +0x4102a6e0: sethi %hi(0x1ff8000), %g1 +0x4102a6e4: b,a 0x40e9cbc0 + +---------------- +IN: +0x410230e0: sethi %hi(0x278000), %g1 +0x410230e4: b,a 0x40e25d60 + +---------------- +IN: +0x41026920: sethi %hi(0x1088000), %g1 +0x41026924: b,a 0x40d77da0 + +---------------- +IN: +0x41024140: sethi %hi(0x690000), %g1 +0x41024144: b,a 0x40e25f00 + +---------------- +IN: +0x00245c20: sethi %hi(0xc8000), %g1 +0x00245c24: sethi %hi(0x40d77c00), %g1 +0x00245c28: jmp %g1 + 0x1a0 ! 0x40d77da0 +0x00245c2c: nop + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: sethi %hi(0x40d76c00), %g1 +0x00245ba8: jmp %g1 + 0x80 ! 0x40d76c80 +0x00245bac: nop + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: sethi %hi(0x40d76400), %g1 +0x00245e68: jmp %g1 + 0x260 ! 0x40d76660 +0x00245e6c: nop + +---------------- +IN: +0x002465a0: sethi %hi(0x328000), %g1 +0x002465a4: sethi %hi(0x40d69000), %g1 +0x002465a8: jmp %g1 + 0x198 ! 0x40d69198 +0x002465ac: nop + +** +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +``` + +gdb says: +``` +#0 0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000079343d6f7034 in abort () + at /home/martin/current/src/lib/libc/stdlib/abort.c:74 +#2 0x000079343e06a03a in g_assertion_message[cold] () + from /usr/pkg/lib/libglib-2.0.so.0 +#3 0x000079343e03c719 in g_assertion_message_expr () + from /usr/pkg/lib/libglib-2.0.so.0 +#4 0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, + cs=<optimized out>) at ../target/sparc/translate.c:5695 +#5 0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7, + ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80) + at ../accel/tcg/translator.c:152 +#6 0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816 +#7 0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + pc=pc@entry=1206519, host_pc=0x7933f52a58f7, + max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>) + at ../accel/tcg/translate-all.c:278 +#8 0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, + pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, + cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358 +#9 0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993 +#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039 +#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/cpu-exec.c:1065 +#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops.c:78 +#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520) + at ../util/qemu-thread-posix.c:541 +#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000) + at /home/martin/current/src/lib/libpthread/pthread.c:595 +#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/280 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/280 new file mode 100644 index 00000000..a52d19ec --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/280 @@ -0,0 +1,4 @@ + + + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2815 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2815 new file mode 100644 index 00000000..4236102b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2815 @@ -0,0 +1,4 @@ + + + +clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2846 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2846 new file mode 100644 index 00000000..e2a6268f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/2846 @@ -0,0 +1,4 @@ + + + +linux-user hangs if fd_trans_lock is held during fork diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/311 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/311 new file mode 100644 index 00000000..ff15261d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/311 @@ -0,0 +1,4 @@ + + + +qemu user mode: rt signals not implemented for sparc guests diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/324 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/324 new file mode 100644 index 00000000..fe76e37d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/324 @@ -0,0 +1,4 @@ + + + +chrome based apps can not be run under qemu user mode diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/355 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/355 new file mode 100644 index 00000000..8286c0d0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/355 @@ -0,0 +1,4 @@ + + + +A possible divide by zero bug in get_whole_cluster diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/385 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/385 new file mode 100644 index 00000000..1b07af17 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/385 @@ -0,0 +1,4 @@ + + + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/419 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/419 new file mode 100644 index 00000000..f9d5b396 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/419 @@ -0,0 +1,4 @@ + + + +bsd-user dumps core for all binaries emulated diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/442 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/442 new file mode 100644 index 00000000..ea8a9a23 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/442 @@ -0,0 +1,4 @@ + + + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/447 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/447 new file mode 100644 index 00000000..ab149091 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/447 @@ -0,0 +1,4 @@ + + + +qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/562107 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/562107 new file mode 100644 index 00000000..89ee1857 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/562107 @@ -0,0 +1,15 @@ + + + +QEmu GDB stub uses IPv6 instead of v4 (or both) + +This bug has been reported by several people already. + +See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/ +and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248 + + +Seems like a very easy fix. + +Regards, +Matthijs ter Woord \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/645662 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/645662 new file mode 100644 index 00000000..50426a81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/645662 @@ -0,0 +1,43 @@ + + + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit + +When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)), +gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu, +3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources +on Debian Lenny with kernel 2.6.34.6 from kernel.org, gcc (Debian 4.3.2-1.1) 4.3. + +Regression testing errors: + +test_cmath +test test_cmath failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in + self.fail(error_message) +AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0)) +Expected: complex(3.141592653589793, -2.1073424255447014e-08) +Received: complex(3.141592653589793, -2.1073424338879928e-08) +Received value insufficiently close to expected value. + + +test_float +test test_float failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in + self.assertEqual(s, repr(float(s))) +AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25' + + +test_math +test test_math failed -- multiple errors occurred; run in verbose mode for deta + +=> + +runtests.sh -v test_math + +le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math +test_math BAD + 1 BAD + 0 GOOD + 0 SKIPPED + 1 total +le01:~/tools/python3/Python-3.1.2# \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/693 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/693 new file mode 100644 index 00000000..30224262 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/693 @@ -0,0 +1,13 @@ + + + +Qemu increased memory usage with TCG +Description of problem: +The issue is that instances that are supposed to use only a small amount of memory (like 256MB) suddenly use a much higher amount of RSS when running the accel=tcg, around 512MB in the above example. This was not happening with qemu-4.2 (on Ubuntu 20.04). This is also not happening when using accel=kvm instead. The issue has been first noticed on Debian 11 (Bullseye) with the versions above, but it is happening in the same way on Centos 8 Stream, Ubuntu 21.10 and a pre-release version of Ubuntu 22.04. It also also seen when testing with qemu-6.1 built from source. +Steps to reproduce: +1. Deploy devstack (https://opendev.org/openstack/devstack) with VIRT_TYPE=qemu on a VM +2. Start an instance with cirros image and a flavor allocating 256MB +3. Do a ps and see a RSS size of about 512MB being used after the instance has finished booting +4. Expected result (seen with qemu-4.2 or VIRT_TYPE=kvm): RSS stays < 256MB +Additional information: +I can try to find a smaller commandline for manual reproduction if needed. The above sample is generated by OpenStack Nova via libvirt. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/695 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/695 new file mode 100644 index 00000000..9b14ae6c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/695 @@ -0,0 +1,4 @@ + + + +MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/697 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/697 new file mode 100644 index 00000000..35cb85c4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/697 @@ -0,0 +1,4 @@ + + + +linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/698 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/698 new file mode 100644 index 00000000..35855075 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/698 @@ -0,0 +1,361 @@ + + + +linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map +Description of problem: +QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor. + +The following source file: + +```c +#include <fcntl.h> +#include <inttypes.h> +#include <stdbool.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/wait.h> + +static const char string[] = "Hello, world!\n"; + +static bool copy_to_stdout(const char *path) +{ + bool success = false; + + int fd = open(path, O_RDONLY); + if (fd < 0) { + perror("open"); + return false; + } + + char buf[16 * 1024]; + while (true) { + ssize_t bytes_read = read(fd, buf, sizeof(buf)); + if (bytes_read == 0) { + success = true; + goto out; + } else if (bytes_read < 0) { + perror("read"); + goto out; + } + ssize_t bytes_written = 0; + while (bytes_written < bytes_read) { + ssize_t ret = write(STDOUT_FILENO, buf + bytes_written, + bytes_read - bytes_written); + if (ret < 0) { + perror("write"); + goto out; + } + bytes_written += ret; + } + } + +out: + close(fd); + return success; +} + +static bool dump_maps(void) +{ + printf("Maps read by self:\n"); + fflush(stdout); + if (!copy_to_stdout("/proc/self/maps")) + return false; + + printf("\nMaps read by child process:\n"); + fflush(stdout); + pid_t pid = fork(); + if (pid < 0) { + perror("fork"); + return false; + } + if (pid == 0) { + char parent_maps[32]; + sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid()); + if (copy_to_stdout(parent_maps)) + _exit(EXIT_SUCCESS); + else + _exit(EXIT_FAILURE); + } + int wstatus; + if (waitpid(pid, &wstatus, 0) < 0 || + !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS) + return false; + + printf("\n"); + return true; +} + +int main(void) +{ + if (!dump_maps()) + return EXIT_FAILURE; + + int fd = open("/proc/self/mem", O_RDONLY); + if (fd < 0) { + perror("open: /proc/self/mem"); + return EXIT_FAILURE; + } + + char buf[sizeof(string)]; + printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n", + sizeof(buf), string, (uintptr_t)string, buf, + (unsigned int)getpid()); + fflush(stdout); + + if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) { + perror("pread: /proc/self/mem"); + return EXIT_FAILURE; + } + + if (memcmp(buf, string, sizeof(buf)) != 0) { + fprintf(stderr, "buffer doesn't match\n"); + return EXIT_FAILURE; + } + + return EXIT_SUCCESS; +} +``` + +when compiled for 32-bit ARM produces the following output: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +3ffff000-40000000 r-xp 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00010000-00020000 ---p 00000000 00:00 0 +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +0008c000-0009b000 ---p 00000000 00:00 0 +0009b000-0009c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +0009c000-0009d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +0009d000-000c0000 rw-p 00000000 00:00 0 +000c0000-4000f000 ---p 00000000 00:00 0 +4000f000-40010000 r--p 00000000 00:00 0 +40010000-40011000 ---p 00000000 00:00 0 +40011000-40811000 rw-p 00000000 00:00 0 +40811000-100000000 ---p 00000000 00:00 0 +100000000-100001000 r--p 00000000 00:00 0 +5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddff3000-5636de010000 rw-p 00000000 00:00 0 +5636df67b000-5636df80c000 rw-p 00000000 00:00 0 [heap] +7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 +7f300ffff000-7f3010000000 ---p 00000000 00:00 0 +7f3010000000-7f3010021000 rw-p 00000000 00:00 0 +7f3010021000-7f3014000000 ---p 00000000 00:00 0 +7f3017119000-7f301719a000 rw-p 00000000 00:00 0 +7f301719a000-7f301719b000 ---p 00000000 00:00 0 +7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 +7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 +7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 +7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806 /usr/lib/libc-2.33.so +7f3018011000-7f301801a000 rw-p 00000000 00:00 0 +7f301801a000-7f3018021000 r--p 00000000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018030000-7f3018034000 r--p 00016000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018037000-7f301803b000 rw-p 00000000 00:00 0 +7f301803b000-7f301803e000 r--p 00000000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018050000-7f3018053000 r--p 00015000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018053000-7f3018054000 ---p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018054000-7f3018055000 r--p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018056000-7f3018065000 r--p 00000000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819 /usr/lib/libm-2.33.so +7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018197000-7f3018198000 ---p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018198000-7f3018199000 r--p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819 /usr/lib/libm-2.33.so +7f301819a000-7f3018233000 r--p 00000000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018333000-7f301839f000 r--p 00199000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 +7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f3018508000-7f301859d000 r--p 00156000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 +7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 +7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018700000-7f3018701000 r--p 00008000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018702000-7f3018705000 r--p 00000000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018705000-7f3018713000 r-xp 00003000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018713000-7f3018719000 r--p 00011000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018719000-7f301871a000 ---p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871a000-7f301871b000 r--p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871b000-7f301871c000 rw-p 00018000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871c000-7f301871e000 rw-p 00000000 00:00 0 +7f301871e000-7f301871f000 r--p 00000000 00:19 2549795 /usr/lib/ld-2.33.so +7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795 /usr/lib/ld-2.33.so +7f3018743000-7f301874c000 r--p 00025000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795 /usr/lib/ld-2.33.so +7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0 [stack] +7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0 [vvar] +7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331 +buffer doesn't match +``` + +The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping: + +``` +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +``` + +but on the host, it's mapped differently: + +``` +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +``` + +When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00400000-00401000 r--p 00000000 00:19 297 /usr/bin/qemu-arm-static +00401000-00769000 r-xp 00001000 00:19 297 /usr/bin/qemu-arm-static +00769000-00abe000 r--p 00369000 00:19 297 /usr/bin/qemu-arm-static +00abe000-00c58000 r--p 006bd000 00:19 297 /usr/bin/qemu-arm-static +00c58000-00cd3000 rw-p 00857000 00:19 297 /usr/bin/qemu-arm-static +00cd3000-00cf7000 rw-p 00000000 00:00 0 +0253c000-0268e000 rw-p 00000000 00:00 0 [heap] +42645000-42655000 ---p 00000000 00:00 0 +42655000-426c1000 r--p 00000000 00:19 8275924 /home/osandov/repro +426c1000-426d0000 ---p 00000000 00:00 0 +426d0000-426d1000 r--p 0006b000 00:19 8275924 /home/osandov/repro +426d1000-426d2000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +426d2000-426f5000 rw-p 00000000 00:00 0 +426f5000-82645000 ---p 00000000 00:00 0 +82645000-82646000 ---p 00000000 00:00 0 +82646000-82e46000 rw-p 00000000 00:00 0 +82e46000-142635000 ---p 00000000 00:00 0 +142635000-142636000 r--p 00000000 00:00 0 +7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 +7f558bfff000-7f558c000000 ---p 00000000 00:00 0 +7f558c000000-7f558c021000 rw-p 00000000 00:00 0 +7f558c021000-7f5590000000 ---p 00000000 00:00 0 +7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 +7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 +7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 +7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0 [stack] +7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0 [vvar] +7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443 +pread: /proc/self/mem: Input/output error +``` +Steps to reproduce: +1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro). +2. Run `qemu-arm ./repro`. +Additional information: +I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126. + +This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/754635 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/754635 new file mode 100644 index 00000000..84577858 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/754635 @@ -0,0 +1,58 @@ + + + +-d option outs wrong info about sections + +For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: +$ cat /tmp/qemu.log | grep -A7 guest +Relocating guest address space from 0x08048000 to 0x8048000 +guest_base 0x0 +start end size prot +00048000-0005f000 00017000 r-x +0005f000-00069000 0000a000 rw- +00040000-00041000 00001000 --- +00041000-00041800 00000800 rw- +00041800-0005d800 0001c000 r-x +0005d800-0005f800 00002000 rw- + +But such command in 0.12.5 release outs this: +$ cat /tmp/qemu.log | grep -A7 guest +guest_base 0x0 +start end size prot +00f38000-00f39000 00001000 --- +08048000-0805f000 00017000 r-x +0805f000-08061000 00002000 rw- +40000000-40080000 00080000 rw- +40080000-40081000 00001000 --- +40081000-4009d000 0001c000 r-x + +It looks correct. +I received such differences and with qemu-microblaze. + +After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: +in 0.12.5: +end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); + +in 0.14.0: +int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, + +V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 + +I make this changes: +$ diff -up qemu-0.14.0/exec.c exec.c +--- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 ++++ exec.c 2011-04-08 17:26:09.800464003 +0400 +@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk + data.prot = 0; + + for (i = 0; i < V_L1_SIZE; i++) { +- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, ++ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), + V_L1_SHIFT / L2_BITS - 1, l1_map + i); + if (rc != 0) { + return rc; + +After this outputs looks correct. + +I don't know code base good, and think what may to do more general corrections. +Host system: linux i386 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/796480 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/796480 new file mode 100644 index 00000000..3fe14f69 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/796480 @@ -0,0 +1,48 @@ + + + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/805 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/805 new file mode 100644 index 00000000..1d393a30 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/805 @@ -0,0 +1,17 @@ + + + +qemu-hexagon: [binary]: Error mapping file: Invalid argument +Description of problem: +Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error: +`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument` +Steps to reproduce: +``` +./qemu-hexagon <hexagon-binary> +qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument +``` +Additional information: +A similar problem has been reported on the mailing list: +https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html + +Unfortunately without a solution. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/866 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/866 new file mode 100644 index 00000000..344afc81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/866 @@ -0,0 +1,56 @@ + + + +linux-user: substantial memory leak when threads are created and destroyed +Description of problem: +Substantial memory leak when the following simple program is executed on `qemu-arm`, +```c +// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread` + +#include <assert.h> +#include <pthread.h> + +#define MAGIC_RETURN ((void *)42) + +void *thread_main(void *arg) +{ + return MAGIC_RETURN; +} + +int main(int argc, char *argv[]) +{ + size_t i; + for (i = 0;; i++) + { + pthread_t thread; + assert(pthread_create(&thread, NULL, thread_main, NULL) == 0); + void *ret; + assert(pthread_join(thread, &ret) == 0); + assert(ret == MAGIC_RETURN); + } + + return 0; +} +``` +Steps to reproduce: +1. +``` +export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf +export ARMSDK=/${TOOLCHAIN_PREFIX} +export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc +export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc +``` +2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'` +3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1` +4. `$CC test_qemu.c -o test_qemu.out -pthread` +5. `qemu-arm -L $SYSROOT ./test_qemu.out` +6. Observe memory usage keeps ramping up and crashes the process once out of memory. +Additional information: +Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from +```bash +valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out +# Send CTRL-C before the process crashes due to oom +callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100 xtmemory.kcg > annot.log +``` + +# diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/886621 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/886621 new file mode 100644 index 00000000..95c15b1e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/886621 @@ -0,0 +1,295 @@ + + + +Mac OS X Lion: segmentation fault + + +Process: qemu [5680] +Path: /usr/local/xeos-build/qemu/bin/qemu +Identifier: qemu +Version: ??? (???) +Code Type: X86-64 (Native) +Parent Process: make [5677] + +Date/Time: 2011-11-05 18:53:25.574 +0100 +OS Version: Mac OS X 10.7.2 (11C74) +Report Version: 9 +Sleep/Wake UUID: 3C81B8F7-0321-4621-923C-AB655F2CC701 + +Interval Since Last Report: 503994 sec +Crashes Since Last Report: 35 +Per-App Crashes Since Last Report: 9 +Anonymous UUID: 28E7367A-4697-43A4-8D12-005F1917DFD3 + +Crashed Thread: 0 Dispatch queue: com.apple.main-thread + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000003a + +VM Regions Near 0x3a: +--> + __TEXT 0000000107c75000-0000000107ebc000 [ 2332K] r-x/rwx SM=COW /usr/local/xeos-build/qemu/bin/qemu + +Application Specific Information: +objc[5680]: garbage collection is OFF + +Thread 0 Crashed:: Dispatch queue: com.apple.main-thread +0 qemu 0x0000000107d9d0ed 0x107c75000 + 1212653 +1 qemu 0x0000000107dabc39 0x107c75000 + 1272889 +2 ??? 0x000000010c3b007c 0 + 4500160636 + +Thread 1:: Dispatch queue: com.apple.libdispatch-manager +0 libsystem_kernel.dylib 0x00007fff85abb7e6 kevent + 10 +1 libdispatch.dylib 0x00007fff8e7b15be _dispatch_mgr_invoke + 923 +2 libdispatch.dylib 0x00007fff8e7b014e _dispatch_mgr_thread + 54 + +Thread 2: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 3: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 4: +0 libsystem_kernel.dylib 0x00007fff85abb192 __workq_kernreturn + 10 +1 libsystem_c.dylib 0x00007fff85886594 _pthread_wqthread + 758 +2 libsystem_c.dylib 0x00007fff85887b85 start_wqthread + 13 + +Thread 5: +0 libsystem_kernel.dylib 0x00007fff85abb036 __sigwait + 10 +1 libsystem_c.dylib 0x00007fff8583aaab sigwait + 68 +2 qemu 0x0000000107d221ef 0x107c75000 + 709103 +3 libsystem_c.dylib 0x00007fff858848bf _pthread_start + 335 +4 libsystem_c.dylib 0x00007fff85887b75 thread_start + 13 + +Thread 0 crashed with X86 Thread State (64-bit): + rax: 0x5433ade07f7c29e7 rbx: 0x0000000000000010 rcx: 0x0000000000000000 rdx: 0x0000000000002000 + rdi: 0x0000000000000010 rsi: 0x0000000000000000 rbp: 0x00007fff678714a0 rsp: 0x00007fff67871470 + r8: 0x0000000109fe8000 r9: 0x0000000000000fff r10: 0x00007fa7c185c01d r11: 0x0000000000000246 + r12: 0x00000001087ae368 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000001f80 + rip: 0x0000000107d9d0ed rfl: 0x0000000000010202 cr2: 0x000000000000003a +Logical CPU: 6 + +Binary Images: + 0x107c75000 - 0x107ebbff7 +qemu (??? - ???) <FECE8C8E-BD8E-34F1-B222-32D79C7A0037> /usr/local/xeos-build/qemu/bin/qemu + 0x1087cb000 - 0x1088b5fe7 +libglib-2.0.0.dylib (2704.0.0 - compatibility 2704.0.0) <5E6151CC-61F8-3335-A6FA-EFDD71474FA6> /usr/local/macmade/sw/glib/lib/libglib-2.0.0.dylib + 0x108917000 - 0x10891ffff +libintl.8.dylib (9.1.0 - compatibility 9.0.0) <7D75E177-3172-2F78-1E08-1118A3D2D2A9> /usr/local/webstart/sw/gettext/lib/libintl.8.dylib + 0x108928000 - 0x108949fff +libpng12.0.dylib (23.0.0 - compatibility 23.0.0) <FDE69E98-1D25-EEA1-99CF-F0A04A9AD7FF> /usr/local/webstart/sw/lib-png/lib/libpng12.0.dylib + 0x10895a000 - 0x10897aff7 +libjpeg.62.dylib (63.0.0 - compatibility 63.0.0) <AD465C8A-66A4-E794-CA9A-96FB1B4D6CF0> /usr/local/webstart/sw/lib-jpeg/lib/libjpeg.62.dylib + 0x108987000 - 0x108a67ff7 +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) <54A03BBE-E505-9FF1-79AA-D4D5139BBF9C> /usr/local/webstart/sw/lib-iconv/lib/libiconv.2.dylib + 0x7fff67875000 - 0x7fff678a9ac7 dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld + 0x7fff8547d000 - 0x7fff8547efff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib + 0x7fff8582b000 - 0x7fff8582efff com.apple.help (1.3.2 - 42) <AB67588E-7227-3993-927F-C9E6DAC507FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help + 0x7fff8582f000 - 0x7fff85835fff libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib + 0x7fff85836000 - 0x7fff85913fef libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib + 0x7fff85914000 - 0x7fff85914fff com.apple.audio.units.AudioUnit (1.7.1 - 1.7.1) <04C10813-CCE5-3333-8C72-E8E35E417B3B> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit + 0x7fff85915000 - 0x7fff8591bfff IOSurface (??? - ???) <06FA3FDD-E6D5-391F-B60D-E98B169DAB1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface + 0x7fff85964000 - 0x7fff85972fff com.apple.NetAuth (1.0 - 3.0) <F384FFFD-70F6-3B1C-A886-F5B446E456E7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth + 0x7fff85aa4000 - 0x7fff85ac4fff libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib + 0x7fff85ac5000 - 0x7fff85b10ff7 com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration + 0x7fff85c2a000 - 0x7fff85c39ff7 com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL + 0x7fff85c3a000 - 0x7fff85c3eff7 com.apple.CommonPanels (1.2.5 - 94) <0BB2C436-C9D5-380B-86B5-E355A7711259> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels + 0x7fff85ebb000 - 0x7fff85fbefff libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib + 0x7fff85fbf000 - 0x7fff86063fef com.apple.ink.framework (1.3.2 - 110) <F69DBD44-FEC8-3C14-8131-CC0245DBBD42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink + 0x7fff860c5000 - 0x7fff860cafff libpam.2.dylib (3.0.0 - compatibility 3.0.0) <D952F17B-200A-3A23-B9B2-7C1F7AC19189> /usr/lib/libpam.2.dylib + 0x7fff860dd000 - 0x7fff86147fff com.apple.framework.IOKit (2.0 - ???) <87D55F1D-CDB5-3D13-A5F9-98EA4E22F8EE> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit + 0x7fff86148000 - 0x7fff8614ffff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib + 0x7fff8627e000 - 0x7fff862abfe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib + 0x7fff862ac000 - 0x7fff86314ff7 com.apple.Symbolication (1.2 - 89) <1D7F9E72-B1B6-30CF-AC8A-23A763930A92> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication + 0x7fff86315000 - 0x7fff86316ff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib + 0x7fff8633a000 - 0x7fff8634cff7 libbsm.0.dylib (??? - ???) <349BB16F-75FA-363F-8D98-7A9C3FA90A0D> /usr/lib/libbsm.0.dylib + 0x7fff8634d000 - 0x7fff863b5ff7 com.apple.audio.CoreAudio (4.0.1 - 4.0.1) <7966E3BE-376B-371A-A21D-9BD763C0BAE7> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio + 0x7fff86411000 - 0x7fff86423ff7 libsasl2.2.dylib (3.15.0 - compatibility 3.0.0) <6245B497-784B-355C-98EF-2DC6B45BF05C> /usr/lib/libsasl2.2.dylib + 0x7fff86428000 - 0x7fff86462fff libncurses.5.4.dylib (5.4.0 - compatibility 5.4.0) <387DE593-9CC5-38C7-911B-A5F2264D34F2> /usr/lib/libncurses.5.4.dylib + 0x7fff86463000 - 0x7fff864a2ff7 libGLImage.dylib (??? - ???) <2D1D8488-EC5F-3229-B983-CFDE0BB37586> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib + 0x7fff864a3000 - 0x7fff86545ff7 com.apple.securityfoundation (5.0 - 55005) <0D59908C-A61B-389E-AF37-741ACBBA6A94> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation + 0x7fff86546000 - 0x7fff865cbff7 com.apple.Heimdal (2.1 - 2.0) <C92E327E-CB5F-3C9B-92B0-F1680095C8A3> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal + 0x7fff865cc000 - 0x7fff865d0fff libCGXType.A.dylib (600.0.0 - compatibility 64.0.0) <5EEAD17D-006C-3855-8093-C7A4A97EE0D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib + 0x7fff865d1000 - 0x7fff8664cff7 com.apple.print.framework.PrintCore (7.1 - 366.1) <3F140DEB-9F87-3672-97CC-F983752581AC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore + 0x7fff8664d000 - 0x7fff86654ff7 com.apple.CommerceCore (1.0 - 17) <AA783B87-48D4-3CA6-8FF6-0316396022F4> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore + 0x7fff86655000 - 0x7fff86655fff com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff86656000 - 0x7fff8665afff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib + 0x7fff8665b000 - 0x7fff86768fff libJP2.dylib (??? - ???) <6052C973-9354-35CB-AAB9-31D00D8786F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib + 0x7fff86769000 - 0x7fff867acff7 libRIP.A.dylib (600.0.0 - compatibility 64.0.0) <2B1571E1-8E87-364E-BC36-C9C9B5D3EAC4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib + 0x7fff867ad000 - 0x7fff86d91fff libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib + 0x7fff86d92000 - 0x7fff86da4ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib + 0x7fff87016000 - 0x7fff8701cfff libGFXShared.dylib (??? - ???) <343AE6C0-EB02-333C-8D35-DF6093B92758> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib + 0x7fff8701d000 - 0x7fff87290fff com.apple.CoreImage (7.82 - 1.0.1) <282801B6-5D80-3E2C-88A4-00FE29906D5A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage + 0x7fff872da000 - 0x7fff87315fff com.apple.LDAPFramework (3.0 - 120.1) <0C23534F-A8E7-3144-B2B2-50F9875101E2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP + 0x7fff87322000 - 0x7fff87524fff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib + 0x7fff87a4c000 - 0x7fff87a4dfff libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib + 0x7fff87b4f000 - 0x7fff87b4ffff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib + 0x7fff87b50000 - 0x7fff87ba7fff libTIFF.dylib (??? - ???) <FF0D9A24-6956-3F03-81EA-3EEAD22C9DB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib + 0x7fff87c87000 - 0x7fff8839a587 com.apple.CoreGraphics (1.600.0 - ???) <A9F2451E-6F60-350E-A6E5-539669B53074> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics + 0x7fff8839b000 - 0x7fff883b1ff7 com.apple.ImageCapture (7.0 - 7.0) <69E6E2E1-777E-332E-8BCF-4F0611517DD0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture + 0x7fff883b2000 - 0x7fff883b9fff com.apple.NetFS (4.0 - 4.0) <B9F41443-679A-31AD-B0EB-36557DAF782B> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS + 0x7fff883d7000 - 0x7fff884b5fff com.apple.ImageIO.framework (3.1.1 - 3.1.1) <13E549F8-5BD6-3BAE-8C33-1D0BD269C081> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO + 0x7fff884b6000 - 0x7fff884b6fff com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa + 0x7fff884b7000 - 0x7fff884b7fff com.apple.ApplicationServices (41 - 41) <03F3FA8F-8D2A-3AB6-A8E3-40B001116339> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices + 0x7fff884b8000 - 0x7fff8861efff com.apple.CFNetwork (520.2.5 - 520.2.5) <406712D9-3F0C-3763-B4EB-868D01F1F042> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork + 0x7fff8861f000 - 0x7fff88943fff com.apple.HIToolbox (1.8 - ???) <A3BE7C59-52E6-3A7F-9B30-24B7DD3E95F2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox + 0x7fff88944000 - 0x7fff88961ff7 com.apple.openscripting (1.3.3 - ???) <A64205E6-D3C5-3E12-B1A0-72243151AF7D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting + 0x7fff88962000 - 0x7fff88c3aff7 com.apple.security (7.0 - 55010) <93713FF4-FE86-3B4C-8150-5FCC7F3320C8> /System/Library/Frameworks/Security.framework/Versions/A/Security + 0x7fff88c5b000 - 0x7fff88cbbfff libvDSP.dylib (325.4.0 - compatibility 1.0.0) <3A7521E6-5510-3FA7-AB65-79693A7A5839> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib + 0x7fff88cbf000 - 0x7fff88d43ff7 com.apple.ApplicationServices.ATS (317.5.0 - ???) <FE629F2D-6BC0-3A58-9844-D8B9A6808A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS + 0x7fff88d81000 - 0x7fff88e48ff7 com.apple.ColorSync (4.7.0 - 4.7.0) <F325A9D7-7203-36B7-8C1C-B6A4D5CC73A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync + 0x7fff88e59000 - 0x7fff88e6dff7 com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis + 0x7fff88e6e000 - 0x7fff88e79ff7 com.apple.speech.recognition.framework (4.0.19 - 4.0.19) <7ADAAF5B-1D78-32F2-9FFF-D2E3FBB41C2B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition + 0x7fff88f54000 - 0x7fff88f55fff libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib + 0x7fff89095000 - 0x7fff89148fff com.apple.CoreText (220.11.0 - ???) <4EA8E2DF-542D-38D5-ADB9-C0DAA73F898B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText + 0x7fff8932e000 - 0x7fff894cdfff com.apple.QuartzCore (1.7 - 270.0) <E8FC9AA4-A5CB-384B-AD29-7190A1387D3E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore + 0x7fff894f6000 - 0x7fff89530fe7 com.apple.DebugSymbols (2.1 - 87) <E9000AB8-CCE4-3636-871D-E17703814B68> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols + 0x7fff89531000 - 0x7fff8958cff7 com.apple.HIServices (1.10 - ???) <BAB8B422-7047-3D2D-8E0A-13FCF153E4E7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices + 0x7fff89a1d000 - 0x7fff89a6bfff libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib + 0x7fff89a6c000 - 0x7fff89ac0ff7 com.apple.ScalableUserInterface (1.0 - 1) <1873D7BE-2272-31A1-8F85-F70C4D706B3B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface + 0x7fff89ac1000 - 0x7fff89ae0fff libresolv.9.dylib (46.0.0 - compatibility 1.0.0) <33263568-E6F3-359C-A4FA-66AD1300F7D4> /usr/lib/libresolv.9.dylib + 0x7fff89b26000 - 0x7fff89b65fff com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE + 0x7fff89fd5000 - 0x7fff8a1a9fff com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation + 0x7fff8a1aa000 - 0x7fff8a1d3fff libJPEG.dylib (??? - ???) <64D079F9-256A-323B-A837-84628B172F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib + 0x7fff8a929000 - 0x7fff8a94dfff com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos + 0x7fff8a94e000 - 0x7fff8a94efff com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices + 0x7fff8a94f000 - 0x7fff8a9c4ff7 libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib + 0x7fff8af21000 - 0x7fff8afa4fef com.apple.Metadata (10.7.0 - 627.20) <E00156B0-663A-35EF-A307-A2CEB00F1845> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata + 0x7fff8b02d000 - 0x7fff8b036ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib + 0x7fff8b06d000 - 0x7fff8b10cfff com.apple.LaunchServices (480.21 - 480.21) <6BFADEA9-5BC1-3B53-A013-488EB7F1AB57> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices + 0x7fff8b10d000 - 0x7fff8b14efff com.apple.QD (3.12 - ???) <4F3C5629-97C7-3E55-AF3C-ACC524929DA2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD + 0x7fff8b14f000 - 0x7fff8b251ff7 libxml2.2.dylib (10.3.0 - compatibility 10.0.0) <D46F371D-6422-31B7-BCE0-D80713069E0E> /usr/lib/libxml2.2.dylib + 0x7fff8b2f6000 - 0x7fff8b2f9fff libCoreVMClient.dylib (??? - ???) <E034C772-4263-3F48-B083-25A758DD6228> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib + 0x7fff8b2fd000 - 0x7fff8b402ff7 libFontParser.dylib (??? - ???) <B9A53808-C97E-3293-9C33-1EA9D4E83EC8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib + 0x7fff8b41e000 - 0x7fff8b449ff7 libxslt.1.dylib (3.24.0 - compatibility 3.0.0) <8051A3FC-7385-3EA9-9634-78FC616C3E94> /usr/lib/libxslt.1.dylib + 0x7fff8b49e000 - 0x7fff8b4a3fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib + 0x7fff8b656000 - 0x7fff8b65bfff libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib + 0x7fff8b65c000 - 0x7fff8b695fe7 libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib + 0x7fff8b696000 - 0x7fff8b69bff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib + 0x7fff8b6c6000 - 0x7fff8b6d1ff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib + 0x7fff8b909000 - 0x7fff8bd36fff libLAPACK.dylib (??? - ???) <4F2E1055-2207-340B-BB45-E4F16171EE0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib + 0x7fff8bd37000 - 0x7fff8bd42fff com.apple.CommonAuth (2.1 - 2.0) <BFDD0A8D-4BEA-39EC-98B3-2E083D7B1ABD> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth + 0x7fff8bd43000 - 0x7fff8bd76ff7 com.apple.GSS (2.1 - 2.0) <9A2C9736-DA10-367A-B376-2C7A584E6C7A> /System/Library/Frameworks/GSS.framework/Versions/A/GSS + 0x7fff8bd77000 - 0x7fff8bd78ff7 libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib + 0x7fff8bd79000 - 0x7fff8bd7dfff libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib + 0x7fff8bdac000 - 0x7fff8bdc8ff7 com.apple.GenerationalStorage (1.0 - 125) <31F60175-E38D-3C63-8D95-32CFE7062BCB> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage + 0x7fff8bdcd000 - 0x7fff8bdf5ff7 com.apple.CoreVideo (1.7 - 70.1) <98F917B2-FB53-3EA3-B548-7E97B38309A7> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo + 0x7fff8bdf6000 - 0x7fff8be0dfff com.apple.MultitouchSupport.framework (220.62.1 - 220.62.1) <F21C79C0-4B5A-3645-81A6-74F8EFA900CE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport + 0x7fff8be0e000 - 0x7fff8be34ff7 com.apple.framework.familycontrols (3.0 - 300) <41A6DFC2-EAF5-390A-83A1-C8832528705C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls + 0x7fff8c071000 - 0x7fff8c155def libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib + 0x7fff8c156000 - 0x7fff8c17dfff com.apple.PerformanceAnalysis (1.10 - 10) <2A058167-292E-3C3A-B1F8-49813336E068> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis + 0x7fff8c17e000 - 0x7fff8c1c0ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib + 0x7fff8c3ff000 - 0x7fff8c452fff libFontRegistry.dylib (??? - ???) <57FBD85F-41A6-3DB9-B5F4-FCC6B260F1AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib + 0x7fff8c461000 - 0x7fff8c4fbff7 com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit + 0x7fff8d20f000 - 0x7fff8d24aff7 libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib + 0x7fff8d24b000 - 0x7fff8d250fff libGIF.dylib (??? - ???) <393E2DB5-9479-39A6-A75A-B5F20B852532> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib + 0x7fff8d251000 - 0x7fff8d268fff com.apple.CFOpenDirectory (10.7 - 144) <9709423E-8484-3B26-AAE8-EF58D1B8FB3F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory + 0x7fff8d269000 - 0x7fff8d26efff com.apple.OpenDirectory (10.7 - 146) <91A87249-6A2F-3F89-A8DE-0E95C0B54A3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory + 0x7fff8d26f000 - 0x7fff8d2c1ff7 libGLU.dylib (??? - ???) <3C9153A0-8499-3DC0-AAA4-9FA6E488BE13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib + 0x7fff8d2c2000 - 0x7fff8d789fff FaceCoreLight (1.4.7 - compatibility 1.0.0) <E9D2A69C-6E81-358C-A162-510969F91490> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight + 0x7fff8d78a000 - 0x7fff8d792fff libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib + 0x7fff8d793000 - 0x7fff8d7bcfff com.apple.CoreServicesInternal (113.8 - 113.8) <C1A3CF1B-BC45-3FC6-82B3-1511EBBA9D51> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal + 0x7fff8d823000 - 0x7fff8d838fff com.apple.speech.synthesis.framework (4.0.74 - 4.0.74) <C061ECBB-7061-3A43-8A18-90633F943295> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis + 0x7fff8e34d000 - 0x7fff8e371ff7 com.apple.RemoteViewServices (1.2 - 39) <862849C8-84C1-32A1-B87E-B29E74778C9F> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices + 0x7fff8e508000 - 0x7fff8e51bff7 libCRFSuite.dylib (??? - ???) <034D4DAA-63F0-35E4-BCEF-338DD7A453DD> /usr/lib/libCRFSuite.dylib + 0x7fff8e7a7000 - 0x7fff8e7a9ff7 com.apple.print.framework.Print (7.1 - 247.1) <8A4925A5-BAA3-373C-9B5D-03E0270C6B12> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print + 0x7fff8e7aa000 - 0x7fff8e7adff7 com.apple.securityhi (4.0 - 1) <B37B8946-BBD4-36C1-ABC6-18EDBC573F03> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI + 0x7fff8e7ae000 - 0x7fff8e7bcfff libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib + 0x7fff8e7bd000 - 0x7fff8e7befff liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib + 0x7fff8e7cc000 - 0x7fff8e7e9fff libPng.dylib (??? - ???) <3C70A94C-9442-3E11-AF51-C1B0EF81680E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib + 0x7fff8e7ea000 - 0x7fff8e7eafff com.apple.Accelerate (1.7 - Accelerate 1.7) <82DDF6F5-FBC3-323D-B71D-CF7ABC5CF568> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate + 0x7fff8e7eb000 - 0x7fff8e801fff libGL.dylib (??? - ???) <6A473BF9-4D35-34C6-9F8B-86B68091A9AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib + 0x7fff8e810000 - 0x7fff8e81aff7 liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib + 0x7fff8e95f000 - 0x7fff8e9f5ff7 libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib + 0x7fff8e9f6000 - 0x7fff8ec10fef com.apple.CoreData (104 - 358.12) <33B1FA75-7970-3751-9DCC-FF809D3E1FA2> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData + 0x7fff8ef91000 - 0x7fff8f2aaff7 com.apple.Foundation (6.7.1 - 833.20) <D922F590-FDA6-3D89-A271-FD35E2290624> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation + 0x7fff8f2ab000 - 0x7fff8f38cfff com.apple.CoreServices.OSServices (478.29 - 478.29) <B487110E-C942-33A8-A494-3BDEDB88B1CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices + 0x7fff8f3c8000 - 0x7fff8f3d5fff libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <931F40EB-CA75-3A90-AC97-4DB8E210BC76> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib + 0x7fff8f44d000 - 0x7fff8f4c0fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib + 0x7fff8f7e3000 - 0x7fff8f7e3fff com.apple.Carbon (153 - 153) <895C2BF2-1666-3A59-A669-311B1F4F368B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon + 0x7fff8fb82000 - 0x7fff8fc9aff7 com.apple.DesktopServices (1.6.1 - 1.6.1) <4418EAA6-7163-3A77-ABD3-F8289796C81A> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv + 0x7fff8fc9d000 - 0x7fff8fc9ffff com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent + 0x7fff8fca0000 - 0x7fff8fdf9fff com.apple.audio.toolbox.AudioToolbox (1.7.1 - 1.7.1) <4877267E-F736-3019-85D3-40A32A042A80> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox + 0x7fff8fef9000 - 0x7fff8ff39ff7 libcups.2.dylib (2.9.0 - compatibility 2.0.0) <B7173CA4-CE16-3BAB-8D83-185FCEFA15F5> /usr/lib/libcups.2.dylib + 0x7fff8ff9c000 - 0x7fff900a8fff libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib + 0x7fff900a9000 - 0x7fff900b7ff7 libkxld.dylib (??? - ???) <65BE345D-6618-3D1A-9E2B-255E629646AA> /usr/lib/system/libkxld.dylib + 0x7fff900b8000 - 0x7fff900beff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib + 0x7fff900cb000 - 0x7fff90204fef com.apple.vImage (5.1 - 5.1) <EB634387-CD15-3246-AC28-5FB368ACCEA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage + 0x7fff9020d000 - 0x7fff9023dff7 com.apple.DictionaryServices (1.2.1 - 158.2) <3FC86118-7553-38F7-8916-B329D2E94476> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices + 0x7fff9024e000 - 0x7fff90343fff libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib + 0x7fff90344000 - 0x7fff9038aff7 libcurl.4.dylib (7.0.0 - compatibility 7.0.0) <EAF61ADC-DC00-34CE-B23E-7238ED54E31D> /usr/lib/libcurl.4.dylib + 0x7fff9038b000 - 0x7fff903a8ff7 libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib + 0x7fff90b3e000 - 0x7fff90b3ffff libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib + 0x7fff90b40000 - 0x7fff90e5cff7 com.apple.CoreServices.CarbonCore (960.18 - 960.18) <6020C3FB-6125-3EAE-A55D-1E77E38BEDEA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore + 0x7fff90e9b000 - 0x7fff90e9bfff com.apple.vecLib (3.7 - vecLib 3.7) <9A58105C-B36E-35B5-812C-4ED693F2618F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib + 0x7fff90fe4000 - 0x7fff90feafff com.apple.DiskArbitration (2.4.1 - 2.4.1) <CEA34337-63DE-302E-81AA-10D717E1F699> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration + 0x7fff91024000 - 0x7fff91027fff libRadiance.dylib (??? - ???) <CD89D70D-F177-3BAE-8A26-644EA7D5E28E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib + 0x7fff91220000 - 0x7fff91222fff libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib + 0x7fff91223000 - 0x7fff9128bfff com.apple.CoreSymbolication (2.1 - 71) <0715BF39-D53C-3BFE-BBEA-B8EBF7274850> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication + 0x7fff9128c000 - 0x7fff912eefff com.apple.coreui (1.2.1 - 164.1) <F7972630-F696-3FC5-9FCF-A6E1C8771078> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI + 0x7fff912ef000 - 0x7fff9135ffff com.apple.datadetectorscore (3.0 - 179.4) <2A822A13-94B3-3A43-8724-98FDF698BB12> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore + 0x7fff91367000 - 0x7fff91394ff7 com.apple.opencl (1.50.63 - 1.50.63) <DB335C5C-3ABD-38C8-B6A5-8436EE1484D3> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL + 0x7fff91395000 - 0x7fff91f96ff7 com.apple.AppKit (6.7.2 - 1138.23) <5CD2C850-4F52-3BA2-BA11-3107DFD2D23C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit + 0x7fff91f97000 - 0x7fff91f99fff libCVMSPluginSupport.dylib (??? - ???) <61D89F3C-C64D-3733-819F-8AAAE4E2E993> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib + +External Modification Summary: + Calls made by other processes targeting this process: + task_for_pid: 2 + thread_create: 0 + thread_set_state: 0 + Calls made by this process: + task_for_pid: 0 + thread_create: 0 + thread_set_state: 0 + Calls made by all processes on this machine: + task_for_pid: 103153 + thread_create: 1 + thread_set_state: 0 + +VM Region Summary: +ReadOnly portion of Libraries: Total=144.3M resident=100.5M(70%) swapped_out_or_unallocated=43.8M(30%) +Writable regions: Total=185.9M written=3692K(2%) resident=23.0M(12%) swapped_out=0K(0%) unallocated=162.9M(88%) + +REGION TYPE VIRTUAL +=========== ======= +CG backing stores 1496K +CG image 4K +CG raster data 64K +CG shared images 3480K +CoreGraphics 16K +CoreServices 4112K +MALLOC 67.1M +MALLOC guard page 32K +MALLOC_LARGE (reserved) 25.3M reserved VM address space (unallocated) +Memory tag=242 12K +STACK GUARD 24K +Stack 66.5M +VM_ALLOCATE 16.1M +__CI_BITMAP 80K +__DATA 21.1M +__IMAGE 1256K +__LINKEDIT 48.1M +__TEXT 96.2M +__UNICODE 544K +mapped file 32.2M +shared memory 308K +=========== ======= +TOTAL 383.7M +TOTAL, minus reserved VM space 358.4M + +Model: MacBookPro8,3, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 1.70f3 +Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB +Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB +Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020 +AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18) +Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports +Network Service: Wi-Fi, AirPort, en1 +Serial ATA Device: APPLE SSD TS512C, 500.28 GB +Serial ATA Device: MATSHITADVD-R UJ-898 +USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfa100000 / 2 +USB Device: BRCM2070 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0xfa110000 / 5 +USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7 +USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0253, 0xfa120000 / 4 +USB Device: hub_device, 0x0424 (SMSC), 0x2514, 0xfd100000 / 2 +USB Device: Freecom Hard Drive XS, 0x07ab (Freecom Computer Peripherals), 0xfc8e, 0xfd120000 / 5 +USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/909 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/909 new file mode 100644 index 00000000..dc380c91 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/909 @@ -0,0 +1,14 @@ + + + +qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries +Description of problem: +**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** + +Trying to chroot into a mips n32 installation fails with +``` +/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data +``` +however, bash, libc.so.6, and qemu all exist and have the proper abi + +The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/922 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/922 new file mode 100644 index 00000000..6078a920 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/922 @@ -0,0 +1,23 @@ + + + +QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying. + +This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0 + +I wrote small test to demonstrate this bug. +Steps to reproduce: +1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2) +2. `$ make # To build the docker container` +3. `$ make shell # To run ARM bash` +4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault: +``` +[root@0d81b08f032b /]# /qemu --version +qemu-arm version 6.2.90 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done +Segmentation fault (core dumped) +[root@0d81b08f032b /]# +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/939 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/939 new file mode 100644 index 00000000..6525f2ba --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/939 @@ -0,0 +1,78 @@ + + + +qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit +Description of problem: +In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) + +So, I used the following test program, statically linked: +``` +#include <stdlib.h> +#include <stdio.h> +#include <string.h> + +int main() { + + char *pointer; + int i; + + for (i=1; i<301; i++) { + + printf("Allocation %i : ", i); + pointer = malloc(20480000 * sizeof(char)); + + printf(" pointer is %p, ", pointer); + + if (! pointer) { + printf("malloc failed\n"); + exit(0); + }; + + memset(pointer, 0xDB, 20480000); + printf(" filled\n"); + } +}; +``` + +With mips3 n32 I get the following output: +``` +pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest +/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest +Allocation 1 : pointer is 0x40802010, filled +Allocation 2 : pointer is 0x41b8b010, filled +Allocation 3 : pointer is 0x42f14010, filled +[...] +Allocation 51 : pointer is 0x7d8c4010, filled +Allocation 52 : pointer is 0x7ec4d010, filled +qemu: unhandled CPU exception 0x15 - aborting +pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0 +GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200 +GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000 +GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369 +GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010 +GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000 +GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000 +GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000 +GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854 +CP0 Status 0x24800010 Cause 0x00000000 EPC 0x0000000000000000 + Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000 + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +** +ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +``` + +For mips2 o32 I get the more correct looking output +``` +pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest +/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest +Allocation 1 : pointer is 0x3ec76008, filled +Allocation 2 : pointer is 0x3d8ed008, filled +Allocation 3 : pointer is 0x3c564008, filled +[...] +Allocation 104 : pointer is 0x4082c008, filled +Allocation 105 : pointer is (nil), malloc failed +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/95 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/95 new file mode 100644 index 00000000..d69c86bb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/95 @@ -0,0 +1,4 @@ + + + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/967 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/967 new file mode 100644 index 00000000..ff15a3c4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/967 @@ -0,0 +1,227 @@ + + + +qemu 6.2 user mode memory leak when mmap + munmap is called +Description of problem: +Launch a program with qemu user mode emulator, +If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. + +Excepted behavior: qemu-x86_64 costs very less memory after munmap is called. +Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap]. +Steps to reproduce: +1.Compile this code with g++. +```shell +g++ -o main.bin main.cpp +``` +```cpp +#include <chrono> +#include <cstdio> +#include <sys/types.h> +#include <unistd.h> +#include <cstdlib> +#include <sys/mman.h> + +#include <thread> + +static constexpr size_t pageSize = 4096; + +int main(){ + constexpr size_t size = 1024*100*pageSize*1000; + + void* data = mmap(nullptr, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); + + if(data == nullptr){ + perror("mmap failed"); + exit(1); + } + + int error = munmap(data, size); + + if(error !=0){ + perror("munmap failed"); + exit(1); + } + + + printf("mmap munmap test done\n"); + while(true){ + std::this_thread::sleep_for(std::chrono::seconds(10000)); + } + + return 0; +} +``` +2. run main.bin with qemu-x86_64 +```shell +$ qemu-x86_64 ./main.bin +mmap munmap test done +``` +3. check memory usage by top +``` +$ top -p `pgrep "qemu"` +top - 16:00:39 up 6:41, 1 user, load average: 0.08, 0.12, 0.10 +Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie +%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +MiB Mem : 15969.1 total, 8249.3 free, 6048.2 used, 1671.5 buff/cache +MiB Swap: 2048.0 total, 1209.6 free, 838.4 used. 9544.3 avail Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 38521 jcq 20 0 2634324 2.3g 7840 S 0.0 14.8 0:04.48 qemu-x86_64 +``` + +4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB. +```shell +$ cat /proc/38521/maps +4000000000-4000001000 r--p 00000000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000001000-4000002000 r--p 00001000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000002000-4000003000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000003000-4000004000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000004000-4000005000 rw-p 00003000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000005000-4000026000 rw-p 00000000 00:00 0 +4001005000-4001006000 ---p 00000000 00:00 0 +4001006000-4001806000 rw-p 00000000 00:00 0 +4001806000-400183d000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +400183d000-400183e000 ---p 00000000 00:00 0 +400183e000-4001840000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001840000-4001842000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001842000-4001844000 rw-p 00000000 00:00 0 +4001863000-4001a78000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a78000-4001a7c000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7e000-4001a8d000 rw-p 00000000 00:00 0 +5611c96af000-5611c9734000 r--p 00000000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9902000-5611c993c000 r--p 00252000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9950000-5611c996e000 rw-p 00000000 00:00 0 +5611ca5e0000-56125d125000 rw-p 00000000 00:00 0 [heap] +7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 +7f203ffff000-7f2040000000 ---p 00000000 00:00 0 +7f2040000000-7f2040021000 rw-p 00000000 00:00 0 +7f2040021000-7f2044000000 ---p 00000000 00:00 0 +7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 +7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 +7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 +7f2048676000-7f2048678000 r--p 00000000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f204867f000-7f2048680000 r--p 00009000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048683000-7f204868d000 r--p 00000000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048705000-7f204870d000 r--p 00000000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874a000-7f204874b000 ---p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874b000-7f204874c000 r--p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874d000-7f2048757000 r--p 00000000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048790000-7f2048792000 r--p 00042000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048793000-7f2048795000 rw-p 00000000 00:00 0 +7f2048795000-7f2048798000 r--p 00000000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048957000-7f2048959000 r--p 00000000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f204895d000-7f2048976000 r--p 00006000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 +7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049043000-7f2049045000 rw-p 00000000 00:00 0 +7f2049045000-7f2049047000 r--p 00000000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049049000-7f204904a000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904a000-7f204904b000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904c000-7f2049069000 r--p 00000000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049182000-7f2049183000 ---p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049183000-7f2049184000 r--p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049185000-7f2049186000 rw-p 00000000 00:00 0 +7f2049186000-7f2049188000 r--p 00000000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918a000-7f204918b000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918b000-7f204918c000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 +7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0 [stack] +7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0 [vvar] +7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] +``` +Additional information: +qemu is installed by ubuntu's apt. + +sudo apt install qemu-user + +compiler version: +``` +g++ --version +g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0 +Copyright (C) 2021 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` + +libc version: +``` +ldd --version +ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +Written by Roland McGrath and Ulrich Drepper. +``` diff --git a/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/979 b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/979 new file mode 100644 index 00000000..3c6e7967 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:70b/output/runtime/979 @@ -0,0 +1,10 @@ + + + +s390x floating point conversion functions broken +Description of problem: +While collecting additional reference files for float_convs (and float_convd) I noticed that the s390x handling of some cases is broken. See diff for details: + +``` + diff -y tests/tcg/s390x-linux-user/float_convs.out ../../tests/tcg/s390x/float_convs.ref +# |