diff options
Diffstat (limited to 'results/classifier/no-thinking-deepseek-r1:32b/output/manual-review')
34 files changed, 1586 insertions, 0 deletions
diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1072 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1072 new file mode 100644 index 00000000..be8fef07 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1072 @@ -0,0 +1,27 @@ + + + +different behavior when remote debugger is used +Description of problem: +I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: + +1. Is this intended behavior? +1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) +1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. + +The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) +The preprocessed code is as follows: + if (((((st.st_mode)) & 0170000) == (0020000))) + +I then compared two different approaches to run Qemu: + +1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR +1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). + +Thanks! +Steps to reproduce: +1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) +2. +3. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1156313 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1156313 new file mode 100644 index 00000000..76a0b70e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1156313 @@ -0,0 +1,129 @@ + +semantic: 0.869 +mistranslation: 0.841 +assembly: 0.789 +device: 0.777 +instruction: 0.707 +other: 0.705 +vnc: 0.702 +graphic: 0.657 +socket: 0.605 +boot: 0.576 +network: 0.533 +KVM: 0.518 + +X86-64 flags handling broken + +The current qemu sources cause improper handling of flags on x86-64. +This bug seems to have shown up a few weeks ago. + +A plain install of Debian GNU/Linux makes user processes catch +spurious signals. The kernel seems to run stably, though. + +The ADX feature works very poorly. It might be related; at least it +allows for reproducibly provoking invalid behaviour. + +Here is a test case: + +================================================================ +qemumain.c +#include <stdio.h> +long adx(); +int +main () +{ + printf ("%lx\n", adx (0xffbeef, 17)); + return 0; +} +================================================================ +qemuadx.s: + .globl adx +adx: xor %rax, %rax +1: dec %rdi + jnz 1b + .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adox %rax, %rax + .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adcx %rax, %rax + ret +================================================================ + +Compile and execute: +$ gcc -m64 qemumain.c qemuadx.s +$ a.out +ffffff8000378cd8 + +Expected output is simply "0". The garbage value varies between qemu +compiles and guest systems. + +Note that one needs a recent GNU assembler in order to handle adox and +adcx. For convenience I have supplied them as byte sequences. + +Exaplanation and feeble analysis: + +The 0xffbeef argument is a loop count. It is necessary to loop for a +while in order to trigger this bug. If the loop count is decreased, +the bug will seen intermittently; the lower the count, the less +frequent the invalid behaviour. + +It seems like a reasonable assumption that this bug is related to +flags handling at context switch. Presumably, qemu keeps flags state +in some internal format, then recomputes then when needing to form the +eflags register, as needed for example for context switching. + +I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT, +but I strongly suspect that to be impossible. I use +qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version +6.0.6) . + +The bug happens also with the guest FreeBSD x86_64 version 9.1. (The +iteration count for triggering the problem 50% of the runs is not the +same when using the kernel Linux and FreeBSD's kernel, presumably due +to different ticks.) + +The bug happens much more frequently for a loaded system; in fact, the +loop count can be radically decreased if two instances of the trigger +program are run in parallel. + +Richard Henderson <email address hidden> writes: + + Patch at http://patchwork.ozlabs.org/patch/229139/ + +Thanks. I can confirm that this fixes the bug triggered by my test case +(and yours). However, the instability of Debian GNU/Linux x86_64 has +not improved. + +The exact same Debian version (debian "testing") updated at the same +time runs well on hardware. + +My qemu Debian system now got messed up, since I attempted an upgrade in +the buggy qemu, which segfaulted several times during the upgrade. I +need to reinstall, and then rely on -snapshot. + +There is a problem with denorms which is reproducible, but whether that +is a qemu bug, and whether it can actually cause the observed +instability, is questionable. Here is a testcase for that problem: + + + + +It should terminate. The observed buggy behaviour is that it hangs. + +The instability problem can be observed at gmplib.org/devel/tm-date.html. +hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx. + +Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org). +It is neither instable nor does it run the denorms testcase poorly. + +I fully realise this is a hopeless bug report, but I am sure you can +reproduce it, since it is far from GMP specific. After all apt-get +update; apt-get upgrade triggered it. Debugging it will be a nightmare. + +Qemu version: main git repo from less than a week ago + Richard ADX +patch. + +-- +Torbjörn + + +It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug. + + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1267955 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1267955 new file mode 100644 index 00000000..f18f0c66 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1267955 @@ -0,0 +1,45 @@ + + + +[i386] Parity Flag Not Set On xor %eax,%eax + +Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid + +Steps To Reproduce + +$ cat > prog.hex << EOF + +7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 +02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 +00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 +00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 +00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 +00 10 00 00 + +31 c0 +9c + +b8 04 00 00 00 +bb 01 00 00 00 +89 e1 +ba 04 00 00 00 +cd 80 + +b8 01 00 00 00 +bb 00 00 00 00 +cd 80 + +EOF + +$ xxd -p -r prog.hex > prog +$ chmod 700 prog + +$ ./prog | hexdump -vC +00000000 46 02 00 00 |F...| +00000004 + +$ qemu-i386 ./prog | hexdump -vC +00000000 42 02 00 00 |B...| +00000004 + +On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1311614 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1311614 new file mode 100644 index 00000000..35739fc7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1346769 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1346769 new file mode 100644 index 00000000..9e0db973 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1346769 @@ -0,0 +1,39 @@ + + + +/proc/self/maps content returned to 32-bits guest under 64-bits qemu + +Reading /proc/self/maps a user doesn't get a stack record. Not all programs relies on the maps file but some do. + +The bug found by running 32-bits binaries with address sanitizer (Asan) instrumentations under 64-bit qemu. + +$ 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 /tmp/test +==4092==AddressSanitizer CHECK failed: /home/michail/Downloads/gcc-4.9.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:63 "(((uptr)&rl >= start && (uptr)&rl < end)) != (0)" (0x0, 0x0) + #0 0xf632ff01 (/home/michail/build/lib32/libasan.so.1+0x53f01) + #1 0xf6333f49 (/home/michail/build/lib32/libasan.so.1+0x57f49) + #2 0xf6338785 (/home/michail/build/lib32/libasan.so.1+0x5c785) + #3 0xf6338bd1 (/home/michail/build/lib32/libasan.so.1+0x5cbd1) + #4 0xf6331baf (/home/michail/build/lib32/libasan.so.1+0x55baf) + #5 0xf6331dca (/home/michail/build/lib32/libasan.so.1+0x55dca) + #6 0xf6331f5a (/home/michail/build/lib32/libasan.so.1+0x55f5a) + #7 0xf6330bd4 (/home/michail/build/lib32/libasan.so.1+0x54bd4) + #8 0xf67ebeec (/lib/ld-linux.so.2+0xeeec) + #9 0xf67de10e (/lib/ld-linux.so.2+0x110e) + +This happened because during initialization Asan can't find stack boundaries. + +For some reasons Qemu wants to report stack boundaries just for several arch targets skipping other ones. This is from linux-user/syscall.c open_self_maps() + +#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32) + dprintf(fd, "%08llx-%08llx rw-p %08llx 00:00 0 [stack]\n", + (unsigned long long)ts->info->stack_limit, + (unsigned long long)(ts->info->start_stack + + (TARGET_PAGE_SIZE - 1)) & TARGET_PAGE_MASK, + (unsigned long long)0); +#endif + +Not very clear why the case covers just specific targets. + +This bug continues the previously reported issue with not hiden system map http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1388 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1388 new file mode 100644 index 00000000..ef331b07 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1416988 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1416988 new file mode 100644 index 00000000..11c57f0e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1416988 @@ -0,0 +1,35 @@ + + + +Wrong signal handling in qemu-aarch64. + +Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests connected with stack unwinding fail with: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +or run into infinite loop. + +Here is one example: + +$ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc-aarch64/gcc/ /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe + +$ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 -/cleanup-11.exe +qemu: uncaught target signal 11 (Segmentation fault) - core dumped. + +Actually, this caused by ABI incompatibility between Linux Kernel (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux and target_siginfo structure in qemu-aarch64 differ: + +sizeof (struct target_siginfo) = 136 // QEMU +sizeof (struct siginfo) = 128 // Linux Kernel + + +This caused by wrong TARGET_SI_PAD_SIZE defined in linux-user/syscall_defs.h: + +#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) + +In Kernel respective value is: + +#define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) +............................................. +#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) // for Aarch64 + +Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1462640 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1462640 new file mode 100644 index 00000000..b4e114a6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1462640 @@ -0,0 +1,38 @@ + + + +shmat fails on 32-to-64 setup + + +I am trying to run a guest mips32 program (user mode) on a x86_64 host. The program fails on a call to shmat() reproducibly. when digging into this problem, I could make a small guest POC that fails when compiled as i386 (-m32) running on a x86_64 host, but pass when compiled as 64bit. The problem has to do with mmap flags. + +From what I can understand, when running 32bits guests programs, qemu reserve the whole guest virtual space with an mmap call. That mmap call specifys MAP:PRIVATE flag. When shmat is called, it tries to make part of that region MAP_SHARED and that fails. + +As a possible fix, it looks like it is possible to first unmap the shm region before calling shmat. + +steps to reproduce: +1 - create a file shm.c with content below +2 - compile with: gcc -m32 shm.c -o shm32 +3 - run on a x86_64 host: qemu-i386 ./shm32 +4 - observe shmat fails, by returning ptr -1 + +5- compile without -m32: : gcc shm.c -o shm64 +6 - observe it pass: qemu-x84_64 ./shm64 + + + +#include <sys/ipc.h> +#include <sys/shm.h> +#include <sys/mman.h> +#include <stdio.h> + +int main() +{ + struct shmid_ds shm_desc; + int err = 0; + int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666); + err = shmctl(id, IPC_STAT, &shm_desc); + const void *at = 0x7f7df38ea000; + void* ptr = shmat(id, at, 0); + printf( "got err %d, ptr %p\n", err, ptr ); +} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1533141 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1533141 new file mode 100644 index 00000000..2abc9d08 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1541 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1541 new file mode 100644 index 00000000..a677253a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1541 @@ -0,0 +1,35 @@ + + + +Invalid position of G_NORETURN in clang v15 +Description of problem: +Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7. + +Switching `extern` with `G_NORETURN` seems to fix the issue. +Steps to reproduce: +1. Build qemu system for MIPSEL or use minimal reproducer: + +`example.cpp`: +``` +#include "/path/to/qemu/include/glib-compat.h" + +extern G_NORETURN +void // QEMU_ERROR("code path is reachable") + qemu_build_not_reached_always(void); +``` + +``` +$ clang++ --version +clang version 15.0.7 +Target: x86_64-pc-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp +example.cpp:3:8: error: an attribute list cannot appear here +extern G_NORETURN + ^~~~~~~~~~ +/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN' +# define G_NORETURN [[noreturn]] + ^~~~~~~~~~~~ +1 error generated. +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1550503 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1550503 new file mode 100644 index 00000000..2471785e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1550503 @@ -0,0 +1,16 @@ + + + +target-arm/helper.c:5493: bad test ? + +[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true. + +Source code is + + (env->uncached_cpsr & CPSR_M) != CPSR_USER && + +but + +./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) + +./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1553 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1553 new file mode 100644 index 00000000..89fab3c5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1553 @@ -0,0 +1,15 @@ + + + +Build error: implicit declaration of function 'qemu_close_to_socket' +Description of problem: +When build the latest master code with MSYS2 on Windows 10, GCC reports: +../ui/spice-core.c: In function 'watch_remove': +../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration] + 152 | qemu_close_to_socket(watch->fd); + | ^~~~~~~~~~~~~~~~~~~~ +../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs] +Steps to reproduce: +1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu +2. cd build +3. make diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1594394 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1594394 new file mode 100644 index 00000000..284d39d8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1594394 @@ -0,0 +1,44 @@ + + + +Using setreuid / setegid crashes x86_64 user-mode target + +When setreuid() or setegid() are called from x86_64 target code in user mode, qemu crashes inside the NPTL signal handlers. x86 targets do not directly use a syscall to handle setreuid() / setegid(); instead the x86 NPTL implementation sets up a temporary data region in memory (__xidcmd) and issues a signal (SIGRT1) to all threads, allowing the handler for that signal to issue the syscall. Under qemu, __xidcmd remains null (see variable display below backtrace). + +Backtrace: +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x3fff85c74fc0 (LWP 74517)] +0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +263 nptl-init.c: No such file or directory. +(gdb) thread apply all bt + +Thread 3 (Thread 0x3fff87e8efc0 (LWP 74515)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060109080 in futex_wait (val=<optimized out>, ev=<optimized out>) at /build/qemu/util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=0x62367bb0 <rcu_call_ready_event>) at /build/qemu/util/qemu-thread-posix.c:399 +#3 0x000000006010f73c in call_rcu_thread (opaque=<optimized out>) at /build/qemu/util/rcu.c:250 +#4 0x0000000060176f8c in start_thread (arg=0x3fff87e8efc0) at pthread_create.c:336 +#5 0x00000000601cebf4 in clone () + +Thread 2 (Thread 0x3fff85c74fc0 (LWP 74517)): +#0 0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +#1 <signal handler called> +#2 0x00000000601cc42c in syscall () +#3 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#4 do_futex (val3=<optimized out>, uaddr2=275186650880, timeout=0, val=1129, op=128, uaddr=275186651116) at /build/qemu/linux-user/syscall.c:6201 +#5 do_syscall (cpu_env=0x1000abfd350, num=<optimized out>, arg1=275186651116, arg2=<optimized out>, arg3=1129, arg4=0, arg5=275186650880, arg6=<optimized out>, arg7=0, arg8=0) + at /build/qemu/linux-user/syscall.c:10651 +#6 0x00000000600347b8 in cpu_loop (env=0x1000abfd350) at /build/qemu/linux-user/main.c:317 +#7 0x0000000060036ae0 in clone_func (arg=0x3fffc4c2ca38) at /build/qemu/linux-user/syscall.c:5445 +#8 0x0000000060176f8c in start_thread (arg=0x3fff85c74fc0) at pthread_create.c:336 +#9 0x00000000601cebf4 in clone () + +Thread 1 (Thread 0x1000aa05000 (LWP 74511)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#2 do_futex (val3=<optimized out>, uaddr2=1, timeout=0, val=1, op=128, uaddr=275078324992) at /build/qemu/linux-user/syscall.c:6201 +#3 do_syscall (cpu_env=0x1000aa23890, num=<optimized out>, arg1=275078324992, arg2=<optimized out>, arg3=1, arg4=0, arg5=1, arg6=<optimized out>, arg7=0, arg8=0) at /build/qemu/linux-user/syscall.c:10651 +#4 0x00000000600347b8 in cpu_loop (env=0x1000aa23890) at /build/qemu/linux-user/main.c:317 +#5 0x00000000600020e4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu/linux-user/main.c:4779 +(gdb) p __xidcmd +$1 = (struct xid_command *) 0x0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1716767 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1716767 new file mode 100644 index 00000000..8ae1b92c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1716767 @@ -0,0 +1,37 @@ + + + +file(1) fails with "Invalid argument" on qemu-sh4-user + +We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file: + +(sid_sh4)root@vs94:/# file /bin/bash +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +Running with "-d" yields more output: + +(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail +322: >> 7 byte&,=97,"(ARM)"] +0 == 97 = 0 +mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1) +mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000 + +323: >> 7 byte&,=-1,"(embedded)"] +0 == 18446744073709551615 = 0 +[try softmagic 1] +[try elf -1] +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +It seems that the comparison above has a bogus (overflown?) value. + +On actual hardware, it works: + +root@tirpitz:~> file /bin/bash +/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped +root@tirpitz:~> + +I have uploaded a chroot with Debian unstable which allows to reproduce the issue: + +> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1724485 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1724485 new file mode 100644 index 00000000..6c668c40 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1737444 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1737444 new file mode 100644 index 00000000..dd7ef2fd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1776478 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1776478 new file mode 100644 index 00000000..ea670a05 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1776478 @@ -0,0 +1,49 @@ + + + +Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation + +Hey, +I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. + +When running a compilation of DISTRHO-Ports we get: + +lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE +Makefile:62: recipe for target 'gen_lv2' failed +make[1]: *** [gen_lv2] Error 134 +make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' +Makefile:104: recipe for target 'lv2' failed +make: *** [lv2] Error 2 + + +lv2_ttl_generator source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator + +The command that is ruining is +lv2_ttl_generator ./TAL-Filter-2.so + +And ./TAL-Filter-2.so source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source + + + +Is there a way to debug what is going on? +This runs fine on a Raspberrypi which is armv7 + +A workaround would also help. + + +Bug in Zynthian: +https://github.com/zynthian/zynthian-sys/issues/59 +Bug in DISTRHO-Ports: +https://github.com/DISTRHO/DISTRHO-Ports/issues/29 + +Using qemu-arm-static version from master from two days ago: +qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 + +Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) + +Thanks, +Guy \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1777226 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1777226 new file mode 100644 index 00000000..7b39dace --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1777226 @@ -0,0 +1,18 @@ + + + +qemu-user warnings confuse userland applications + +I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: + +configure: Found potential Boot JDK using configure arguments +configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring +configure: (Your Boot JDK version must be one of: 10 11) +configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK +configure exiting with result code 1 + +See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=sh4&ver=11%7E18-1&stamp=1529119043&raw=0 + +Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. + +Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1783362 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1783362 new file mode 100644 index 00000000..021feb3f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1783362 @@ -0,0 +1,50 @@ + + + +qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 + +As shown in https://github.com/beehive-lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host executing a ELF 64-bit LSB executable, ARM aarch64 binary. + +Steps to reproduce the bug: + +- (cross-)compile the attached source file: + +$ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c -o mmap_qemu + +- Execute in a x86_64 host with qemu-user and qemu-user-binfmt: + +$ ./mmap_qemu +alloc: 0 +MAP_FAILED: -1 +errno: 0 +mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +- Execute in a ARM host without any additional dependecy: + +$ ./mmap_qemu +alloc: -1 +MAP_FAILED: -1 +errno: 22 + +The bug is present in Fedora: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.17.7-200.fc28.x86_64 + +And also in Ubuntu: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.15.0-23-generic + +Possibly related to: + +- https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html +- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1785203 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1785203 new file mode 100644 index 00000000..82e74066 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1785203 @@ -0,0 +1,46 @@ + + + +accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. + +qemu-riscv64 version 2.12.93 crashes when mincore() is called with invalid pointer with the following message: + +qemu-riscv64: /opt/qemu/accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600014ef + +Testcase: + +#include <sys/mman.h> + +int main (void) +{ + unsigned char v; + return mincore ((void *) 0x00000010000000000, 1, &v); +} + +Backtrace: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x000000006000140a in abort () at abort.c:79 +#2 0x00000000600012ec in __assert_fail_base ( + fmt=0x6024eae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", + file=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=2511, + function=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") at assert.c:92 +#3 0x000000006010e10e in __assert_fail ( + assertion=assertion@entry=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", file=file@entry=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=line@entry=2511, + function=function@entry=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") + at assert.c:101 +#4 0x000000006003e916 in page_check_range (start=start@entry=1099511627776, len=len@entry=1, + flags=flags@entry=1) at /opt/qemu/accel/tcg/translate-all.c:2511 +#5 0x0000000060057717 in access_ok (size=1, addr=1099511627776, type=0) + at /opt/qemu/linux-user/qemu.h:567 +#6 lock_user (copy=0, len=1, guest_addr=1099511627776, type=0) + at /opt/qemu/linux-user/qemu.h:567 +#7 do_syscall (cpu_env=cpu_env@entry=0x622fca28, num=232, arg1=1099511627776, arg2=1, + arg3=274886298751, arg4=0, arg5=274886298808, arg6=66518, arg7=0, arg8=0) + at /opt/qemu/linux-user/syscall.c:11635 +#8 0x0000000060066c5c in cpu_loop (env=env@entry=0x622fca28) + at /opt/qemu/linux-user/riscv/cpu_loop.c:55 +#9 0x0000000060002156 in main (argc=<optimized out>, argv=0x7fffffffed68, + envp=<optimized out>) at /opt/qemu/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1813398 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1813398 new file mode 100644 index 00000000..cf95330d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1814128 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1814128 new file mode 100644 index 00000000..7b23ecb0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1821444 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1821444 new file mode 100644 index 00000000..572d8a99 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1821444 @@ -0,0 +1,32 @@ + + + +qemu-ppc (user) incorrectly translates float32 arithmetics + +I'm using qemu-3.1.0 (Gentoo). + +When I was running regression test suite via qemu-ppc for GHC I noticed a few uint32_t<->float32 failures I did not expect to encounter. + +Here is an example + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + printf("0x1 = %e\n", *(volatile float*)&i); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && ./a +0x1 = 2.802597e-45 + +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/ +a 100% 826KB 102.0KB/s 00:08 + +$ ssh timberdoodle.ppc64.dev.gentoo.org ./a +0x1 = 1.401298e-45 +$ qemu-ppc ./a +0x1 = 2.802597e-45 + +Looks like off-by-one bit somewhere. I'm not sure if it's FPU instruction or some internals of printf() that are emulated incorrectly. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1858461 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1858461 new file mode 100644 index 00000000..c23f0f8d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1858461 @@ -0,0 +1,26 @@ + + + +Please refactor linux-user/mips/cpu_loop.c + +Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. + +Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: + +``` +MIPS_SYS(sys_getdents64_x32, 3) +``` + +But + +``` +syscall_num = env->active_tc.gpr[2] - 4000; +if (syscall_num >= sizeof(mips_syscall_args)) { + ret = -TARGET_ENOSYS; +``` + +returns -TARGET_ENOSYS + +We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. + +Can you please refactor mips cpu loop in the same way as arm? Thank you. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1869241 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1869241 new file mode 100644 index 00000000..6b7faaa9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1869241 @@ -0,0 +1,22 @@ + + + +svn checkout fails with E000075 "Value too large for defined data type" + +I try to autobuild for ARM7 with qemu-arm-static. Part of this is downloading source via SVN. + +Whenever I try to download a SVN repository I get the following output: + + svn: E000075: Can't read directory '...': Value too large for defined data type + +qemu-arm-static version is 4.2.0 + +I've also tried older versions without change. + +Platform I try to emulate is armv7h (Arch Linux ARM for Raspberry Pi 2) + +Host system is AMD64 + +This can be reproduced 100% of the time. Here I have the issue happening on Travis CI: + +https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/304839747#L7228 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1884719 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1884719 new file mode 100644 index 00000000..58e4b595 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1884719 @@ -0,0 +1,135 @@ + + + +Function not implemented when using libaio + +Hello + +I experience "Function not implemented" errors when trying to use Linux libaio library in foreign architecture, e.g. aarch64. + +I've faced this problem while using https://github.com/multiarch/qemu-user-static, i.e. Docker+QEMU. +I understand that I do not use plain QEMU and you may count this report as a "distribution of QEMU"! Just let me know what are the steps to test it with plain QEMU and I will test and update this ticket! + + +Here are the steps to reproduce the issue: + +1) On x86_64 machine register QEMU: + + `docker run -it --rm --privileged multiarch/qemu-user-static --reset --credential yes --persistent yes` + +2) Start a Docker image with foreign CPU architecture, e.g. aarch64 + + `docker run -it arm64v8/centos:8 bash` + +3) Inside the Docker container install GCC and libaio + + `yum install gcc libaio libaio-devel` + +4) Compile the following C program + +``` +#include <stdio.h> +#include <errno.h> +#include <libaio.h> +#include <stdlib.h> + +struct io_control { + io_context_t ioContext; +}; + +int main() { + int queueSize = 10; + + struct io_control * theControl = (struct io_control *) malloc(sizeof(struct io_control)); + if (theControl == NULL) { + printf("theControl is NULL"); + return 123; + } + + int res = io_queue_init(queueSize, &theControl->ioContext); + io_queue_release(theControl->ioContext); + free(theControl); + printf("res is: %d", res); +} +``` + + ``` + cat > test.c + [PASTE THE CODE ABOVE HERE] + ^D + ``` + + `gcc test.c -o out -laio && ./out` + + +When executed directly on aarch64 machine (i.e. without emulation) or on x86_64 Docker image (e.g. centos:8) it prints `res is: 0`, i.e. it successfully initialized a LibAIO queue. + +But when executed on Docker image with foreign/emulated CPU architecture it prints `res is: -38` (ENOSYS). `man io_queue_init` says that error ENOSYS is returned when "Not implemented." + +Environment: + +QEMU version: 5.0.0.2 (https://github.com/multiarch/qemu-user-static/blob/master/.travis.yml#L24-L28) +Container application: Docker +Output of `docker --version`: + +``` +Client: + Version: 19.03.8 + API version: 1.40 + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 23:42:35 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: + Engine: + Version: 19.03.8 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.8 + Git commit: afacb8b7f0 + Built: Wed Mar 11 22:48:33 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.3.3-0ubuntu2 + GitCommit: + runc: + Version: spec: 1.0.1-dev + GitCommit: + docker-init: + Version: 0.18.0 + GitCommit: +``` + +Same happens with Ubuntu (arm64v8/ubuntu:focal). + +I've tried to `strace` it but : + +``` +/usr/bin/strace: ptrace(PTRACE_TRACEME, ...): Function not implemented +/usr/bin/strace: PTRACE_SETOPTIONS: Function not implemented +/usr/bin/strace: detach: waitpid(112): No child processes +/usr/bin/strace: Process 112 detached +``` + +Here are the steps to reproduce the problem with strace: + + ``` + docker run --rm -it --security-opt seccomp:unconfined --security-opt apparmor:unconfined --privileged --cap-add ALL arm64v8/centos:8 bash + + yum install -y strace` + + strace echo Test + ``` + +Note: I used --privileged, disabled seccomp and apparmor, and added all capabilities + +Disabling security solves the "Permission denied" problem but then comes the "Not implemented" one. + + +Any idea what could be the problem and how to work it around ? +I've googled a lot but I wasn't able to find any problems related to libaio on QEMU. + +Thank you! +Martin \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1895471 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1895471 new file mode 100644 index 00000000..517420fb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1895471 @@ -0,0 +1,26 @@ + + + +compilation error with clang in util/async.c + +configured with ` CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable-jemalloc --enable-fuzzing --enable-sdl` and after make I get the following error related to c11 atomics. I'm using clang because I'm experimenting with fuzzer + +[glitz@archlinux /code/qemu/build]$ ninja -j5 +[479/2290] Compiling C object libqemuutil.a.p/util_async.c.o +FAILED: libqemuutil.a.p/util_async.c.o +clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -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 -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c +../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or' +#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid) + *flags = atomic_fetch_and(&bh->flags, + ^ ~~~~~~~~~~ +/usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and' +#define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST) + ^ ~~~~~~ +2 errors generated. +[483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o +ninja: build stopped: subcommand failed. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1904259 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1904259 new file mode 100644 index 00000000..df07207a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/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:32b/output/manual-review/1906193 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1906193 new file mode 100644 index 00000000..3d8af207 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/1906193 @@ -0,0 +1,60 @@ + + + +riscv32 user mode emulation: fork return values broken + +When running in a chroot with riscv32 (on x86_64; qemu git master as of today): + +The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! + +gcc-10.2 + +=============================================== +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> +#include <sys/wait.h> + +main(c, v) + int c; + char **v; +{ + pid_t pid, p; + int s, i, n; + + s = 0; + pid = fork(); + if (pid == 0) + exit(42); + + /* wait for the process */ + p = wait(&s); + if (p != pid) + exit (255); + + if (WIFEXITED(s)) + { + int r=WEXITSTATUS(s); + if (r!=42) { + printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); + } + } +} +=============================================== + +(riscv-ilp32 chroot) farino /tmp # ./wait-test-short +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 + +=============================================== +(riscv-ilp32 chroot) farino /tmp # gcc --version +gcc (Gentoo 10.2.0-r1 p2) 10.2.0 +Copyright (C) 2020 Free Software Foundation, Inc. +Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es +gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. + +(riscv-ilp32 chroot) farino /tmp # ld --version +GNU ld (Gentoo 2.34 p6) 2.34.0 +Copyright (C) 2020 Free Software Foundation, Inc. +This program is free software; you may redistribute it under the terms of +the GNU General Public License version 3 or (at your option) a later version. +This program has absolutely no warranty. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/2825 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/2825 new file mode 100644 index 00000000..283fd455 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/2825 @@ -0,0 +1,40 @@ + + + +execveat with file descriptor and empty filename returns ENOENT when cross architectures +Description of problem: +On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors. + +I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error). +Steps to reproduce: +1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. +2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64` +3. Run different versions of test +4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64` +5. Sample outputs + +``` +rrex@debian:~/Downloads$ ./test +****Running to prepare execve +fd=3 +File size: 772296 bytes + +execveat with AT_EMPTY_PATH: +**Running in execve + +execveat with fd path: /proc/self/fd/3 +**Running in execve + +rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 +****Running to prepare execve +fd=3 +File size: 706104 bytes + +execveat with AT_EMPTY_PATH: +!!execveat a fd failed with errno: No such file or directory + +execveat with fd path: /proc/self/fd/3 +**Running in execve +``` +Additional information: +# diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/449 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/449 new file mode 100644 index 00000000..7b194c31 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/449 @@ -0,0 +1,71 @@ + + + +s390x linux-user assertion fires in vector asm on master +Description of problem: +Seeing a assert being fired when running this go program that executes vector instructions: + +[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go) + +``` +qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed. +SIGABRT: abort +PC=0x5b660 m=0 sigcode=4294967290 + +goroutine 1 [running]: +runtime.sigpanic() + /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660 +crypto/elliptic.p256SqrInternalVMSL() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600 +p256SqrInternal() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8 +crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c +crypto/elliptic.p256Sqr(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81 +crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6 +crypto/elliptic.initTable() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2 +crypto/elliptic.initP256Arch(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57 +crypto/elliptic.initP256() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960 +crypto/elliptic.initAll() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4 +sync.(*Once).doSlow(0x2168e8, 0x122be8) + /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c +sync.(*Once).Do(...) + /home/jalbrecht/s390x/15/go/src/sync/once.go:57 +crypto/elliptic.P256(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433 +main.main() + /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e +runtime.main() + /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4 +runtime.goexit() + /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52 + +r0 0x0 r1 0xc000198bc0 +r2 0xc000198ce0 r3 0xc000198ce0 +r4 0x1401a0 r5 0xc000198be0 +r6 0xc000198bc0 r7 0x1c00f0 +r8 0xda600 r9 0xc0001989a8 +r10 0x217810 r11 0x0 +r12 0x4000800378 r13 0xc000000180 +r14 0xda600 r15 0xc000198998 +pc 0x5b660 link 0xda600 +exit status 2 +``` +Steps to reproduce: +On an amd64 linux host: +1. Download attached ecdsaexample.go file +2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz +3. Build a qemu-s390x-static from current master +4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go +Additional information: +@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues. + +This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs. + +cc: @ruixinbao diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/456 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/456 new file mode 100644 index 00000000..af5974ce --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/456 @@ -0,0 +1,32 @@ + + + +Qemu User (x86_64) Hangs after futex function not implemented error +Description of problem: +Qemu User hangs on futex call with the following last strace +``` +futex(0x0000004001a01654,FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI,0,NULL,NULL,0) = -1 errno=38 (Function not implemented) +``` +This is the last call until giving a SIGINT with CTRL + C where the following strace is output +``` +futex(0x00000040b0085180,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,2,NULL,NULL,0) = -1 errno=4 (Interrupted system call) +--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL, si_pid=0, si_uid=0} --- + +``` +Steps to reproduce: +1. Install steamcmd https://developer.valvesoftware.com/wiki/SteamCMD +2. In the steamcmd shell install Valheim dedicated server with `app_update 896660` +3. Navigate to the downloaded app `cd ~/Steam/steamapps/common/Valheim\ dedicated\ server/` +4. Run `qemu-x86_64 valheim_server.x86_64` +5. The process hangs as per description. +Additional information: +The issue was originally encountered on a raspberry pi ARM64 host using the ubuntu 5.2.0 version of qemu. Installed cross libararies: +* libc6-amd64-cross +* libgcc-s1-amd64-cross + +It was then replicated on the x86 host fedora with a build of the qemu master branch. +The full qemu -strace output is provided below +[qemu_strace_output.log](/uploads/96e0e31b1e63191a94d73f05023c5173/qemu_strace_output.log) + +The expected output found when running `strace ./valheim_server.x86_64` without qemu on the x86_64 host is attached below +[expected_output.log](/uploads/b3b25618103de8a3b9c0ef227bbffc9c/expected_output.log) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/714 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/714 new file mode 100644 index 00000000..acca70ae --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/714 @@ -0,0 +1,46 @@ + + + +Command line arguments are not passed correctly with user-space semihosting +Description of problem: +The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1): +``` +$ qemu-arm -cpu cortex-m7 ./a.out 123 test +argc: 1 +argv: + - @@@ + +$ qemu-arm -cpu cortex-m7 ./a.out +argc: 1 +argv: + [0] @ +``` +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> + +int main(int argc, char* argv[]) { + std::cout << "argc: " << argc << "\n"; + std::cout << "argv: \n"; + + for (int i = 0; i < argc; i++) + std::cout << " [" << i << "] " << argv[i] << "\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 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. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 ./a.out +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/739785 b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/739785 new file mode 100644 index 00000000..f02406e4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/manual-review/739785 @@ -0,0 +1,37 @@ + + + +qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Good time of day everybody, + +I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. + +1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ +2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +./configure --static --disable-blobs --disable-system --target-list=i386-linux-user +make + +3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. +uname -a +Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + +4. Added the following options into /etc/rc.local +/sbin/modprobe binfmt_misc +/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + +6.Now i chroot into /i386 and I get this: +[root@Plugbox i386]# chroot . +[II aI hnve ao n@P /]# pacman -Suy +bash: fork: Invalid argument + +7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: +[root@Plugbox linux-user-test-0.3]# make +./qemu-linux-user.sh +[qemu-i386] +../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile +BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +make: *** [test] Error 127 \ No newline at end of file |