diff options
Diffstat (limited to 'results/classifier/no-thinking-deepseek-r1:32b')
1104 files changed, 25283 insertions, 0 deletions
diff --git a/results/classifier/no-thinking-deepseek-r1:32b/analysis.csv b/results/classifier/no-thinking-deepseek-r1:32b/analysis.csv new file mode 100644 index 000000000..cb42304d5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/analysis.csv @@ -0,0 +1,4 @@ +category, count +instruction, 113 +manual-review, 2 +runtime, 4 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/categories.csv b/results/classifier/no-thinking-deepseek-r1:32b/categories.csv new file mode 100644 index 000000000..25384563c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/categories.csv @@ -0,0 +1,5 @@ +category, count +manual-review, 34 +instruction, 191 +syscall, 76 +runtime, 250 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1022 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1022 new file mode 100644 index 000000000..d81aef62e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1022 @@ -0,0 +1,36 @@ + + + +RISC-V: Simulation terminated with seg fault when encountering `vsra.vx` +Description of problem: +QEMU simulation terminated with segmentation fault. Here is the backtrace of the simulation + +``` +(gdb) r +Starting program: qemu/build/qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 a.out +Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-164.el8_5.3.x86_64 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +[New Thread 0x7ffff4edd700 (LWP 3239772)] + +Thread 1 "qemu-riscv64" received signal SIGSEGV, Segmentation fault. +0x00007fffe8004fad in code_gen_buffer () +Missing separate debuginfos, use: yum debuginfo-install glib2-2.56.4-156.el8.x86_64 gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-4.el8.x86_64 libffi-3.1-22.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libtasn1-4.13-3.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64 pcre-8.42-6.el8.x86_64 +(gdb) bt +#0 0x00007fffe8004fad in code_gen_buffer () +#1 0x00005555556a0b9b in cpu_tb_exec (tb_exit=<synthetic pointer>, itb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:358 +#2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:848 +#3 cpu_exec (cpu=cpu@entry=0x555555eed3d0) at ../accel/tcg/cpu-exec.c:1007 +#4 0x00005555555e6d30 in cpu_loop (env=0x555555ef56f0) at ../linux-user/riscv/cpu_loop.c:37 +#5 0x00005555555df9f7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:909 +``` +Steps to reproduce: +1. Checkout to QEMU's latest master (`ec11dc41eec5142b4776db1296972c6323ba5847`) +2. `mkdir build ; cd build ; ../configure ; make -j24` +3. `qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 ./a.out` +Additional information: +Attaching code (output.c) and binary (a.out) + +[a.out](/uploads/0ecfb436a439619527ef645bdc781a48/a.out) + +[output.c](/uploads/cd492b4c9468f0b48412e76e7f6fcf91/output.c) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1027 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1027 new file mode 100644 index 000000000..cad3d64f5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1051 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1051 new file mode 100644 index 000000000..fcbf675c2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1051 @@ -0,0 +1,4 @@ + + + +or1k tcg SIGILL diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1054812 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1054812 new file mode 100644 index 000000000..8b1d033c4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1075 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1075 new file mode 100644 index 000000000..1c45079ab --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1079080 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1079080 new file mode 100644 index 000000000..069bd5e2b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1079080 @@ -0,0 +1,13 @@ + + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1092 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1092 new file mode 100644 index 000000000..60c305b43 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1092 @@ -0,0 +1,17 @@ + + + +PPC: `sraw` instructions does not set `ca` and `ca32` flags. +Description of problem: +The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to +[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. +Additional information: +This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). + +**sraw** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 + +**srawi** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095531 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095531 new file mode 100644 index 000000000..0de5aed7b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095531 @@ -0,0 +1,60 @@ + + + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. + +-------------- +IN: +0x0000000040804aa8: st %i0, [ %fp + 0x44 ] + +OP: + ---- 0x40804aa8 + ld_i64 tmp1,regwptr,$0xb0 + mov_i64 tmp0,tmp1 + movi_i64 tmp2,$0x44 + add_i64 tmp0,tmp0,tmp2 + ld_i64 tmp2,regwptr,$0x80 + ext32u_i64 tmp0,tmp0 + qemu_st32 tmp2,tmp0,$0x0 + +OUT: [size=345] +0x6032d7f0: mov 0x40(%r14),%rbp +0x6032d7f4: mov 0xb0(%rbp),%rbx +0x6032d7fb: add $0x44,%rbx +0x6032d7ff: mov 0x80(%rbp),%rbp +0x6032d806: mov %ebx,%ebx <- bug +0x6032d808: mov %ebp,%edi +0x6032d80a: bswap %edi +0x6032d80c: mov %edi,(%rbx) + +-------------- +IN: +0x0000000040804aec: add %l7, %o7, %l7 +0x0000000040804af0: ld [ %l7 ], %g2 + +OP: + ---- 0x40804aec + ld_i64 tmp1,regwptr,$0x78 + ld_i64 tmp2,regwptr,$0x38 + add_i64 tmp0,tmp1,tmp2 + st_i64 tmp0,regwptr,$0x78 + + ---- 0x40804af0 + ld_i64 tmp1,regwptr,$0x78 + mov_i64 tmp0,tmp1 + ext32u_i64 tmp0,tmp0 + qemu_ld32u g2,tmp0,$0x0 + +OUT: [size=395] +0x6032da80: mov 0x40(%r14),%rbp +0x6032da84: mov 0x78(%rbp),%rbx +0x6032da88: mov 0x38(%rbp),%r12 +0x6032da8c: add %r12,%rbx +0x6032da8f: mov %rbx,0x78(%rbp) +0x6032da93: mov 0x78(%rbp),%rbx +0x6032da97: mov %ebx,%ebx <- bug +0x6032da99: mov (%rbx),%ebx + +In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095857 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095857 new file mode 100644 index 000000000..c82825908 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1095857 @@ -0,0 +1,14 @@ + + + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +end up executing as + +mov eax,[r15] + +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1129571 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1129571 new file mode 100644 index 000000000..dc66da3bb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1129571 @@ -0,0 +1,17 @@ + + + +libreoffice armhf FTBFS + +We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. + +While we do not have a small test case yet, we do have a build log (attaching here). + +The relevant snippet from the build log is: + +3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro +dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' + +We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. + +Any help in tracking this down would be appreciated. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1156 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1156 new file mode 100644 index 000000000..76296a60b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1156 @@ -0,0 +1,4 @@ + + + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1178 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1178 new file mode 100644 index 000000000..ffe5b226f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1178 @@ -0,0 +1,4 @@ + + + +is that riscv64 `feq.s` only should consider the lowest 32-bits. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1207896 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1207896 new file mode 100644 index 000000000..03d4dc725 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1233225 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1233225 new file mode 100644 index 000000000..0a7a2516c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1233225 @@ -0,0 +1,27 @@ + + + +mips/mipsel linux user float division problem + +Hi, + +I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program: + +#include <stdio.h> +int main(int argc, char **argv) +{ + int a = 1; + double d = a/2.0; + printf("%f\n", d); + return 0; +} + +Instead of printing 0.5, it will print 2.0 if executed in qemu user mode. + +$ mipsel-linux-gnu-gcc mipstest.c +$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out +2.0 + +Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode. + +Can anybody else reproduce this problem? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1245543 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1245543 new file mode 100644 index 000000000..6ca865d95 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1245543 @@ -0,0 +1,26 @@ + + + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1248 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1248 new file mode 100644 index 000000000..49134e68b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1248 @@ -0,0 +1,14 @@ + + + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1248168 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1248168 new file mode 100644 index 000000000..06b56a323 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1251 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1251 new file mode 100644 index 000000000..a9c329191 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1251 @@ -0,0 +1,18 @@ + + + +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1254786 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1254786 new file mode 100644 index 000000000..315e2004c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1254786 @@ -0,0 +1,45 @@ + + + +qemu-m68k-static: illegal instruction ebc0 during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian (ports) sid m68k + +$ sudo qemu-debootstrap --no-check-gpg --arch=m68k sid m68k http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch m68k --foreign --no-check-gpg sid m68k http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot m68k /debootstrap/debootstrap --second-stage +qemu: fatal: Illegal instruction: ebc0 @ f67e5662 +D0 = 6ffffef5 A0 = f67fbf58 F0 = 0000000000000000 ( 0) +D1 = 0000010a A1 = 00000000 F1 = 0000000000000000 ( 0) +D2 = 0000000f A2 = 00000000 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = f67e0000 F3 = 0000000000000000 ( 0) +D4 = 00000000 A4 = 00000000 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67fc000 F5 = 0000000000000000 ( 0) +D6 = 00000000 A6 = f6fff7cc F6 = 0000000000000000 ( 0) +D7 = 00000000 A7 = f6fff580 F7 = 0000000000000000 ( 0) +PC = f67e5662 SR = 0000 ----- FPRESULT = 0 +Aborted (core dumped) + +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 16:08:26 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:32b/output/instruction/1283519 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1283519 new file mode 100644 index 000000000..c65570d39 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1283519 @@ -0,0 +1,13 @@ + + + +PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped + +When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions: + +If the binary contains vrfim QEMU sees vrfiz +If the binary contains vrfin QEMU sees vrfim +If the binary contains vrfiz QEMU sees vrfin +The vrfip instruction is correctly recognized. + +Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1308381 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1308381 new file mode 100644 index 000000000..0560b9306 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1308381 @@ -0,0 +1,17 @@ + + + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1328996 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1328996 new file mode 100644 index 000000000..418a4353a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1328996 @@ -0,0 +1,6 @@ + + + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1339 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1339 new file mode 100644 index 000000000..dd0af5e85 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1339 @@ -0,0 +1,19 @@ + + + +RVV vfncvt.rtz.x.f.w Assertion failed +Description of problem: +when execute +``` +vsetvli t0, x0, e16, m1 +vfncvt.rtz.x.f.w v0, v4 +``` +report error: + +qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped) +Steps to reproduce: +1. write the code +2. compile +3. excute +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1368 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1368 new file mode 100644 index 000000000..a0d2c738c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1368 @@ -0,0 +1,41 @@ + + + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1370 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1370 new file mode 100644 index 000000000..da284a401 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1370 @@ -0,0 +1,16 @@ + + + +x86 BLSI and BLSR semantic bug +Description of problem: +The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("blsi rax, rbx"); +} +``` +2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1371 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1371 new file mode 100644 index 000000000..a77c0b1fe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1371 @@ -0,0 +1,22 @@ + + + +x86 BLSMSK semantic bug +Description of problem: +The result of instruction BLSMSK is different with from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x65b2e276ad27c67"); + asm("mov rbx, 0x62f34955226b2b5d"); + asm("blsmsk eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - CF = 0 + - QEMU + - CF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1372 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1372 new file mode 100644 index 000000000..ded24a388 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1372 @@ -0,0 +1,23 @@ + + + +x86 BEXTR semantic bug +Description of problem: +The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x17b3693f77fb6e9"); + asm("mov rbx, 0x8f635a775ad3b9b4"); + asm("mov rcx, 0xb717b75da9983018"); + asm("bextr eax, ebx, ecx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x5a + - QEMU + - RAX = 0x635a775a +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1373 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1373 new file mode 100644 index 000000000..d31e7a28e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1373 @@ -0,0 +1,23 @@ + + + +x86 ADOX and ADCX semantic bug +Description of problem: +The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("push 512; popfq;"); + asm("mov rax, 0xffffffff84fdbf24"); + asm("mov rbx, 0xb197d26043bec15d"); + asm("adox eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF). + - CPU + - OF = 0 + - QEMU + - OF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1374 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1374 new file mode 100644 index 000000000..f23fdda34 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1374 @@ -0,0 +1,25 @@ + + + +x86 BZHI semantic bug +Description of problem: +The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xb1aa9da2fe33fe3"); + asm("mov rbx, 0x80000000ffffffff"); + asm("mov rcx, 0xf3fce8829b99a5c6"); + asm("bzhi rax, rbx, rcx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x0x80000000ffffffff + - SF = 1 + - QEMU + - RAX = 0xffffffff + - SF = 0 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1375 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1375 new file mode 100644 index 000000000..62948b02a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1375 @@ -0,0 +1,22 @@ + + + +x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN +Description of problem: +The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];"); + asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];"); + asm("addsubps xmm1, xmm2"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2. + - CPU + - xmm1[3] = 0xffffffff + - QEMU + - xmm1[3] = 0x7fffffff +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1376 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1376 new file mode 100644 index 000000000..f6ab4a57f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1376 @@ -0,0 +1,18 @@ + + + +x86 LSL and LAR fault +Description of problem: +From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xa02e698e741f5a6a"); + asm("mov rbx, 0x20959ddd7a0aef"); + asm("lsl ax, bx"); +} +``` +2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1377 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1377 new file mode 100644 index 000000000..b8faf56e9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1377 @@ -0,0 +1,16 @@ + + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1397 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1397 new file mode 100644 index 000000000..5267b8404 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1397 @@ -0,0 +1,4 @@ + + + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1404690 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1404690 new file mode 100644 index 000000000..7ef62aa3c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1404690 @@ -0,0 +1,41 @@ + + + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1412 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1412 new file mode 100644 index 000000000..9c9539b49 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1412 @@ -0,0 +1,8 @@ + + + +QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1428352 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1428352 new file mode 100644 index 000000000..860650387 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1428352 @@ -0,0 +1,47 @@ + + + +SYSRET instruction incorrectly implemented + +The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic: + +SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *) + +Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here: + +http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html + +[...] + SS(SEL) = IA32_STAR[63:48] + 8; + SS(PL) = 0x3; +[...] + +In other words, the value of the %ss register is supposed to be loaded from bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call. + +However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this: + + cpu_x86_load_seg_cache(env, R_SS, selector + 8, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +It should look like this: + + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss). + +The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.) + +This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :) + +Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM. + +The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware. + +- Bill (<email address hidden>) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1441 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1441 new file mode 100644 index 000000000..9aaffc7f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1441 @@ -0,0 +1,37 @@ + + + +Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction +Description of problem: +When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.``` + +It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848 +Steps to reproduce: +The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6): +``` +/* test.c */ +#include <riscv_vector.h> + +#define LEN 4 + +int main(int argc, char *argv[]) { + double in[LEN]; + int out[LEN]; + + vfloat64m1_t vf = vle64_v_f64m1(in, LEN); + vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN); + vse32_v_i32mf2(out, vi, LEN); + + return 0; +} +``` + +The above `test.c` can be compiled and run as follows: +``` +clang -O3 -march=rv64gcv -static test.c +qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out +qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed. +Segmentation fault (core dumped) +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1452 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1452 new file mode 100644 index 000000000..d0390a57f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1452 @@ -0,0 +1,4 @@ + + + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1469342 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1469342 new file mode 100644 index 000000000..31e8630a1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1469342 @@ -0,0 +1,6 @@ + + + +qemu-i386 pentium3/athlon incorrect instruction set + +Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1531 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1531 new file mode 100644 index 000000000..e6a3bf1f6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1536 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1536 new file mode 100644 index 000000000..252246abf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1536 @@ -0,0 +1,19 @@ + + + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1547 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1547 new file mode 100644 index 000000000..879730151 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1574346 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1574346 new file mode 100644 index 000000000..59fce0e2b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1574346 @@ -0,0 +1,15 @@ + + + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1590336 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1590336 new file mode 100644 index 000000000..5f78ff54e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1590336 @@ -0,0 +1,18 @@ + + + +qemu-arm does not reject vrintz on non-v8 cpu + +Hello, + +It seems that qemu-arm does not reject some v8-only instructions as it should, but executes them "correctly". + +For instance, while compiling/running some of the GCC ARM instrinsics tests, we noticed that +vrintz should be rejected on cortex-a9 for instance, while it is executed as if the instruction was supported. + +objdump says: + 1074c: f3fa05a0 vrintz.f32 d16, d16 +and qemu -d in_asm says: +0x0001074c: f3fa05a0 vabal.u<illegal width 64> q8, d26, d16 + +The problem is still present in qemu-2.6.0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1594069 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1594069 new file mode 100644 index 000000000..2d47150c2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1594069 @@ -0,0 +1,11 @@ + + + +SIMD instructions translated to scalar host instructions + +SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. + +I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). + +[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 +[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1605123 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1605123 new file mode 100644 index 000000000..f79f6cadd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1605123 @@ -0,0 +1,31 @@ + + + +PEXT returns wrong values, seemingly switches arguments + +Hi, + +I fiddled with BMI2 instructions and discovered that pext instructions +emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It +seemingly switches up its arguments. I suspect that the error is around the +gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext +in target-i386/int_helper.c and it works fine. + +I ran my program on a CPU with BMI2 instruction set too, and it indeed +returns different values. + +I didn't check pdep, it could have the same problem. + +$ qemu-x86_64 --version +qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux + +I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". + +$ gcc --version +gcc (Debian 5.4.0-6) 5.4.0 20160609 + +Best regards, +Lénárd Szolnoki \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1606 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1606 new file mode 100644 index 000000000..6f678ad0f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1606 @@ -0,0 +1,32 @@ + + + +riscv: fence.i is not functional +Description of problem: +The attached user-level test is designed to do the following (in iteration): + + - Thread P0 on CPU0 changes some text/code, while + + - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code. + +Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification). +Steps to reproduce: +1. echo 2 > /proc/sys/vm/nr_hugepages +2. ./CoRF+fence.i +Additional information: +Example output: +```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c) +Test CoRF+fence.i Allowed +Histogram (4 states) +25784 :>1:x5=0xa009; 1:x7=2; +24207 *>1:x5=0xa009; 1:x7=1; <-- THIS LINE +8 :>1:x5=0xa019; 1:x7=1; +1 :>1:x5=0xa019; 1:x7=2; +Ok +Witnesses +Positive: 24207 Negative 25793 +Condition exists (1:x5=0xa009 /\ 1:x7=1) is validated +Observation CoRF+fence.i Sometimes 24207 25793 +Time CoRF+fence.i 0.85 +Hash= +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1611394 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1611394 new file mode 100644 index 000000000..0e397a201 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1611394 @@ -0,0 +1,32 @@ + + + +qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV] + +According to "Signal Processing Engine (SPE) Programming Environments Manual" at +http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1 + +c.f section 4.2.3 and also Figure 2-2. + +When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision floating-point instructions +should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt. + + +Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be removed. +Namely, in the definitions of +1. GEN_SPEFPUOP_ARITH2_32_32 +2. gen_efsabs +3. gen_efsnabs +4. gen_efsneg +5. GEN_SPEFPUOP_COMP_32 + +Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct. + +One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both +efs- and efd- instructions, and will need to be split in two versions. +The efs-use (i.e for efscfd) should be as it is today, but the use by efd-instructions +(e.g efdctui) will need to add a test for MSR[SPV]. + + + +(I've looked at today's HEAD-revision of target-ppc/translate.c). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1612 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1612 new file mode 100644 index 000000000..076536677 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1612 @@ -0,0 +1,54 @@ + + + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include <arm_sve.h> +#include <stdio.h> + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, + 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, + 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1613817 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1613817 new file mode 100644 index 000000000..f631772b2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1613817 @@ -0,0 +1,59 @@ + + + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1614348 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1614348 new file mode 100644 index 000000000..c9442ce00 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1620 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1620 new file mode 100644 index 000000000..e286fd225 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1620 @@ -0,0 +1,97 @@ + + + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include <stdio.h> + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1637 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1637 new file mode 100644 index 000000000..75c917c47 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1637 @@ -0,0 +1,4 @@ + + + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1641637 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1641637 new file mode 100644 index 000000000..82d651dca --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1641637 @@ -0,0 +1,716 @@ + + + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 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. + + +Thanks! \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1642 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1642 new file mode 100644 index 000000000..acf88a9a1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1642 @@ -0,0 +1,25 @@ + + + +Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host +Description of problem: +Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581. + +I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51 +Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le ` + +UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`) +Steps to reproduce: +N/A +Additional information: +``` +Thread 9 received signal SIGSEGV, Segmentation fault. +0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +60 CMPXCHG_HELPER(cmpxchgo_le, Int128) +(gdb) bt +#0 0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, + addr=18446684150325987376, oldv=46236672343829145701101521005152, + newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +#1 0x00000247a124f73d in ?? () + +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1661815 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1661815 new file mode 100644 index 000000000..9f7701f6e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1713066 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1713066 new file mode 100644 index 000000000..dc59a9d52 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1713066 @@ -0,0 +1,22 @@ + + + +Incorrect handling of aarch64 ldp in some cases + +In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. + +Given the following instruction: +ldp x0, x1, [x0] + +This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. + +I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. + +I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. + +I've observed this on: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard + +And checked I still get the same behaviour on: +QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) +Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1722 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1722 new file mode 100644 index 000000000..c35957aa5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1722 @@ -0,0 +1,90 @@ + + + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1725267 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1725267 new file mode 100644 index 000000000..544060feb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1725267 @@ -0,0 +1,34 @@ + + + +armeb regression since qemu version 2.8 + +Hi, + +I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. + +I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. + +# with 2.7: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +$ echo $? +0 +# with 2.8, 2.10.1: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) +$ echo $? +134 + +The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c + +Running with -d in_asm shows a difference early in the startup code: +IN: _dl_sysdep_start +[...] +0x40a17790: 908ff103 addls pc, pc, r3, lsl #2 + +and then the next address is not the same with qemu 2.7 and 2.10.1 + +I hope you have enough data/information to reproduce and confirm/fix the problem. + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1737 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1737 new file mode 100644 index 000000000..9ee7e33cc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1737 @@ -0,0 +1,52 @@ + + + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1738434 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1738434 new file mode 100644 index 000000000..3a255ebc4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1738434 @@ -0,0 +1,31 @@ + + + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +Environment: +QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img +Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 +Host OS: Windows 10 x64 version 1703 build 15063.786 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1748296 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1748296 new file mode 100644 index 000000000..73411abc8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1748296 @@ -0,0 +1,28 @@ + + + +TCG throws Invalid Opcode when executing x86 BMI shlx instruction + +I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. + +The code executes correctly and passes the test under KVM. + +I have created a complete repro here: https://github.com/doug65536/qemu-bmibug + +The makefile has the following utility targets: + +debug-kvm: Build and run the VM using KVM and wait for gdbstub attach + +run: Run the test case with TCG, make fails if the test fails. (It will fail) + +run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) + +debug: Build and run the VM with TCG and wait for GDB attach + +attach-gdb: Run GDB and attach to KVM gdbstub + +The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. + +You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. + +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751422 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751422 new file mode 100644 index 000000000..81442661b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751422 @@ -0,0 +1,7 @@ + + + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751494 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751494 new file mode 100644 index 000000000..e53701f55 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1751494 @@ -0,0 +1,39 @@ + +instruction: 0.878 +graphic: 0.676 +assembly: 0.586 +device: 0.585 +semantic: 0.580 +mistranslation: 0.510 +other: 0.502 +socket: 0.335 +network: 0.320 +vnc: 0.279 +boot: 0.154 +KVM: 0.051 + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. + +The exact commit that causes this problem is this: + +commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac +tcg/i386: Add vector operations + +This has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1756927 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1756927 new file mode 100644 index 000000000..7ad0a2c7f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1756927 @@ -0,0 +1,21 @@ + + + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +The last entry should read 'long-descriptor'. + + +Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 +Ubuntu verison: 16.04 LTS +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1761401 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1761401 new file mode 100644 index 000000000..fc9257bd5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1761401 @@ -0,0 +1,13 @@ + + + +ARM/Neon: vcvt rounding error + +Hello, + +While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. + +The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. +The expected result is 125, but we get 126 instead. + +Maybe it's just a matter of default rounding mode? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1771 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1771 new file mode 100644 index 000000000..818e547e8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1771 @@ -0,0 +1,36 @@ + + + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1779 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1779 new file mode 100644 index 000000000..3264198e0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1779 @@ -0,0 +1,33 @@ + + + +PowerPC AltiVec source vector subnormal values are not flushed to zero +Description of problem: +AltiVec specifies that source and result vectors are flushed to zero (in NJ mode). Only result vectors are flushed to zero. +Steps to reproduce: +1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +See the offending Rust program: + +``` +#![feature(stdsimd, powerpc_target_feature)] + +use std::arch::powerpc::*; + +#[target_feature(enable = "altivec")] +unsafe fn add(x: f32, y: f32) -> f32 { + let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) }; + array[0] +} + +pub fn main() { + let result = unsafe { add(-1.0857398e-38, 0.) }; + assert_eq!(result, 0.); + + // if the input is flushed, the result will be +0 + // if only the output is flushed, the result is -0 + assert!(result.is_sign_positive()); +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1780 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1780 new file mode 100644 index 000000000..dd71873ae --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1780 @@ -0,0 +1,20 @@ + + + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1781281 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1781281 new file mode 100644 index 000000000..d358dc7b7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1781281 @@ -0,0 +1,31 @@ + + + +qemu-ppc64le uncaught target signal 4 (Illegal instruction) + +qemu-ppc64le version 2.12.0 +host machine: x86_64 Arch Linux + +I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. +0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +#1 0x000055555567ee68 in ?? () +#2 0x000055555567fd18 in ?? () +#3 0x00005555556805ef in process_pending_signals () +#4 0x0000555555661e69 in cpu_loop () +#5 0x000055555561fd72 in main () + +This can be reproduced by downloading this patch (patchset 1): + +https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 + +and running + +qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" + +I don't observe any issues when running the code on a POWER9 machine. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1785734 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1785734 new file mode 100644 index 000000000..1346c5a11 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1785734 @@ -0,0 +1,78 @@ + + + +movdqu partial write at page boundary + +In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example. + +Tested on the qemu-3.0.0-rc1 release. + + +% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x7 +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 + +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x6 +*(0x70000ff8+ 0) = 77 +*(0x70000ff8+ 1) = 66 +*(0x70000ff8+ 2) = 55 +*(0x70000ff8+ 3) = 44 +*(0x70000ff8+ 4) = 33 +*(0x70000ff8+ 5) = 22 +*(0x70000ff8+ 6) = 11 +*(0x70000ff8+ 7) = 0 +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1790 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1790 new file mode 100644 index 000000000..5d081e59e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1790 @@ -0,0 +1,32 @@ + + + +[AARCH64] STGP instruction is not writing the value of the second register to memory +Description of problem: +My application is built with Clang 16 and the option -fsanitize=memtag-stack. +It means the the MTE protection is activated for the stack. +The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. +The following instruction was not working as expected: + 18004: 69000895 stgp x21, x2, [x4] +The value of the second register x2 is not transferred to the memory. +Only x21 is written. + +I think that the issue is in trans_STGP(). +We don't call finalize_memop_pair() like we do for in the general trans_STP(). + +``` +diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c +index 7d0c8f79a7..f599f3e136 100644 +--- a/target/arm/tcg/translate-a64.c ++++ b/target/arm/tcg/translate-a64.c +@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) + + tcg_rt = cpu_reg(s, a->rt); + tcg_rt2 = cpu_reg(s, a->rt2); ++ mop = a->sz + 1; ++ mop = finalize_memop_pair(s, mop); + + assert(a->sz == 3); +``` + +With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793119 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793119 new file mode 100644 index 000000000..9990b2c6d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793119 @@ -0,0 +1,32 @@ + + + +Wrong floating-point emulation on AArch64 with FPCR set to zero + +On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). + +I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`. + +Output on real hardware: +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` equals `q`. + +Output on qemu 3.0.0 (Linux user-mode emulation): +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` is not equal to `q`. + +Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv". + +Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793608 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793608 new file mode 100644 index 000000000..e865e400c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1793608 @@ -0,0 +1,19 @@ + + + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1806243 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1806243 new file mode 100644 index 000000000..d3250c600 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1806243 @@ -0,0 +1,87 @@ + + + +ARM conditional branch after if-then instruction not working + +Hello + +There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. + +2000407a: push {lr} +2000407c: movs r0, r6 +2000407e: ldmia r7!, {r1, r6} +20004080: push {r0, r1} +20004082: str.w r6, [r7, #-4]! +20004086: ldr r6, [sp, #0] +20004088: pop {r0, r1} +2000408a: adds r0, #1 +2000408c: cmp r0, r1 +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here +20004096: pop {pc} + +I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: + +void f() { + static uint8_t stack[256]{}; + stack[255] = 4; + + asm volatile("\n\t" + "push {lr}" + "\n\t" + + // pre-conditions + "movs r7, %[stack]" + "\n\t" + "movs r6, #1" + "\n\t" + + "movs r0, r6" + "\n\t" + "ldmia r7!, {r1, r6}" + "\n\t" + "push {r0, r1}" + "\n\t" + "1:" + "\n\t" + "str.w r6, [r7, #-4]!" + "\n\t" + "ldr r6, [sp, #0]" + "\n\t" + "pop {r0, r1}" + "\n\t" + "adds r0, #1" + "\n\t" + "cmp r0, r1" + "\n\t" + "itt lt" + "\n\t" + "pushlt {r0, r1}" + "\n\t" + + // Original instruction + //"blt.w 0x20004082" // ; unpredictable <IT:lt> + + // Trying to fake it + "blt.w 1b" + "\n\t" + + "pop {pc}" + "\n\t" + : + : [stack] "r"(&stack[255])); +} + +The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? + +Quickly reading through already reported ARM bugs I think this might be related: +https://bugs.launchpad.net/qemu/+bug/1364501 +At least the symptoms sound identical. + + +The versions I'm running are: +QEMU 3.0.0 +arm-none-eabi-gdb 8.2 + +I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1815024 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1815024 new file mode 100644 index 000000000..7376befa4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1815024 @@ -0,0 +1,18 @@ + + + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1818075 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1818075 new file mode 100644 index 000000000..7eb43be42 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1818075 @@ -0,0 +1,56 @@ + + + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/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/instruction/1820686 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1820686 new file mode 100644 index 000000000..a141dce7d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1820686 @@ -0,0 +1,8 @@ + + + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821430 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821430 new file mode 100644 index 000000000..da8071c4c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821430 @@ -0,0 +1,35 @@ + + + +qemu-user-arm (4.0.0-rc0) crashes + +I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. +qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: + +first case (sadly I don't have more data handy, can reproduce at a later time if needed): +(gdb) x/i $pc +=> 0xfffce314: vseleq.f64 d0, d17, d0 + +second case (llvm-config): +qemu cmdline: +qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode + +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +output from gdb(arm) attached to qemu-user-arm +Program received signal SIGILL, Illegal instruction. +0xf9f77f80 in ?? () +(gdb) bt +#0 0xf9f77f80 in ?? () +#1 0xfffd796c in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) x/i $pc +=> 0xf9f77f80: vrintm.f64 d18, d18 + + +The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) +work flawlessly. + +This is clearly a regression. +Please fix before releasing 4.0.0. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821515 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821515 new file mode 100644 index 000000000..9392e639a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1821515 @@ -0,0 +1,41 @@ + + + +qemu-ppc (user) incorrectly converts float(nan)->double(non-nan) + +Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs. +Here is the minimal reproducer: + +```c +// cat a.c +#include <stdio.h> +#include <math.h> +#include <stdint.h> + +int main() { + volatile float f1 = NAN; + volatile float f2 = NAN; + printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n", + f1, *(volatile uint32_t*)&f1, + f2, *(volatile uint32_t*)&f2, + (f1 >= f2) ? "True" + : "False"); + volatile double d = f1; + printf ("d (%e, %#llx)\n", + d, *(volatile uint64_t*)&d); +} +``` + +``` +# incorrect execution: +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a +f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True +d (5.104236e+38, 0x47f8000000000000) + +# correct execution +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/; ssh timberdoodle.ppc64.dev.gentoo.org ./a +f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False +d (nan, 0x7ff8000000000000) +``` + +Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1824778 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1824778 new file mode 100644 index 000000000..0661b89a8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1824778 @@ -0,0 +1,10 @@ + + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1826568 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1826568 new file mode 100644 index 000000000..cebbffe97 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1826568 @@ -0,0 +1,16 @@ + + + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1828867 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1828867 new file mode 100644 index 000000000..a17fd5b58 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1828867 @@ -0,0 +1,11 @@ + + + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1832422 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1832422 new file mode 100644 index 000000000..eeb2facc5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1832422 @@ -0,0 +1,12 @@ + + + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1833 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1833 new file mode 100644 index 000000000..39a745ea4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1833 @@ -0,0 +1,87 @@ + + + +ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element +Description of problem: +QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. + +This seems to be a simple issue; I tracked it down to: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 + +Updating that `+ 1` to a `+ 8` fixes the problem. +Steps to reproduce: +```c +#include <stdio.h> +#include <stdint.h> +#include <string.h> + +void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { + asm volatile( + "smstart sm\n" + "smstart za\n" + "ptrue p0.b\n" + "mov x12, xzr\n" + "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" + "st1q {za0h.q[w12, 0]}, p0, %1\n" + "smstop za\n" + "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); +} + +void print_first_128(uint8_t* data) { + putchar('['); + for (int i = 0; i < 16; i++) { + printf("%02d", data[i]); + if (i != 15) + printf(", "); + } + printf("]\n"); +} + +int main() { + _Alignas(16) uint8_t dest[512] = { }; + _Alignas(16) uint8_t src[512] = { }; + for (int i = 0; i < sizeof(src); i++) + src[i] = i; + puts("Before"); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); + st1q_sme_copy_test(src, dest); + puts("\nAfter "); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); +} +``` + +Compile with (requires at least clang ~14, tested with clang 16):<br/> +`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:<br/> +`qemu-aarch64 -cpu max,sme=on ./qemu_repro` + +It's expected just to copy from `src` to `dest` and output: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +``` + +But currently outputs: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] +``` +Additional information: +N/A diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1833668 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1833668 new file mode 100644 index 000000000..c6a88da61 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1841990 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1841990 new file mode 100644 index 000000000..309b9baa5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1841990 @@ -0,0 +1,41 @@ + + + +instruction 'denbcdq' misbehaving + +Instruction 'denbcdq' appears to have no effect. Test case attached. + +On ppc64le native: +-- +gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq +$ ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x22080000000000000000000000000000 +$ ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x22080000000000000000000000000001 +$ ./test-denbcdq $(seq 0 99) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x22080000000000000000000000000080 +-- + +With "qemu-ppc64le -cpu power9" +-- +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x0000000000000000000000000000000c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x0000000000000000000000000000001c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x0000000000000000000000000000100c +-- + +I started looking at the code, but I got confused rather quickly. Could be related to endianness? I think denbcdq arrived on the scene before little-endian was a big deal. Maybe something to do with utilizing implicit floating-point register pairs... I don't think the right data is getting to helper_denbcdq, which would point back to the gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1847467 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1847467 new file mode 100644 index 000000000..e0900ebd8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1847467 @@ -0,0 +1,19 @@ + + + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1857 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1857 new file mode 100644 index 000000000..64840da4c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1858415 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1858415 new file mode 100644 index 000000000..9a66d641a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1858415 @@ -0,0 +1,27 @@ + + + +in tcp_emu function has OOB bug + +qemu version: 4.1.0 + +```c +int tcp_emu(struct socket *so, struct mbuf *m){ +............ +case EMU_REALAUDIO: +............ + while (bptr < m->m_data + m->m_len) { + case 6: +............ + lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1]; +............ + *(uint8_t *)bptr++ = (p >> 8) & 0xff; + *(uint8_t *)bptr = p & 0xff; +............ + } +............ +............ +} +``` + +bptr)[1] and bptr++ ,may make bptr == m->m_data + m->m_len,and cause OOB（out of bounds.） \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1859713 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1859713 new file mode 100644 index 000000000..52aabc3d9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1859713 @@ -0,0 +1,28 @@ + + + +ARM v8.3a pauth not working + +Host: Ubuntu 19.10 - x86_64 machine +QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master) + +ARMV8.3 pauth is not working well. + +With a test code containing two pauth instructions: + - paciasp that sign LR with A key and sp as context; + - autiasp that verify the signature. + +Test: + - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664) + +Expected: + - autiasp places an invalid pointer in LR + +Result: + - autiasp successfully auth the pointer and places 0x0400660 in LR. + +Further explanations: + Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating. + With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + Values of top_bit and bottom_bit are strictly the same and it should not. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1861404 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1861404 new file mode 100644 index 000000000..769be0f54 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1861404 @@ -0,0 +1,53 @@ + + + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1861605 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1861605 new file mode 100644 index 000000000..09ddfa40c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1863247 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1863247 new file mode 100644 index 000000000..06754fce8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1863247 @@ -0,0 +1,11 @@ + + + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1869782 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1869782 new file mode 100644 index 000000000..4128c9607 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1869782 @@ -0,0 +1,16 @@ + + + +qemu-arm-static crashes "segmentation fault" when running "svn checkout" + +I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this. + +Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420 + +I don't get this error with an armv7h chroot. + +Maybe now I'll just try to remove all uses of svn in my build scripts... + +Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it... + +Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1873898 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1873898 new file mode 100644 index 000000000..452c82c83 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1873898 @@ -0,0 +1,41 @@ + + + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1874888 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1874888 new file mode 100644 index 000000000..8a9610f12 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1874888 @@ -0,0 +1,46 @@ + + + +certain programs make QEMU crash with "tcg fatal error" + +The following code snippet crashes qemu with + +.../tcg/tcg.c:3279: tcg fatal error +qemu-x86_64: /usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed. + +================ +int main() { + /* +00000000 <.data>: + 0: 2e 45 71 ff cs rex.RB jno 0x3 + 4: e9 00 00 f0 00 jmp 0xf00009 + 9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14] + e: c4 a3 7d 08 64 82 44 vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0 + 15: 00 + 16: 0f 1e 0a nop DWORD PTR [rdx] + 19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8] + 1d: 66 47 0f 3a 0c 3d 00 rex.RXB blendps xmm15,XMMWORD PTR [rip+0x8000],0x0 # 0x8028 + 24: 80 00 00 00 + 28: c4 e3 f9 df 5f 86 0d vaeskeygenassist xmm3,XMMWORD PTR [rdi-0x7a],0xd + 2f: c4 e2 55 92 74 fc 0a vgatherdps ymm6,DWORD PTR [rsp+ymm7*8+0xa],ymm5 + 36: c4 e2 f9 17 9a 01 00 vptest xmm3,XMMWORD PTR [rdx+0x1] + 3d: 00 00 +*/ + char buf[] = { + 0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D, 0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A, 0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00, 0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92, 0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00 + }; + void (*f)(void) = (void (*) (void))buf; + f(); + return 0; +} +================ +Steps to reproduce: +1) clang -static repro.c -o repro +2) qemu-x86_64-static repro + +Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are affected. + +A few more snippets that cause the same sort of behavior: +1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00, 0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF, 0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A + +2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00, 0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45, 0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C, 0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1877794 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1877794 new file mode 100644 index 000000000..936efc4c8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1877794 @@ -0,0 +1,6 @@ + + + +Constant Folding on 64-bit Subtraction causes SIGILL on linux-user glxgears ppc64le to x86_64 by way of generating bad shift instruction with c=-1 + +Hello, I've been recently working on my own little branch of QEMU implementing the drm IOCTLs, when I discovered that glxgears seems to crash in GLXSwapBuffers(); with a SIGILL. I investigated this for about 2 weeks, manually trying to trace the call stack, only to find that we seemingly crash in a bad shift instruction. Originally intended to be an shr_i64 generated to an RLDICL, we end up with an all ones(-1) c value, which gets thrown to the macro for generating the MB, and replaces the instruction with mostly ones. This new instruction, FFFFFFE0 is invalid on ppc64le, and crashes in a host SIGILL in codegen_buffer. I tried to see if the output of translate.c had this bad instruction, but all I got were two (shr eax, cl) instructions, and upon creating a test program with shr (eax, cl) in it, nothing happened. Then figuring that there was nothing actually wrong with the instruction in the first place, I turned my eye to the optimizer, and completely disabled constant folding for arithmetic instructions. This seemed to actually resolve the issue, and then I slowly enabled constant folding again on various instructions only to find that enabling not on the shifts, but on subtraction seemed to cause the bug to reappear. I am bewildered and frankly at this point I'm not sure I have a chance in hell of figuring out what causes it, so I'm throwing it here. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1881450 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1881450 new file mode 100644 index 000000000..37d7e0e6e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1883268 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1883268 new file mode 100644 index 000000000..97be215b8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1889288 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1889288 new file mode 100644 index 000000000..352290089 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1889288 @@ -0,0 +1,10 @@ + + + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1898954 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1898954 new file mode 100644 index 000000000..19fd0521e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1898954 @@ -0,0 +1,29 @@ + + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1901 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1901 new file mode 100644 index 000000000..dd2f3a207 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1901 @@ -0,0 +1,22 @@ + + + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1904210 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1904210 new file mode 100644 index 000000000..6a5a268f2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1904210 @@ -0,0 +1,54 @@ + + + +Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) + +This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. + +Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). + +Which means, it could be a bug in recent release. + +You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. + +In 2.5.0 version the -strace logs: +116 uname(0xf6ffed40) = 0 +116 brk(NULL) = 0x0009f000 +116 brk(0x0009fd00) = 0x0009fd00 +116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 +116 brk(0x000c0d00) = 0x000c0d00 +116 brk(0x000c1000) = 0x000c1000 +116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 +116 fstat64(1,0xf6ffe8e8) = 0 +116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 +116 fstat64(0,0xf6ffe7d0) = 0 +116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 +116 write(1,0xa5548,6)input: = 6 +116 read(0,0xa6550,4096)flag{ + = 6 +116 write(1,0xa5548,7)wrong! + = 7 +116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) +116 exit_group(0) + +In 2.11.1, it shows: +113 uname(0xfffeed30) = 0 +113 brk(NULL) = 0x0009f000 +113 brk(0x0009fd00) = 0x0009fd00 +113 readlink("/proc/self/exe",0xfffede68,4096) = 21 +113 brk(0x000c0d00) = 0x000c0d00 +113 brk(0x000c1000) = 0x000c1000 +113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 +113 fstat64(1,0xfffee8d8) = 0 +113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 +113 fstat64(0,0xfffee7c0) = 0 +113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 +113 write(1,0xa5548,6)input: = 6 +113 read(0,0xa6550,4096)flag{ + = 6 +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1905356 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1905356 new file mode 100644 index 000000000..7c92cb919 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1905356 @@ -0,0 +1,15 @@ + + + +No check for unaligned data access in ARM32 instructions + +hi + +According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. + +I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. + +To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908 new file mode 100644 index 000000000..6375c0e2a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908 @@ -0,0 +1,52 @@ + + + +8.1.0 regression: abnormal segfault in qemu-riscv64-static +Description of problem: +loading_from_clipboard_test of Cockatrice segfaults in qemu-riscv64-static. +Steps to reproduce: +1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment +2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U` +3. Build cockatrice 2.9.0 with tests in the container: https://github.com/Cockatrice/Cockatrice/releases/tag/2023-09-14-Release-2.9.0 +4. Run tests/loading_from_clipboard/loading_from_clipboard_test in the container +Additional information: +I have done bisection and find out that this commit caused the regression: 2d708164e0475064e0e2167bd73e8570e22df1e0 + +qemu built from HEAD(494a6a2) is still affected by this bug. + +Backtrace: + +``` +#0 0x00007fffe849f133 in code_gen_buffer () +#1 0x00007ffff7b3a433 in cpu_tb_exec (cpu=0x7ffff7f71010, itb=0x7fffe849f040 <code_gen_buffer+4845587>, +tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:457 +#2 0x00007ffff7b3aeac in cpu_loop_exec_tb (cpu=0x7ffff7f71010, tb=0x7fffe849f040 <code_gen_buffer+4845587>, +pc=46912625654024, last_tb=0x7fffffffde30, tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:919 +#3 0x00007ffff7b3b0e0 in cpu_exec_loop (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) at ../qemu/accel/tcg/cpu-exec.c:1040 +#4 0x00007ffff7b3b19e in cpu_exec_setjmp (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) +at ../qemu/accel/tcg/cpu-exec.c:1057 +#5 0x00007ffff7b3b225 in cpu_exec (cpu=0x7ffff7f71010) at ../qemu/accel/tcg/cpu-exec.c:1083 +#6 0x00007ffff7a53707 in cpu_loop (env=0x7ffff7f71330) at ../qemu/linux-user/riscv/cpu_loop.c:37 +#7 0x00007ffff7b5d0e0 in main (argc=4, argv=0x7fffffffe768, envp=0x7fffffffe790) at ../qemu/linux-user/main.c:999 +``` + +``` +0x7fffe849f105 <code_gen_buffer+4845784> jl 0x7fffe849f265 <code_gen_buffer+4846136> │ +│ 0x7fffe849f10b <code_gen_buffer+4845790> mov 0x50(%rbp),%rbx │ +│ 0x7fffe849f10f <code_gen_buffer+4845794> mov %rbx,%r12 │ +│ 0x7fffe849f112 <code_gen_buffer+4845797> mov %r12,0x70(%rbp) │ +│ 0x7fffe849f116 <code_gen_buffer+4845801> movabs $0x2aaaaf9bb000,%r13 │ +│ 0x7fffe849f120 <code_gen_buffer+4845811> mov %r13,0x38(%rbp) │ +│ 0x7fffe849f124 <code_gen_buffer+4845815> movq $0xffffffffaf9bb000,0x60(%rbp) │ +│ 0x7fffe849f12c <code_gen_buffer+4845823> mov $0xffffffffaf9bb4e0,%r13 │ +│ > 0x7fffe849f133 <code_gen_buffer+4845830> movzwl 0x0(%r13),%r13d │ +│ 0x7fffe849f138 <code_gen_buffer+4845835> and $0x7f,%ebx │ +│ 0x7fffe849f13b <code_gen_buffer+4845838> shl $0x7,%r13 │ +│ 0x7fffe849f13f <code_gen_buffer+4845842> add %r13,%rbx │ +│ 0x7fffe849f142 <code_gen_buffer+4845845> mov %rbx,0x50(%rbp) │ +│ 0x7fffe849f146 <code_gen_buffer+4845849> shl %rbx │ +│ 0x7fffe849f149 <code_gen_buffer+4845852> mov %rbx,0x38(%rbp) │ +│ 0x7fffe849f14d <code_gen_buffer+4845856> movabs $0x2aaaaf9a88e0,%r13 │ +│ 0x7fffe849f157 <code_gen_buffer+4845866> add %r13,%rbx │ +│ 0x7fffe849f15a <code_gen_buffer+4845869> mov %rbx,0x60(%rbp) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908626 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908626 new file mode 100644 index 000000000..a5714eef2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1908626 @@ -0,0 +1,68 @@ + + + +Atomic test-and-set instruction does not work on qemu-user + +I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: +``` + host: CentOS7 x86_64 + container: centos:centos7.9.2009 --platform linux/arm64/v8 + qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ +``` + +However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock +has something wrong. +``` +https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h +https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c +``` + +So I extract its spinlock implementation into one test C source file (see attachment file), +and get reprodcued: + +``` +$ gcc spinlock_qemu.c +$ ./a.out +C -- slock inited, lock value is: 0 +parent 139642, child 139645 +P -- slock lock before, lock value is: 0 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +... +... +... +``` + +NOTE: this code always works on PHYSICAL ARM64 server. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1909 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1909 new file mode 100644 index 000000000..5c8aa9308 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1909 @@ -0,0 +1,53 @@ + + + +regression: 8.0.0 segfaults on coverage counter increment +Description of problem: +With qemu 8.0.0, my test program segfaults while incrementing a gcov counter: + +``` +Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/2i $pc +=> 0x4bc9a8 <__CortexA53843419_464004>: str x8, [x9, #2512] + 0x4bc9ac <__CortexA53843419_464004+4>: b 0x464008 <mock_hyp_params_Destroy+24> +(gdb) p $x8 +$10 = 1 +(gdb) p $x9 +$11 = 5234688 +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) stepi + +Program received signal SIGSEGV, Segmentation fault. +0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep 4fe9d0 +00000000004fe9d0 l O .bss 0000000000000008 __llvm_gcov_ctr.5 +(gdb) shell qemu-aarch64 --version +qemu-aarch64 version 8.0.0 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +(gdb) +``` + +With qemu 6.2.0, it doesn't segfault (at least not at this point, you +may ignore the segfault at the end due to a bug in the test program). +``` +$ /usr/bin/qemu-aarch64 --version +qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +$ /usr/bin/qemu-aarch64 ./build/gcov/out/test_hyp-props.out +test_hyp-props.c:13:test__setup_str_prop:PASS +test_hyp-props.c:14:test__log_print_handler:PASS +test_hyp-props.c:15:test__setup_log_print_prop:PASS +test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS +test_hyp-props.c:17:test__vm_info_alloc:PASS +test_hyp-props.c:18:test__memory_status_get:PASS +test_hyp-props.c:19:test__memory_status_get_fail:PASS +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage. +2. Run it with qemu-aarch64 8.0.0 +3. Hopefully, it will segfault early for no good reason. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1910 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1910 new file mode 100644 index 000000000..cd18fcd56 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1910 @@ -0,0 +1,65 @@ + + + +Signal handlers in x86_64 userspace have wrongly aligned stack +Description of problem: +Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause. + +```plaintext +> qemu-x86_64 /usr/bin/ruby -e '`true`' +-e:1: [BUG] Segmentation fault at 0x0000000000000000 +ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu] + +-- Control frame information ----------------------------------------------- +c:0003 p:---- s:0011 e:000010 CFUNC :` +c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] +c:0001 p:0000 s:0003 E:0015b0 DUMMY [FINISH] + +-- Ruby level backtrace information ---------------------------------------- +-e:1:in `<main>' +-e:1:in ``' + +-- Machine register context ------------------------------------------------ + RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98 + RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000 + RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000 + R8: 0x00002aaaab2aaa50 R9: 0x0000000000000050 R10: 0x0000000000000008 + R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310 + R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246 + +-- C level backtrace information ------------------------------------------- +``` + +```plaintext +(gdb) x/i $pc +=> 0x2aaaab50f98a: movaps %xmm0,(%rsp) +(gdb) p/x $rsp +$3 = 0x2aaaab2a9998 +``` +Steps to reproduce: +1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'``` +Additional information: +The x86_64 psABI says: + +> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point. + +However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`. + +The relevant kernel code: + +https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123 + +```plaintext + sp -= frame_size; + + if (ia32_frame) + /* + * Align the stack pointer according to the i386 ABI, + * i.e. so that on function entry ((sp + 4) & 15) == 0. + */ + sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4; + else + sp = round_down(sp, FRAME_ALIGNMENT) - 8; +``` + +CC @lvivier @bonzini @rth7680 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1912934 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1912934 new file mode 100644 index 000000000..93b930bf7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1912934 @@ -0,0 +1,20 @@ + + + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1913913 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1913913 new file mode 100644 index 000000000..65ce919d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1914021 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1914021 new file mode 100644 index 000000000..3287d096f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1914021 @@ -0,0 +1,30 @@ + + + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +readelf -h a.out_err +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1915327 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1915327 new file mode 100644 index 000000000..5651f2a1f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1915327 @@ -0,0 +1,37 @@ + + + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU + +QEMU version: +1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging + +Consider the following little program: + +$ cat 1.c +#include <stdio.h> +int main() { + int mem = 0x12345678; + register long rax asm("rax") = 0x1234567812345678; + register int edi asm("edi") = 0x77777777; + asm("cmpxchg %[edi],%[mem]" + : [ mem ] "+m"(mem), [ rax ] "+r"(rax) + : [ edi ] "r"(edi)); + long rax2 = rax; + printf("rax2 = %lx\n", rax2); +} + +According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU: + +$ gcc 1.c +$ ./a.out +rax2 = 1234567812345678 + +However, QEMU appears to zero extend EAX to RAX: + +$ qemu-x86_64 ./a.out +rax2 = 12345678 + +This is also the case for lock cmpxchg. + +Found in BPF development context: https://lore<email address hidden> \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1916269 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1916269 new file mode 100644 index 000000000..6c64e5313 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1916269 @@ -0,0 +1,22 @@ + + + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1918026 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1918026 new file mode 100644 index 000000000..17a762155 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1918026 @@ -0,0 +1,32 @@ + + + +RISCV64 32-bit AMOs incorrectly simulated + +Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) + +test: + amomaxu.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); // FAIL, saw -11 +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); // FAIL, raw -11 +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); + +test: + amomax.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); // FAIL, saw -7 + +I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1922887 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1922887 new file mode 100644 index 000000000..1cdbb541c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1922887 @@ -0,0 +1,33 @@ + + + +STR in Thumb 32 decode problem + +Hi + +It seems that QEMU does not have a proper check on the STR instruction in Thumb32 mode. + +Specifically, the machine code is 0xf84f0ddd, which is 0b1111 1000 0100 1111 0000 1101 1101 1101. +This is an STR (immediate, Thumb) instruction with a T4 encoding scheme. + +The symbols is + +Rn = 1111 +Rt = 0000 +P = 1 +U = 0 +W = 1 + +The decode ASL is below: + +if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT; +if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH; +if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED; +t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); +index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’); +if t == 15 || (wback && n == t) then UNPREDICTABLE; + +When Rn == 1111, it should be an undefined instruction, which should raise SEGILL signal. However, it seems that QEMU does not check this constraint, which should be a bug. Many thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1925512 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1925512 new file mode 100644 index 000000000..a847cd79a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1925512 @@ -0,0 +1,21 @@ + + + +UNDEFINED case for instruction BLX + +Hi + +I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). + +11110 S imm10H 11 J1 0 J2 imm10L H + + +if H == '1' then UNDEFINED; +I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); +targetInstrSet = InstrSet_A32; +if InITBlock() && !LastInITBlock() then UNPREDICTABLE; + +According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926044 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926044 new file mode 100644 index 000000000..c1dcc0401 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926044 @@ -0,0 +1,33 @@ + + + +QEMU-user doesn't report HWCAP2_MTE + +Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a + +Host Debian 5.10.24 x86_64 GNU + +Configured with "configure --disable-system --enable-linux-user --static" + +This one works and prints "OK" as expected: +clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK + + +This one fails and print "0": +cat mytest.c +#include <stdio.h> +#include <sys/auxv.h> + +#ifndef HWCAP2_MTE +#define HWCAP2_MTE (1 << 18) +#endif + +int main(int ac, char **av) +{ + printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE)); +} + + +clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926202 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926202 new file mode 100644 index 000000000..8a2a96e8b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/1926759 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926759 new file mode 100644 index 000000000..437445902 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1926759 @@ -0,0 +1,21 @@ + + + +WFI instruction results in unhandled CPU exception + +Hi + +I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. + +qemu: unhandled CPU exception 0x10001 - aborting +R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec +R04=00010a28 R05=00010158 R06=00087460 R07=00010158 +R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 +R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 +PSR=60000010 -ZC- A usr32 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 + +WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1941 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1941 new file mode 100644 index 000000000..4624fd6d6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1941 @@ -0,0 +1,105 @@ + + + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1955 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1955 new file mode 100644 index 000000000..4164d2368 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1955 @@ -0,0 +1,40 @@ + +instruction: 0.950 +graphic: 0.840 +semantic: 0.801 +device: 0.645 +other: 0.493 +socket: 0.420 +network: 0.394 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +assembly: 0.183 +KVM: 0.107 + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1967248 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1967248 new file mode 100644 index 000000000..c84ead78a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/1967248 @@ -0,0 +1,41 @@ + + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2072564 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2072564 new file mode 100644 index 000000000..3a9c3be06 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/2078 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2078 new file mode 100644 index 000000000..73f219935 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2078 @@ -0,0 +1,37 @@ + + + +Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target +Description of problem: +I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests. Certain arithmetic operation that will trap in the guest will crash Qemu. First case encountered is below. +Steps to reproduce: +1. Compile and run the following program in the m68k guest: + +``` +virt68k:thorpej 3$ cat crash-qemu.c +#include <limits.h> +#include <stdlib.h> + +int divisor = -1; + +int +main(int argc, char *argv[]) +{ + + if (argc > 1) + divisor = atoi(argv[1]); + + return INT_MIN / divisor; +} +virt68k:thorpej 4$ +``` + +Another minimal case would be: + +``` +move.l #-2147483648,%d0 +move.l #-1,%d1 +divsl.l %d1,%d1:%d0 +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2083 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2083 new file mode 100644 index 000000000..ca2fcabbd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2083 @@ -0,0 +1,114 @@ + + + +AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result +Description of problem: +The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer: + +``` +import numpy as np +vl = 128 +esize = 32 +dim = vl // esize + +A = range(16) +B = range(16, 32) +C = np.zeros((4, 4,), dtype=np.int32) + +for row in range(dim): + for col in range(dim): + for k in range(4): + C[row, col] += A[4*row + k] * B[4*col + k] + +print(C) + +[[ 110 134 158 182] + [ 390 478 566 654] + [ 670 822 974 1126] + [ 950 1166 1382 1598]] +``` + +main.c +``` +#include <stdio.h> +#include <stdint.h> + +void foo(int *dst); + +int main() { + int32_t dst[16]; + foo(dst); + + // This should print: + // >>> 110 134 158 182 + // >>> 390 478 566 654 + // >>> 670 822 974 1126 + // >>> 950 1166 1382 1598 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%d ", dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S + +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.b + index z0.b, #0, #1 + mov z1.d, z0.d + add z1.b, z1.b, #16 + + zero {za} + smopa za0.s, p0/m, p0/m, z0.b, z1.b + + // Read the first 4x4 sub-matrix of elements from tile 0: + mov w12, #0 + mova z0.s, p0/m, za0h.s[w12, #0] + mova z1.s, p0/m, za0h.s[w12, #1] + mova z2.s, p0/m, za0h.s[w12, #2] + mova z3.s, p0/m, za0h.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme main.c foo.S +$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out +>>> 110 478 158 654 +>>> 0 0 0 0 +>>> 670 1166 974 1598 +>>> 0 0 0 0 +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2089 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2089 new file mode 100644 index 000000000..42ff91e11 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2089 @@ -0,0 +1,30 @@ + + + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2136 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2136 new file mode 100644 index 000000000..20d62a582 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2136 @@ -0,0 +1,38 @@ + + + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2175 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2175 new file mode 100644 index 000000000..1ed7e24f6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2175 @@ -0,0 +1,41 @@ + + + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2203 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2203 new file mode 100644 index 000000000..b2e549ee0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2203 @@ -0,0 +1,4 @@ + + + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2248 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2248 new file mode 100644 index 000000000..9a2f29fd8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2248 @@ -0,0 +1,39 @@ + + + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2302 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2302 new file mode 100644 index 000000000..687b2201f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2302 @@ -0,0 +1,28 @@ + + + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2317 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2317 new file mode 100644 index 000000000..34e976a1c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2317 @@ -0,0 +1,41 @@ + + + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2318 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2318 new file mode 100644 index 000000000..9ed785f09 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2318 @@ -0,0 +1,37 @@ + + + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2319 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2319 new file mode 100644 index 000000000..98e922d21 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2319 @@ -0,0 +1,20 @@ + + + +SPARC32-bit SDIV of negative divisor gives wrong result +Description of problem: +SDIV of negative divisor gives wrong result because of typo in helper_sdiv(). This is true for QEMU 9.0.0 and earlier. + +Place -1 in the Y register and -128 in another reg, then -120 in another register and do SDIV into a result register, instead of the proper value of 1 for the result, the incorrect value of 0 is produced. + +There is a typo in target/sparc/helper.c that causes the divisor to be consider unsigned, this patch fixes it: + +\*\*\* helper.c.ori Tue Apr 23 16:23:45 2024 --- helper.c Mon Apr 29 20:14:07 2024 + +--- + +\*\*\* 121,127 \*\*\*\* return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } + +! a64 /= b; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); --- 121,127 ---- return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } + +! a64 /= b32; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2371 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2371 new file mode 100644 index 000000000..9a778851f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2371 @@ -0,0 +1,55 @@ + + + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2372 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2372 new file mode 100644 index 000000000..007c25eab --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2372 @@ -0,0 +1,112 @@ + + + +A bug in AArch64 UMOPA/UMOPS (4-way) instruction +Description of problem: +umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. + +However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: +``` +// target/arm/tcg/sme_helper.c +#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ +static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ +{ \ + uint64_t sum = 0; \ + /* Apply P to N as a mask, making the inactive elements 0. */ \ + n &= expand_pred_h(p); \ + sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ + sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ + sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ + sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ + return neg ? a - sum : a + sum; \ +} + +DEF_IMOP_64(umopa_d, uint16_t, uint16_t) +``` +When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z20[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA2H[128] = { 0x0, }; +char o_ZA2H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA2H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P1\n" + "add x29, x29, :lo12:i_P1\n" + "ldr p1, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z20\n" + "add x29, x29, :lo12:i_Z20\n" + "ldr z20, [x29]\n" + "adrp x29, i_ZA2H\n" + "add x29, x29, :lo12:i_ZA2H\n" + "mov x15, 0\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h + "adrp x29, o_ZA2H\n" + "add x29, x29, :lo12:o_ZA2H\n" + "mov x15, 0\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "smstop\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2373 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2373 new file mode 100644 index 000000000..57a05a745 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2373 @@ -0,0 +1,98 @@ + + + +A bug in AArch64 FMOPA/FMOPS (widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used. + +However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P2[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z16[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA3H[128] = { 0x0, }; +uint64_t i_fpcr = 0x0001000000; // FZ = 1; +char o_ZA3H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA3H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P2\n" + "add x29, x29, :lo12:i_P2\n" + "ldr p2, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z16\n" + "add x29, x29, :lo12:i_Z16\n" + "ldr z16, [x29]\n" + "adrp x29, i_ZA3H\n" + "add x29, x29, :lo12:i_ZA3H\n" + "mov x15, 0\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x81a0aa03\n" // fmopa za3.s, p2/m, p5/m, z16.h, z0.h + "adrp x29, o_ZA3H\n" + "add x29, x29, :lo12:o_ZA3H\n" + "mov x15, 0\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2374 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2374 new file mode 100644 index 000000000..3b6a0325a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2374 @@ -0,0 +1,114 @@ + + + +A bug in AArch64 FMOPA/FMOPS (non-widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. + +However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: +``` +// target/arm/tcg/sme_helper.c +void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, + void *vpm, void *vst, uint32_t desc) +{ +... + float_status fpst; + + /* + * Make a copy of float_status because this operation does not + * update the cumulative fp exception status. It also produces + * default nans. + */ + fpst = *(float_status *)vst; + set_default_nan_mode(true, &fpst); + +... + *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used +... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. + 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z27[32] = { + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA1H[128] = { 0x0, }; +char o_ZA1H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA1H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P0\n" + "add x29, x29, :lo12:i_P0\n" + "ldr p0, [x29]\n" + "adrp x29, i_P6\n" + "add x29, x29, :lo12:i_P6\n" + "ldr p6, [x29]\n" + "adrp x29, i_Z9\n" + "add x29, x29, :lo12:i_Z9\n" + "ldr z9, [x29]\n" + "adrp x29, i_Z27\n" + "add x29, x29, :lo12:i_Z27\n" + "ldr z27, [x29]\n" + "adrp x29, i_ZA1H\n" + "add x29, x29, :lo12:i_ZA1H\n" + "mov x15, 0\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s + "adrp x29, o_ZA1H\n" + "add x29, x29, :lo12:o_ZA1H\n" + "mov x15, 0\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2375 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2375 new file mode 100644 index 000000000..68c073b1b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2375 @@ -0,0 +1,88 @@ + + + +A bug in AArch64 FJCVTZS instruction +Description of problem: +fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero. + +However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value: +``` +// target/arm/vfp_helper.c +uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus) +{ + float_status *status = vstatus; + uint32_t inexact, frac; + uint32_t e_old, e_new; + + e_old = get_float_exception_flags(status); + set_float_exception_flags(0, status); + frac = float64_to_int32_modulo(value, float_round_to_zero, status); + e_new = get_float_exception_flags(status); + set_float_exception_flags(e_old | e_new, status); + + if (value == float64_chs(float64_zero)) { + /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */ + inexact = 1; + } else { + /* Normal inexact or overflow or NaN */ + inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked. + } + + /* Pack the result and the env->ZF representation of Z together. */ + return deposit64(frac, 32, 32, inexact); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint64_t i_fpcr = 0x01000000; // FZ = 1; +char o_X28[8]; +uint64_t o_nzcv; + +void __attribute__ ((noinline)) show_state() { + char Z = ((o_nzcv >> 30) & 1); + + printf("PSTATE.Z: %d\n", Z); + printf("X28: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_X28[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "adrp x29, i_D27\n" + "add x29, x29, :lo12:i_D27\n" + "ldr d27, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x1e7e037c\n" // fjcvtzs w28, d27 + "mrs x26, nzcv\n" + "adrp x29, o_nzcv\n" + "add x29, x29, :lo12:o_nzcv\n" + "str x26, [x29]\n" + "adrp x29, o_X28\n" + "add x29, x29, :lo12:o_X28\n" + "str x28, [x29]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2386 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2386 new file mode 100644 index 000000000..e62e288cb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2386 @@ -0,0 +1,46 @@ + + + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2419 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2419 new file mode 100644 index 000000000..e3b6e57cc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2419 @@ -0,0 +1,21 @@ + + + +ldapr_stlr_i instructions doesn't consider signed offset +Description of problem: +The format ldapr_stlr_i models the load acquire / store release immediate instructions. \ +These instructions has a bug in the sign extension calculation of the imm field. \ +imm should be defined as s9 instead of 9. + +@ldapr_stlr_i .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i + +Should be changed to: + +@ldapr_stlr_i .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i +Steps to reproduce: +1. Run ARM target +2. Generate any ldapr_stlr_i instructions (for example: LDAPUR) +3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail. +Additional information: +In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \ +I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2422 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2422 new file mode 100644 index 000000000..b3ada641f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2422 @@ -0,0 +1,72 @@ + + + +`vill` not set after reserved `vsetvli` instruction usage +Description of problem: +The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code. + +Here is the quote from the spec: + +> When `rs1=x0` and `rd=x0`, the instruction operates as if the current +> vector length in `vl` is used as the AVL, and the resulting value is +> written to `vl`, but not to a destination register. This form can +> only be used when VLMAX and hence `vl` is not actually changed by the +> new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio +> that would result in a change of VLMAX is reserved. +> Use of the instruction is also reserved if `vill` was 1 beforehand. +> Implementations may set `vill` in either case. + +Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand". +Steps to reproduce: +1. Create `test.c` +```C +#include <assert.h> + +/* Position of vill in vtype. */ + +#define VILL_BIT (__riscv_xlen - 1) + +/* Return true if vill is 1. */ + +int vill_set_p () +{ + __UINT64_TYPE__ vtype; + asm volatile ("csrr %0, vtype" : "=r"(vtype)); + + return (vtype >> VILL_BIT) & 1; +} + +/* Return true if vill is 0. */ + +int vill_clear_p () +{ + return !vill_set_p (); +} + +int main () +{ + int vl; + + assert (vill_clear_p ()); + + /* Valid: vl = VLMAX. */ + asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl)); + assert (vill_clear_p ()); + + /* Valid: vl and VLMAX not changed. */ + asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n"); + assert (vill_clear_p ()); + + /* Reserved: Reduce VLMAX. */ + asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n"); + assert (vill_set_p ()); + + return 0; +} +``` +2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d` +3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test` +4. The final assertion fails because executing the reserved `vsetvli` did not set `vill` +``` +assertion "vill_set_p ()" failed: file "test.c", line 40, function: main +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2474 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2474 new file mode 100644 index 000000000..9a7c3f996 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2474 @@ -0,0 +1,99 @@ + + + +x86_64: strange translation of "vpgatherqq" +Description of problem: +The translate of instruction "vpgatherqq" is confusing. + +It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj". +Steps to reproduce: +1. Make a simple embedded assembly code named test.c: +``` +int main() +{ + asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7"); + return 0; +} +``` +and compile it: +``` +gcc -o test test.c -static +``` + +2. Run it with QEMU, print the micro ops: +``` +qemu-x86_64 -d op -D a.out test +``` +We can get output like this (only contain vpgatherqq): +``` + ---- 000000000040174d 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc14,env,$0x3d0 #This is xmm2 + add_i64 loc16,env,$0x4d0 + add_i64 loc18,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2 + mov_vec v128,e8,tmp20,v128$0x0 + st_vec v128,e8,tmp20,env,$0x4e0 + mov_vec v128,e8,tmp22,v128$0x0 + st_vec v128,e8,tmp22,env,$0x520 + + ---- 0000000000401757 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc23,env,$0x410 #This is xmm3 + add_i64 loc25,env,$0x4d0 + add_i64 loc26,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2 + mov_vec v128,e8,tmp27,v128$0x0 + st_vec v128,e8,tmp27,env,$0x4e0 + mov_vec v128,e8,tmp28,v128$0x0 + st_vec v128,e8,tmp28,env,$0x520 + + ---- 0000000000401761 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc29,env,$0x310 #This is xmm4 ??? + add_i64 loc31,env,$0x4d0 + add_i64 loc32,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2 + mov_vec v128,e8,tmp33,v128$0x0 + st_vec v128,e8,tmp33,env,$0x4e0 + mov_vec v128,e8,tmp34,v128$0x0 + st_vec v128,e8,tmp34,env,$0x520 + + ---- 000000000040176b 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc35,env,$0x490 #This is xmm5 + add_i64 loc37,env,$0x4d0 + add_i64 loc38,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2 + mov_vec v128,e8,tmp39,v128$0x0 + st_vec v128,e8,tmp39,env,$0x4e0 + mov_vec v128,e8,tmp40,v128$0x0 + st_vec v128,e8,tmp40,env,$0x520 +``` +3. + +Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence. + +From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310. + +I used GDB to track it, the location where the change occurred is: + +target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215: +``` + if (rm == 4) { + int code = x86_ldub_code(env, s); + scale = (code >> 6) & 3; + index = ((code >> 3) & 7) | REX_X(s); + if (index == 4) { + index = -1; /* no index */ + } + base = (code & 7) | REX_B(s); + havesib = 1; + } +``` +This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350). +Additional information: +Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2483 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2483 new file mode 100644 index 000000000..7c0fba74f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2483 @@ -0,0 +1,23 @@ + + + +m68k: jsr (sp) doesn't work as expected +Description of problem: +Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first. + +``` + ff8241e6 22 4f movea.l SP,A1 + ff8241e8 70 68 moveq #0x68,D0 + LAB_ff8241ea XREF[1]: ff8241ee(j) + ff8241ea 12 d8 move.b (A0)+,(A1)+ + ff8241ec 53 80 subq.l #0x1,D0 + ff8241ee 66 fa bne.b LAB_ff8241ea + ff8241f0 4e 97 jsr (SP) +``` + +`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think? +What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails. + +Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing. + +{width=289 height=759} diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2487 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2487 new file mode 100644 index 000000000..c5d0c2770 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2487 @@ -0,0 +1,71 @@ + + + +qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Description of problem: +Using this basic test file: + +```c +int +main (void) +{ + return 0; +} +``` + +compiled into a static executable using an x86_64 toolchain (glibc or musl both tested), + +``` +gwyn ~/qemu-bug # file test1 +test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped + +gwyn ~/qemu-bug # file test2 +test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped +``` + +Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version +qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty) +Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers +``` + +QEMU crashes: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2 +** +ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Aborted +``` +Steps to reproduce: +1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer. +2. Run any simple x86_64 executable. +3. Observe the crash. +Additional information: +Bisected to here: + +``` +commit 15957eb9efe2da67c796612cead95cba28ba9bda +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Oct 27 05:57:31 2023 +0200 + + target/i386: use TSTEQ/TSTNE to test low bits + + When testing the sign bit or equality to zero of a partial register, it + is useful to use a single TSTEQ or TSTNE operation. It can also be used + to test the parity flag, using bit 0 of the population count. + + Do not do this for target_ulong-sized values however; the optimizer would + produce a comparison against zero anyway, and it avoids shifts by 64 + which are undefined behavior. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/emit.c.inc | 5 ++--- + target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- + 2 files changed, 22 insertions(+), 11 deletions(-) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2495 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2495 new file mode 100644 index 000000000..2ba714012 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2495 @@ -0,0 +1,75 @@ + + + +A bug in x86-64 MMX instructions +Description of problem: +It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x270 + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f84f82ec143 +``` + +However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f98e82ec143 +``` + +I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. + +It seems this bug looks similar to #2474. +Steps to reproduce: +1. Write `test.c` +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uint8_t o_R8[8]; + +void __attribute__ ((noinline)) show_state() { + printf("R8: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_R8[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".intel_syntax noprefix\n" + "mov r8, qword ptr [rip + i_R8]\n" + "movq mm0, qword ptr [rip + i_MM0]\n" + ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" + "mov qword ptr [rip + o_R8], r8\n" + ".att_syntax\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` +3. Run QEMU using this command: `qemu-x86_64 ./test.bin` +4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2497 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2497 new file mode 100644 index 000000000..92bc09806 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2497 @@ -0,0 +1,6 @@ + + + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2498 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2498 new file mode 100644 index 000000000..bf51612fa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2498 @@ -0,0 +1,54 @@ + + + +m68k: fpu: fmovem with multiple control registers has incorrect in memory order +Description of problem: +It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers. + +According to the manual: + +``` +The +registers are always moved in the same order, regardless of the addressing mode +used; the floating-point control register is moved first, followed by the floating-point +status register, and the floating-point instruction address register is moved last. +``` + +Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary. + +Maybe something like this is needed: + +``` diff +commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt) +Author: Daniel Palmer <daniel@thingy.jp> +Date: Tue Aug 13 09:52:54 2024 +0900 + + fix fmovem ordering + +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index 92dc9d8563..64ff2df06e 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + */ + + if (is_write && mode == 4) { +- for (i = 2; i >= 0; i--, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + gen_qemu_store_fcr(s, addr, 1 << i); + if (mask != 1) { + tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG)); +@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + } + tcg_gen_mov_i32(AREG(insn, 0), addr); + } else { +- for (i = 0; i < 3; i++, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + if (is_write) { + gen_qemu_store_fcr(s, addr, 1 << i); + } else { +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2499 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2499 new file mode 100644 index 000000000..f6bfb80d5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2499 @@ -0,0 +1,33 @@ + + + +m68k: fpu: fsave/frestore should be enabled for 68020/68030 +Description of problem: +valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. + +I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. + +``` diff +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index d5d2322329..92dc9d8563 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) + gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); + return; + } +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + SRC_EA(env, addr, OS_LONG, 0, NULL); + /* FIXME: check the state frame */ + } else { +@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) + return; + } + +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + /* always write IDLE */ + TCGv idle = tcg_constant_i32(0x41000000); + DEST_EA(env, insn, OS_LONG, idle, NULL); +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2500 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2500 new file mode 100644 index 000000000..a23fcaed6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2500 @@ -0,0 +1,7 @@ + + + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2504 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2504 new file mode 100644 index 000000000..b62e4b7ad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2504 @@ -0,0 +1,10 @@ + + + +linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine +Description of problem: +on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. +Steps to reproduce: +[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2536 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2536 new file mode 100644 index 000000000..afd1e571a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2536 @@ -0,0 +1,4 @@ + + + +Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2569 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2569 new file mode 100644 index 000000000..2d07cccc8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/2595 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2595 new file mode 100644 index 000000000..07e871de6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2595 @@ -0,0 +1,138 @@ + + + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2604 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2604 new file mode 100644 index 000000000..eaa3a5380 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/266 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/266 new file mode 100644 index 000000000..bd31cb7da --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/266 @@ -0,0 +1,4 @@ + + + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2672 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2672 new file mode 100644 index 000000000..00d274700 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2672 @@ -0,0 +1,23 @@ + + + +Skipping a jal instruction in riscv64 baremetal emulation +Description of problem: +The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: + +``` +0x80006070: 00200513 addi a0,zero,2 +0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 + +---------------- +IN: _Z15int_switch_modehh +0x80006078: 0000 illegal + +---------------- +IN: mtvec_table +0x8000e600: 64d0406f j 20044 # 0x8001344c +``` +Steps to reproduce: +1. Execute the same binary with QEMU. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2696 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2696 new file mode 100644 index 000000000..3fdc8f0a0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2696 @@ -0,0 +1,15 @@ + + + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2730 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2730 new file mode 100644 index 000000000..7d94e5a01 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2730 @@ -0,0 +1,13 @@ + + + +riscv Calculation error！ +Steps to reproduce: +The following command will produce an error output + +```asm + lui s0, 0x80000 + lw a1, -48(s0) +``` +The value of a1 becomes 0xffffffff + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2775 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2775 new file mode 100644 index 000000000..d4fa3fbda --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/2802 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2802 new file mode 100644 index 000000000..e174b9b20 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2802 @@ -0,0 +1,29 @@ + + + +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2865 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2865 new file mode 100644 index 000000000..91400a862 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2865 @@ -0,0 +1,55 @@ + + + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2878 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2878 new file mode 100644 index 000000000..0cf0f9d8c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2878 @@ -0,0 +1,4 @@ + + + +Support for avx512 in qemu user space emulation. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2971 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2971 new file mode 100644 index 000000000..706ee9d06 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/2971 @@ -0,0 +1,47 @@ + + + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/312 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/312 new file mode 100644 index 000000000..eeba93125 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/312 @@ -0,0 +1,4 @@ + + + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/333 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/333 new file mode 100644 index 000000000..674954ef0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/333 @@ -0,0 +1,4 @@ + + + +random errors on aarch64 when executing __aarch64_cas8_acq_rel diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/361 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/361 new file mode 100644 index 000000000..afcbbb584 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/361 @@ -0,0 +1,4 @@ + + + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/364 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/364 new file mode 100644 index 000000000..19a9fae8c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/364 @@ -0,0 +1,4 @@ + + + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/381 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/381 new file mode 100644 index 000000000..459d6c328 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/381 @@ -0,0 +1,4 @@ + + + +ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/390 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/390 new file mode 100644 index 000000000..28313d0fb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/390 @@ -0,0 +1,4 @@ + + + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/422 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/422 new file mode 100644 index 000000000..d637043bf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/422 @@ -0,0 +1,4 @@ + + + +Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/427 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/427 new file mode 100644 index 000000000..87592bc9b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/427 @@ -0,0 +1,4 @@ + + + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/494 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/494 new file mode 100644 index 000000000..041ca2b3d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/494 @@ -0,0 +1,4 @@ + + + +cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/508 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/508 new file mode 100644 index 000000000..a5b701b3a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/508 @@ -0,0 +1,4 @@ + + + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/514 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/514 new file mode 100644 index 000000000..76794e17a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/514 @@ -0,0 +1,28 @@ + + + +MTE reports false positive for "str" instruction with the SP as the base register. +Description of problem: +When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. +Steps to reproduce: +Clang version: clang version 12.0.1. +I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: +``` +0000000000000c14 <test_func>: + c14: a9bc7bfd stp x29, x30, [sp, #-64]! + c18: f9000bf7 str x23, [sp, #16] + ... +``` +Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. +When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": +ESR_EL1=0x96000051. + +According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: +``` +A Tag Unchecked access will be generated for a load or store that uses either of the following: +• A base register only, with the SP as the base register. +• A base register plus immediate offset addressing form, with the SP as the base register. +``` +Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/625 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/625 new file mode 100644 index 000000000..53d7d0c2e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/625 @@ -0,0 +1,26 @@ + + + +qemu-hppa floating point POWER function is incorrect +Description of problem: +The floating point power function produces incorrect values, and possibly stack misshapes as well. +Steps to reproduce: +1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static +2. $ qemu-hppa pow +3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 +Additional information: +Example C source to reproduce, pow.c: +``` +#include <stdio.h> +#include <math.h> +int main() +{ + double base, expo, res; + base=10.0; + expo=6.0; + // res sould be 1e+6 + res = pow(base, expo); + printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); + return 0; +} +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/645662 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/645662 new file mode 100644 index 000000000..50426a819 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/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:32b/output/instruction/695 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/695 new file mode 100644 index 000000000..9b14ae6c3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/695 @@ -0,0 +1,4 @@ + + + +MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/754 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/754 new file mode 100644 index 000000000..1b78c2d09 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/754 @@ -0,0 +1,210 @@ + + + +qem_m68k : trapcs instruction causes the non-execution of the following 2 instructions +Description of problem: +In try to run following code : +``` +8004615a: 204f moveal %sp,%a0 +8004615c: b1c7 cmpal %d7,%a0 +8004615e: 55fc trapcs +80046160: 4e56 0000 linkw %fp,#0 +80046164: 2f14 movel %a4@,%sp@- +80046166: 288e movel %fp,%a4@ +80046168: c74d exg %a3,%a5 +8004616a: 48e7 3030 moveml %d2-%d3/%a2-%a3,%sp@- +8004616e: 7001 moveq #1,%d0 +80046170: 3b40 816c movew %d0,%a5@(-32404) +80046174: 7218 moveq #24,%d1 +80046176: 3b41 816a movew %d1,%a5@(-32406) +8004617a: 242d 8004 movel %a5@(-32764),%d2 +8004617e: 2b42 815c movel %d2,%a5@(-32420) +80046182: 206d 8008 moveal %a5@(-32760),%a0 +80046186: 2268 8010 moveal %a0@(-32752),%a1 +8004618a: 2b49 8158 movel %a1,%a5@(-32424) +8004618e: 42ad 8154 clrl %a5@(-32428) +80046192: 246d 8154 moveal %a5@(-32428),%a2 +80046196: 2b4a 8160 movel %a2,%a5@(-32416) +8004619a: 2b4a 8164 movel %a2,%a5@(-32412) +8004619e: 422d 8168 clrb %a5@(-32408) +800461a2: 7604 moveq #4,%d3 +800461a4: 2b43 8150 movel %d3,%a5@(-32432) +800461a8: 2668 8010 moveal %a0@(-32752),%a3 +800461ac: 2b4b 814c movel %a3,%a5@(-32436) +800461b0: 2268 8010 moveal %a0@(-32752),%a1 +800461b4: 266d 8008 moveal %a5@(-32760),%a3 +800461b8: 206b 8008 moveal %a3@(-32760),%a0 +800461bc: 4e90 jsr %a0@ +800461be: 2b48 8148 movel %a0,%a5@(-32440) +800461c2: 4cdf 0c0c moveml %sp@+,%d2-%d3/%a2-%a3 +800461c6: c74d exg %a3,%a5 +800461c8: 289f movel %sp@+,%a4@ +800461ca: 4e5e unlk %fp +800461cc: 4e75 rts +``` +When I run qemu-m68k -cpu m68020 -d in_asm,cpu, I have : +``` +---------------- +IN: +0x8004615a: moveal %sp,%a0 +0x8004615c: cmpal %d7,%a0 +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +0x80046166: movel %fp,%a4@ +0x80046168: exg %a3,%a5 +0x8004616a: moveml %d2-%d3/%a2-%a3,%sp@- +0x8004616e: moveq #1,%d0 +0x80046170: movew %d0,%a5@(-32404) +0x80046174: moveq #24,%d1 +0x80046176: movew %d1,%a5@(-32406) +0x8004617a: movel %a5@(-32764),%d2 +0x8004617e: movel %d2,%a5@(-32420) +0x80046182: moveal %a5@(-32760),%a0 +0x80046186: moveal %a0@(-32752),%a1 +0x8004618a: movel %a1,%a5@(-32424) +0x8004618e: clrl %a5@(-32428) +0x80046192: moveal %a5@(-32428),%a2 +0x80046196: movel %a2,%a5@(-32416) +0x8004619a: movel %a2,%a5@(-32412) +0x8004619e: clrb %a5@(-32408) +0x800461a2: moveq #4,%d3 +0x800461a4: movel %d3,%a5@(-32432) +0x800461a8: moveal %a0@(-32752),%a3 +0x800461ac: movel %a3,%a5@(-32436) +0x800461b0: moveal %a0@(-32752),%a1 +0x800461b4: moveal %a5@(-32760),%a3 +0x800461b8: moveal %a3@(-32760),%a0 +0x800461bc: jsr %a0@ + +Trace 0: 0x7f83a807e780 [00000000/8004615a/00000000/00000000] +D0 = 00000012 A0 = 8004615a F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd7000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN + + +---------------- +IN: +0x80046358: lea %a1@(0,%d0:l),%a0 +0x8004635c: rts + +Trace 0: 0x7f83a807eac0 [00000000/80046358/00000000/00000000] +D0 = 00000001 A0 = 80046358 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000018 A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) +D2 = ffffffff A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000004 A3 = 8000c040 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 8000c3b0 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045fe0 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046358 SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +``` +Stack pointer is 80045fe0, it should be 80045FD8. + +When I run with options -cpu m68020 -d in_asm,cpu,op -singlestep, I have : +``` +---------------- +IN: +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +Disassembler disagrees with translator over instruction decoding +Please report this to qemu-devel@nongnu.org + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 8004615e 00000000 + mov_i32 tmp0,$0x0 + call flush_flags,$0x0,$0,env,CC_OP + setcond_i32 tmp2,CC_C,tmp0,ne + neg_i32 tmp2,tmp2 + mov_i32 tmp0,$0x56 + mov_i32 PC,$0x80046162 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a75c3 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 8004615e SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046162: orib #20,%d0 + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 80046162 00000000 + mov_i32 tmp0,$0x14 + ext8s_i32 tmp3,D0 + or_i32 tmp4,tmp3,tmp0 + and_i32 D0,D0,$0xffffff00 + ext8u_i32 tmp6,tmp4 + or_i32 D0,D0,tmp6 + ext8s_i32 CC_N,tmp4 + discard CC_C + discard CC_Z + discard CC_V + mov_i32 CC_OP,$0xb + mov_i32 PC,$0x80046166 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a7683 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046162 SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046166: movel %fp,%a4@ + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + +... +``` +I can see that instructions +``` +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +``` +are not executed +and an extra instruction +``` +0x80046162: orib #20,%d0 +``` +is executed +Steps to reproduce: +Run chroot qemu-m68k qemu-m68k-static -cpu m68020 -d in_asm,cpu -D log1.txt ./test +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/799 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/799 new file mode 100644 index 000000000..2a038a0be --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/799 @@ -0,0 +1,50 @@ + + + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/824 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/824 new file mode 100644 index 000000000..a93e2e869 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/824 @@ -0,0 +1,15 @@ + + + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/826 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/826 new file mode 100644 index 000000000..d79f7cf28 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/826 @@ -0,0 +1,19 @@ + + + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/837 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/837 new file mode 100644 index 000000000..3f61a028a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/837 @@ -0,0 +1,33 @@ + + + +x86 user: icebp/int1 raises wrong signal +Description of problem: +This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. + +Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. + +This also happens on an AArch64 host. +``` +$ ./icebp +Trace/breakpoint trap +$ qemu-x86_64 ./icebp +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Steps to reproduce: +1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 +``` + .globl _start +_start: + .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it +#ifdef __x86_64__ + mov $60, %eax + syscall +#else + mov $1, %eax + int $0x80 +#endif +``` +2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message +3. Run on qemu-user. Notice how it raises `SIGILL`. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/890 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/890 new file mode 100644 index 000000000..26d32f2ea --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/890 @@ -0,0 +1,4 @@ + + + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/904308 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/904308 new file mode 100644 index 000000000..93fdd56b6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/904308 @@ -0,0 +1,101 @@ + + + +x86: BT/BTS/BTR/BTC: ZF flag is unaffected + +Hello! + +Bug was found in qemu.git. +See target-i386/translate.c: + + case 0x1ba: /* bt/bts/btr/btc Gv, im */ + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + op = (modrm >> 3) & 7; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + if (mod != 3) { + s->rip_offset = 1; + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + /* load shift */ + val = ldub_code(s->pc++); + gen_op_movl_T1_im(val); + if (op < 4) + goto illegal_op; + op -= 4; + goto bt_op; + case 0x1a3: /* bt Gv, Ev */ + op = 0; + goto do_btx; + case 0x1ab: /* bts */ + op = 1; + goto do_btx; + case 0x1b3: /* btr */ + op = 2; + goto do_btx; + case 0x1bb: /* btc */ + op = 3; + do_btx: + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + reg = ((modrm >> 3) & 7) | rex_r; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + gen_op_mov_TN_reg(OT_LONG, 1, reg); + if (mod != 3) { + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + /* specific case: we need to add a displacement */ + gen_exts(ot, cpu_T[1]); + tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot); + tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot); + tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + bt_op: + tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1); + switch(op) { + case 0: + tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + break; + case 1: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + case 2: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_not_tl(cpu_tmp0, cpu_tmp0); + tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + default: + case 3: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + } + s->cc_op = CC_OP_SARB + ot; + if (op != 0) { + if (mod != 3) + gen_op_st_T0_A0(ot + s->mem_index); + else + gen_op_mov_reg_T0(ot, rm); + tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + } + break; + +always set zf... + +There is fixed patch. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/947 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/947 new file mode 100644 index 000000000..74f0d403d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/947 @@ -0,0 +1,16 @@ + + + +TCG AARCH64 Segmentation fault when helper function is called +Description of problem: +Segmentation fault in the TCG thread. +The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). +It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). +Additional information: +The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 +`t2 = t1 & ~(0xffffUL << s1);`. +The fix would be `t2 = t1 & ~(0xffffULL << s1);` + + +[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) +[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/952 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/952 new file mode 100644 index 000000000..08f0cf817 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/952 @@ -0,0 +1,100 @@ + + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) +Description of problem: +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 + 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello + +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. + +But it's coredump. + +I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. + +host： +``` +$qemu-arm -g 12345 hello +``` +service: +``` +$gdb-multiarch hello +(gdb) target remote localhost:12345 +Remote debugging using localhost:12345 +0x0000a602 in _start () +(gdb) ni +0x0000a604 in _start () +(gdb) +0x0000a608 in _start () +(gdb) +0x0000a608 in _start () +``` +Another way to check: +``` +$gdb qemu-arm +(gdb) run hello +(gdb) bt +#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 +(gdb) up +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +772 sigsuspend(&act.sa_mask); +(gdb) +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +1099 dump_core_and_abort(sig); +(gdb) +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); +(gdb) +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +472 process_pending_signals(env); +(gdb) l +467 default: +468 error: +469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); +470 abort(); +471 } +472 process_pending_signals(env); +473 } +474 } +475 +476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) +(gdb) p cpu_exec(cs) +$2 = 7 +``` +Here process_pending_signals(env) gives SIGTRAP?? + +Here is my binary: +[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/984 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/984 new file mode 100644 index 000000000..ec5ada195 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/984 @@ -0,0 +1,26 @@ + + + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/993 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/993 new file mode 100644 index 000000000..2486b5077 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/993 @@ -0,0 +1,84 @@ + + + +Invalid opcode vzeroupper +Description of problem: +Got many invalid opcode error with Fedora 36 +See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410 + +Crash stack and disassemble. +``` +Downloading separate debug info for /lib64/liblzma.so.5... +Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000... +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'. +Program terminated with signal SIGILL, Illegal instruction. +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))] +(gdb) bt +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +#1 0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255") + at sha-x86-ssse3.c:215 +#2 0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, + hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83 +#3 0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, + key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294 +#4 0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, + digest=0x55a79d80b948) at hash_int.c:167 +#5 0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, + ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640 +#6 0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, + psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59 +#7 0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35 +#8 0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097 +#9 _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, + buf=buf@entry=0x0) at handshake.c:1656 +#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072 +#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871 +#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, + cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968 +#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, + cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564 +#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, + cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848 +#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441 +#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354 +#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827 +#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442 +#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +(gdb) +(gdb) disassemble +Dump of assembler code for function sha512_block_data_order_avx2: + 0x00007f89783cbe00 <+0>: mov %rsp,%rax + 0x00007f89783cbe03 <+3>: push %rbx + 0x00007f89783cbe04 <+4>: push %rbp + 0x00007f89783cbe05 <+5>: push %r12 + 0x00007f89783cbe07 <+7>: push %r13 + 0x00007f89783cbe09 <+9>: push %r14 + 0x00007f89783cbe0b <+11>: push %r15 + 0x00007f89783cbe0d <+13>: sub $0x520,%rsp + 0x00007f89783cbe14 <+20>: shl $0x4,%rdx + 0x00007f89783cbe18 <+24>: and $0xfffffffffffff800,%rsp + 0x00007f89783cbe1f <+31>: lea (%rsi,%rdx,8),%rdx + 0x00007f89783cbe23 <+35>: add $0x480,%rsp + 0x00007f89783cbe2a <+42>: mov %rdi,0x80(%rsp) + 0x00007f89783cbe32 <+50>: mov %rsi,0x88(%rsp) + 0x00007f89783cbe3a <+58>: mov %rdx,0x90(%rsp) + 0x00007f89783cbe42 <+66>: mov %rax,0x98(%rsp) +=> 0x00007f89783cbe4a <+74>: vzeroupper + 0x00007f89783cbe4d <+77>: sub $0xffffffffffffff80,%rsi + 0x00007f89783cbe51 <+81>: mov (%rdi),%rax + 0x00007f89783cbe54 <+84>: mov %rsi,%r12 + 0x00007f89783cbe57 <+87>: mov 0x8(%rdi),%rbx + 0x00007f89783cbe5b <+91>: cmp %rdx,%rsi + 0x00007f89783cbe5e <+94>: mov 0x10(%rdi),%rcx + 0x00007f89783cbe62 <+98>: cmove %rsp,%r12 + 0x00007f89783cbe66 <+102>: mov 0x18(%rdi),%rdx + 0x00007f89783cbe6a <+106>: mov 0x20(%rdi),%r8 + 0x00007f89783cbe6e <+110>: mov 0x28(%rdi),%r9 + 0x00007f89783cbe72 <+114>: mov 0x30(%rdi),%r10 + 0x00007f89783cbe76 <+118>: mov 0x38(%rdi),%r11 + 0x00007f89783cbe7a <+122>: jmp 0x7f89783cbe80 <sha512_block_data_order_avx2+128> + 0x00007f89783cbe7c <+124>: nopl 0x0(%rax) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/998 b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/998 new file mode 100644 index 000000000..b66ece524 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/instruction/998 @@ -0,0 +1,63 @@ + + + +AArch64: SCTLR_EL1.BT0 set incorrectly in user mode +Description of problem: +PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV. + + #include <stdint.h> + #include <stdlib.h> + #include <unistd.h> + #include <string.h> + #include <stdio.h> + #include <sys/mman.h> + + // PACIASP is a valid BTI landing pad, but there are some conditions + // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch + // onto a PACIASP landing pad is only valid if it originates from + // x16 or x17 (i.e. br x17 is OK, br x3 is not). + // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a). + + // Sample function which starts with a paciasp instruction + // (comes from -mbranch-protection=pac-ret+leaf) + void indirect_fn(int i) { + // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK. + i = i+1; + // Can't access this function from the copied location, so will segfault. + fprintf(stderr, "reachable\n"); + } + + int main(int argc, char **argv) { + // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc + // so instead map a page and copy the sample function there. + void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (e == MAP_FAILED) { + return 1; + } + memcpy(e, (void*)indirect_fn, 64); + mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // paciasp is a valid landing pad if the branch comes from an unprotected area, + // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI. + void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (f == MAP_FAILED) { + return 1; + } + uint32_t *x = (uint32_t*)f; + x[0] = 0xd503245fuL; // bti c + x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR + mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // Jump to the shim + asm volatile ( + "mov x3, %0\n" + "mov x2, %1\n" + "blr x2\n" + : : "p"(e), "p"(f) : "x2", "x3"); + + // Execution should not reach here + return 1; + } +Steps to reproduce: +1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar. +2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample` 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 000000000..be8fef072 --- /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 000000000..76a0b70e8 --- /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 000000000..f18f0c665 --- /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 000000000..35739fc7a --- /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 000000000..9e0db9734 --- /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 000000000..ef331b079 --- /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 000000000..11c57f0ee --- /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 000000000..b4e114a60 --- /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 000000000..2abc9d087 --- /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 000000000..a677253a1 --- /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 000000000..2471785eb --- /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 000000000..89fab3c5f --- /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 000000000..284d39d80 --- /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 000000000..8ae1b92ce --- /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 000000000..6c668c40d --- /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 000000000..dd7ef2fd5 --- /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 000000000..ea670a053 --- /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 000000000..7b39dace9 --- /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 000000000..021feb3f1 --- /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 000000000..82e74066d --- /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 000000000..cf95330de --- /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 000000000..7b23ecb00 --- /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 000000000..572d8a990 --- /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 000000000..c23f0f8d9 --- /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 000000000..6b7faaa9b --- /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 000000000..58e4b5956 --- /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 000000000..517420fb3 --- /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 000000000..df07207ac --- /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 000000000..3d8af2070 --- /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 000000000..283fd4559 --- /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 000000000..7b194c316 --- /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 000000000..af5974ced --- /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 000000000..acca70ae6 --- /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 000000000..f02406e4b --- /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 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1010 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1010 new file mode 100644 index 000000000..125ff29d5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1010 @@ -0,0 +1,81 @@ + + + +Errors on 9p mounts +Description of problem: +I'm trying to run Docker VMs with [Lima](https://github.com/lima-vm/lima), which uses QEMU. I'm trying to expose my home directory on macOS to the Ubuntu VM using `9p`. This is how the mount point looks like inside the Ubuntu VM: + +``` +root@lima-docker:~# mount | grep Users +mount0 on /Users/carlos type 9p (rw,relatime,dirsync,fscache,cachetag=4294894070,access=user,trans=virtio,version=9p2000.u) +root@lima-docker:~# +``` + +The problem I'm seeing is that doing an `ls -l /Users/carlos` gives a "Timer expired" error, and no output: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: reading directory '/Users/carlos': Timer expired +total 0 +``` + +Under `strace`, it seems that the timer error is raised by the `getdents64` system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +openat(AT_FDCWD, "/Users/carlos", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 +newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=1984, ...}, AT_EMPTY_PATH) = 0 +mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xffffa16bf000 +getdents64(3, 0xffffa16bf040, 131072) = -1 ETIME (Timer expired) +[..] +``` + +I've also tried the `9p2000.L` protocol instead, and the results are a bit better. I do get a directory listing, but I see "xxx" errors: + +``` +root@lima-docker:~# ls -l /Users/carlos +ls: /Users/carlos: Network dropped connection on reset +ls: /Users/carlos/Music: Network dropped connection on reset +ls: /Users/carlos/Pictures: Network dropped connection on reset +ls: /Users/carlos/Desktop: Network dropped connection on reset +ls: /Users/carlos/Library: Network dropped connection on reset +ls: /Users/carlos/Public: Network dropped connection on reset +ls: /Users/carlos/Movies: Network dropped connection on reset +ls: /Users/carlos/Applications: Network dropped connection on reset +ls: /Users/carlos/Dropbox: Network dropped connection on reset +ls: /Users/carlos/Maildir: Network dropped connection on reset +ls: /Users/carlos/Documents: Network dropped connection on reset +ls: /Users/carlos/Downloads: Network dropped connection on reset +total 0 +drwx------ 5 carlos dialout 160 Dec 6 10:31 Applications +drwx------ 4 carlos dialout 128 Apr 28 14:40 Desktop +drwx------ 12 carlos dialout 384 Apr 30 08:44 Documents +drwx------ 164 carlos dialout 5248 Apr 29 13:50 Downloads +drwx------ 8 carlos dialout 256 Sep 4 2021 Dropbox +drwx------ 82 carlos dialout 2624 Apr 8 14:05 Library +drwxr-xr-x 3 carlos dialout 96 Nov 12 12:28 Maildir +drwx------ 4 carlos dialout 128 Jul 19 2021 Movies +drwx------ 4 carlos dialout 128 Aug 19 2021 Music +drwx------ 4 carlos dialout 128 Jul 19 2021 Pictures +drwxr-xr-x 4 carlos dialout 128 Jul 19 2021 Public +``` + +The errors in this case seem to come from the `lgetxattr`system call: + +``` +root@lima-docker:~# strace -f ls -l /Users/carlos +[..] +statx(AT_FDCWD, "/Users/carlos/Downloads", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=5248, ...}) = 0 +lgetxattr("/Users/carlos/Downloads", "security.selinux", 0xaaaaec72da70, 255) = -1 ENETRESET (Network dropped connection on reset) +write(2, "ls: ", 4ls: ) = 4 +write(2, "/Users/carlos/Downloads", 23/Users/carlos/Downloads) = 23 +write(2, ": Network dropped connection on "..., 37: Network dropped connection on reset) = 37 +[..] +``` + +I've reported this to the Lima folks at https://github.com/lima-vm/lima/issues/831, and they suggested opening an issue here. Any ideas? +Steps to reproduce: +1. If you have Lima installed (I'm using version 0.10.0): `limactl start --name=docker ./lima-templates/docker.yaml` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1010484 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1010484 new file mode 100644 index 000000000..d0df25318 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1028 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1028 new file mode 100644 index 000000000..cda1046c4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1028 @@ -0,0 +1,37 @@ + + + +Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest +Description of problem: +assert message: +qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed. + +For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64. +Steps to reproduce: +1.enable cfg.Zve64f + +2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below +``` + li t0, -1, + vsetvli x0, t0, e64,m1,tu,mu + li t1, -1 + vmv.v.x v0, t1 +``` +Additional information: +Below is a possible solution if it's appropriate. +``` +#if TARGET_LONG_BITS == 32 + if (s->sew == 3) { + TCGv_i64 s1_i64 = tcg_temp_new_i64(); + tcg_gen_ext_tl_i64(s1_i64, s1); + tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1_i64); + tcg_temp_free_i64(s1_i64); + } else { +#endif + tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1); +#if TARGET_LONG_BITS == 32 + } +#endif +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1031920 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1031920 new file mode 100644 index 000000000..18445cd5f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1031920 @@ -0,0 +1,40 @@ + + + +Linux user gdbserver does not respond to remote `Ctrl-C' interrupts + +The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: + +$ qemu-arm -g 1234 a.out + +and then connecting from gdb: + +(gdb) target remote :1234 +Remote debugging using :1234 +[New Remote target] +[Switching to Remote target] +0x00008ba8 in _start () +(gdb) b main +Breakpoint 1 at 0x8cb0: file hello.c, line 5. +(gdb) cont +Continuing. + +Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 +5 int n = 0; +(gdb) l +1 #include <stdio.h> +2 +3 int main (int argc, char **argv) +4 { +5 int n = 0; +6 +7 for (;;) { +8 printf ("Hello, World!\n"); +9 sleep (5); +10 } +(gdb) cont +Continuing. +^C^CInterrupted while waiting for the program. +Give up (and stop debugging it)? (y or n) y + +Notice that the `Ctrl-C' interrupts are ignored. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1034 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1034 new file mode 100644 index 000000000..151e0ef81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1041 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1041 new file mode 100644 index 000000000..e12e90d4e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1044 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1044 new file mode 100644 index 000000000..683946032 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1059 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1059 new file mode 100644 index 000000000..e8a073781 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1066909 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1066909 new file mode 100644 index 000000000..769b35996 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1066909 @@ -0,0 +1,10 @@ + + + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1068900 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1068900 new file mode 100644 index 000000000..8c4f04574 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1070 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1070 new file mode 100644 index 000000000..7f24dfa9e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1086 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1086 new file mode 100644 index 000000000..56d70a3b2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1086 @@ -0,0 +1,72 @@ + + + +Numpy/scipy test suites fails in QEMU on ppc64le (but not on aarch64) +Description of problem: +I'm not really qualified to report this problem, but after being affected by it for ~2 years (and QEMU 7 not fixing things), I decided to give it a shot. Please excuse reporting deficiencies, I'll endeavour to fix them as best I can once pointed out. + +In my spare time, I help out for the packaging effort in the [conda-forge](https://conda-forge.org/) ecosystem, which is mostly associated/attached to the python world, but - in contrast to the vanilla python tools - also deals with non-python dependencies, and in particular has strong enough abstractions to deal with ABI-issues and generally provides much better integration than the packages on PyPI. + +This strength of abstraction has also allowed conda-forge to publish artefacts for many more architectures than most projects are commonly able to provide precompiled binaries for. Due to the lack of (reliable) public CI for aarch64 & ppc64le, these packages are mostly cross-compiled from linux-x86. Where cross compilation is not possible, the packages are compiled in emulation through QEMU, coming through https://github.com/multiarch/qemu-user-static (this is the part of the infrastructure I don't fully understand myself...). The full infrastructure is somewhat involved, but should not be relevant (hopefully) to the issue at hand (see instructions below) - and even if that turns out to be the case, that would be a great information gain as well. + +In either case, the tests for the package (ideally comprising the entire upstream test suite) are then run in emulation. + +Two of the so-called "feedstocks" I co-maintain are for [numpy](https://github.com/conda-forge/numpy-feedstock) and [scipy](https://github.com/conda-forge/scipy-feedstock), and there have been persistent issues with running the test suite in emulation on PPC (interestingly, the same setup on a different architecture - aarch64 - has no problems). However, the compiled artefacts on PPC run fine on native hardware. + +Said otherwise, it appears numpy/scipy are exercising QEMU enough to uncover some bugs. I've seen similar problems also in other packages (e.g. the cvxpy-stack), reinforcing the impression that this is a QEMU issue, and not one on the level of the individual packages. + +Depending on the exact combination of python version, the result of the numpy test suite might be as follows: +``` +320 failed, 18900 passed, 361 skipped, 36 xfailed, 9 xpassed, 144 warnings in 2516.49s (0:41:56) +``` + +Looking at the test failures, sometimes the results are garbage +``` +> assert_array_max_ulp(x, x+eps, maxulp=20) +E AssertionError: Arrays are not almost equal up to 20 ULP (max difference is 8.55554e+08 ULP) + +eps = 1.1920929e-07 +self = <numpy.testing.tests.test_utils.TestULP object at 0x401ec8beb0> +x = array([ 2.3744986e-38, nan, 2.2482052e-15, 7.5780330e+28, + nan, nan, 5.8310814e+29, -5.6511531e+24, + 1.0010809e+00, 1.0101526e+00], dtype=float32) +``` +sometimes the values are permuted +``` +> assert_array_equal(actual, desired) +E AssertionError: +E Arrays are not equal +E +E x and y nan location mismatch: +E x: array([0.000000e+00, 6.704092e-39, 9.000000e+00, 2.350989e-38, +E 0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00, +E 6.772341e-39, nan], dtype=float32) +E y: array([6.704092e-39, 6.772341e-39, 0.000000e+00, 0.000000e+00, +E 0.000000e+00, 0.000000e+00, nan, 2.350989e-38, +E 2.000000e+00, 7.000000e+00], dtype=float32) +``` +sometimes the results are fundamentally different (zero vs. non-zero) +``` +> raise AssertionError(msg) +E AssertionError: +E Arrays are not almost equal to 6 decimals +E +E Mismatched elements: 72 / 216 (33.3%) +E Max absolute difference: 1. +E Max relative difference: 1. +E x: array([[[[[0., 0., 0.], +E [0., 0., 0.], +E [0., 0., 0.]],... +E y: array([[[[[1., 0., 0.], +E [0., 1., 0.], +E [0., 0., 1.]],... +``` + +I don't know where it goes wrong, but it's not just a little tolerance violation. One PR that illustrates this is [here](https://github.com/conda-forge/numpy-feedstock/pull/274) and the respective CI run is [here](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=526218&view=results) (ignore the errors for osx-arm64, those are unrelated). +Steps to reproduce: +1. In an emulated ppc64 machine, install miniforge from [here](https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-ppc64le.sh) +2. Run `conda create -n test_env numpy pytest cython hypothesis typing_extensions` and then `conda activate test_env` +3. Run `python -c "import numpy; numpy.test()"` +4. Pick any test that fails and run it as `python -c "import numpy; numpy.test(tests='x.y.z')"` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1093 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1093 new file mode 100644 index 000000000..a8de95a84 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1098729 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1098729 new file mode 100644 index 000000000..4bae42db1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1102 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1102 new file mode 100644 index 000000000..7399874bc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1128 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1128 new file mode 100644 index 000000000..902f0bafe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1128 @@ -0,0 +1,27 @@ + + + +PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer` +Description of problem: +`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable. + +In fact it copies all bits from the source `GPR` and _excludes_ each flag bit. + +This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`. + +Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). + +A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481 +Steps to reproduce: +Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to: + +- Execute a binary which executes something like: +``` +r4 = 0xffffffffffffffff +mtxer r4 +``` +and check the `cpu_xer` value after the `xer` write. + +Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`. +Additional information: +Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1143 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1143 new file mode 100644 index 000000000..12f8fe91e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1147 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1147 new file mode 100644 index 000000000..b4e7fe14b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1165383 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1165383 new file mode 100644 index 000000000..8571e394e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1172613 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1172613 new file mode 100644 index 000000000..fb4026413 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1182490 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1182490 new file mode 100644 index 000000000..2fb9375e6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1187319 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1187319 new file mode 100644 index 000000000..7216dc4d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1209 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1209 new file mode 100644 index 000000000..c77928700 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/121 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/121 new file mode 100644 index 000000000..74768dcb1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1211 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1211 new file mode 100644 index 000000000..496c499ac --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/122 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/122 new file mode 100644 index 000000000..24cc126d6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/122 @@ -0,0 +1,4 @@ + + + +linux-user does not check PROT_EXEC diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1221966 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1221966 new file mode 100644 index 000000000..0da40dbc9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1221966 @@ -0,0 +1,37 @@ + + + +SIGSEGV in static_code_gen_buffer + +Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault. I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git. I've also tried a statically linked sh from /sbin/ and it also segfaulted. + +wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc +GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) +Copyright (C) 2010 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-redhat-linux-gnu". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done. +(gdb) run ../sparc/ls +Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls +[Thread debugging using libthread_db enabled] + +Program received signal SIGSEGV, Segmentation fault. +0x00007ffff8259116 in static_code_gen_buffer () +Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64 +(gdb) where +#0 0x00007ffff8259116 in static_code_gen_buffer () +#1 0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr= + 0x7ffff82590d0 "A\213n \205í\017\205Í") + at /home/anotheruvula/qemu-devel/cpu-exec.c:56 +#2 0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/cpu-exec.c:631 +#3 0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348) + at /home/anotheruvula/qemu-devel/linux-user/main.c:1089 +#4 0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp= + 0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083 +(gdb) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1228 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1228 new file mode 100644 index 000000000..e3d920faa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1245703 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1245703 new file mode 100644 index 000000000..29fde6870 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1246990 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1246990 new file mode 100644 index 000000000..9b2c6b07d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1246990 @@ -0,0 +1,41 @@ + + + +[qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version. + +On linux: + +./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) + +$ sudo ./qemu-x86_64 ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ sudo gdb ./qemu-x86_64 +(gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +(gdb) where +#0 0x00005555559c21bd in static_code_gen_buffer () +#1 0x00005555555b74d5 in cpu_tb_exec (cpu=0x555557972580, tb_ptr=0x5555559c2190 <static_code_gen_buffer+819792> "A\213n\250\205\355\017\205\257") + at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56 +#2 0x00005555555b817d in cpu_x86_exec (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631 +#3 0x00005555555d997a in cpu_loop (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283 +#4 0x00005555555eca6b in clone_func (arg=0x7fffffffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266 +#5 0x00007ffff71bfe0e in start_thread (arg=0x7ffff7f04700) at pthread_create.c:311 +#6 0x00007ffff6ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 + +$ file rjsupplicant +rjsupplicant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped + +$ uname -r +3.10-2-amd64 + + +And it can be run on Linux amd64 successfully. + +Though I don't have the source code of rjsupplicant, so I don't have further information. + +`qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log + + +The binary is available to download at http://ge.tt/6pgG1tw/v/0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1254672 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1254672 new file mode 100644 index 000000000..bfb059d9e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1254672 @@ -0,0 +1,44 @@ + + + +ps segfaults with qemu-{arm,armel,mips,powerpc}-static + +Host: Ubuntu Precise AMD64 +Guest: Debian Testing armhf + +After running a debootstrap for Debian testing/armhf and entering the chroot, simply running "ps" causes a segmentation fault. + +$ sudo qemu-debootstrap --arch=armhf testing armhf http://ftp.uk.debian.org/debian/ +[...] +$ sudo chroot armhf +# ps +Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4). +/bin/ps:display.c:59: please report this bug + +I couldn't find a bug report for procps, which would be unusual if such a bug existed, so I'm assuming the bug is in qemu. + +Unfortunately trying to run debootstrap for an Ubuntu variant fails to find the release file. + +ps is used a lot, as you can imagine, but specifically it fails when trying to install some packages via "apt-get install" and no attempt is made to recover. + +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 10:43:12 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:32b/output/runtime/1254828 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1254828 new file mode 100644 index 000000000..b8ef18853 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1255 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1255 new file mode 100644 index 000000000..bf1cc937e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1261743 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1261743 new file mode 100644 index 000000000..63b65d984 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1263747 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1263747 new file mode 100644 index 000000000..3dfdf616c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1263747 @@ -0,0 +1,32 @@ + + + +Arm64 fails to run a binary which runs OK on real hardware + +This binary: + +http://oirase.annexia.org/tmp/test.gz + +runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly. + +On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. + +---- +The following section is only if you wish to compile this binary from source, otherwise you can ignore it. + +First compile OCaml from: + +https://github.com/ocaml/ocaml + +(note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: + +https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html + + ./configure + make -j1 world.opt + +Then do: + + echo 'print_endline "hello, world"' > test.ml + ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test + ./test \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1267 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1267 new file mode 100644 index 000000000..c27f29476 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1267 @@ -0,0 +1,96 @@ + + + +qemu-i386 missing VDSO +Description of problem: +Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue. +I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping` + +Interestingly, qemu-x86_64 and qemu-arm appear to work just fine. + +Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct: + +``` +~/src/qemu/build$ /bin/lldb ./qemu-i386 +(lldb) target create "./qemu-i386" +Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64). +(lldb) run /home/ayke/src/tinygo/tinygo/test +Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64) +Process 97986 stopped +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 +libc.so.6`__sigsuspend: +-> 0xfffff78fb9fc <+92>: svc #0 + 0xfffff78fba00 <+96>: cmn x0, #0x1, lsl #12 ; =0x1000 + 0xfffff78fba04 <+100>: b.hi 0xfffff78fba3c ; <+156> + 0xfffff78fba08 <+104>: mov w19, w0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 + frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5 + frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13 + frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13 + frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9 + frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5 + frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160 + frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81 +(lldb) ^D +``` + +I got a better (but still not great) backtrace in Qemu 7.0.0: + +``` +~/src/tinygo/tinygo$ /bin/lldb qemu-i386 +(lldb) target create "qemu-i386" +Current executable set to 'qemu-i386' (aarch64). +(lldb) run test +Process 98106 launched: '/usr/bin/qemu-i386' (aarch64) +Process 98106 stopped +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 +qemu-i386`cpu_ldub_code: +-> 0xaaaaaac4b564 <+32>: ldrb w0, [x0, w1, uxtw] + 0xaaaaaac4b568 <+36>: str xzr, [x2] + 0xaaaaaac4b56c <+40>: ret + +qemu-i386`cpu_lduw_code: + 0xaaaaaac4b570 <+0>: mrs x2, TPIDR_EL0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 + frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72 + frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144 + frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24 + frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400 + frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72 + frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364 + frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480 + frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208 + frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020 + frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160 + frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48 +(lldb) ^D +``` + +And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable: + +``` +#0 0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170 +#1 0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#2 translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#3 x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916 +#4 0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506 +#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569 +#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>) + at ../../accel/tcg/translator.c:103 +#7 0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512) + at ../../target/i386/translate.c:8631 +#8 0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, + cflags@entry=0) at ../../accel/tcg/translate-all.c:1744 +#9 0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414 +#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770 +#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207 +#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/127 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/127 new file mode 100644 index 000000000..08e8ed49f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/127 @@ -0,0 +1,4 @@ + + + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1285363 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1285363 new file mode 100644 index 000000000..c16a45f34 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1287195 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1287195 new file mode 100644 index 000000000..c16f930d1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1294898 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1294898 new file mode 100644 index 000000000..ac8e8197d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1319100 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1319100 new file mode 100644 index 000000000..65028a4f0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1346784 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1346784 new file mode 100644 index 000000000..2395c80f2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1356916 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1356916 new file mode 100644 index 000000000..79e79640f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1356916 @@ -0,0 +1,9 @@ + + + +Too small argv limit + +Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: + +$ /bin/true $(yes | head -n 100000) +-bash: /bin/true: Argument list too long \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1357206 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1357206 new file mode 100644 index 000000000..d9675457d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1357226 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1357226 new file mode 100644 index 000000000..be6c99f12 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1361 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1361 new file mode 100644 index 000000000..05f83e078 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1361 @@ -0,0 +1,23 @@ + + + +ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0 +Description of problem: +[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default. As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2. + +The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`: +``` +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} --- +``` +despite that address nominally being mapped by the last memory syscall to touch that area +``` +openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4 +[...] +mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000 +``` + +Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause. +Steps to reproduce: +Run a ppc64el Linux executable under `qemu-user` with `-p 65536`. +Additional information: +Please advise what more would be useful. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1361912 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1361912 new file mode 100644 index 000000000..c5b00197c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1361912 @@ -0,0 +1,12 @@ + + + +qemu-mips64 Segmentation fault + +When I ran qemu-mips64 for any mips 64 executable , I got this error: + +$ ./qemu-mips64 ../lang +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Is this a known issue? \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1362635 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1362635 new file mode 100644 index 000000000..9536b6dee --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/140 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/140 new file mode 100644 index 000000000..dfa0ce56f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/140 @@ -0,0 +1,4 @@ + + + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1429313 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1429313 new file mode 100644 index 000000000..8313542ac --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1435 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1435 new file mode 100644 index 000000000..b7aa2928e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1471 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1471 new file mode 100644 index 000000000..670b1af3c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1471 @@ -0,0 +1,19 @@ + + + +16fc5726a6 breaks curl SSL connections +Description of problem: +`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`). +Steps to reproduce: +1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 +2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0 +3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` +4. Observe the following error message: + +``` +curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature +``` + +Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. + +Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a). diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1478 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1478 new file mode 100644 index 000000000..bdd8513e1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1494 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1494 new file mode 100644 index 000000000..38369c1ad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1494 @@ -0,0 +1,935 @@ + + + +[regression] [bisected] [coredump] qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0 +Description of problem: +qemu-x86_64 segfaults when trying to compile yay inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9. + +It works with qemu-7.2 so this is a regression in git master (or less likely with the patch). + +``` +[niko@talos2 yay]$ makepkg -s +==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:03:01 PM CET) +==> Checking runtime dependencies... +==> Checking buildtime dependencies... +==> Retrieving sources... + -> Found yay-11.3.2.tar.gz +==> Validating source files with sha256sums... + yay-11.3.2.tar.gz ... Passed +==> Extracting sources... + -> Extracting yay-11.3.2.tar.gz with bsdtar +==> Removing existing $pkgdir/ directory... +==> Starting build()... +go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay +go: downloading github.com/Jguer/votar v1.0.0 +go: downloading github.com/Jguer/aur v1.0.1 +go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 +go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 +go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab +go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 +go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 +go: downloading github.com/leonelquinteros/gotext v1.5.0 +go: downloading github.com/adrg/strutil v0.3.0 +go: downloading golang.org/x/text v0.3.7 +make: *** [Makefile:113: yay] Illegal instruction (core dumped) +``` + +``` +[niko@talos2 yay]$ makepkg -s +==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:10:01 PM CET) +==> Checking runtime dependencies... +==> Checking buildtime dependencies... +==> Retrieving sources... + -> Found yay-11.3.2.tar.gz +==> Validating source files with sha256sums... + yay-11.3.2.tar.gz ... Passed +==> Extracting sources... + -> Extracting yay-11.3.2.tar.gz with bsdtar +==> Starting build()... +go build -trimpath -mod=readonly -modcacherw -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay +go: downloading github.com/Jguer/votar v1.0.0 +go: downloading github.com/Jguer/go-alpm/v2 v2.1.2 +go: downloading github.com/Morganamilo/go-srcinfo v1.0.0 +go: downloading github.com/Jguer/aur v1.0.1 +go: downloading github.com/leonelquinteros/gotext v1.5.0 +go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5 +go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035 +go: downloading github.com/adrg/strutil v0.3.0 +go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab +go: downloading golang.org/x/text v0.3.7 +# math/bits +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xabb70a] + +goroutine 4 [running]: +runtime.throw({0xdbf491?, 0x1?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0001d7750 sp=0xc0001d7720 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0001d77b0 sp=0xc0001d7750 pc=0x44f4ea +cmd/compile/internal/ssa.ValHeap.Less({{0xc0001ae1c0, 0x4, 0x8}, {0xc0001de700, 0x28, 0x100}}, 0x8?, 0xc0001de700?) + /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:59 +0xaa fp=0xc0001d77e0 sp=0xc0001d77b0 pc=0xabb70a +cmd/compile/internal/ssa.(*ValHeap).Less(0x4?, 0x8?, 0xc0001de700?) + <autogenerated>:1 +0x77 fp=0xc0001d7860 sp=0xc0001d77e0 pc=0xad7677 +container/heap.up({0xf24240, 0xc00019eb40}, 0xc00081b370?) + /usr/lib/go/src/container/heap/heap.go:92 +0x7e fp=0xc0001d7898 sp=0xc0001d7860 pc=0x7024de +container/heap.Push({0xf24240, 0xc00019eb40}, {0xdb1f80?, 0xc00081b370?}) + /usr/lib/go/src/container/heap/heap.go:53 +0x5a fp=0xc0001d78c0 sp=0xc0001d7898 pc=0x7022da +cmd/compile/internal/ssa.schedule(0xc0004ea000) + /usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:349 +0x151c fp=0xc0001d7eb0 sp=0xc0001d78c0 pc=0xabcd9c +cmd/compile/internal/ssa.Compile(0xc0004ea000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0001dbb68 sp=0xc0001d7eb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071b540, 0x2) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0001dbea8 sp=0xc0001dbb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071b540, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0001dbf70 sp=0xc0001dbea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001dbfb0 sp=0xc0001dbf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001dbfe0 sp=0xc0001dbfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001dbfe8 sp=0xc0001dbfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [semacquire]: +runtime.gopark(0xc0000062e8?, 0xc00019a050?, 0x0?, 0xa0?, 0x4027dba128?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005ad968 sp=0xc0005ad948 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.semacquire1(0xc0008c4768, 0x20?, 0x1, 0x0, 0x0?) + /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005ad9d0 sp=0xc0005ad968 pc=0x44c9af +sync.runtime_Semacquire(0xc0008b8000?) + /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005ada08 sp=0xc0005ad9d0 pc=0x46a6e7 +sync.(*WaitGroup).Wait(0xc000659800?) + /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005ada30 sp=0xc0005ada08 pc=0x487deb +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005ada88 sp=0xc0005ada30 pc=0xcc6675 +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005adf20 sp=0xc0005ada88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005adf80 sp=0xc0005adf20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005adfe0 sp=0xc0005adf80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005adfe8 sp=0xc0005adfe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009afb0 sp=0xc00009af90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009afe0 sp=0xc00009afb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009afe8 sp=0xc00009afe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 17 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096780 sp=0xc000096760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000967c8 sp=0xc000096780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000967e0 sp=0xc0000967c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000967e8 sp=0xc0000967e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 18 [GC scavenge wait]: +runtime.gopark(0xc000194000?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096f70 sp=0xc000096f50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000096fa0 sp=0xc000096f70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000096fc8 sp=0xc000096fa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc000096fe0 sp=0xc000096fc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000096fe8 sp=0xc000096fe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 33 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027cf9f48?, 0x0?, 0x0?, 0xc00009a770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009a628 sp=0xc00009a608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009a7e0 sp=0xc00009a628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009a7e8 sp=0xc00009a7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 49 [select]: +runtime.gopark(0xc0004e6fb0?, 0x2?, 0xf0?, 0x6d?, 0xc0004e6f6c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0004e6da0 sp=0xc0004e6d80 pc=0x43b716 +runtime.selectgo(0xc0004e6fb0, 0xc0004e6f68, 0xc000504000?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0004e6ee0 sp=0xc0004e6da0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0004e6fe0 sp=0xc0004e6ee0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004e6fe8 sp=0xc0004e6fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 3 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0004f7858 sp=0xc0004f7838 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0004f79e0 sp=0xc0004f7858 pc=0x46f85b +cmd/compile/internal/ssa.is64BitInt(0xc000141480) + /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:218 +0xa fp=0xc0004f79e8 sp=0xc0004f79e0 pc=0x7e2e8a +cmd/compile/internal/ssa.rewriteValueAMD64_OpLoad(0xc00086a458) + /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:29312 +0x51 fp=0xc0004f7a28 sp=0xc0004f79e8 pc=0x884911 +cmd/compile/internal/ssa.rewriteValueAMD64(0xc00089f678?) + /usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:838 +0x31be fp=0xc0004f7a48 sp=0xc0004f7a28 pc=0x819bbe +cmd/compile/internal/ssa.applyRewrite(0xc0001b2000, 0xdf92a8, 0xdf9348, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:133 +0x1016 fp=0xc0004f7e80 sp=0xc0004f7a48 pc=0x7e27d6 +cmd/compile/internal/ssa.lower(0xc0001b2000?) + /usr/lib/go/src/cmd/compile/internal/ssa/lower.go:10 +0x2f fp=0xc0004f7eb0 sp=0xc0004f7e80 pc=0x7b4c4f +cmd/compile/internal/ssa.Compile(0xc0001b2000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0004fbb68 sp=0xc0004f7eb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071b900, 0x3) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0004fbea8 sp=0xc0004fbb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071b900, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0004fbf70 sp=0xc0004fbea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004fbfb0 sp=0xc0004fbf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004fbfe0 sp=0xc0004fbfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004fbfe8 sp=0xc0004fbfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 50 [runnable]: +cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc0007ce6d8?) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc0000dbbf0 sp=0xc0000dbbe8 pc=0x79c375 +cmd/compile/internal/ssa.flagalloc(0xc0000ca000) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc0000dbeb0 sp=0xc0000dbbf0 pc=0x79c0ca +cmd/compile/internal/ssa.Compile(0xc0000ca000) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0000dfb68 sp=0xc0000dbeb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc00071ba40, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0000dfea8 sp=0xc0000dfb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc00071ba40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dff70 sp=0xc0000dfea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dffb0 sp=0xc0000dff70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dffe0 sp=0xc0000dffb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dffe8 sp=0xc0000dffe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 51 [runnable]: +cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc000780d90?) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc00091bbf0 sp=0xc00091bbe8 pc=0x79c375 +cmd/compile/internal/ssa.flagalloc(0xc000774540) + /usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc00091beb0 sp=0xc00091bbf0 pc=0x79c0ca +cmd/compile/internal/ssa.Compile(0xc000774540) + /usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc00091fb68 sp=0xc00091beb0 pc=0x76bc43 +cmd/compile/internal/ssagen.buildssa(0xc000703900, 0x0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc00091fea8 sp=0xc00091fb68 pc=0xaf0527 +cmd/compile/internal/ssagen.Compile(0xc000703900, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc00091ff70 sp=0xc00091fea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc00091ffb0 sp=0xc00091ff70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc00091ffe0 sp=0xc00091ffb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00091ffe8 sp=0xc00091ffe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +# unicode/utf8 +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x411410] + +goroutine 19 [running]: +runtime.throw({0xdbf491?, 0x4000804d28?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0004f1830 sp=0xc0004f1800 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0004f1890 sp=0xc0004f1830 pc=0x44f4ea +runtime.mapaccess2_fast32(0xc0009b3c00, 0xc000562000, 0x6be729) + /usr/lib/go/src/runtime/map_fast32.go:53 +0x170 fp=0xc0004f1898 sp=0xc0004f1890 pc=0x411410 +cmd/compile/internal/ssagen.genssa(0xc000562000, 0xc000988ee0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:6964 +0x965 fp=0xc0004f1ea8 sp=0xc0004f1898 pc=0xb27345 +cmd/compile/internal/ssagen.Compile(0xc0000fcb40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0004f1f70 sp=0xc0004f1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004f1fb0 sp=0xc0004f1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004f1fe0 sp=0xc0004f1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004f1fe8 sp=0xc0004f1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [semacquire]: +runtime.gopark(0x20?, 0xd7ca20?, 0x0?, 0x60?, 0xc00003a600?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005a9968 sp=0xc0005a9948 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.semacquire1(0xc0006d5a88, 0x20?, 0x1, 0x0, 0x0?) + /usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005a99d0 sp=0xc0005a9968 pc=0x44c9af +sync.runtime_Semacquire(0xc0000fdb80?) + /usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005a9a08 sp=0xc0005a99d0 pc=0x46a6e7 +sync.(*WaitGroup).Wait(0xc0008ca400?) + /usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005a9a30 sp=0xc0005a9a08 pc=0x487deb +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005a9a88 sp=0xc0005a9a30 pc=0xcc6675 +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005a9f20 sp=0xc0005a9a88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005a9f80 sp=0xc0005a9f20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005a9fe0 sp=0xc0005a9f80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005a9fe8 sp=0xc0005a9fe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 17 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027cf9fe8?, 0x0?, 0x0?, 0xc00009c770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 49 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0009c1308 sp=0xc0009c12e8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0009c1490 sp=0xc0009c1308 pc=0x46f85b +cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000754700) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0009c16f0 sp=0xc0009c1490 pc=0x779bb7 +cmd/compile/internal/ssa.BuildFuncDebug(0xc00041e5a0?, 0xc000754700, 0xc000000049?, 0xa?, 0xc00098c000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0009c1898 sp=0xc0009c16f0 pc=0x77adb6 +cmd/compile/internal/ssagen.genssa(0xc000754700, 0xc0004bfce0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0009c1ea8 sp=0xc0009c1898 pc=0xb2790b +cmd/compile/internal/ssagen.Compile(0xc0000fc8c0, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0009c1f70 sp=0xc0009c1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0009c1fb0 sp=0xc0009c1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0009c1fe0 sp=0xc0009c1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0009c1fe8 sp=0xc0009c1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 5 [select]: +runtime.gopark(0xc00009e7b0?, 0x2?, 0xf0?, 0xe5?, 0xc00009e76c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009e5a0 sp=0xc00009e580 pc=0x43b716 +runtime.selectgo(0xc00009e7b0, 0xc00009e768, 0x0?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc00009e6e0 sp=0xc00009e5a0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc00009e7e0 sp=0xc00009e6e0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009e7e8 sp=0xc00009e7e0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 50 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0001cd308 sp=0xc0001cd2e8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001cd490 sp=0xc0001cd308 pc=0x46f85b +cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000192000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0001cd6f0 sp=0xc0001cd490 pc=0x779bb7 +cmd/compile/internal/ssa.BuildFuncDebug(0xc0001a65a0?, 0xc000192000, 0xc000000049?, 0x12?, 0xc0001a4000) + /usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0001cd898 sp=0xc0001cd6f0 pc=0x77adb6 +cmd/compile/internal/ssagen.genssa(0xc000192000, 0xc00019f260) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0001cdea8 sp=0xc0001cd898 pc=0xb2790b +cmd/compile/internal/ssagen.Compile(0xc0000fca00, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0001cdf70 sp=0xc0001cdea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001cdfb0 sp=0xc0001cdf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001cdfe0 sp=0xc0001cdfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001cdfe8 sp=0xc0001cdfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 20 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0008e10f8 sp=0xc0008e10d8 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0008e1280 sp=0xc0008e10f8 pc=0x46f85b +cmd/compile/internal/ssagen.AddrAuto(0xc000201ed0, 0x81308171a15?) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7649 +0x94 fp=0xc0008e12a8 sp=0xc0008e1280 pc=0xb2d9d4 +cmd/compile/internal/amd64.ssaGenValue(0xc0008bec60, 0xc000781ab0) + /usr/lib/go/src/cmd/compile/internal/amd64/ssa.go:1037 +0x13dc fp=0xc0008e1898 sp=0xc0008e12a8 pc=0xb3d6bc +cmd/compile/internal/ssagen.genssa(0xc0004e4000, 0xc0008e8070) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7024 +0x3ff8 fp=0xc0008e1ea8 sp=0xc0008e1898 pc=0xb2a9d8 +cmd/compile/internal/ssagen.Compile(0xc0000fcc80, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0008e1f70 sp=0xc0008e1ea8 pc=0xae7b8f +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0008e1fb0 sp=0xc0008e1f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0008e1fe0 sp=0xc0008e1fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0008e1fe8 sp=0xc0008e1fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +# internal/reflectlite +unexpected fault address 0x0 +fatal error: fault +[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x66b360] + +goroutine 6 [running]: +runtime.throw({0xdbf491?, 0x8?}) + /usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000dc720 sp=0xc0000dc6f0 pc=0x4389fd +runtime.sigpanic() + /usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0000dc780 sp=0xc0000dc720 pc=0x44f4ea +cmd/compile/internal/abi.(*assignState).regAllocate(0xc0000dc7a0, 0x41b2b1, {0x14cdd40, 0xc0000dc808}, 0xa8) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:607 fp=0xc0000dc788 sp=0xc0000dc780 pc=0x66b360 +cmd/compile/internal/abi.(*assignState).assignParamOrReturn(0xc0000dc8a8, 0xc0008977a0, {0xf23198, 0xc000a0b080}, 0x20?) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:777 +0x165 fp=0xc0000dc840 sp=0xc0000dc788 pc=0x66bae5 +cmd/compile/internal/abi.(*ABIConfig).ABIAnalyzeFuncType(0xc0000bca60, 0xc00089b710) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:404 +0x3d7 fp=0xc0000dc9f8 sp=0xc0000dc840 pc=0x669a17 +cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze(0xd41a80?, 0xc0000d0600?, 0x0?) + /usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:432 +0x5d fp=0xc0000dcb68 sp=0xc0000dc9f8 pc=0x669e7d +cmd/compile/internal/ssagen.buildssa(0xc0008cc500, 0x1) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:455 +0x1209 fp=0xc0000dcea8 sp=0xc0000dcb68 pc=0xaef709 +cmd/compile/internal/ssagen.Compile(0xc0008cc500, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dcf70 sp=0xc0000dcea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dcfb0 sp=0xc0000dcf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dcfe0 sp=0xc0000dcfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dcfe8 sp=0xc0000dcfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 1 [runnable]: +runtime.gopark(0xc0000be000?, 0xc0004edec0?, 0xb0?, 0x99?, 0xc000739978?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000739910 sp=0xc0007398f0 pc=0x43b716 +runtime.chansend(0xc000d540c0, 0xc0007399e8, 0x1, 0xc0007399d8?) + /usr/lib/go/src/runtime/chan.go:259 +0x42e fp=0xc000739998 sp=0xc000739910 pc=0x40602e +runtime.chansend1(0xd7ca20?, 0x4000803501?) + /usr/lib/go/src/runtime/chan.go:145 +0x1d fp=0xc0007399c8 sp=0xc000739998 pc=0x405bdd +cmd/compile/internal/gc.compileFunctions.func4(0xc00180cc40) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:160 +0x27 fp=0xc0007399e8 sp=0xc0007399c8 pc=0xcc68a7 +cmd/compile/internal/gc.compileFunctions.func5({0xc001099500, 0x222, 0x350?}) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:170 +0x53 fp=0xc000739a30 sp=0xc0007399e8 pc=0xcc6713 +cmd/compile/internal/gc.compileFunctions() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:181 +0x1ff fp=0xc000739a88 sp=0xc000739a30 pc=0xcc663f +cmd/compile/internal/gc.Main(0xdf8e28) + /usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc000739f20 sp=0xc000739a88 pc=0xcc86aa +main.main() + /usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc000739f80 sp=0xc000739f20 pc=0xcf00bd +runtime.main() + /usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc000739fe0 sp=0xc000739f80 pc=0x43b2e7 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000739fe8 sp=0xc000739fe0 pc=0x46e201 + +goroutine 2 [force gc (idle)]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.forcegchelper() + /usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201 +created by runtime.init.6 + /usr/lib/go/src/runtime/proc.go:293 +0x25 + +goroutine 3 [GC sweep wait]: +runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.bgsweep(0x0?) + /usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce +runtime.gcenable.func1() + /usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:178 +0x6b + +goroutine 4 [GC scavenge wait]: +runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716 +runtime.goparkunlock(...) + /usr/lib/go/src/runtime/proc.go:387 +runtime.(*scavengerState).park(0x1487ce0) + /usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13 +runtime.bgscavenge(0x0?) + /usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5 +runtime.gcenable.func2() + /usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201 +created by runtime.gcenable + /usr/lib/go/src/runtime/mgc.go:179 +0xaa + +goroutine 17 [finalizer wait]: +runtime.gopark(0x43ba92?, 0x4027d38828?, 0x0?, 0x0?, 0xc00009c770?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716 +runtime.runfinq() + /usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201 +created by runtime.createfing + /usr/lib/go/src/runtime/mfinal.go:163 +0x45 + +goroutine 5 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc000194658 sp=0xc000194638 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001947e0 sp=0xc000194658 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc0001fe500, {0xf2a400, 0xc000a990a0?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1432 +0xbb fp=0xc000194b68 sp=0xc0001947e0 pc=0xaf509b +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d9540, 0x2) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc000194ea8 sp=0xc000194b68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d9540, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc000194f70 sp=0xc000194ea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc000194fb0 sp=0xc000194f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc000194fe0 sp=0xc000194fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000194fe8 sp=0xc000194fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 33 [select]: +runtime.gopark(0xc0000997b0?, 0x2?, 0xf0?, 0x95?, 0xc00009976c?) + /usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0000995a0 sp=0xc000099580 pc=0x43b716 +runtime.selectgo(0xc0000997b0, 0xc000099768, 0xc000110000?, 0x0, 0xd26040?, 0x1) + /usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0000996e0 sp=0xc0000995a0 pc=0x44b8be +cmd/compile/internal/gc.compileFunctions.func3() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0000997e0 sp=0xc0000996e0 pc=0xcc6a12 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000997e8 sp=0xc0000997e0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8 + +goroutine 22 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0000ad2d0 sp=0xc0000ad2b0 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0000ad458 sp=0xc0000ad2d0 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf295c0, 0xc00134d450?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0000ad7e0 sp=0xc0000ad458 pc=0xaf517a +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf29800, 0xc0013eebc0?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1441 +0x45e5 fp=0xc0000adb68 sp=0xc0000ad7e0 pc=0xaf95c5 +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d8b40, 0x3) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc0000adea8 sp=0xc0000adb68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d8b40, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000adf70 sp=0xc0000adea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000adfb0 sp=0xc0000adf70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000adfe0 sp=0xc0000adfb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000adfe8 sp=0xc0000adfe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 + +goroutine 49 [runnable]: +runtime.asyncPreempt2() + /usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0017932d0 sp=0xc0017932b0 pc=0x439e1f +runtime.asyncPreempt() + /usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc001793458 sp=0xc0017932d0 pc=0x46f85b +cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf295c0, 0xc00140a960?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0017937e0 sp=0xc001793458 pc=0xaf517a +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf2a400, 0xc000a92a10?}) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1436 +0x150 fp=0xc001793b68 sp=0xc0017937e0 pc=0xaf5130 +cmd/compile/internal/ssagen.(*state).stmtList(...) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421 +cmd/compile/internal/ssagen.buildssa(0xc0005d9680, 0x0) + /usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc001793ea8 sp=0xc001793b68 pc=0xaf03e6 +cmd/compile/internal/ssagen.Compile(0xc0005d9680, 0x0?) + /usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc001793f70 sp=0xc001793ea8 pc=0xae796c +cmd/compile/internal/gc.compileFunctions.func5.1(0x0?) + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc001793fb0 sp=0xc001793f70 pc=0xcc681a +cmd/compile/internal/gc.compileFunctions.func3.1() + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc001793fe0 sp=0xc001793fb0 pc=0xcc6c52 +runtime.goexit() + /usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc001793fe8 sp=0xc001793fe0 pc=0x46e201 +created by cmd/compile/internal/gc.compileFunctions.func3 + /usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245 +``` +Steps to reproduce: +1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended) +2. Chroot into it using the following script: +``` +#!/bin/bash + +basedir="/home/niko/chroots/arch-x86_64" +cp /etc/resolv.conf ${basedir}/etc/ +cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/ +sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a> +mount --make-slave --bind ${basedir} ${basedir} +mount -t proc none ${basedir}/proc +mount -t sysfs none ${basedir}/sys/ +mount --make-rslave --rbind /dev ${basedir}/dev +mount --make-rslave --rbind /run ${basedir}/run +chroot ${basedir} /bin/bash +sleep 3 +umount -R ${basedir}/run +umount -R ${basedir}/dev +umount ${basedir}/sys +umount ${basedir}/proc +umount ${basedir} +mount | grep chroots | grep arch-x86_64 | grep -v snap +``` +3. Initialize pacaman keyring and update system: +``` +# pacman-key --init +# pacman-key --populate +# pacman -Syu +``` +4. Download the yay `PKGBUILD` from the AUR (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=yay) and run `makepkg -s` +5. Wait for the crash. +Additional information: +``` +Wed 2023-02-15 17:03:22 CET 495600 1000 1000 SIGILL present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +Wed 2023-02-15 17:11:25 CET 509058 1000 1000 SIGSEGV present /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 > +talos2 ~ # coredumpctl gdb 495600 + PID: 495600 (go) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 4 (ILL) + Timestamp: Wed 2023-02-15 17:03:21 CET (13min ago) + Command Line: /usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldflags $'-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.go.1000.33cad872d21043ebbe3dd6581bdd28c6.495600.1676477001000000.zst (present) + Size on Disk: 7.4M + Message: Process 495600 (go) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 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 "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +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 /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libresolv.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/f2/f2133743f1bb49d82c152c57fea6c71755a865029a19ff845dd27e420f5fa0be-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/89/89e115246dee235465b64002c5ab8a7df3a3f1b776d78dab9cd937c4892860a0-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/79/791d1887c70eed91dc52577c14310590649cb307ef557d46d8cc10df4704a957-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/86/86d5a3a0121a98ed0805aa57bc14d0bd85178c04054816d99495336d86c5bf5f-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/31/31d19f3051c8985f29f85ea43d9445e4b848c58a17a79d4e726280a9bced5743-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/79/79d75d9215f18cbef6b6a66468f78efd92edc13f7093f600b1552032732410aa-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/bc/bcdca8f344789eb190a1124fe919aa975d08f07250bfc6d780b0ae0cc28092fe-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/86/86e73e7b053ab6e1e1d149b5d1bbba621bfc3d0bbc66ec6310c072c82a7221e7-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/b1/b12eb8399331175352cb92b971280ba5c0c501c6ffa5c330921c3c0667c5f199-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/32/3264d3f95a5e2e731c952060b0cd4cb3bc37ff884513397336d40c935d098e5b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/19/1977592d2d60e1dd1025609428d04f6cc17283759aae0c97bd8f35e8a341679b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/a9/a9b261a012c19401c1fd78154a20f58bb7778e731e17f903eb3fe8ed3a5ddd59-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/96/9697f94a563c1bd04db2a82ac1770821f97548911f616dd1149bb87d0f48d65b-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/56/56e54c1dc0b6bee517915ce0bdf694a3b94f4de88b2cabb987b645e1255594fb-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/7e/7e9d9d14f25fe76951999c17680e09a181c5f14c9c4f30fe6bff8d0d669590c3-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/f4/f431652315a861a2a85b47ae12cfc99734b3db4754aa35c9158254e4ba3507c0-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/1c/1c51052ad1af6b1a1575f9bbc3f4616ed673578a285ae9a29f5548eed68c05dd-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/be/be3037525f021f1d7e2e8499d3dcc0f44be39adf70eb91979c96db3e5645bcf1-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/55/557fa6c4030abc2d7b6407ce3093ae5772939f1a2595be09dd670ecd1c5ec8f2-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/69/69a73f1b9f395cf4a1666dde8d7971a0bd9313fbfa55a5109eb02e59b301be09-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/ab/abc0750a5bd45b2346aa5bc87092f67207e9436307e3e32cb470952f87d13fb6-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/da/dadc71547f56ab68eccefd0d571599f99739a3d75acc444d97829d6ab62a6922-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/91/915619420aacc3b5964e7537365661258ab52ec44fb7ab29790258822c793de5-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/68/6834d594cb4ffe53979a0c4611bb5200e6e0c580acb42f4383ed2fb6a93d758d-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/c6/c6ccbc76ef432925fc1a5ea22ab750ac591f3e8983d2f33f54b01c799e3a274d-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/89/893c62418d079bf692b5ff17db226ae3d0fefdc87cbd0c64f30c437677a288ec-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d8/d8666c5d7807c5a08b30f2278a1efd691c188804b3090704bd0b3f8ef06c40d9-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d4/d401ca16783c19ff776f35305023173b63e2610e313b9a793734af80afda4e83-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/d0/d0593989dbf79e26b8bf6705325c6b44044e560a22c3ab81d320c67dcd97f1eb-d during file-backed mapping note processing + +warning: Can't open file /home/niko/.cache/go-build/57/572953ae015634b922f88b0191804a949206100adb6bd2454db615e2774dbe30-d during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_mymachines.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libcap.so.2.67 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgcc_s.so.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_resolve.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libnss_myhostname.so.2 during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 495627] +[New LWP 495604] +[New LWP 495603] +[New LWP 495614] +[New LWP 495602] +[New LWP 495610] +[New LWP 495618] +[New LWP 495606] +[New LWP 495621] +[New LWP 495608] +[New LWP 495612] +[New LWP 495629] +[New LWP 495615] +[New LWP 495622] +[New LWP 495600] +[New LWP 495605] +[New LWP 495623] +[New LWP 495630] +[New LWP 495616] +[New LWP 495633] +[New LWP 495634] +[New LWP 495635] +[New LWP 495636] +[New LWP 495637] +[New LWP 495632] +[New LWP 495609] +[New LWP 495620] +[New LWP 495617] +[New LWP 495624] +[New LWP 495628] +[New LWP 495625] +[New LWP 495607] +[New LWP 495613] +[New LWP 495626] +[New LWP 495619] +[New LWP 495611] +[New LWP 495631] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldf'. +Program terminated with signal SIGILL, Illegal instruction. +#0 0x00003fff9d5d7284 in code_gen_buffer () +[Current thread is 1 (Thread 0x3fff4bf3c380 (LWP 495627))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x3fff4bf3c380 (LWP 495627) 0x00003fff9d5d7284 in code_gen_buffer () + 2 Thread 0x3fffa85ec380 (LWP 495604) 0x000000001029ba2c in __lll_lock_wait () + 3 Thread 0x3fffa862d380 (LWP 495603) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 4 Thread 0x3fffa8362380 (LWP 495614) 0x00000000100ef210 in tb_jmp_cache_get_tb (hash=3271, jc=0x3fff6c00c5c0) + at ../accel/tcg/tb-jmp-cache.h:38 + 5 Thread 0x3fffa8eaf380 (LWP 495602) 0x00000000102cf6ec in syscall () + 6 Thread 0x3fffa8466380 (LWP 495610) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 7 Thread 0x3fffa815d380 (LWP 495618) 0x00000000101e07c8 in g_hash_table_lookup () + 8 Thread 0x3fffa856a380 (LWP 495606) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 9 Thread 0x3fffa809a380 (LWP 495621) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 10 Thread 0x3fffa84e8380 (LWP 495608) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 11 Thread 0x3fffa83e4380 (LWP 495612) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 12 Thread 0x3fff4beba380 (LWP 495629) 0x00003fff9c1c84b8 in code_gen_buffer () + 13 Thread 0x3fffa8321380 (LWP 495615) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 14 Thread 0x3fffa86ae380 (LWP 495622) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 15 Thread 0x200f4000 (LWP 495600) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 16 Thread 0x3fffa85ab380 (LWP 495605) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 17 Thread 0x3fffa8059380 (LWP 495623) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 18 Thread 0x3fff4be79380 (LWP 495630) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 19 Thread 0x3fffa82e0380 (LWP 495616) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 20 Thread 0x3fff4bdb6380 (LWP 495633) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 21 Thread 0x3fff4bd75380 (LWP 495634) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 22 Thread 0x3fff4bd34380 (LWP 495635) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 23 Thread 0x3fff4bcf3380 (LWP 495636) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 24 Thread 0x3fff4bcb2380 (LWP 495637) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 25 Thread 0x3fff4bdf7380 (LWP 495632) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 26 Thread 0x3fffa84a7380 (LWP 495609) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 27 Thread 0x3fffa80db380 (LWP 495620) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 28 Thread 0x3fffa829f380 (LWP 495617) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 29 Thread 0x3fff4bfff380 (LWP 495624) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 30 Thread 0x3fff4befb380 (LWP 495628) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 31 Thread 0x3fff4bfbe380 (LWP 495625) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 32 Thread 0x3fffa8529380 (LWP 495607) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 33 Thread 0x3fffa83a3380 (LWP 495613) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 34 Thread 0x3fff4bf7d380 (LWP 495626) 0x00003fff9d5d7284 in code_gen_buffer () + 35 Thread 0x3fffa811c380 (LWP 495619) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 36 Thread 0x3fffa8425380 (LWP 495611) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 + 37 Thread 0x3fff4be38380 (LWP 495631) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75 +(gdb) quit +talos2 ~ # coredumpctl gdb 509058 + PID: 509058 (make) + UID: 1000 (niko) + GID: 1000 (niko) + Signal: 11 (SEGV) + Timestamp: Wed 2023-02-15 17:11:24 CET (6min ago) + Command Line: /usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/pkg/yay PREFIX=/usr build + Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64 + Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Unit: user@1000.service + User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope + Slice: user-1000.slice + Owner UID: 1000 (niko) + Boot ID: 33cad872d21043ebbe3dd6581bdd28c6 + Machine ID: b3e834569b8ff461391f5ac061feb773 + Hostname: talos2 + Storage: /var/lib/systemd/coredump/core.make.1000.33cad872d21043ebbe3dd6581bdd28c6.509058.1676477484000000.zst (present) + Size on Disk: 1.0M + Message: Process 509058 (make) of user 1000 dumped core. + +GNU gdb (Gentoo 12.1 vanilla) 12.1 +Copyright (C) 2022 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 "powerpc64le-unknown-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://bugs.gentoo.org/>. +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 /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64... +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 +BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 + +warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libguile-3.0.so.1.6.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgc.so.1.5.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libffi.so.8.1.2 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libunistring.so.5.0.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libgmp.so.10.4.1 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libcrypt.so.2.0.0 during file-backed mapping note processing + +warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing + +warning: core file may not match specified executable file. +[New LWP 509058] +[New LWP 509060] +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib64/libthread_db.so.1". +Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000010278798 in sigsuspend () +[Current thread is 1 (Thread 0x1bde9000 (LWP 509058))] +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x1bde9000 (LWP 509058) 0x0000000010278798 in sigsuspend () + 2 Thread 0x3fffae0ef380 (LWP 509060) 0x00000000102cf6ec in syscall () +(gdb) quit +``` + +Download coredumps: + +https://drive.google.com/file/d/1GosaobKvmuRg-olaA1-aZcp7zAZcWmcF/view?usp=share_link + +https://drive.google.com/file/d/1N0BmlBIYY-qT5lHqlrKXvPL_FdYl3GfI/view?usp=share_link diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1495 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1495 new file mode 100644 index 000000000..705279de4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1512 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1512 new file mode 100644 index 000000000..ff48c0904 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1512 @@ -0,0 +1,4 @@ + + + +AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1519037 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1519037 new file mode 100644 index 000000000..73971ba44 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1527765 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1527765 new file mode 100644 index 000000000..4fce454c8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1528 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1528 new file mode 100644 index 000000000..83543fca8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1528239 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1528239 new file mode 100644 index 000000000..77560ec11 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1563612 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1563612 new file mode 100644 index 000000000..8b9361c8a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1563612 @@ -0,0 +1,53 @@ + + + +pulseaudio applications crash under linux-user-x86_64 + +Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): + +# apt-get install build-essential qemu-user libpulse-dev pulseaudio +$ cat > test.c << __EOF +#include <pulse/simple.h> + +int main(void) { + pa_simple *s; + pa_sample_spec ss; + ss.format = PA_SAMPLE_S16NE; + ss.channels = 2; + ss.rate = 44100; + s = pa_simple_new(NULL, // Use the default server. + "Fooapp", // Our application's name. + PA_STREAM_PLAYBACK, + NULL, // Use the default device. + "Music", // Description of our stream. + &ss, // Our sample format. + NULL, // Use default channel map + NULL, // Use default buffering + // attributes. + NULL // Ignore error code. + ); + + int16_t buf[2 * 1000]; + int i; + memset(buf, 0, sizeof buf); + for (i = 0; i < 44; i++) { + pa_simple_write(s, buf, sizeof buf, NULL); + } + + pa_simple_free(s); + + return 0; +} +__EOF +$ gcc test.c -o test -lpulse -lpulse-simple +$ ./test +<no output, no error> +$ qemu-x86_64 ./test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ + + +I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. + +Thank you for developing QEMU. :-) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1568107 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1568107 new file mode 100644 index 000000000..7518d6f0e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1585840 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1585840 new file mode 100644 index 000000000..71d869719 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1585840 @@ -0,0 +1,12 @@ + + + +multiprocess program gets incorrect results with qemu arm-linux-user + +The attached program can run either in a threaded mode or a multiprocess mode. It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process". "success" of the test is defined as the final count being seen as 2000000 by both tasks. + +In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes. But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode. + +The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes. I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware) + +I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1591611 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1591611 new file mode 100644 index 000000000..6d7918b88 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1593 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1593 new file mode 100644 index 000000000..6ad5a6aed --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1593 @@ -0,0 +1,10 @@ + + + +SLIRP hostfwd ignores bind address and uses `INADDR_ANY` +Description of problem: +When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). +Additional information: +The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 + +Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1603734 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1603734 new file mode 100644 index 000000000..e542bd20d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1605443 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1605443 new file mode 100644 index 000000000..9a30c6f0b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1605443 @@ -0,0 +1,14 @@ + + + +QEMU epoll for i386-linux-user on arm host is broken in 2.6 + +I'm trying to get wine running on qemu-i386 on arm. + +I found that 2.5.1 is OK, but 2.6 is not. + +By bisecting, I found commit 928bed6a057cedd6110e634865e021a24029785a is the problem. + +I reverted this commit, and then epoll is OK now. + +It seems that the commit broke epoll of qemu-i386 on arm. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1623020 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1623020 new file mode 100644 index 000000000..f33d7ee9d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1641861 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1641861 new file mode 100644 index 000000000..b1e75a03d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1648 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1648 new file mode 100644 index 000000000..e69c40386 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1650 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1650 new file mode 100644 index 000000000..a762d263f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1650 @@ -0,0 +1,17 @@ + + + +Consider doing runtime detection of MAP_FIXED_NOREPLACE +Description of problem: +``` +qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option) +``` +strace says +``` + mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported) +``` +Steps to reproduce: +1. `apt install qemu-i386-static 32subsystem` +2. `strace qemu-i386-static /opt/32/bin/as` +Additional information: +Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime? diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1654137 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1654137 new file mode 100644 index 000000000..d5672caa3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1659901 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1659901 new file mode 100644 index 000000000..00e73f655 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1667401 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1667401 new file mode 100644 index 000000000..29692971e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1671 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1671 new file mode 100644 index 000000000..12f4d7b2a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1673976 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1673976 new file mode 100644 index 000000000..19e395365 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1673976 @@ -0,0 +1,14 @@ + + + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) + +I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. + +locale-gen +Generating locales... + en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale + +I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1696353 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1696353 new file mode 100644 index 000000000..355c83de7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1696353 @@ -0,0 +1,38 @@ + + + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1697 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1697 new file mode 100644 index 000000000..eb55b0932 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1701821 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1701821 new file mode 100644 index 000000000..b144d8c9b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1701821 @@ -0,0 +1,217 @@ + + + +floating-point operation bugs in qemu-sh4 + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + asinf + cbrtf + copysignf + coshf + expm1f + fabsf + floor + fmaf + ldexpf + logbf + round + roundf + sinhf + tanhf + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure asinf cbrtf copysignf coshf expm1f fabsf floor fma fmaf fmal ldexpf logbf round roundf sinhf tanhf +- Set environment variables for using qemu-sh4. +- cd testdir-math; mkdir build-sh4; cd build-sh4; ./configure --host=sh4-linux; make; make check + +Here are the failures (from the file testdir-math/build-sh4/gltests/test-suite.log): + + +FAIL: test-asinf +================ + +pc=0xf6751cdc sr=0x00000101 pr=0xf6758e86 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6751cd6 fpul=0x3f19999a +r0=0xf6751d88 r1=0x00000000 r2=0x00080000 r3=0x00000000 +r4=0xf6ffe21c r5=0xf6ffe230 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x3f19999a r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe230 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-asinf (exit status: 1) + +FAIL: test-cbrtf +================ + +pc=0x00400980 sr=0x00000001 pr=0x00400684 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x00400960 fpul=0x00000000 +r0=0x00400ae8 r1=0x00412070 r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00412064 r9=0x00400960 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe21c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-cbrtf (exit status: 1) + +FAIL: test-copysignf +==================== + +pc=0x004004ce sr=0x00000001 pr=0xf668d28c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004d2 fpul=0x00000000 +r0=0x80000000 r1=0x3f4ccccd r2=0xf6674284 r3=0xf6ffe2b0 +r4=0x00000001 r5=0xf6ffe2e4 r6=0xf6ffe2ec r7=0x00000000 +r8=0x00411088 r9=0x00411084 r10=0x00000000 r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0x004004d2) +Unhandled trap: 0x1a0 +FAIL test-copysignf (exit status: 1) + +FAIL: test-coshf +================ + +pc=0xf675223a sr=0x00000101 pr=0xf675223c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675231c fpul=0x3f19999a +r0=0x3f19999a r1=0x3f19999a r2=0x000000e0 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400734 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in delay slot (delayed_pc=0xf675231c) +Unhandled trap: 0x1a0 +FAIL test-coshf (exit status: 1) + +FAIL: test-expm1f +================= + +pc=0xf6757e08 sr=0x00000000 pr=0x004005ce fpscr=0x00081000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6757dfe fpul=0x00000000 +r0=0xf6757fb0 r1=0x00001000 r2=0x00080000 r3=0x3eb17218 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400514 r9=0x00000064 r10=0x00400514 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe234 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-expm1f (exit status: 1) + +FAIL: test-fabsf +================ + +pc=0x00400504 sr=0x00000001 pr=0xf660228c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004ec fpul=0x00000000 +r0=0x00400640 r1=0x00412074 r2=0x00000000 r3=0x00412078 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00080000 +r8=0x004007ac r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe260 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fabsf (exit status: 1) + +FAIL: test-floor2 +================= + +../../gltests/test-floor2.c:130: assertion 'correct_result_p (x, reference)' failed +qemu: uncaught target signal 6 (Aborted) - core dumped +FAIL test-floor2 (exit status: 134) + +FAIL: test-fmaf2 +================ + +pc=0xf675f5ac sr=0x00000101 pr=0xf675f5a6 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675f5a6 fpul=0x01800000 +r0=0xf675f4a4 r1=0x000065b0 r2=0x00080000 r3=0x3f800000 +r4=0x01800000 r5=0x00000000 r6=0xffffffe9 r7=0x7f800000 +r8=0xffffff6b r9=0xf6ffe1e4 r10=0xf6ffe1e8 r11=0xffffff6b +r12=0xf67ab008 r13=0xf6ffe1d8 r14=0x004004dc r15=0xf6ffe18c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fmaf2 (exit status: 1) + +FAIL: test-ldexpf +================= + +pc=0xf669efa0 sr=0x00000001 pr=0xf669ef9a fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf669ef9a fpul=0x3f99999a +r0=0xfffffdc6 r1=0x000c9d70 r2=0x00080000 r3=0x3f19999a +r4=0x0019999a r5=0x3f19999a r6=0xffffffe9 r7=0x7f800000 +r8=0x00000001 r9=0x0040041c r10=0xf6ffe23c r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe218 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-ldexpf (exit status: 1) + +FAIL: test-logbf +================ + +pc=0xf675842c sr=0x00000001 pr=0x00400664 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758422 fpul=0x00000000 +r0=0xf6758480 r1=0x00000000 r2=0x00080000 r3=0x00080000 +r4=0x00000000 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0xf6ffe24c r9=0x0040054c r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe244 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-logbf (exit status: 1) + +FAIL: test-round2 +================= + +FAIL test-round2 (exit status: 1) + +FAIL: test-roundf2 +================== + +FAIL test-roundf2 (exit status: 1) + +FAIL: test-sinhf +================ + +pc=0xf675581c sr=0x00000101 pr=0xf675a784 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6755858 fpul=0x3f19999a +r0=0xf6755930 r1=0x317fffff r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe238 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0xf6755858) +Unhandled trap: 0x1a0 +FAIL test-sinhf (exit status: 1) + +FAIL: test-tanhf +================ + +pc=0xf6758ca4 sr=0x00000100 pr=0x0040057c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758c9a fpul=0x3f19999a +r0=0xf6758d00 r1=0x00000000 r2=0x00080000 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe254 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-tanhf (exit status: 1) + + +I don't have access to sh4 hardware, so I cannot provide this as a comparison point. +But most of the test failures don't look like "merely" a wrong computation by glibc. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1704638 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1704638 new file mode 100644 index 000000000..97f7a9eb3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1707 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1707 new file mode 100644 index 000000000..a29648edb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1707 @@ -0,0 +1,26 @@ + + + +linux-user qemu-x86_64 can't exec a binary on aarch64 or Loongarch. +Description of problem: +on master branch, we build an simply hello.c with x86_cross gcc. +then. run './build/qemu-x86_64 hello', no output. +Steps to reproduce: +1. build an hello.c with x86_64 cross. use --static. +2. build qemu-x86_64 on aarch64 or LoongArch host. +3. run './build/qemu-x86_64 hello' +Additional information: +[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt) + + + + [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello) + + +The following commit causes this problem． + +commit 86f04735ac2088d5c069c3d1712212ec7428c562 +Author: Helge Deller <deller@gmx.de> +Date: Sun Dec 25 09:23:19 2022 +0100 + + linux-user: Fix brk() to release pages diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1715162 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1715162 new file mode 100644 index 000000000..9dbb34466 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1727737 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1727737 new file mode 100644 index 000000000..9b47ff8e2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1727737 @@ -0,0 +1,28 @@ + + + +qemu-arm stalls on a GCC sanitizer test since qemu-2.7 + +Hi, + +I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. + +After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 + +I'm attaching a tarball containing: +alloca_instruments_all_paddings.exe : the testcase, and the needed libs: +lib/librt.so.1 +lib/libdl.so.2 +lib/ld-linux-armhf.so.3 +lib/libasan.so.5 +lib/libc.so.6 +lib/libgcc_s.so.1 +lib/libpthread.so.0 +lib/libm.so.6 + +To reproduce the problem: +$ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe +returns in less than a second with qemu-2.7, and never with qemu-2.8 + +Using -d in_asm suggests that the program "almost" completes and qemu seems to stall on: +0x40b6eb44: e08f4004 add r4, pc, r4 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1734 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1734 new file mode 100644 index 000000000..93a5449a7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1734 @@ -0,0 +1,19 @@ + + + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1735384 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1735384 new file mode 100644 index 000000000..69d4ee82c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1736 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1736 new file mode 100644 index 000000000..4b20e2446 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1740219 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1740219 new file mode 100644 index 000000000..9517dedf6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1741 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1741 new file mode 100644 index 000000000..64d3f1c15 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1748612 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1748612 new file mode 100644 index 000000000..3b01e0161 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1755 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1755 new file mode 100644 index 000000000..09f12d8e8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1756519 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1756519 new file mode 100644 index 000000000..d6a31f730 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1761153 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1761153 new file mode 100644 index 000000000..7ca0da995 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1761153 @@ -0,0 +1,26 @@ + + + +qemu-user incorrect mmap for large files on 64bits host and 32bits executable. + +qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf. + +See attached test program `test_mmap.c`. + +``` +$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap +$ file test_mmap +test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped +$ uname -a +Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +$ qemu-i386 --version +qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ ./test_mmap +$ qemu-i386 test_mmap +Incorrect data 1 +``` + +Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c) + +The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1761535 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1761535 new file mode 100644 index 000000000..38a8d1bb9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1763 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1763 new file mode 100644 index 000000000..ed6bf63e6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1763536 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1763536 new file mode 100644 index 000000000..d18dcbccb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1765970 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1765970 new file mode 100644 index 000000000..627353f18 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1768 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1768 new file mode 100644 index 000000000..3b1bd6194 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1768246 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1768246 new file mode 100644 index 000000000..70b9b9230 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1770 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1770 new file mode 100644 index 000000000..7ba477592 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1770 @@ -0,0 +1,25 @@ + + + +Wrong unpacked structure for epoll_event on qemu-or1k (openrisc) +Description of problem: +When using cmake automoc, the process will infinite loop waiting for epoll_events. +Steps to reproduce: +1. Try to compile cmake with qt5 support +2. The build process will freeze when "Automatic MOC" is invoked +Additional information: +The problem is that or1k has a "packed" epoll_event structure, so it should be also packed in target_epoll_event structure. +Following the (very trivial) patch: +``` +--- qemu-20230327/linux-user/syscall_defs.h.orig 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h 2023-06-30 17:29:39.034322213 +0200 +@@ -2714,7 +2709,7 @@ + #define FUTEX_CMD_MASK ~(FUTEX_PRIVATE_FLAG | FUTEX_CLOCK_REALTIME) + + #ifdef CONFIG_EPOLL +-#if defined(TARGET_X86_64) ++#if defined(TARGET_X86_64) || defined(TARGET_OPENRISC) + #define TARGET_EPOLL_PACKED QEMU_PACKED + #else + #define TARGET_EPOLL_PACKED +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1773743 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1773743 new file mode 100644 index 000000000..d98167cc5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1774149 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1774149 new file mode 100644 index 000000000..55ffb3347 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1779634 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1779634 new file mode 100644 index 000000000..c2c447e8a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1779634 @@ -0,0 +1,38 @@ + + + +qemu-x86_64 on aarch64 reports "Synchronous External Abort" + +Purpose: to run x86_64 utilities on aarch64 platform (Intel/Dell network adapters' firmware upgrade tools) +System: aarch64 server platform, with ubuntu 16.04 (xenial) Linux 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:14:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux + +Reproduce: +1) build linux-user qemu-x86_64 static from source (tried both version 1.12.0 & 1.11.02) + ./configure --target-list=x86_64-linux-user --disable-system --static --enable-linux-user + +2) install the interpreter into binfmt_misc filesystem + $ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 + enabled + interpreter /usr/local/bin/qemu-x86_64 + flags: + offset 0 + magic 7f454c4602010100000000000000000002003e00 + mask fffffffffffefefcfffffffffffffffffeffffff + +3) packaging Intel/Dell upgrade utilities into docker images, I've published two on docker hub: + REPOSITORY TAG IMAGE ID CREATED SIZE + heyi/dellupdate latest 8e013f5511cd 6 hours ago 210MB + heyi/nvmupdate64e latest 9d2de9d0edaa 3 days ago 451MB + +4) run the docker container on aarch64 server platform: + docker run -it --privileged --network host --volume /usr/local/bin/qemu-x86_64:/usr/local/bin/qemu-x86_64 heyi/dellupdate:latest + +5) finally, within docker container run the upgrade tool: + # ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN + +Errors: in dmesg it reports excessive 'Synchronous External Abort': + +kernel: [242850.159893] Synchronous External Abort: synchronous external abort (0x92000610) at 0x0000000000429958 +kernel: [242850.169199] Unhandled fault: synchronous external abort (0x92000610) at 0x0000000000429958 + +thanks and best regards, Yi \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1791763 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1791763 new file mode 100644 index 000000000..75bb22faf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1791763 @@ -0,0 +1,16 @@ + + + +broken signal handling in nios2 user-mode emulation + +This bug is against the 3.0 release. + +It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. + +Some problems I've identified and tried to fix with the attached patch are: + +- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. + +- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. + +With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1793539 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1793539 new file mode 100644 index 000000000..9b541f405 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1796520 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1796520 new file mode 100644 index 000000000..73bbb8c49 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1796520 @@ -0,0 +1,39 @@ + + + +autogen crashes on qemu-sh4-user after 61dedf2af7 + +Running "autogen --help" crashes on qemu-sh4-user with: + +(sid-sh4-sbuild)root@nofan:/# autogen --help +Unhandled trap: 0x180 +pc=0xf64dd2de sr=0x00000000 pr=0xf63b9c74 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf61102a8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf64dd2a0 fpul=0x00000003 +r0=0xf6fc1320 r1=0x00000000 r2=0xffff5dc4 r3=0xf67bfb50 +r4=0xf6fc1230 r5=0xf6fc141c r6=0x000003ff r7=0x00000000 +r8=0x00000004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 +r12=0xf63e2258 r13=0xf63eae1c r14=0x00000804 r15=0xf6fc1220 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@nofan:/# + +Bi-secting found this commit to be the culprit: + +61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit +commit 61dedf2af79fb5866dc7a0f972093682f2185e17 +Author: Richard Henderson <email address hidden> +Date: Tue Jul 18 10:02:50 2017 -1000 + + target/sh4: Add missing FPSCR.PR == 0 checks + + Both frchg and fschg require PR == 0, otherwise undefined_operation. + + Reviewed-by: Aurelien Jarno <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target + +Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1798 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1798 new file mode 100644 index 000000000..4d67e4936 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1799200 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1799200 new file mode 100644 index 000000000..4048274d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1805 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1805 new file mode 100644 index 000000000..970804b2f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1807 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1807 new file mode 100644 index 000000000..aee76b466 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1807 @@ -0,0 +1,27 @@ + + + +sparc64 always segfaults doesn't work on Ubuntu 23.04 +Description of problem: +It segfaults when it tries to use 'printf' or 'puts' to print to the screen. +Steps to reproduce: +Do the following at the command line + +``` +$ sparc64-linux-gnu-g++ --version +sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0 +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. +$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp +$ sparc64-linux-gnu-g++ -o test test.cpp -static +$ qemu-sparc64-static --version +qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +$ qemu-sparc64-static ./test +Segmentation fault (core dumped) +$ qemu-sparc-static ./test +qemu-sparc-static: ./test: Invalid ELF image for this architecture +$ qemu-sparc32plus-static ./test +qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1808563 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1808563 new file mode 100644 index 000000000..c92c9e47d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1808563 @@ -0,0 +1,20 @@ + + + +Listing the contents of / lists QEMU_LD_PREFIX instead + +Seeing this in qemu-user version 3.1.0 + +Demo: +$ QEMU_LD_PREFIX=$(pwd)/usr/armv7a-cros-linux-gnueabi ../run/qemu-arm /tmp/coreutils --coreutils-prog=ls / +etc lib usr +$ ls / +boot etc lib lib64 lost+found mnt root sbin sys usr +bin dev export home lib32 net proc run tmp var +$ ls usr/armv7a-cros-linux-gnueabi +etc lib usr + +In strace, the openat for "/" is remapped to the directory specified in QEMU_LD_PREFIX: +[pid 5302] openat(AT_FDCWD, "/tmp/qemu/usr/armv7a-cros-linux-gnueabi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 + +As an aside, if I change the code to do chdir("/"); opendir("."); it works fine. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1808565 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1808565 new file mode 100644 index 000000000..e7558e3b6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1809546 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1809546 new file mode 100644 index 000000000..50b50bdd9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1812 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812 new file mode 100644 index 000000000..014e2dbf4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1812451 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812451 new file mode 100644 index 000000000..208d03c34 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812451 @@ -0,0 +1,17 @@ + + + +In windows host, tftp arbitrary file read vulnerability + +https://github.com/qemu/qemu/blob/master/slirp/tftp.c#L343 + + if (!strncmp(req_fname, "../", 3) || + req_fname[strlen(req_fname) - 1] == '/' || + strstr(req_fname, "/../")) { + tftp_send_error(spt, 2, "Access violation", tp); + return; + } + +There are file path check for not allowing escape tftp directory. +But, in windows, file path is separated by "\" backslash. +So, guest can read arbitrary file in Windows host. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812861 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812861 new file mode 100644 index 000000000..6acdc2c36 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1812861 @@ -0,0 +1,25 @@ + + + +QEMU in user-mode emulation mode crashes when the user program jumps to an invalid address + +Running this code: + +void (*func)() = 0x12345678; + +int main() +{ + func(); + return 0; +} + +Produces the following output: + +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +Segmentation fault + +The expected result is as follows: + +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:32b/output/runtime/1818483 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1818483 new file mode 100644 index 000000000..a05053f1c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1819 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1819 new file mode 100644 index 000000000..a1740d8e3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1824344 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1824344 new file mode 100644 index 000000000..de20fccdf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1824344 @@ -0,0 +1,48 @@ + + + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1829459 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1829459 new file mode 100644 index 000000000..850ebbedd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1829459 @@ -0,0 +1,38 @@ + + + +qemu seems to lack support for pid namespace. + +# Version + +qemu-4.0.0 + +# commands used to launch qemu-aarch64 in user mode. + +printf '%s\n' ':qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}" >/proc/sys/fs/binfmt_misc/register + +> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin +> sudo chroot $RPI /bin/ksh -l + +# host + +Gentoo Linux amd64 + +# Guest + +Gentoo Linux aarch64 + +# The problem that I have + +"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid argument". +"emerge" is Gentoo's package manager that compiles and installs packages. + +# How to reproduce the issue + +Execute + +unshare --pid -- echo hello world + +or + +python -c "import portage.process; portage.process.spawn(['echo', 'hello', 'world'], unshare_pid=True)" \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1830 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1830 new file mode 100644 index 000000000..27322faa2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1830 @@ -0,0 +1,29 @@ + + + +command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host +Description of problem: +The command hangs in the container, taking over the CPU: + +``` +$ docker run -it centos:7 +[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true & +[1] 74 +[root@42e655bf3d60 /]# 74: file=/usr/bin/true [0]; generating link map + +[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args + PID PPID ELAPSED TIME S COMMAND + 1 0 34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash + 74 1 03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so + 80 1 4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args +[root@42e655bf3d60 /]# +``` +Steps to reproduce: +1. Start container +2. Run `/lib64/ld-2.17.so --list /usr/bin/true` +Additional information: +1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario. +2. My team build environment has amd64 native architecture hardware. I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container. +3. My team builds several Linux images daily - about a dozen amd64 and eight arm64. This is the only image that's causing us this problem. +4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`. +5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1832353 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1832353 new file mode 100644 index 000000000..8840513fa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1832916 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1832916 new file mode 100644 index 000000000..fd8f7301e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1834496 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1834496 new file mode 100644 index 000000000..5d9767168 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1835693 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1835693 new file mode 100644 index 000000000..1ccfe9701 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1835839 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1835839 new file mode 100644 index 000000000..c863d3fa3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1836078 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1836078 new file mode 100644 index 000000000..506e6e585 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1836192 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1836192 new file mode 100644 index 000000000..935aefbc1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1836558 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1836558 new file mode 100644 index 000000000..3fc7acaf2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1840922 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1840922 new file mode 100644 index 000000000..79a8d0f3f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1854 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1854 new file mode 100644 index 000000000..fd165c9ee --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1854738 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1854738 new file mode 100644 index 000000000..b4fa75fd3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1854738 @@ -0,0 +1,31 @@ + + + +ppc doesn't support for mttcg but ppc64 supported + +Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for support +``` + ppc) + gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" + ;; + ppc64) + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64le) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64abi32) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + echo "TARGET_ABI32=y" >> $config_target_mak + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1857811 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1857811 new file mode 100644 index 000000000..929d55838 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1857811 @@ -0,0 +1,10 @@ + + + +qemu user static binary seems to lack support for network namespace. + +Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. + +Unable to configure loopback interface: Operation not supported + +If I disable emerge's network-sandbox which utilizes network namespace, the error disappears. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1860056 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1860056 new file mode 100644 index 000000000..441b6f4ad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1860056 @@ -0,0 +1,23 @@ + + + +mips binaries segfault + +Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host. + +Example: + + +$ cat mips/test/hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1860610 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1860610 new file mode 100644 index 000000000..aafd772cd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1862167 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1862167 new file mode 100644 index 000000000..512a54b7c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1862986 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1862986 new file mode 100644 index 000000000..354df31cc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1863445 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1863445 new file mode 100644 index 000000000..699fc350e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1869073 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1869073 new file mode 100644 index 000000000..37f73332e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1870477 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1870477 new file mode 100644 index 000000000..bc0c353b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1870477 @@ -0,0 +1,36 @@ + + + +qemu-arm hangs when golang running test + + +1. Environment: +Ubuntu 16.04.5 X86_64 +qemu-arm version 4.2.0 +go version go 1.14.1 linux/arm + +2. Summary: +Sometimes "go run test.go" command hang + + +3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500 + + +test.go +====================================== +package main +import "fmt" +func main(){ + for i:=0; i<1000; i++ { + fmt.Printf("[%d] Hello world\n", i) + } +} +====================================== + +i tested "go run test.go" command called 500 times at qemu arm env. +qemu hangs about 200~300. + +attached strace log. + +please check. +thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1878501 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1878501 new file mode 100644 index 000000000..960a09162 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1880225 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1880225 new file mode 100644 index 000000000..8223b6071 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1880332 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1880332 new file mode 100644 index 000000000..7bbdf9749 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1880722 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1880722 new file mode 100644 index 000000000..c4c29c70e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1883784 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1883784 new file mode 100644 index 000000000..1f5853f84 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1883784 @@ -0,0 +1,12 @@ + + + +[ppc64le] qemu behavior differs from ppc64le hardware + +I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing). + +I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu. + +I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked). They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value). + +Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1885350 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1885350 new file mode 100644 index 000000000..c4b1be6a4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1885350 @@ -0,0 +1,26 @@ + + + +RISCV dynamic rounding mode is not behaving correctly + +Hello, + +I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. + +So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. + +static void gen_set_rm(DisasContext *ctx, int rm) +{ + TCGv_i32 t0; + if (ctx->frm == rm) { + return; + } + ctx->frm = rm; + t0 = tcg_const_i32(rm); + gen_helper_set_rounding_mode(cpu_env, t0); + tcg_temp_free_i32(t0); +} + + +My testcase: +I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1886097 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1886097 new file mode 100644 index 000000000..01677e722 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1886097 @@ -0,0 +1,36 @@ + + + +Error in user-mode calculation of ELF program's brk + +There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 + PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +The call to set_brk in Linux's binfmt_elf.c receives these arguments: + + set_brk(0xa3160, 0xa3160, 1) + +Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). + +I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is + + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + +which overlaps with the TLS segment: + + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + +However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1887306 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1887306 new file mode 100644 index 000000000..63e2ebc02 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1887306 @@ -0,0 +1,58 @@ + + + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1888303 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1888303 new file mode 100644 index 000000000..a6c3d6e8c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1888728 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1888728 new file mode 100644 index 000000000..68b6cce83 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1889411 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1889411 new file mode 100644 index 000000000..fae0a1013 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1890 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1890 new file mode 100644 index 000000000..bacc2dcb4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1892081 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1892081 new file mode 100644 index 000000000..2410ef983 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1892081 @@ -0,0 +1,17 @@ + + + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions + +Attached below is a matrix multiplication program for double data +types. The program performs the casting operation "(double)rand()" +when generating random numbers. + +This operation calls the integer to float softfloat conversion +function "int32_to_float_64". + +Adding the "QEMU_FLATTEN" attribute to the function definition +decreases the instructions per call of the function by about 63%. + +Attached are before and after performance screenshots from +KCachegrind. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1894029 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1894029 new file mode 100644 index 000000000..dbb691fe3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1895 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895 new file mode 100644 index 000000000..bfa89de85 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895 @@ -0,0 +1,149 @@ + + + +qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash +Description of problem: +When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards. + +We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise. +Steps to reproduce: +1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment +2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U` +3. Install gcc inside the container: `sudo pacman -Syu gcc` +4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i) +5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus` +Additional information: +Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware. + +g++ version: g++ (GCC) 13.2.1 20230801 + +testcase.i: + +```c++ +namespace std { +typedef long unsigned size_t; +inline namespace __cxx11 {} +} // namespace std +typedef char uint8_t; +namespace std { +template <typename _Default, typename, template <typename> class> +struct __detector { + using type = _Default; +}; +template <typename _Default, template <typename> class _Op> +using __detected_or = __detector<_Default, void, _Op>; +template <typename _Default, template <typename> class _Op> +using __detected_or_t = typename __detected_or<_Default, _Op>::type; +template <typename> class allocator; +namespace __cxx11 { +template <typename _CharT, typename = _CharT, typename = allocator<_CharT>> +class basic_string; +} +typedef basic_string<char> string; +} // namespace std +template <typename _Tp> class __new_allocator { +public: + typedef _Tp value_type; +}; +namespace std { +template <typename _Tp> using __allocator_base = __new_allocator<_Tp>; +template <typename _Tp> class allocator : public __allocator_base<_Tp> {}; +template <class _E> class initializer_list { + typedef size_t size_type; + typedef _E *iterator; + iterator _M_array; + size_type _M_len; +}; +struct __allocator_traits_base { + template <typename _Tp> using __pointer = typename _Tp::const_pointer; +}; +template <typename _Alloc> struct allocator_traits : __allocator_traits_base { + typedef typename _Alloc::value_type value_type; + using pointer = __detected_or_t<value_type, __pointer>; +}; +} // namespace std +namespace __gnu_cxx { +template <typename _Alloc> +struct __alloc_traits : std::allocator_traits<_Alloc> {}; +} // namespace __gnu_cxx +namespace std { +namespace __cxx11 { +template <typename _CharT, typename, typename _Alloc> class basic_string { + typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits; + +public: + typedef typename _Alloc_traits::pointer pointer; + struct _Alloc_hider { + _Alloc_hider(pointer, _Alloc); + } _M_dataplus; + pointer _M_local_data(); + basic_string(_CharT *, _Alloc __a = _Alloc()) + : _M_dataplus(_M_local_data(), __a) {} + ~basic_string(); +}; +} // namespace __cxx11 +} // namespace std +namespace v8 { +class StartupData {}; +} // namespace v8 +namespace std { +template <typename _Tp> class vector { +public: + typedef _Tp value_type; + vector(initializer_list<value_type>); +}; +namespace builtins { +struct CodeCacheInfo { + string id; + vector<uint8_t> data; +}; +} // namespace builtins +struct IsolateDataSerializeInfo {}; +struct EnvSerializeInfo {}; +struct SnapshotMetadata { + enum { kDefault } type; + string node_version; + string node_arch; + string v8_cache_version_tag; +}; +struct SnapshotData { + enum { kNotOwned } data_ownership; + SnapshotMetadata metadata; + v8::StartupData v8_snapshot_blob_data; + IsolateDataSerializeInfo isolate_data_info; + EnvSerializeInfo env_info; + vector<builtins::CodeCacheInfo> code_cache; +} snapshot_data{ + SnapshotData::kNotOwned, + SnapshotMetadata::kDefault, + "", + "", + "", + {}, + {}, + {}, + {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}}; +} // namespace std +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895080 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895080 new file mode 100644 index 000000000..eb26fb5fc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1895305 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895305 new file mode 100644 index 000000000..7776d39c2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1895703 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1895703 new file mode 100644 index 000000000..d32f52a0b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1906536 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1906536 new file mode 100644 index 000000000..ce49bf0bc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1907817 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1907817 new file mode 100644 index 000000000..dc04f7b7f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1907969 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1907969 new file mode 100644 index 000000000..58e7ba57a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1907969 @@ -0,0 +1,61 @@ + + + +linux-user/i386: Segfault when mixing threads and signals + +Given the following C program, qemu-i386 will surely and certainly segfault when executing it. +The problem is only noticeable if the program is statically linked to musl's libc and, as written +in the title, it only manifests when targeting i386. + +Removing the pthread calls or the second raise() makes it not segfault. + +The crash is in some part of the TCG-generated code, right when it tries to perform a +%gs-relative access. + +If you want a quick way of cross-compiling this binary: + +* Download a copy of the Zig compiler from https://ziglang.org/download/ +* Compile it with + `zig cc -target i386-linux-musl <C-FILE> -o <OUT>` + +``` +#include <pthread.h> +#include <signal.h> +#include <stdio.h> +#include <string.h> +#include <sys/types.h> +#include <unistd.h> +#include <asm/prctl.h> +#include <sys/syscall.h> + +void sig_func(int sig) +{ + write(1, "hi!\n", strlen("hi!\n")); +} + +void func(void *p) { } + +typedef void *(*F)(void *); + +int main() +{ + pthread_t tid; + + struct sigaction action; + action.sa_flags = 0; + action.sa_handler = sig_func; + + if (sigaction(SIGUSR1, &action, NULL) == -1) { + return 1; + } + + // This works. + raise(SIGUSR1); + + pthread_create(&tid, NULL, (F)func, NULL); + pthread_join(tid, NULL); + + // This makes qemu segfault. + raise(SIGUSR1); +} +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1908551 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1908551 new file mode 100644 index 000000000..42a66cbf9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1909921 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1909921 new file mode 100644 index 000000000..ed041b772 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1910605 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1910605 new file mode 100644 index 000000000..1b4342cfe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1910605 @@ -0,0 +1,19 @@ + + + +qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address + + + +Snippet of code sample: + +struct usbdevfs_bulktransfer Bulk; +Bulk.ep = hUsb->UsbOut; +Bulk.len = Len; +Bulk.data = (void *)pData; +Bulk.timeout = Timeout; +Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, &Bulk) + +The above code sample return -1 (EFAULT) Bad address when using qemu-arm-static but is running ok when on qemu-aarch64-static. + +I use a 64-bit intel laptop \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1913 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1913 new file mode 100644 index 000000000..155199be1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1914870 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1914870 new file mode 100644 index 000000000..9a7c055ba --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1915531 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1915531 new file mode 100644 index 000000000..dc0a16e53 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1915925 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1915925 new file mode 100644 index 000000000..dd9f8600c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1915925 @@ -0,0 +1,20 @@ + + + +ARM semihosting HEAPINFO results wrote to wrong address + +This affects latest development branch of QEMU. + +According to the ARM spec of the HEAPINFO semihosting call: + +https://developer.arm.com/documentation/100863/0300/Semihosting-operations/SYS-HEAPINFO--0x16-?lang=en + +> the PARAMETER REGISTER contains the address of a pointer to a four-field data block. + +However, QEMU treated the PARAMETER REGISTER as pointing to a four-field data block directly. + +Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting-newlib + +This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. + +Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1916344 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1916344 new file mode 100644 index 000000000..5d13405ec --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1917184 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1917184 new file mode 100644 index 000000000..f7314da81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1927530 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1927530 new file mode 100644 index 000000000..605bf2ed4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1927530 @@ -0,0 +1,42 @@ + + + +qemu-aarch64 MTE fails to report tag mismatch + +Hi, + +While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). + +I am attaching: +bitfield-2.exe +ld-linux-aarch64.so.1 +libc.so.6 +libdl.so.2 +libhwasan.so.0 +libm.so.6 +libpthread.so.0 +librt.so.1 + +The testcase can be executed via: +qemu-aarch64 -L . bitfield-2.exe + +it currently generates: +HWAddressSanitizer:DEADLYSIGNAL +==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 (pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137) +==21137==The signal is caused by a UNKNOWN memory access. +==21137==Hint: address points to the zero page. + #0 0x550084e318 in GetAccessInfo /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 + #1 0x550084e318 in HwasanOnSIGTRAP /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401 + #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426 + #3 0x5f01651fec (<unknown module>) + #4 0x550084b508 in __hwasan_load2 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379 + #5 0x400768 in f /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17 + #6 0x4007d0 in main /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24 + #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308 + #8 0x400688 (/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688) + +HWAddressSanitizer can not provide additional info. +SUMMARY: HWAddressSanitizer: SEGV /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 in GetAccessInfo +==21146==ABORTING + +while the testcase expects HWAddressSanitizer: tag-mismatch on address 0x..... \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1930 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1930 new file mode 100644 index 000000000..65a18ca72 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1936977 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1936977 new file mode 100644 index 000000000..50182117e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1952 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1952 new file mode 100644 index 000000000..b08e13127 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/1953 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/1953 new file mode 100644 index 000000000..700d78cdc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2027 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2027 new file mode 100644 index 000000000..f9fb7e78f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2035 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2035 new file mode 100644 index 000000000..11a2bf388 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2082 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2082 new file mode 100644 index 000000000..33b0f7a9e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2119 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2119 new file mode 100644 index 000000000..c2d7b188c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2122 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2122 new file mode 100644 index 000000000..859d184f7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2122 @@ -0,0 +1,10 @@ + + + +qemu-user-static segfault running ldconfig on host x86_64 with client arm64 +Description of problem: +qemu segfault +Steps to reproduce: +1. download ubuntu jammy arm64 rootfs (I assume any will do) +2. mount it (with /proc from host so apt is happy) +3. execute an apt uninstall that triggers libc-bin processing diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2127 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2127 new file mode 100644 index 000000000..083ec4b35 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2156 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2156 new file mode 100644 index 000000000..4e1504dae --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2157 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2157 new file mode 100644 index 000000000..0223b0aaf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2170 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2170 new file mode 100644 index 000000000..a82ba2bbc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2170 @@ -0,0 +1,47 @@ + + + +qemu-x86_64 crashes when the application calls pthread_getattr_np() +Description of problem: +QEMU user emulation crashes with this program: +``` +#define _GNU_SOURCE +#include <stdio.h> +#include <pthread.h> + +int main() +{ + pthread_attr_t attr; + int error = pthread_getattr_np(pthread_self(), &attr); + + printf("%d\n", error); + return 0; +} +``` +Steps to reproduce: +1. Compile the program above +2. Run QEMU +Additional information: +QEMU crashes with: +``` +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault (core dumped) + +``` + +In gdb I get this backtrace: +``` +#0 0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381 +#5 0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658 +#7 0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012 + +``` + +This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb. +The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2208 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2208 new file mode 100644 index 000000000..aceb5eff3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2223 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2223 new file mode 100644 index 000000000..3331178e4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2262 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2262 new file mode 100644 index 000000000..31e8cc135 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2262 @@ -0,0 +1,202 @@ + + + +linux-user riscv32: wait4/waitpid returns wrong value +Description of problem: +Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely. + +strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. +Steps to reproduce: +1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it. +2. run `sleep 1000 &` +3. run `ls` +4. infinite hangs + +I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed. + +<details><summary>simple_shell.c</summary> + +``` +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <string.h> +#include <sys/wait.h> +#include <signal.h> + +#define MAX_LINE 80 /* The maximum length command */ + +#define BACKGROUND 0 +#define FOREGROUND 1 + +struct Job { + pid_t pid; + char command[MAX_LINE]; + int state; // 0 for background, 1 for foreground +}; + +struct Job jobs[10]; // Maximum 10 background jobs +int num_jobs = 0; + +void handle_signal(int signum) { + // Do nothing for now +} + +int launch_process(char **args, int state) { + pid_t pid; + int status; + + pid = fork(); + if (pid == 0) { + // Child process + if (execvp(args[0], args) == -1) { + perror("Error in execvp"); + exit(EXIT_FAILURE); + } + } else if (pid < 0) { + // Error forking + perror("Error forking"); + } else { + // Parent process + if (state == FOREGROUND) { + // Wait for the child process to finish if it's foreground + do { + wait4(pid, &status, WUNTRACED, NULL); + } while (!WIFEXITED(status) && !WIFSIGNALED(status)); + } else { + // Background process, add to jobs list + jobs[num_jobs].pid = pid; + strcpy(jobs[num_jobs].command, args[0]); + jobs[num_jobs].state = BACKGROUND; + num_jobs++; + } + } + return 1; +} + +void bg_command(int job_number) { + // Send SIGCONT signal to a background job + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = BACKGROUND; + } +} + +void fg_command(int job_number) { + // Bring a background job to foreground + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = FOREGROUND; + int status; + wait4(jobs[job_number].pid, &status, WUNTRACED, NULL); + } +} + +int main(void) { + char *args[MAX_LINE/2 + 1]; /* command line arguments */ + int should_run = 1; /* flag to determine when to exit program */ + char command[MAX_LINE]; /* buffer to hold the command */ + char *token; /* token for parsing the command */ + + signal(SIGINT, handle_signal); /* Ignore SIGINT for now */ + signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */ + + while (should_run) { + printf("Shell> "); + fflush(stdout); + fgets(command, MAX_LINE, stdin); /* read command from stdin */ + command[strcspn(command, "\n")] = '\0'; /* remove newline character */ + + if (strcmp(command, "exit") == 0) { + should_run = 0; /* exit the shell */ + continue; + } + + if (strcmp(command, "") == 0) { + continue; /* skip empty commands */ + } + + if (strcmp(command, "cd") == 0) { + char *home = getenv("HOME"); + chdir(home); + continue; + } + + if (strcmp(command, "bg") == 0) { + // Run the most recent background job in the background + bg_command(num_jobs - 1); + continue; + } + + if (strcmp(command, "fg") == 0) { + // Bring the most recent background job to foreground + fg_command(num_jobs - 1); + continue; + } + + token = strtok(command, " "); + int i = 0; + while (token != NULL) { + args[i] = token; + token = strtok(NULL, " "); + i++; + } + args[i] = NULL; + + if (strcmp(args[i-1], "&") == 0) { + args[i-1] = NULL; + launch_process(args, BACKGROUND); + } else { + launch_process(args, FOREGROUND); + } + + pid_t tmp; + // Check if any background jobs have finished + for (int j = 0; j < num_jobs; j++) { + if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) { + printf("[%d] Done\t%s\n", j, jobs[j].command); + // Remove job from list + for (int k = j; k < num_jobs - 1; k++) { + jobs[k] = jobs[k + 1]; + } + num_jobs--; + } + printf("wait4 ret: %d\n", tmp); + } + } + return 0; +} +``` + +</details> + +<details><summary>loop.c</summary> +int main() {while(1){}} +</details> + +1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32` +2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop` +3. run shell with qemu user +``` +qemu-user-riscv32 ./shell_riscv32 +shell> ./loop & +[0] Done ./sleep_riscv32 +wait4 ret: 98298 +``` +where it is supposed to return 0 on riscv64 or x86 +Additional information: +More context: +This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats, +``` +waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +waitid(P_ALL, -1, ^Cstrace: Process 237805 detached +``` +It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2304 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2304 new file mode 100644 index 000000000..98b4e73d0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2309 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2309 new file mode 100644 index 000000000..41394ee53 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2336 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2336 new file mode 100644 index 000000000..52e60fc62 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2336 @@ -0,0 +1,26 @@ + + + +qemu-x86_64 crash on LoongArch +Description of problem: + +Steps to reproduce: +1. build a static hello test on x86_64 machine. +2. build qemu-x86_64 on LoongArch. +3. run 'qemu-x86_64 hello 'on LoongArch. +Additional information: +1 result + +[root@localhost qemu]# ./build/qemu-x86_64 ~/hello +Bus error (core dumped) + +2 Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 + +3 full log with -d in_asm,op,out_asm,strace +see log.txt + +[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt) + +[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64) + +[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2353 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2353 new file mode 100644 index 000000000..38d8490e4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2353 @@ -0,0 +1,59 @@ + + + +linux-user: may map interpreter at address 0 with nonzero guest_base +Description of problem: +QEMU's user-mode emulation will, under certain conditions, map the ELF interpreter at guest address 0. This is not only a violation of Linux's policy never to map anything at the first page of any virtual address space, but also a cause of confusion (and segfaults) within certain libcs; though I only tested with musl. Musl [interprets a NULL base address](https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dlstart.c#L105) as the dynamic linker being invoked directly, causing it to compute its base address incorrectly. + +The problem arises in `load_elf_image()`, which chooses a `load_addr` of 0 for the ELF interpreter (i.e. the musl dynamic loader). This is passed to `target_mmap()`. I do not know whether `target_mmap()` is meant to follow the POSIX rule that (in absence of `MAP_FIXED`) "All implementations interpret an *addr* value of 0 as granting the implementation complete freedom in selecting *pa*" or if 0 is requesting 0. + +QEMU's usermode mmap() implementation translates the guest address to a host address (this is effectively a no-op with `guest_base == 0`) and passes it along to the host Linux. This means that, when `guest_base == 0`, a NULL input address means "put it anywhere," but when `guest_base != 0`, NULL means "put it at (guest address) 0." +Steps to reproduce: +1. Download a rootfs of Alpine Linux AArch64. +2. Install `gcc` (with `apk add gcc`) in the rootfs. `gcc` is not compiled as PIC, making QEMU use a nonzero `guest_base`. +3. Attempt to run `gcc` within the rootfs via QEMU. +Additional information: +I am interested in submitting a MR that fixes this issue, but I do not know which of 4 possible solutions is preferred: + +1. Modify `load_elf_image()` to ensure that `load_addr` is never NULL. +2. Modify `target_mmap()` so that NULLs are passed to the kernel as NULLs. +3. Modify the guest<->host translation facilities (`g2h_untagged` et al) to translate NULL as NULL. Overwhelmingly, a NULL pointer semantically means "there is no pointer here" and not "a pointer to the zeroth address," so treating these as valid addresses in the translation functions is arguably going against the grain. +4. When a nonzero `guest_base` is selected, reserve the first page of the guest VA space, so that the host kernel cannot accidentally put anything there. + +Here is my local patch that implements item 2 above, which indeed stops the segfaults for me: +<details><summary>Patch</summary> + +```diff +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index be3b9a6..dad29ef 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -559,7 +559,7 @@ static abi_long mmap_h_eq_g(abi_ulong start, abi_ulong len, + int host_prot, int flags, int page_flags, + int fd, off_t offset) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + abi_ulong last; + + p = mmap(want_p, len, host_prot, flags, fd, offset); +@@ -609,7 +609,7 @@ static abi_long mmap_h_lt_g(abi_ulong start, abi_ulong len, int host_prot, + int mmap_flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t fileend_adj = 0; + int flags = mmap_flags; + abi_ulong last, pass_last; +@@ -739,7 +739,7 @@ static abi_long mmap_h_gt_g(abi_ulong start, abi_ulong len, + int flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t host_offset = offset & -host_page_size; + abi_ulong last, real_start, real_last; + bool misaligned_offset = false; +``` +</details> diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2376 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2376 new file mode 100644 index 000000000..2f1d3c564 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2376 @@ -0,0 +1,117 @@ + + + +A bug in ARM VCMLA.f16/VCMLA.f32 instructions +Description of problem: +The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. + +The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: +``` +// target/arm/tcg/vec_helper.c +void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float16 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float16); + intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; + intptr_t i, j; + + ... +} + +... + +void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float32 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float32); + intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; + intptr_t i, j; + + ... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +// zero inputs should produce zero output +char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched +char o_D30[8]; +char o_D31[8]; + +void __attribute__ ((noinline)) show_state() { + printf("D30: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D30[i]); + } + printf("\n"); + printf("D31: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D31[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "movw r7, #:lower16:i_D4\n" + "movt r7, #:upper16:i_D4\n" + "vldr d4, [r7]\n" + "movw r7, #:lower16:i_D8\n" + "movt r7, #:upper16:i_D8\n" + "vldr d8, [r7]\n" + "movw r7, #:lower16:i_D30\n" + "movt r7, #:upper16:i_D30\n" + "vldr d30, [r7]\n" + "movw r7, #:lower16:i_D31\n" + "movt r7, #:upper16:i_D31\n" + "vldr d31, [r7]\n" + "adr r7, Lbl_thumb + 1\n" + "bx r7\n" + ".thumb\n" + "Lbl_thumb:\n" + ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 + "adr r7, Lbl_arm\n" + "bx r7\n" + ".arm\n" + "Lbl_arm:\n" + "movw r7, #:lower16:o_D30\n" + "movt r7, #:upper16:o_D30\n" + "vstr d30, [r7]\n" + "movw r7, #:lower16:o_D31\n" + "movt r7, #:upper16:o_D31\n" + "vstr d31, [r7]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2448 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2448 new file mode 100644 index 000000000..ba65ac929 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2448 @@ -0,0 +1,49 @@ + + + +linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin +Description of problem: +When a `*-linux-user` is used as binfmt_misc, and... + +- The `O` (i.e. open-binary) flag is set +- File descriptor 0 is closed when running the executable + +FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable. + +Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior. +Steps to reproduce: +1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary) +2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`) +3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output) + +The correct behavior is (You can see by running the native `cat <&-`): + +``` +cat: -: Bad file descriptor +cat: closing standard input: Bad file descriptor +``` + +Instead, the executable `cat` itself is dumped to stdout. + +Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable. +Additional information: +I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far: + +In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765) + +```c + execfd = qemu_getauxval(AT_EXECFD); + if (execfd == 0) { + execfd = open(exec_path, O_RDONLY); + if (execfd < 0) { + printf("Error while loading %s: %s\n", exec_path, strerror(errno)); + _exit(EXIT_FAILURE); + } + } +``` + +However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value. + +`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`. + +Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay? diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2460 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2460 new file mode 100644 index 000000000..19cfd6dc9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2486 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2486 new file mode 100644 index 000000000..6cd7e0640 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2505 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2505 new file mode 100644 index 000000000..3eaa737f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2505 @@ -0,0 +1,4 @@ + + + +Interpreter ELF flags ignored when selecting CPU diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2525 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2525 new file mode 100644 index 000000000..5ba0def18 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2560 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2560 new file mode 100644 index 000000000..9fb270f27 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2560 @@ -0,0 +1,108 @@ + + + +Go garbage collector crashes when using qemu-x86_64 on an aarch64 host +Description of problem: +Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something? + +The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`. + +Output from Go when it crashes: + +``` +$ sudo chroot . go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0xa95b29?, 0x797b1e2a383c?}) + runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c +runtime.(*lfstack).push(0x0?, 0xc0005041c0?) + runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45 +runtime.(*spanSetBlockAlloc).free(...) + runtime/mspanset.go:322 +runtime.(*spanSet).reset(0xf46980) + runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219 +runtime.finishsweep_m() + runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd +runtime.gcStart.func2() + runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f +runtime.systemstack(0x0) + runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a +```` +Steps to reproduce: +0. Use an aarch64 host system! + +1. Set up binfmt to use qemu-x86_64: + +``` +$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 +enabled +interpreter /usr/bin/qemu-x86_64 +flags: OCF +offset 0 +magic 7f454c4602010100000000000000000002003e00 +mask fffffffffffefe00fffffffffffffffffeffffff +``` + +2. Download/extract x86_64 rootfs: + +``` +$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz +``` + +3. Create example app in the x86_64 rootfs: + +``` +package main + +func main() { +} +``` + +4. Build using chroot: + +``` +$ sudo chroot /path/to/x86_64/rootfs apk add go +$ sudo chroot /path/to/x86_64/rootfs go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push +... +``` + +5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU: + +``` +$ sudo chroot . env GOGC=off go build main.go +# might have to mount /dev to build successfully, but Go doesn't panic! +``` +Additional information: +I've bisected this exact crash/failure to: + +``` +commit 2952b642a555207748dd961fcbfdc48f198eebb6 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Feb 13 10:20:27 2024 -1000 + + linux-user: Split out do_munmap + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +Though a different crash starts happening at the commit before that one: + +``` +commit ad87d26e6bb13257409f412224c862fc54025e8b +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jan 2 12:57:55 2024 +1100 + + linux-user: Do early mmap placement only for reserved_va + + For reserved_va, place all non-fixed maps then proceed + as for MAP_FIXED. + + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +FYI @rth7680 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2580 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2580 new file mode 100644 index 000000000..cdc12b610 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2590 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2590 new file mode 100644 index 000000000..94fcd1b86 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2596 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2596 new file mode 100644 index 000000000..153a9d456 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2598 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2598 new file mode 100644 index 000000000..0a978ad07 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2606 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2606 new file mode 100644 index 000000000..060630676 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2606 @@ -0,0 +1,201 @@ + + + +PowerPC host code is broken on Darwin +Description of problem: +Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. +Steps to reproduce: +1. Run the build of qemu on Darwin ppc, see it fail. +Additional information: +This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): +``` +--- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 +@@ -25,17 +25,11 @@ + # else + # error "Unknown ABI" + # endif +-#endif +- +-#ifndef _CALL_SYSV +-# error "Unsupported ABI" + #endif + +- + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -47,11 +41,8 @@ + * arguments being syscall arguments (also 'long'). + */ + safe_syscall_base: +- .cfi_startproc +- stwu 1, -8(1) +- .cfi_def_cfa_offset 8 +- stw 30, 4(1) +- .cfi_offset 30, -4 ++ stwu r1, -8(r1) ++ stw r30, 4(r1) + + /* + * We enter with r3 == &signal_pending +@@ -64,14 +55,14 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- mr 30, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ mr r30, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* + * This next sequence of code works in conjunction with the +@@ -83,25 +74,22 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(30) +- cmpwi 0, 12, 0 ++ lwz r12, 0(r30) ++ cmpwi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- lwz 30, 4(1) /* restore r30 */ +- addi 1, 1, 8 /* restore stack */ +- .cfi_restore 30 +- .cfi_def_cfa_offset 0 ++ lwz r30, 4(r1) /* restore r30 */ ++ addi r1, r1, 8 /* restore stack */ ++ + bnslr+ /* return on success */ + b safe_syscall_set_errno_tail + + /* code path when we didn't execute the syscall */ +-2: lwz 30, 4(1) +- addi 1, 1, 8 +- addi 3, 0, QEMU_ERESTARTSYS ++2: lwz r30, 4(r1) ++ addi r1, r1, 8 ++ addi r3, 0, QEMU_ERESTARTSYS + b safe_syscall_set_errno_tail + +- .cfi_endproc +- + .size safe_syscall_base, .-safe_syscall_base + + +--- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 +@@ -13,7 +13,6 @@ + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -23,19 +22,10 @@ + * second one the system call number (as a 'long'), and all further + * arguments being syscall arguments (also 'long'). + */ +-#if _CALL_ELF == 2 +-safe_syscall_base: +- .cfi_startproc +- .localentry safe_syscall_base,0 +-#else +- .section ".opd","aw" ++ + .align 3 + safe_syscall_base: +- .quad .L.safe_syscall_base,.TOC.@tocbase,0 +- .previous +-.L.safe_syscall_base: +- .cfi_startproc +-#endif ++ + /* We enter with r3 == &signal_pending + * r4 == syscall number + * r5 ... r10 == syscall arguments +@@ -46,16 +36,15 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- std 14, 16(1) /* Preserve r14 in SP+16 */ +- .cfi_offset 14, 16 +- mr 14, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ std r14, 16(r1) /* Preserve r14 in SP+16 */ ++ mr r14, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* This next sequence of code works in conjunction with the + * rewind_if_safe_syscall_function(). If a signal is taken +@@ -66,29 +55,20 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(14) +- cmpwi 0, 12, 0 ++ ld r12, 0(r14) ++ cmpdi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- ld 14, 16(1) /* restore r14 */ ++ ld r14, 16(r1) /* restore r14 */ + bso- 1f + blr + + /* code path when we didn't execute the syscall */ +-2: ld 14, 16(1) /* restore r14 */ +- addi 3, 0, QEMU_ERESTARTSYS ++2: ld r14, 16(r1) /* restore r14 */ ++ addi r3, 0, QEMU_ERESTARTSYS + + /* code path setting errno */ + 1: b safe_syscall_set_errno_tail + nop /* per abi, for the linker to modify */ +- +- .cfi_endproc +- +-#if _CALL_ELF == 2 +- .size safe_syscall_base, .-safe_syscall_base +-#else +- .size safe_syscall_base, .-.L.safe_syscall_base +- .size .L.safe_syscall_base, .-.L.safe_syscall_base +-#endif +``` +(Obviously, it is not made in a portable way – that was not needed at the time.) + +Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/261 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/261 new file mode 100644 index 000000000..5e5ce90d0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/261 @@ -0,0 +1,4 @@ + + + +broken signal handling in nios2 user-mode emulation diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2619 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2619 new file mode 100644 index 000000000..785f38446 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2619 @@ -0,0 +1,4 @@ + + + +INTEGER_OVERFLOW in nios2.c diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2628 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2628 new file mode 100644 index 000000000..3a92fac0e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2632 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2632 new file mode 100644 index 000000000..32006cbc2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2632 @@ -0,0 +1,86 @@ + + + +tcg optimization breaking memory access ordering +Description of problem: +The following code creates register dependency between 2 loads, which forces the first load to finish before the second: +``` +movz w0, #0x2 +str w0, [x1] +ldr w2, [x1] +eor w3, w2, w2 +ldr w4, [x5, w3, sxtw] +``` + +While translating it to tcg IR, it keeps this dependency correctly. +But after running tcg optimizations, it optimized the tcg sequence for `eor w3, w2, w2` at `0000000000000144` to `mov_i64 x3,$0x0`. which then removes the dependency between the loads. + +It results in incorrect behavior on the host on a multiple threaded program +Steps to reproduce: +1. +2. +3. +Additional information: +``` +OP: + ld_i32 loc0,env,$0xfffffffffffffff0 + brcond_i32 loc0,$0x0,lt,$L0 + st8_i32 $0x0,env,$0xfffffffffffffff4 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 + + ---- 000000000000013c 0000000000000000 0000000000001c00 + mov_i64 loc3,x1 + mov_i64 loc4,loc3 + qemu_st_a64_i64 x0,loc4,w16+un+leul,2 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + mov_i64 loc5,x1 + mov_i64 loc6,loc5 + qemu_ld_a64_i64 x2,loc6,w16+un+leul,2 + + ---- 0000000000000144 0000000000000000 0000000000000000 + and_i64 loc7,x2,$0xffffffff + xor_i64 x3,x2,loc7 + and_i64 x3,x3,$0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + mov_i64 loc9,x5 + mov_i64 loc10,x3 + ext32s_i64 loc10,loc10 + add_i64 loc9,loc9,loc10 + mov_i64 loc11,loc9 + qemu_ld_a64_i64 x4,loc11,w16+un+leul,2 + st8_i32 $0x1,env,$0xfffffffffffffff4 +``` + + +``` +OP after optimization and liveness analysis: + ld_i32 tmp0,env,$0xfffffffffffffff0 pref=0xffffffff + brcond_i32 tmp0,$0x0,lt,$L0 dead: 0 + st8_i32 $0x0,env,$0xfffffffffffffff4 dead: 0 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 sync: 0 dead: 0 pref=0xffffffff + + ---- 000000000000013c 0000000000000000 0000000000001c00 + qemu_st_a64_i64 $0x2,x1,w16+un+leul,2 dead: 0 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + qemu_ld_a64_i64 x2,x1,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000144 0000000000000000 0000000000000000 + mov_i64 x3,$0x0 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + qemu_ld_a64_i64 x4,x5,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + st8_i32 $0x1,env,$0xfffffffffffffff4 dead: 0 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2647 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2647 new file mode 100644 index 000000000..ac6622d86 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2647 @@ -0,0 +1,50 @@ + + + +A code error in accel/tcg/user-exec.c +Description of problem: +accel/tcg/user-exec.c: +``` +static int probe_access_internal(CPUArchState *env, vaddr addr, + int fault_size, MMUAccessType access_type, + bool nonfault, uintptr_t ra) +{ + int acc_flag; + bool maperr; + + switch (access_type) { + case MMU_DATA_STORE: + acc_flag = PAGE_WRITE_ORG; + break; + case MMU_DATA_LOAD: + acc_flag = PAGE_READ; + break; + case MMU_INST_FETCH: + acc_flag = PAGE_EXEC; + break; + default: + g_assert_not_reached(); + } + + if (guest_addr_valid_untagged(addr)) { + int page_flags = page_get_flags(addr); + if (page_flags & acc_flag) { + if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE) + && cpu_plugin_mem_cbs_enabled(env_cpu(env))) { + return TLB_MMIO; + } + return 0; /* success */ + } + maperr = !(page_flags & PAGE_VALID); + } else { + maperr = true; + } + + if (nonfault) { + return TLB_INVALID_MASK; + } + + cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra); +} +``` +The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2655 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2655 new file mode 100644 index 000000000..eb6ceccef --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2683 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2683 new file mode 100644 index 000000000..d39a01af4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/275 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/275 new file mode 100644 index 000000000..e7650ebec --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/275 @@ -0,0 +1,4 @@ + + + +Error in user-mode calculation of ELF aux vector's AT_PHDR diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/276 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/276 new file mode 100644 index 000000000..b44725302 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/276 @@ -0,0 +1,4 @@ + + + +Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2761 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2761 new file mode 100644 index 000000000..83689da66 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/280 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/280 new file mode 100644 index 000000000..a52d19ece --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2815 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2815 new file mode 100644 index 000000000..4236102b4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/2846 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/2846 new file mode 100644 index 000000000..e2a6268f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/306 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/306 new file mode 100644 index 000000000..200c62a2d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/306 @@ -0,0 +1,4 @@ + + + +Option to constrain linux-user exec() to emulated CPU only diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/311 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/311 new file mode 100644 index 000000000..ff15261db --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/324 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/324 new file mode 100644 index 000000000..fe76e37d9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/326 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/326 new file mode 100644 index 000000000..f635a6102 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/326 @@ -0,0 +1,4 @@ + + + +QEMU-user ignores MADV_DONTNEED diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/355 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/355 new file mode 100644 index 000000000..8286c0d0f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/356 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/356 new file mode 100644 index 000000000..a9e926b76 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/356 @@ -0,0 +1,4 @@ + + + +qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/385 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/385 new file mode 100644 index 000000000..1b07af179 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/385 @@ -0,0 +1,4 @@ + + + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/419 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/419 new file mode 100644 index 000000000..f9d5b396d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/419 @@ -0,0 +1,4 @@ + + + +bsd-user dumps core for all binaries emulated diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/442 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/442 new file mode 100644 index 000000000..ea8a9a235 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/447 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/447 new file mode 100644 index 000000000..ab1490919 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/562107 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/562107 new file mode 100644 index 000000000..89ee18571 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/570 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/570 new file mode 100644 index 000000000..325d5ea7a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/570 @@ -0,0 +1,4 @@ + + + +linux-user/sh4/termbits.h:276: warning: "TIOCSER_TEMT" redefined diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/602 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/602 new file mode 100644 index 000000000..05132daf5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/602 @@ -0,0 +1,16 @@ + + + +Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation +Description of problem: +In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. +Steps to reproduce: +1. https://cirrus-ci.com/task/5914289870471168 +Additional information: +The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). + +The fix is something like: + +``` +__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/616 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/616 new file mode 100644 index 000000000..3aa0af141 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/616 @@ -0,0 +1,110 @@ + + + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/618 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/618 new file mode 100644 index 000000000..eaab679ff --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/618 @@ -0,0 +1,98 @@ + + + +overflow condition code determined incorrectly after subtraction on s390x +Description of problem: +Paul Eggert found this bug, just by taking a look at the file `qemu/target/s390x/tcg/cc_helper.c`. + +The following program +[foo.c](/uploads/c1f425684fd661c4437950d7d8ddf31d/foo.c) +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int a1 = 0; +int b1 = -2147483648; +long long a2 = 0L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", ! overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", ! overflow_64 (a, b)); + } +} +``` +should print +``` +a = 0x0, b = 0x80000000 +no_overflow = 0 +a = 0x0, b = 0x8000000000000000 +no_overflow = 0 +``` +However, when compiled as an s390x program and executed through qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the 'o' (overflow / ones) condition code: +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + sgr %r1,%r3 ;; subtract b from a + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +The condition code and the overflow bit are defined in the z/Architecture Principles of Operation (POP) http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf page 7-5 / 7-6 / 7-388 : "In mathematical terms, signed addition and subtraction produce a fixed-point overflow when the result is outside the range of representation for signed binary integers." + +I conclude that the bug is in QEMU: QEMU does not set the overflow condition code correctly. +Steps to reproduce: +[foo.static.s390x](/uploads/e4b79b019db590f3a4b13cac41e57ba6/foo.static.s390x) +(the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +The attached patch fixes it. +[0002-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/8d414f84fe0ed36bf07bd28f5e7836ab/0002-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/633 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/633 new file mode 100644 index 000000000..efbea0762 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/633 @@ -0,0 +1,35 @@ + + + +i686-arm-user-static - Allocating guest commpage: Operation not permitted +Steps to reproduce: +1. Run the test case linked earlier. +2. You'll see `apt update` failing: + +``` +Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] +Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] +Err:1 http://archive.raspberrypi.org/debian buster InRelease + At least one invalid signature was encountered. +Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease + At least one invalid signature was encountered. +Reading package lists... Done +W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +``` +Additional information: +Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536). + +Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above. + +apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt) + +Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186 + +I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/654 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/654 new file mode 100644 index 000000000..33a64a50c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/654 @@ -0,0 +1,26 @@ + + + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/690 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/690 new file mode 100644 index 000000000..16e564043 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/690 @@ -0,0 +1,22 @@ + + + +32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. + +Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. + +The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: +``` +[0 ... 53248] - No error at all +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted +``` +Steps to reproduce: +1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) +2. `$ make # will build the docker container` +3. `$ make run # will enter the container` +4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` +Additional information: +A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/693 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/693 new file mode 100644 index 000000000..30224262f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/697 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/697 new file mode 100644 index 000000000..35cb85c47 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/698 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/698 new file mode 100644 index 000000000..358550753 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/704 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/704 new file mode 100644 index 000000000..25f043317 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/704 @@ -0,0 +1,4 @@ + + + +linux-user: misaligned address for type 'struct linux_dirent64' diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/754635 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/754635 new file mode 100644 index 000000000..84577858b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/796480 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/796480 new file mode 100644 index 000000000..3fe14f69e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/805 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/805 new file mode 100644 index 000000000..1d393a30d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/817 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/817 new file mode 100644 index 000000000..bb98d5237 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/817 @@ -0,0 +1,4 @@ + + + +linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/834 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/834 new file mode 100644 index 000000000..99ad9901b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/834 @@ -0,0 +1,62 @@ + + + +linux-user: fails to deliver signals raised during pselect +Description of problem: +When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`. + +Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/) +Steps to reproduce: +A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite). + +```C +#include <stdio.h> +#include <unistd.h> +#include <signal.h> +#include <sys/select.h> + +static void handler(int sig) +{ + puts("SIGNAL"); +} + +int main(int argc, char *argv[]) +{ + struct sigaction sa; + + fd_set rfds; + sigset_t emptyset, blockset; + + sigemptyset (&blockset); + sigemptyset (&emptyset); + sigaddset (&blockset, SIGUSR1); + + sa.sa_handler = handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sigaction(SIGUSR1, &sa, NULL); + + sigprocmask (SIG_BLOCK, &blockset, NULL); + + FD_ZERO(&rfds); + + while(1) { + pselect(0, &rfds, NULL, NULL, NULL, &emptyset); + } + + return 0; +} +``` + +Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`: + +``` +$ ./a.out & +[1] 1683587 +$ kill -USR1 %1 +$ SIGNAL +``` + +When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered). + +The pselect call itself _is_ interrupted, but the signal goes missing. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/866 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/866 new file mode 100644 index 000000000..344afc81d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/886621 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/886621 new file mode 100644 index 000000000..95c15b1e1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/909 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/909 new file mode 100644 index 000000000..dc380c91e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/922 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/922 new file mode 100644 index 000000000..6078a920d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/939 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/939 new file mode 100644 index 000000000..6525f2bab --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/95 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/95 new file mode 100644 index 000000000..d69c86bbb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/967 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/967 new file mode 100644 index 000000000..ff15a3c46 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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:32b/output/runtime/979 b/results/classifier/no-thinking-deepseek-r1:32b/output/runtime/979 new file mode 100644 index 000000000..3c6e7967d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/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 +# diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 new file mode 100644 index 000000000..d2ad3ea54 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 @@ -0,0 +1,4 @@ + + + +qemu-user: add execveat syscall support diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 new file mode 100644 index 000000000..6c3c897d5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 @@ -0,0 +1,44 @@ + + + +9p: newfstatat behaves differently than fstat causing ENOENT for here-documents +Description of problem: +After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error. +Steps to reproduce: +1. I have file `a` with: +``` +cat <<EOF +x +EOF +``` +2. User visible error inside VM: +``` +root@x86_64:~# grep 9p /proc/mounts +/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0 +root@x86_64:~# bash a +cat: -: No such file or directory +``` +3. `strace -fyv bash a` shows: +``` + [pid 291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, +st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0 + [pid 291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory) + [pid 291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5 + [pid 291] write(2</dev/ttyS0>, "-", 1-) = 1 + [pid 291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27 + [pid 291] write(2</dev/ttyS0>, "\n", 1 +``` +Additional information: +In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows: +``` + [pid 283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204, +st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0 + [pid 283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */, +st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0 + [pid 283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 + [pid 283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000 + [pid 283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2 + [pid 283] write(1</dev/ttyS0>, "x\n", 2x +``` + +So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 new file mode 100644 index 000000000..6db76014b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 @@ -0,0 +1,30 @@ + + + +fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented' +Description of problem: +Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109 + +Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in: + +``` +dpkg-buildpackage: info: source package clementine +dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye +dpkg-buildpackage: info: source distribution bullseye +dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com> +dpkg-buildpackage: info: host architecture armhf + dpkg-source --before-build . + fakeroot debian/rules clean +semop(1): encountered an error: Function not implemented +dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1 +``` + +This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109. +Steps to reproduce: +1. Setup (s)chroot with arm architecture (although the architecture may not matter) +2. Run fakeroot in the chroot +3. Observe the failure related to the semop syscall +Additional information: +- Not sure what other information I can provide to be helpful. +- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does. +- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin). diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1052857 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1052857 new file mode 100644 index 000000000..6cf3a4398 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/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:32b/output/syscall/1054831 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1054831 new file mode 100644 index 000000000..96c71a31a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1054831 @@ -0,0 +1,20 @@ + + + +qemu-user-static for sparc32plus : bash: fork: Invalid argument + +On Debian x86-64 host system I setup a sparc chroot using: + +host $ mkdir sparc +host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian +host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static +host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash + +When I then run the second stage of debootstrap I get: + +target $ /debootstrap/debootstrap --second-stage +bash: fork: Invalid argument + +The above procedures works perfectly for armhf. + +This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 new file mode 100644 index 000000000..56fc7d509 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 @@ -0,0 +1,16 @@ + + + +socket type mapping wrong for mips app-level emulation + +linux-user/syscall.c's do_socket function contains socket type remapping to work around the nonsensically-permuted MIPS socket types. However, it fails to account for the SOCK_NONBLOCK and SOCK_CLOEXEC flags that may be or'd onto the type. Thus, a call from the application such as: + +socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) + +will fail to have the type permutation performed, and will be passed to the system as: + +socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP) + +resulting in EPROTONOSUPPORT. + +To fix this, the flag bits should be masked off of the type before the permutation. They also need remapping themselves (since MIPS uses different values for these flags bits). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 new file mode 100644 index 000000000..7cdd34fbc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 @@ -0,0 +1,6 @@ + + + +linux-user emulation of setsockopt ignores optlen + +setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 new file mode 100644 index 000000000..39d32b76e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 @@ -0,0 +1,48 @@ + + + +qemu-i386 fails on system(3) with a cross-toolchain from Buildroot + +qemu-i386 fails with small C program containing a system(). +The C program is cross-compiled with a toolchain created by buildroot (http://buildroot.net/), gcc version 4.6.3, uClibc version 0.9.33.2 . +qemu version 1.2.0 (built with http://git.buildroot.net/buildroot/tree/package/qemu/qemu.mk) +host machine : Ubuntu 12.04 LTS on x86_64. + + $ cat sys.c + #include <stdio.h> + #include <stdlib.h> + + int main() + { + int ret = system("echo hello"); + printf("%d\n", ret); + } + + $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-i386 ./sys + -1 + +same problem with x86_64 : + $ ../../host/usr/bin/x86_64-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-x86_64 sys + -1 + +works fine with arm : + $ ../../host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-arm ./sys + hello + 0 + +works fine with mips : + $ ../../host/usr/bin/mips-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped + $ ../../host/usr/bin/qemu-mips sys + hello + 0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 new file mode 100644 index 000000000..b0fbfb334 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 @@ -0,0 +1,21 @@ + + + +Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error. +Description of problem: +When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error. +``` +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +``` + +I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error. +` syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)` +Steps to reproduce: +1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x +2. +3. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 new file mode 100644 index 000000000..cd164940b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 @@ -0,0 +1,122 @@ + + + +qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? +Description of problem: +- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is +> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` +- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 +- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) +- The problem seems to be limited to n32 (both big and little endian) + +Here's a run with strace functionality enabled: + +``` +dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' +3216 brk(NULL) = 0x40032000 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 +3216 uname(0x3fffebb0) = 0 +3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 +3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4c4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 +3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 +3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 +3216 munmap(0x3f786000,40960) = 0 +3216 munmap(0x3f7b1000,20880) = 0 +3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 +3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4b4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 +3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 +3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 +3216 munmap(0x3f75f000,4096) = 0 +3216 munmap(0x3f781000,57600) = 0 +3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 +3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4a4,512) = 512 +3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 +3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 +3216 munmap(0x3f569000,28672) = 0 +3216 munmap(0x3f757000,33440) = 0 +3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 +3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 +3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 +3216 close(3) = 0 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 set_thread_area(0x3f570580) = 0 +3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 +3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) +3216 Unknown syscall 6331 +3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 +3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 +3216 mprotect(0x4002e000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 +3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 +3216 munmap(0x3f7b7000,11294) = 0 +3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 +3216 brk(NULL) = 0x40032000 +3216 brk(0x40053000) = 0x40053000 +3216 brk(0x40054000) = 0x40054000 +3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 +3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 +3216 close(3) = 0 +3216 geteuid() = 0 +3216 umask(0) = 18 +3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 +3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 unlinkat(3,"troff",0) = 0 +3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 +3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 +3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) +3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 lseek(4,0,SEEK_DATA) = 0 +3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) +3216 lseek(4,0,SEEK_HOLE) = 716800 +3216 lseek(4,0,SEEK_SET) = 0 +3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 +3216 read(4,0x3f348000,131072) = 131072 +3216 write(5,0x3f348000,122880) = 122880 +3216 read(4,0x3f348000,131072) = 131072 +3216 lseek(5,12288,SEEK_CUR) = 135168 +3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) +3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 +3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 +3216 read(6,0x400333a0,4096) = 2998 +3216 read(6,0x400333a0,4096) = 0 +3216 close(6) = 0 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 +3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc428,18): Invalid argument = 18 +3216 write(2,0x3fffc858,1) + = 1 +3216 close(5) = 0 +3216 close(4) = 0 +3216 munmap(0x3f347000,139264) = 0 +3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) +3216 close(0) = 0 +3216 close(1) = 0 +3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # +``` + +More information and debugging on request. Any advice is appreciated. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 new file mode 100644 index 000000000..a19a401fc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 @@ -0,0 +1,28 @@ + + + +qemu-user syscall 439 (faccessat2) not implemented - loongarch64 +Description of problem: +On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in linux-user/syscall +Steps to reproduce: +1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi +2. The result is "ERROR" even if the file "test.sh" exists and it is readeable +3. The correct result should be "OK" +Additional information: +test.sh: + ``` + if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi + ``` +qemu-loongarch -strace log: + ``` +[...] +12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0 +12579 lseek(255,0,SEEK_CUR) = 0 +12579 read(255,0x2016d490,56) = 56 +12579 Unknown syscall 439 +12579 write(1,0x20172010,6) = 6 +12579 read(255,0x2016d490,56) = 0 +12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0 +12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0 +12579 exit_group(0) + ``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 new file mode 100644 index 000000000..96b55b038 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 @@ -0,0 +1,64 @@ + + + +Byte-swapping issue in getresuid on qemu-user-sparc64 +Description of problem: +When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. + +For example, the UID 0x000003e8 (1000) becomes 0x03e80000. +Steps to reproduce: +A minimal test case looks like this: +```c +#define _GNU_SOURCE +#include <stdio.h> +#include <sys/types.h> +#include <pwd.h> +#include <unistd.h> + +int main(int argc, char **argv) { + struct passwd *pw = getpwuid(geteuid()); + if (pw == NULL) { + perror("getpwuid failure"); + return 1; + } + printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); + + uid_t ruid = 0, euid = 0, suid = 0; + if (getresuid(&ruid, &euid, &suid) != 0) { + perror("getresuid failure"); + return 1; + } + printf("getresuid()->suid=0x%08x\n", suid); + + return 0; +} +``` + +Compile and run with: +``` +$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c +$ sudo chroot sid-sparc64 +[chroot] $ qemu-sparc64-static ./test +``` + +Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): +``` +$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c +$ qemu-sparc64-static ./test +``` + +Expected output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x000003e8 +``` + +Actual output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x03e80000 +``` +Additional information: +I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 new file mode 100644 index 000000000..c4c233a02 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 @@ -0,0 +1,108 @@ + + + +qemu-user hangs in m{,un}map loop + +Gentoo amd64 there, tried both 2.3.0 and eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces with qemu-x86_64 as well. + +∞ strace qemu-arm bin/true 2>&1| head -n 100 +execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0 +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +brk(0) = 0x62a4d070 +brk(0x62a4e2b0) = 0x62a4e2b0 +arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0 +set_tid_address(0x62a4dc50) = 7841 +set_robust_list(0x62a4dc60, 24) = 0 +rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17 +brk(0x62a6f2b0) = 0x62a6f2b0 +brk(0x62a70000) = 0x62a70000 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 +mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000 +mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0 +clone(child_stack=0x2c9527f8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 7842 +rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +gettimeofday({1432174351, 569148}, NULL) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +time(NULL) = 1432174351 +openat(AT_FDCWD, "/usr/gnemul/qemu-arm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument) +mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c94eff9000 +brk(0x62a91000) = 0x62a91000 +mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x8000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x9000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xa000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xb000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xc000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xd000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xe000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xf000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x10000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x11000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 new file mode 100644 index 000000000..4204668d8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 @@ -0,0 +1,43 @@ + + + +Unsupported syscalls 370 and 355 + +Qemu seems to be missing syscalls 370 and 355 when running qemu usermode arm. These are used by systemd or some similar new package. This can be detected by creating an debian sid armhf with qemu debootstrap. When the system is launched with "systemd-nspawn -bD sid-arm" this happens (newest git as of today): + +pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. +Press ^] three times within 1s to kill container. +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +/etc/localtime is not a symlink, not updating container timezone. +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 384 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) +Detected virtualization systemd-nspawn. +Detected architecture arm. + +Welcome to Debian GNU/Linux stretch/sid! + +Set hostname to <manos>. +qemu: Unsupported syscall: 355 +Failed to allocate manager object: Function not implemented +[!!!!!!] Failed to allocate manager object, freezing. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 new file mode 100644 index 000000000..30acd8686 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 @@ -0,0 +1,34 @@ + + + +sh4: Unsupported syscall: 186 + +Hello! + +I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port. + +I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186: + +qemu: Unsupported syscall: 186 + +From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as + +#define TARGET_NR_sigaltstack 186 + +Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4: + +#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \ + defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \ + defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC) + ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env)); + break; +#else + goto unimplemented; +#endif + +Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it? + +Thanks, +Adrian + +> [1] https://wiki.debian.org/QemuUserEmulation \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 new file mode 100644 index 000000000..957d6dfd0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 @@ -0,0 +1,53 @@ + + + +qemu hangs in pselect syscall + +I'm using git commit d75aa4372f0414c9960534026a562b0302fcff29 (v2.7.0-rc4) configured with; + --enable-linux-user \ + --disable-system \ + --disable-tools \ + --disable-guest-agent \ + --static --disable-linux-aio \ + --disable-fdt \ + --without-pixman \ + --disable-blobs \ +Stable version (v2.6.0) also have the same problem. + +In a chroot environment I ran below command-line to compile some things, different sources each time. + /usr/bin/qemu-arm -0 /usr/bin/edje_cc /usr/bin/edje_cc -id /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/images_mob/ -DBROWSER_RESOLUTION_720x1280=1 -DPROFILE_MOBILE=1 /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/edc/TextPopup_mob.edc /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/build-tizen/services/SimpleUI/720x1280_TextPopup.edj + +Here is back trace with gdb; +#0 safe_syscall_end () at /usr/src/debug/qemu-2.6.94/linux-user/host/i386/safe-syscall.inc.S:78 +#1 0x60049370 in safe_pselect6 (nfds=10, readfds=0xffa31b5c, writefds=0xffa31bdc, exceptfds=0xffa31c5c, timeout=0x0, sig=0x0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:855 +#2 0x6004b2fe in do_select (n=10, rfd_addr=1082122232, wfd_addr=1082122360, efd_addr=1082122488, target_tv_addr=0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:1386 +#3 0x6005e5ba in do_syscall (cpu_env=0x640d0454, num=142, arg1=10, arg2=1082122232, arg3=1082122360, arg4=1082122488, arg5=0, arg6=1087473216, arg7=0, + arg8=0) at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:9690 +#4 0x60045def in cpu_loop (env=0x640d0454) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:876 +#5 0x60047640 in main (argc=10, argv=0xffa33c84, envp=0xffa33cb0) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:4817 + +Attached core file taken from gdb. To see the stack frame, you could try; +$ tar -xf reproduced_118_04.tar.bz2; gdb --core core.1823 qemu-arm + +And recent strace log for PID 1823(stucked one); +79965 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79966 [ 313s] ==>[pselect6(0xa)=] +79967 [ 313s] [pselect6=0x1]<== +79968 [ 313s] 1823 :0x8e _newselect(10,[9,],[],[],NULL) +79969 [ 313s] 1823 :0x8e => = 0x00000001 ([9,],[],[],NULL) +79970 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79971 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79972 [ 313s] 1823 :0xfc => = 0 +79973 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79974 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79975 [ 313s] 1823 :0x3 => = 8 +79976 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79977 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79978 [ 313s] 1823 :0x107 => = 0 +79979 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79980 [ 313s] ==>[pselect6(0xa)=] + +I'm using 64-bit Ubuntu with kernel release Linux 3.19.0-25-generic #26~14.04.1-Ubuntu. +Reproducibility is low. One occurrence out of 50+ trials. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 new file mode 100644 index 000000000..65fb39f5e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 @@ -0,0 +1,53 @@ + + + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") + +Hello, + +I have the following issue when launching the Teamspeak Server x86 binary on an arm host. + +Host: + Linux 4.6.2 (vanilla) + Ubuntu 14.04.5 LTS + HW: Cubietruck board, armv7l + + +Used SW: Release archive qemu-2.7.0.tar.bz2 and git commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a +Configure options: + ../configure --target-list=i386-linux-user +I attached the output of the configure script as configure.log + +Testcase: + +1. Download and extract TeamSpeak 3 Server 3.0.13.3 (x86) + Souce: http://dl.4players.de/ts/releases/3.0.13.3/teamspeak3-server_linux_x86-3.0.13.3.tar.bz2 + +2. Modifiy ts3server_minimal_runscript.sh for ease of use + - ./ts3server $@ + + /usr/local/bin/qemu-i386 ./ts3server $@ + +3. Execute ./ts3server_minimal_runscript.sh + +Wait for 6 Minutes until teamspeak server started. QEMU saturates the cpu while Teamspeak is precomputing a puzzle. (Whatever that means) + +After that Teamspeak settles with the following output: + 2016-09-03 10:50:59.555582|INFO |Query | |listening on 0.0.0.0:10011, :::10011 + +The Qemu process is now idling with ~2% cpu load. This is actually the first time for me that QEMU is able to successfully launch the Teamspeak server. Kudos! + +4. Connect client 1 + +TS Clients can connect, but the following line is printed pretty often: + Unsupported ancillary data: 0/8 + +The line seems to come from qemu (linux-user/syscall.c) + + +5. Connect client 2 +When a second client is connected the audio transmission is successful for a few seconds, but the server drops the connection after that and refuses to take new connections. + +Please let me know, if you need more information. I'll gladly provide strace or valgrind logs. + +Best regards, +Tobias \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 new file mode 100644 index 000000000..459b87752 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 @@ -0,0 +1,35 @@ + + + +netlink broken on big-endian mips + +Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159) + +As the summary says, netlink is completely broken on big-endian mips running qemu-user. + +Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes. + +[...] +[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0 +[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 +[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0 +[pid 11249] time([1479745823]) = 1479745823 +[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40 +[pid 11249] recvmsg(3, + +Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped. + +Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason. + +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, + #ifdef TARGET_NR_socket + case TARGET_NR_socket: + ret = do_socket(arg1, arg2, arg3); +- fd_trans_unregister(ret); + break; + #endif + #ifdef TARGET_NR_socketpair \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 new file mode 100644 index 000000000..f6d257a86 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 @@ -0,0 +1,29 @@ + + + +In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? + +On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via + + /usr/sbin/qemu-binfmt-conf.sh + +from + + qemu-linux-user-2.9.0-374.1.x86_64 + +on the host, inside the chroot any compile activity is laced with repetitions of + + qemu: Unsupported syscall: 384 + +messages. + +This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... + +From a chat in #IRC, + + [10:05] davidgiluk clever/pgnd: I see it as getrandom + [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it + [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom + [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom + [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? + [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 new file mode 100644 index 000000000..9eea4be1a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 @@ -0,0 +1,10 @@ + + + +golang calls to exec crash user emulation + +An example program can be found here: + +https://github.com/willnewton/qemucrash + +This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 new file mode 100644 index 000000000..1ee2c3ed6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 @@ -0,0 +1,19 @@ + + + +stack smashing in or after recvmsg system call in aarch64 user mode + +A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. + +How to reproduce: +$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0 +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out +*** stack smashing detected ***: ./a.out terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +On native aarch64 hardware: +$ ./a.out +$ echo $? +0 + +The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 new file mode 100644 index 000000000..34a76741a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 @@ -0,0 +1,48 @@ + + + +multithreading not working right under qemu user mode for sh4 + +In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right. + +The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64, powerpc64le. + +How to reproduce: +- Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -lpthread -o test-tls test-tls.c +- Set environment variables for running qemu-sh4. +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-tls + +Expected behaviour: After the "Worker xxxxx dying" line, the main() function prints "OK", and the program terminates. + +Actual behaviour (only on sh4): After the "Worker xxxxx dying" line, it hangs. Attaching gdb to qemu shows 15 threads with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=128, val=val@entry=2, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161181992) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161181992, uaddr2=4134624624, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-160342672, + arg6=-161181992, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=env@entry=0x5584fb3d04f8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86f5dd5 in clone_func (arg=0x7fff4d485c20) at /build/qemu-2.9.0/linux-user/syscall.c:6234 +#6 0x00007f08f05a46ba in start_thread (arg=0x7f08f1368700) at pthread_create.c:333 +#7 0x00007f08f02da3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +and 1 thread with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=0, val=val@entry=18875, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161180376) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161180376, uaddr2=4135101768, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-159865528, + arg6=-161180376, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=0x5584fb3b99a8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86c12d3 in main (argc=<optimized out>, argv=0x7fff4d4878b8, envp=<optimized out>) + at /build/qemu-2.9.0/linux-user/main.c:4860 + +and 1 thread with a stack trace like +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x00005584f876eab5 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x5584faa43d84 <rcu_call_ready_event>) at /build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x00005584f87748ce in call_rcu_thread (opaque=<optimized out>) at /build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f08f05a46ba in start_thread (arg=0x7f08eff62700) at pthread_create.c:333 +#5 0x00007f08f02da3dd 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:32b/output/syscall/1701973 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701973 new file mode 100644 index 000000000..1b13a29b0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701973 @@ -0,0 +1,20 @@ + + + +pread does not work right under qemu-sh4 + +The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread + +Expected output: +ret=1 errno=0 + +Actual output: +ret=0 errno=2 +test-pread.c:44: assertion 'ret == 1' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 new file mode 100644 index 000000000..ea81509d9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 @@ -0,0 +1,20 @@ + + + +pwrite does not work right under qemu-sh4 + +The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pwrite + +Expected output: +buf = 01W3456789 + +Actual output: +buf = 0123456789 +test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 new file mode 100644 index 000000000..e0209f879 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 @@ -0,0 +1,33 @@ + + + +User mode emulation returns wrong value for write(fd, NULL, 0) + +QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c) +OS version: Ubuntu 14.04.3 +Configured with: ../configure --target-list=x86_64-linux-user + +QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1. + +I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case: + +zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c +#include <stdio.h> +#include <unistd.h> +#include <fcntl.h> + +int main() { + ssize_t ret = write(STDOUT_FILENO, NULL, 0); + fprintf(stderr, "write returned %ld\n", ret); + return 0; +} +zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c +zhuowei@zhuowei-tablet:/tmp$ uname -a +Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes +write returned 0 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes +write returned -1 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version +qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 new file mode 100644 index 000000000..13658861b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 @@ -0,0 +1,8 @@ + + + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 new file mode 100644 index 000000000..b161a72f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 @@ -0,0 +1,50 @@ + + + +Empty /proc/self/auxv (linux-user) + +The userspace Linux API virtualization used to fake access to /proc/self/auxv, to provide meaningful data for the guest process. + +For newer qemu versions, this fails: The openat() is intercepted, but there's no content: /proc/self/auxv has length zero (i.e. reading from it returns 0 bytes). + +Good: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +256 /proc/self/auxv + +Bad: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +0 /proc/self/auxv + +This worked in 2.7.1, and fails in 2.10.1. + +This causes e.g. any procps-ng-based tool to segfault while reading from /proc/self/auxv in an endless loop (probably worth another bug report...) + +Doing a "git bisect" shows that this commit: https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem. + +It might be a simple logic (subtraction in the wrong direction?) or sign-ness error: Adding some logging (to v2.10.1) + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 9b6364a..49285f9 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd) + abi_ulong len = ts->info->auxv_len; + char *ptr; + ++ gemu_log(TARGET_ABI_FMT_lu"\n", len); ++ gemu_log(TARGET_ABI_FMT_ld"\n", len); ++ + /* + * Auxiliary vector is stored in target process stack. + * read in whole auxv vector and copy it to file + +shows this output: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +18446744073709551264 +-352 +0 + +And 352 could be the expected length. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 new file mode 100644 index 000000000..fc8e0fa87 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 @@ -0,0 +1,50 @@ + + + +mremap fails with EFAULT if address range overlaps with stack guard +Description of problem: +When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`. + +https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c + +``` c + while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM) + l += PAGE_SIZE; +``` +Steps to reproduce: +Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host. + +``` c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} +``` + +For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container: + +``` +$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest + +/ # apk add alpine-sdk + +...... + +/ # cat test.c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} + +/ # gcc test.c + +/ # ./a.out +``` +Additional information: +Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 new file mode 100644 index 000000000..2ec071756 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 @@ -0,0 +1,10 @@ + + + +linux-user mode does not support memfd_create syscall + +qemu-x86_66 GIT HEAD fails on a userspace application that requires memfd_create with: + +"qemu: Unsupported syscall: 319". + +memfd_create support needs to be implemented in QEMU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 new file mode 100644 index 000000000..10955285a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 @@ -0,0 +1,34 @@ + + + +Go binaries panic with "mmap errno 9" on qemu-user + +Go binaries panic with "mmap errno 9" on qemu-user. + +root@nofan:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} +root@nofan:/# gccgo-7 hello.go -o hello +root@nofan:/# ./hello +mmap errno 9 +fatal error: mmap + +runtime stack: +mmap errno 9 +fatal error: mmap +panic during panic + +runtime stack: +mmap errno 9 +fatal error: mmap +stack trace unavailable +root@nofan:/# + +Tested with qemu from git master with Debian unstable for armel. + +Same binaries work fine on real hardware. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 new file mode 100644 index 000000000..a2237f14e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 @@ -0,0 +1,29 @@ + + + +sbrk() not working under qemu-user with a PIE-compiled binary? + +In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). + +$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash +bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) + +bash has its own malloc implementation based on sbrk(): +https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c + +When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. + +This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: +https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 + +You can find the problematic bash binary in that .deb file: +http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb + +The version of qemu I have been using is 2.11 (Debian package qemu-user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). + +Here are the related Debian bug reports: +https://bugs.debian.org/889869 +https://bugs.debian.org/865599 + +It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 new file mode 100644 index 000000000..cfe5b3d57 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 @@ -0,0 +1,46 @@ + + + +qemu8-user on Linux: SIGSEGV because brk(NULL) does not exist +Description of problem: +On Linux, the return value of the system call brk(NULL) need not point to a page that exists. +If so, then qemu8-user will generate SIGSEGV at the next call to brk() with a higher value, +because qemu8 believes that it should maintain contiguous .bss with bytes of value 0. +Thus qemu8-user so calls `memset(g2h_untagged(target_brk), 0, brk_page - target_brk); +in do_brk() at ../linux-user/syscall.c:867, and this generates SIGSEGV at +the non-existent page that covers brk(NULL). + +Instead, the safest thing to do is nothing at all. +Linux deliberately returns a random value for brk(NULL), subject to the conditions +that the value be at least as large as the maximum over all PT_LOAD of (.p_vaddr + .p_memsz), +and "somewhat near" that maximum. The purpose of randomness is to use variability +to interfere with effectiveness of malware, and to expose application coding errors +regarding brk() and sbrk(). If qemu-user wants to preserve contiguous .bss, +then qemu-user should call memset() only if the first page of the range exists. +(As explained in the next paragraph, "contiguous .bss" is a murky concept.) + +Linux itself is partly to blame, because it computes the maximum (.p_vaddr + .p_memsz) +over all the PT_LOAD of the most recent execve(). The most recent execve() seen by +Linux might have no relationship to the state of the address space at the time of +_either_ call to brk(). The app can do arbitrary mmap, munmap, mprotect at any time. +In particular, the run-time de-compressor of UPX does exactly that for a compressed +main program. The maximum computed by Linux is for the compressed program, +which has a different layout than the de-compressed program. + +There is a Linux system call prctl(PR_SET_MM_BRK, new_value) which sets a value +for "the brk", but that syscall tries to validate the new_value based on +the most recent execve(). Once again, that has no relationship to the current +layout of the address space produced by the UPX de-compressor. +Steps to reproduce: +1. build qemu8-x86_64 from +``` +commit fcb237e64f9d026c03d635579c7b288d0008a6e5 (HEAD -> master, origin/master, origin/HEAD) +Merge: 2ff49e96ac c00aac6f14 +Date: Mon Jul 10 09:17:06 2023 +0100 +``` +2. run `build/qemu-x86_64 -strace upx-4.0.2-amd64_linux/upx --version` where the upx +is from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-amd64_linux.tar.xz +3. output ends with +``` +372621 close(3) = 0 +372621 munmap(0x0000004000803000,3055) = 0 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756807 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756807 new file mode 100644 index 000000000..3ab520168 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/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:32b/output/syscall/1760 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1760 new file mode 100644 index 000000000..336c62075 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1760 @@ -0,0 +1,56 @@ + + + +qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90) +Description of problem: +qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386. +``` +$ strace ./oldmmap +execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0 +[ Process PID=405233 runs in 32 bit mode. ] +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000 +exit(5) = ? ++++ exited with 5 +++ + +$ build/qemu-i386 -strace ./oldmmap +405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000 +405254 exit(5) +``` +Steps to reproduce: +1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S # build 32-bit executable +2. strace ./oldmmap # run under strace +3. build/qemu-i386 -strace ./oldmmap # run under "qemu-i386 -strace" +4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did. +Additional information: +``` +$ cat oldmmap.S +MAP_FIXED= 0x10 +MAP_PRIVATE= 0x02 +MAP_ANONYMOUS= 0x20 + +PROT_READ= 1 +PROT_WRITE= 2 +PROT_EXEC= 4 + +_NR_exit = 1 +_NR_mmap = 90 // oldmmap: %ebx -> array of 6 arguments + + .globl _start +_start: + push $0 // offset + push $-1 // fd + push $MAP_PRIVATE|MAP_ANONYMOUS // flags + push $PROT_READ|PROT_WRITE // protection + push $2<<12 // length + push $0 // addr (kernel chooses) + mov %esp,%ebx + mov $_NR_mmap,%eax + int $0x80 + nop + + mov $5,%ebx + mov $_NR_exit,%eax + int $0x80 + hlt +$ +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 new file mode 100644 index 000000000..245df7766 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 @@ -0,0 +1,126 @@ + + + +unimplemented thread syscalls in nios2 user-mode emulation + +This bug is reported against the 3.0 release. + +I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing when run in user-mode qemu for nios2 target. The problem appears to be that the thread-related syscalls are unimplemented in qemu. Here is output from running with -strace: + +22484 brk(NULL) = 0x00005000 +22484 uname(0x7fffef5a) = 0 +22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe954,512) = 512 +22484 fstat64(3,0x7fffe870) = 0 +22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 +22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe948,512) = 512 +22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 +22484 fstat64(3,0x7fffe864) = 0 +22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 +22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 +22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 +22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe93c,512) = 512 +22484 fstat64(3,0x7fffe858) = 0 +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) + +Note that set_robust_list and clone are reported as unimplemented. + +I've reported the problems with the signal syscalls separately here. +https://bugs.launchpad.net/qemu/+bug/1791763 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 new file mode 100644 index 000000000..fbb73f826 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 @@ -0,0 +1,24 @@ + + + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host + +This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: + +# Setup docker for user-static binfmt +docker run --rm --privileged multiarch/qemu-user-static:register --reset +# Compile the code and run (readdir for / is fine, so create a new directory /test). +docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' +dir=0xff5b4150 +readdir(dir)=(nil) +errno=75: Value too large for defined data type + +Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. + +The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 + +By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. + +The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. + +The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 new file mode 100644 index 000000000..d91c43bdf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 @@ -0,0 +1,50 @@ + + + +aarch64-linux-user master: inconsistent pwrite behaviour + +Hello, + +I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 + +And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +Minimal reproducible sample is the following: + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <string.h> + +/* + System | Result +-------------------------+---------------- + Native x86_64 4.12.14 | pwrite ret = 0 + Native aarch64 4.4.159 | pwrite ret = 0 + qemu-aarch64 at x86_64 | pwrite ret = -1 + ( 20d6c7312f1b8 ) | +*/ + +int main(int argc, char** argv) { + int fd = open("test.dat", O_CREAT | O_RDWR, 0644); + if (fd < 0) { + perror("open"); + return 1; + } + + int ret = fallocate(fd, 0, 0, 1000); + if (ret < 0) { + perror("fallocate"); + return 1; + } + + ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); + printf("pwrite ret = %ld\n", ret_pwrite); + + close(fd); + + return 0; +} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 new file mode 100644 index 000000000..f2902e8bd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 @@ -0,0 +1,24 @@ + + + +util/path.c/follow_path() does not handle "/" well + +Hello, + +I noticed that qemu does not handle "/" very well in follow_path(). + +Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. + +Indeed it does something like + if (__lstat ("/", &st) < 0) +..... +and then loops from current dir toward the top using lstat("..") + +On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot). +OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails. + +I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so? + +If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ? + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 new file mode 100644 index 000000000..40f085527 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 @@ -0,0 +1,38 @@ + + + +qemu: Unsupported syscall: 382 + +I used + +qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] + +When I try to build an image of a docker for an arm, an error occurs. + +This affects the operation of applications. + + +Dockerfile + +ARG ARCH +FROM ${ARCH}/debian:buster-slim + +RUN \ + printf "Install dependencies...\n" && \ + apt-get update && \ + apt-get install -y --no-install-recommends ca-certificates curl + +RUN curl https://google.com + +EOF + +The command that I run + +docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . + + +root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf +:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F + +Here is a related discussion. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 new file mode 100644 index 000000000..7cda11ff7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 @@ -0,0 +1,38 @@ + + + +Support IP_MULTICAST_IF socket option in linux-user +Additional information: +I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet. + +Here's some source code that demonstrates the failure: +``` +#include <sys/socket.h> +#include <arpa/inet.h> +#include <netinet/ip.h> +#include <unistd.h> +#include <assert.h> +#include <stdio.h> + +int main() +{ + int fd, ret; + struct in_addr addr = {htonl(INADDR_LOOPBACK)}; + + fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); + assert(fd >= 0); + ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr)); + if (ret < 0) + { + perror("setsockopt failed"); + return 1; + } + close(fd); + printf("Success!\n"); + return 0; +} +``` + +When run under qemu, it gives the error `setsockopt failed: Protocol not available`. + +It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 new file mode 100644 index 000000000..f7ec248b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 @@ -0,0 +1,23 @@ + + + +Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le + +Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2 image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-ci.org. + +From golang's https://github.com/golang/go/issues/36592: + +It was discovered that golang's time.NewTicker() and time.Sleep() malfunction when a compiled application was run via QEMU's ppc64le emulator in user mode. + +The methods did not malfunction on actual PowerPC hardware or when the same golang application was compiled for golang's arm, arm64 or 386 targets and was run via user mode QEMU on the same system. + +Curiously, the methods also worked when the program was compiled under go 1.11, but do malfunction in go 1.12 and 1.13. + +It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E: +https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b + +We therefore suspect there may be a bug in QEMU's user-mode emulation of ppc64le as relates to vDSO calls to clock_gettime(). + +The nature of the malfunction of time.NewTicker() and time.Sleep() is such that sleeps or ticks with a granularity of less than one second do not appear to be possible (they all revert to 1 second sleeps/ticks). Could it be that the nanoseconds field of clock_gettime() is getting lost in the vDSO version but not in the syscall? Or some other issue calling these methods via vDSO? + +Thanks in advance. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 new file mode 100644 index 000000000..d39d7f69d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 @@ -0,0 +1,33 @@ + + + +ARM QEMU: Unknown syscall 397 + +QEMU is reporting + +``` +Unknown syscall 397 +``` + +(statx if I read tables right) when used via flatpak for ARM images on x86_64. This has been reproduced on Fedora and Gentoo. + +To reproduce: + +- get flatpak KDE 5.12 for arm: + +flatpak install --user org.kde.Sdk/arm/5.12 org.kde.Platform/arm/5.12 + + +- run qmake inside Sdk: + +QEMU_STRACE=1 flatpak run --filesystem=host --command=qmake org.kde.Sdk/arm/5.12 . + + +You will get a host of messages with unknown syscall. In practice, qmake will fail to find .pro files if you have them in that folder and libraries in the system. + +As far as I understand, Flatpak images are built on AARCH64 hardware. + +My config on Gentoo: + +kernel: 4.19.86-gentoo x86_64 +app-emulation/qemu: ~4.2.0-r1 , same with 4.0.0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 new file mode 100644 index 000000000..97bedb20d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 @@ -0,0 +1,51 @@ + + + +segfault mremap 4096 + +a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. + +If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: + +gcc -m32 mremapbug.c +# works +./a.out +# segfault +qemu-i386 a.out + +If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. + + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <sys/mman.h> + +int main(int argc, char *argv[]) +{ + const size_t initial_size = 8192; + + printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); + void *mmap_ptr = mmap(NULL, initial_size, + PROT_READ | PROT_WRITE , + MAP_PRIVATE | MAP_ANONYMOUS, + -1, 0); + printf("mmap returned : %p\n", mmap_ptr); + if (mmap_ptr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + const size_t new_size = 4096; + printf("calling mremap, size=%llu\n", (unsigned long long)new_size); + void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); + printf("mremap returned: %p\n", remap_ptr); + if (remap_ptr != mmap_ptr) { + perror("mreamap"); + exit(1); + } + printf("Success: pointers match\n"); +} + + +This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 new file mode 100644 index 000000000..c7204a9fc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 @@ -0,0 +1,8 @@ + + + +qemu linux-user doesn't support OFD fcntl locks + +"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. + +Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 new file mode 100644 index 000000000..2f0619424 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 @@ -0,0 +1,8 @@ + + + +linux-user: syscall.c lacks pselect6_time64 + +in commit 50efc69586388a975c1ebd90cb8cc8e4a7328bc4 legacy pselect6 definition +for riscv32 was removed in favour of pselect6_time64, but pselect6_time64 is +not available in syscall.c, thus leaving riscv32 without pselect syscall. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 new file mode 100644 index 000000000..d4b24928f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 @@ -0,0 +1,53 @@ + + + +chrome based apps can not be run under qemu user mode + +chrome uses /proc/self/exe to fork render process. +Here a simple code to reproduce the issue. It's output parent then child but failed with qemu: unknown option 'type=renderer'. + +Maybe we can modify exec syscall to replace /proc/self/exe to the real path. + +//gcc -o self self.c +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> +int main(int argc, char** argv) { + if(argc==1){ + printf ("parent\n"); + if ( fork() == 0 ) + { + return execl("/proc/self/exe","/proc/self/exe", "--type=renderer",NULL); + } + } else { + printf ("child\n"); + } + return 0; +} + +similar reports: +https://github.com/AppImage/AppImageKit/issues/965 +https://github.com/golang/go/issues/42080 + +Workardound: +compile chrome or your chrome based app with a patch to content/common/child_process_host_impl.cc:GetChildPath, get the realpath of /proc/self/exe: + +diff --git a/content/common/child_process_host_impl.cc b/content/common/child_process_host_impl.cc +index bc78aba80ac8..9fab74d3bae8 100644 +--- a/content/common/child_process_host_impl.cc ++++ b/content/common/child_process_host_impl.cc +@@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) { + #if defined(OS_LINUX) + // Use /proc/self/exe rather than our known binary path so updates + // can't swap out the binary from underneath us. +- if (child_path.empty() && flags & CHILD_ALLOW_SELF) +- child_path = base::FilePath(base::kProcSelfExe); ++ if (child_path.empty() && flags & CHILD_ALLOW_SELF) { ++ if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) { ++ NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << "."; ++ child_path = base::FilePath(base::kProcSelfExe); ++ } ++ } + #endif + + // On most platforms, the child executable is the same as the current \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 new file mode 100644 index 000000000..84aee5b60 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 @@ -0,0 +1,65 @@ + + + +QEMU-user ignores MADV_DONTNEED + +There is comment int the code "This is a hint, so ignoring and returning success is ok" +https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941 + +But it seems incorrect with the current state of Linux + +"man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html +says the following: +>> These advice values do not influence the semantics +>> of the application (except in the case of MADV_DONTNEED) + +>> After a successful MADV_DONTNEED operation, the semantics +>> of memory access in the specified region are changed: +>> subsequent accesses of pages in the range will succeed, +>> but will result in either repopulating the memory contents +>> from the up-to-date contents of the underlying mapped file +>> (for shared file mappings, shared anonymous mappings, and +>> shmem-based techniques such as System V shared memory +>> segments) or zero-fill-on-demand pages for anonymous +>> private mappings. + +Some applications use this behavior clear memory and it +would be nice to be able to run them on QEMU without +workarounds. + +Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host. + + +``` +#include "assert.h" +#include "stdio.h" +#include <sys/mman.h> +#include <errno.h> + +int main() { + char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + assert(P); + *P = 'A'; + while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) { + } + assert(*P == 0); + + printf("OK\n"); +} + +/* +gcc /tmp/madvice.c -o /tmp/madvice + +qemu-x86_64 /tmp/madvice +madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted + +/tmp/madvice +OK + + +*/ + +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 new file mode 100644 index 000000000..677818f55 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 @@ -0,0 +1,23 @@ + + + +qemu-user clone syscall fails + +qemu-user fails to emulate clone() (https://linux.die.net/man/2/clone). The architecture doesn't seem to matter, tho I've mostly been testing aarch64. + +Attached is clone_test.c that demonstrates the problem. Running it natively looks like this: +$ bin/clone_test +The variable was 9 +clone returned 4177: 0 Success +The variable is now 42 + + +However, running it via qemu looks like: +$ qemu-aarch64-static --version +qemu-aarch64 version 5.2.0 (v5.2.0) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ qemu-aarch64-static ./clone_test +The variable was 9 +clone returned -1: 22 Invalid argument +The variable is now 9 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2101 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2101 new file mode 100644 index 000000000..eefe48057 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/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:32b/output/syscall/2112 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2112 new file mode 100644 index 000000000..bc4154860 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2112 @@ -0,0 +1,29 @@ + + + +Limited Support for MIPS clone syscall in QEMU User Mode +Description of problem: +Hello, + +I have been working with QEMU user mode to run programs based on the MIPS architecture and have encountered a limitation regarding the support for the MIPS clone syscall in the current implementation of QEMU user mode. Specifically, when invoking the clone syscall with certain flags, it results in the error "errno=22 (Invalid argument)" due to the absence of corresponding handling code in QEMU. + +Upon further investigation, I pinpointed the probable cause. QEMU user mode appears to check if the flags for the clone syscall include all the flags defined in CLONE_THREAD_FLAGS. If there is a mismatch, it returns "-TARGET_EINVAL". + +[source code](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c?ref_type=heads#L6564) + +The current CLONE_THREAD_FLAGS in QEMU are set to include: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM). + +However, in my MIPS program, the flags are only: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). + +Aligning my MIPS program to include all the flags as per CLONE_THREAD_FLAGS alters the clone syscall's behavior, deviating from the original semantics required by my MIPS program. + +I am seeking guidance on whether there is a way in QEMU user mode's MIPS syscall handling to exclusively use the flags (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). Alternatively, I am interested in any possible approach to enable support for the MIPS architecture's clone syscall in QEMU user mode. + +Thank you for your time and assistance. +Steps to reproduce: +1. Write a C program that utilizes the clone function, specifying the flags as: CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND. + +strace output: +``` +clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND,child_stack=0x009359a8,parent_tidptr=0x00000f00,tls=0x00000003,child_tidptr=0x2b36d510) = -1 errno=22 (Invalid argument) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 new file mode 100644 index 000000000..ec7f9aaa9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 @@ -0,0 +1,34 @@ + + + +Invalid subprocess commands spawns successfully when running under QEMU +Description of problem: +When executing a subprocess from with a non-existing command EQMU still spawns a process. + +Consider this small rust program for instance: +```rust +use std::process::Command; + +fn main() { + match Command::new("thisdoesnotexist").spawn() { + Ok(child) => { + println!("Child process id is {}", child.id()); + } + Err(_) => { + println!("This should happen"); + } + } +} +``` + +**Executing with `qemu-aarch64`:** +```shell +qemu-aarch64 ./rust-app +Child process id is 20182 +``` + +**Executing regularly:** +```shell +./rust-app +This should happen +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 new file mode 100644 index 000000000..374e0a3b0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 @@ -0,0 +1,35 @@ + + + +qemu-x86_64: segfault when running grep on arm64 host +Description of problem: +An internal segmentation fault occurs when attempting to run `grep` in a Gentoo stage3 chroot +Steps to reproduce: +1. Unpack an x86_64 chroot environment (easiest way is using one of Gentoo's stage3s from https://get.gentoo.org) +2. Run `qemu-x86_64 -L /path/to/x86_64/chroot /path/to/x86_64/chroot/bin/grep` +Additional information: +It seems this only occurs in 8.x.x, 7.x.x does not have this segfault. + +Output: +``` +# qemu-x86_64 -L /bugs/grep-sandbox /bugs/grep-sandbox/bin/grep +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +``` + +GDB bt: +``` +(gdb) bt +#0 open_self_maps_2 (opaque=0xffffffffd0b0, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000000000048539c in walk_memory_regions (priv=priv@entry=0xffffffffd0b0, fn=fn@entry=0x4a13e4 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x00000000004a20bc in open_self_maps_1 (smaps=false, fd=3, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x00000000004aaa00 in do_guest_openat (cpu_env=cpu_env@entry=0x862050, dirfd=dirfd@entry=-100, fname=fname@entry=0x5555555776f1 "/proc/self/maps", flags=0, mode=mode@entry=0, safe=safe@entry=true) + at ../linux-user/syscall.c:8381 +#5 0x00000000004b0cc4 in do_syscall1 (cpu_env=cpu_env@entry=0x862050, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=93824992376561, arg3=arg3@entry=0, arg4=arg4@entry=0, + arg5=arg5@entry=93824992373306, arg6=arg6@entry=0, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x00000000004b2770 in do_syscall (cpu_env=cpu_env@entry=0x862050, num=257, arg1=4294967196, arg2=93824992376561, arg3=0, arg4=0, arg5=93824992373306, arg6=0, arg7=arg7@entry=0, arg8=arg8@entry=0) + at ../linux-user/syscall.c:13658 +#7 0x0000000000404fdc in cpu_loop (env=env@entry=0x862050) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x0000000000400d7c in main (argc=4, argv=0xffffffffed48, envp=<optimized out>) at ../linux-user/main.c:1014 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 new file mode 100644 index 000000000..08119aaf3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 @@ -0,0 +1,61 @@ + + + +qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly +Description of problem: +Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**. + +When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero. +Steps to reproduce: +1. compile this code to binary executable: +```c +#include <unistd.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/if_alg.h> + +int create_alg(const char *alg) +{ + struct sockaddr_alg salg; + int sk; + + sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0); + if (sk < 0) + return -1; + + memset(&salg, 0, sizeof(salg)); + salg.salg_family = AF_ALG; + strcpy((char *) salg.salg_type, "hash"); + strcpy((char *) salg.salg_name, alg); + + if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) { + close(sk); + return -1; + } + + return sk; +} + +int main() { + int fd = create_alg("hmac(sha1)"); + char buf[10]; + int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0); + if(ret < 0){ + perror("err"); + } + else{ + puts("SUCCESS!"); + } + return 0; +} +``` +2. run it in any qemu user space emulator + +On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`. + +The error is neither informative nor intuitive and could be misleading for user programs. +Additional information: +I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 new file mode 100644 index 000000000..103adf3c7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 @@ -0,0 +1,48 @@ + + + +VDSO on armeb seems broken +Description of problem: +I'm seeing the VDSO method for `__clock_gettime64()` crashing under `qemu-armeb` (stack trace under Additional information, below). + +I rebuilt glibc with VDSO globally kludged off, and all was well. +Steps to reproduce: +``` +#include <time.h> +#include <stdlib.h> +#include <stdio.h> + +int main(int argc, char **argv) { + time_t ts; + printf("%ld\n", time(&ts)); + exit(0); +} +``` + +Results, first with VDSO active via a system snapshot, second with the patched glibc: +``` +$ armeb-linux-gnueabihf-gcc -o /tmp/time /tmp/time.c +$ qemu-armeb -L /.mirrorsnaps/.rootsnap.prev/usr/armeb-linux-gnueabihf /tmp/time +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ qemu-armeb -L /usr/armeb-linux-gnueabihf /tmp/time +1715123280 +``` +Additional information: +``` +Program received signal SIGSEGV, Segmentation fault. +0x4082b462 in ?? () +(gdb) bt +#0 0x4082b462 in ?? () +#1 0x40bf64a4 in __GI___clock_gettime64 (clock_id=clock_id@entry=5, tp=tp@entry=0x407fe9c0) + at ../sysdeps/unix/sysv/linux/clock_gettime.c:42 +#2 0x40be9f58 in __GI___time64 (timer=0x0) at ../sysdeps/unix/sysv/linux/time.c:60 +#3 __time (timer=0x407fea04) at ../sysdeps/unix/sysv/linux/time.c:73 +``` + +`clock_gettime.c:42` is +``` + r = INTERNAL_VSYSCALL_CALL (vdso_time64, 2, clock_id, tp); +``` + +Interestingly, the problem doesn't occur on qemu-arm (little endian), all else equal. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 new file mode 100644 index 000000000..31e35832e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 @@ -0,0 +1,66 @@ + + + +linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly +Description of problem: +In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`. +Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html): + +> For getsockopt(), optlen is a value-result argument, initially + containing the size of the buffer pointed to by optval, and + modified on return to indicate the actual size of the value + returned. **If no option value is to be supplied** or returned, + **optval may be NULL.**" + +For me it sounds like accepting NULL without error (and x64 confirms that interpretation). +Steps to reproduce: +1. Use below toy program `getsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -std=gnu11 -pedantic getsockopt.c -o getsockopt +``` + +``` +#include <stdlib.h> +#include <unistd.h> +#include <errno.h> +#include <stdio.h> +#include <netinet/in.h> +#include <sys/socket.h> +#include <netinet/tcp.h> + +static void fail_on_error(int error, const char *msg) { + if (error < 0) { + perror(msg); + exit(errno); + } +} + +int main(int argc, char **argv) { + int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP); + fail_on_error(socketfd, "socket error"); + uint8_t *option_value = NULL; + int32_t len = 0; + int32_t *option_len = &len; + socklen_t opt_len = (socklen_t)*option_len; + int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len); + fail_on_error(status, "getsockopt error"); + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@57646f544f3a:/runtime/programs# ./getsockopt-x64 +root@57646f544f3a:/runtime/programs# ./getsockopt-riscv +getsockopt error: Bad address +``` +Additional information: +I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here: +[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522) + +Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space +instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) + +Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 new file mode 100644 index 000000000..ec48cb93e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 @@ -0,0 +1,95 @@ + + + +linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error +Description of problem: +It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`. +According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work". +Steps to reproduce: +1. Use below toy program `setsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt +``` + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <arpa/inet.h> +#include <netinet/in.h> +#include <unistd.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> + +int main() { + { + int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); + if(sd < 0) { + perror("Opening stream socket error"); + exit(1); + } + else + printf("Opening stream socket....OK.\n"); + + struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; + int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); + + if (err < 0) { + perror("Connect error"); + close(sd); + } + else + printf("Connect...OK.\n"); + } + { + int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); + if(sd < 0) { + perror("Opening stream socket error"); + exit(1); + } + else + printf("Opening stream socket....OK.\n"); + + char option[4] = {0}; + if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) { + perror("setsockopt error"); + close(sd); + exit(1); + } + else + printf("setsockopt...OK.\n"); + + struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; + int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); + + if (err < 0) { + perror("Connect error"); + close(sd); + } + else + printf("Connect...OK.\n"); + } + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@AMDC4705:~/runtime/connect$ ./setsockopt-x64 +Opening stream socket....OK. +Connect error: Network is unreachable +Opening stream socket....OK. +setsockopt...OK. +Connect error: Network is unreachable + +root@AMDC4705:/runtime/connect# ./setsockopt-riscv +Opening stream socket....OK. +Connect error: Network is unreachable +Opening stream socket....OK. +setsockopt error: Protocol not available +``` +Additional information: +In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. +From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 new file mode 100644 index 000000000..13ff21166 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 @@ -0,0 +1,63 @@ + + + +linux-user: Qemu doesn't support `set_robust_list` used by glibc robust mutex implementation +Description of problem: +It seems that syscall set_robust_list is not implemented on Qemu for any Linux platform: [link]( https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L12811) +Steps to reproduce: +1. Use below toy program `set_robust_list.c` and compile it without optimizations like: +``` + gcc -Wall -W -Wextra -std=gnu17 -pedantic set_robust_list.c -o set_robust_list +``` + +``` +#include <stdio.h> +#include <stdlib.h> +#include <errno.h> +#include <sys/syscall.h> +#include <sys/types.h> +#include <unistd.h> +#include <linux/futex.h> +#include <syscall.h> + +int main(void) +{ +#ifdef __NR_set_robust_list + struct robust_list_head head; + size_t len = sizeof(struct robust_list_head); + + // This call to set_robust_list function should fail + int err = syscall(__NR_set_robust_list, &head, -1); + if (err < 0) + perror("1st set_robust_list error"); + else + puts("1st set_robust_list OK"); + + // This call to set_robust_list function should be sucessful + err = syscall(__NR_set_robust_list, &head, len); + if (err < 0) + perror("2nd set_robust_list error"); + else + puts("2nd set_robust_list OK"); +#else + puts("No set_robust_list support"); +#endif + exit(0); +} +``` + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list +1st set_robust_list error: Invalid argument +2nd set_robust_list OK +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list-riscv +1st set_robust_list error: Function not implemented +2nd set_robust_list error: Function not implemented +``` +Additional information: +Working `set_robust_list` on Linux is quite important in context of named robust mutexes. In NPTL `set_robust_list` is used internally at ld.so initialization time to perform following check: [link](https://github.com/bminor/glibc/blob/master/sysdeps/nptl/dl-tls_init_tp.c#L96) + +When syscall fails, later `pthread_mutex_init` (with `PTHREAD_MUTEX_ROBUST` + `PTHREAD_PROCESS_SHARED` attributes) end up with `ENOTSUP` error [link](https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c#L99). + +In dotnet we use robust mutexes for process synchronization purpose. Although there are other available techniques like named semaphores or file locks, robust mutexes are better locking option in case of unexpected process death. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2485 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2485 new file mode 100644 index 000000000..31508fdf4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/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:32b/output/syscall/2553 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2553 new file mode 100644 index 000000000..f6a16c6da --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2553 @@ -0,0 +1,85 @@ + + + +Joining IP multicast fails when emulating 64-bit Linux +Description of problem: +I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. + +This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. + +I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: + +``` +struct target_ip_mreqn { + struct target_in_addr imr_multiaddr; + struct target_in_addr imr_address; + abi_long imr_ifindex; +}; +``` + +but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. + +I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? +Steps to reproduce: +1. take the following C program (distilled from a larger program): + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char *argv[]) +{ + int fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + perror("socket"); + return 1; + } + + struct ip_mreqn mreq; + mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); + mreq.imr_address.s_addr = htonl(INADDR_ANY); + mreq.imr_ifindex = 1; + int size = sizeof(mreq); + printf("size=%u\n", size); + if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, + (char*) &mreq, sizeof(mreq)) < 0) { + perror("setsockopt"); + return 1; + } + printf("OK\n"); + return 0; +} +``` + +2. confirm it works compiled native on amd64/x86_64: + +``` +[peter@amd64 misc]$ gcc mcast.c -o mcast +[peter@amd64 misc]$ ./mcast +size=12 +OK +``` + +3. watch it *not* work emulated: + +``` +[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 +[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 +size=12 +setsockopt: No such device +``` +Additional information: +If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: + + if (optlen < sizeof (struct target_ip_mreq) || + optlen > sizeof (struct target_ip_mreqn)) { + return -TARGET_EINVAL; + } + +Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! + +The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 new file mode 100644 index 000000000..6f7daacfc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 @@ -0,0 +1,40 @@ + + + +qemu-aarch64 cannot properly support some python functions from the `time` module +Description of problem: +When a function is run in python (for example, `time.time()`), python returns the following error: +``` +Traceback (most recent call last): + File "<string>", line 1, in <module> +OSError: [Errno 0] Error +``` +I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem. +Steps to reproduce: +Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts. +1. Create a simple codespace environment. +2. Run the following commands through the terminal: +``` +git clone https://github.com/termux-pacman/glibc-packages +cd glibc-packages +./get-build-package.sh +sudo mkdir /data +sudo chown codespace /data +sudo chgrp codespace /data +sudo apt update +sudo apt install patchelf +./scripts/setup-cgct.sh +``` +3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete. +``` +./build-package.sh -I -w --library glibc gpkg/gobject-introspection +``` +4. Install standard qemu via apt. +5. Run the following command: +``` +qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()" +``` +Additional information: +- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur. + - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502. +For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 new file mode 100644 index 000000000..f3908b636 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 @@ -0,0 +1,4 @@ + + + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 new file mode 100644 index 000000000..0af803764 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 @@ -0,0 +1,13 @@ + + + +golang 1.23 build hangs when running under qemu-user on x86_64 host +Description of problem: +Forwarded from https://github.com/golang/go/issues/70329. + +# +Steps to reproduce: +1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora. +2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 new file mode 100644 index 000000000..3b9132949 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 @@ -0,0 +1,4 @@ + + + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 new file mode 100644 index 000000000..367666b81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 @@ -0,0 +1,28 @@ + + + +getdtablesize() returns wrong value in qemu user mode on Linux/alpha +Description of problem: +The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. +Steps to reproduce: +[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) + +1. +``` +# apt install g++-10-alpha-linux-gnu +``` +2. +``` +$ alpha-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) + +3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. +4. +``` +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? +``` +Expected: `0` +Actual: `1` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 new file mode 100644 index 000000000..044d207a9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 @@ -0,0 +1,33 @@ + + + +getdomainname() is not implemented in QEMU user mode on Linux/sparc64 +Description of problem: +The `getdomainname()` function fails, instead of succeeding. +Steps to reproduce: +[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints +``` +result: (none) +``` +4. +``` +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out +``` +Expected: `result: (none)` +Actual: `getdomainname: Function not implemented` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 new file mode 100644 index 000000000..205f8cfbe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 @@ -0,0 +1,53 @@ + + + +chown() fails when it should succeed in QEMU user mode on Linux/sparc64 +Description of problem: +The `chown()` function fails, instead of succeeding, in a particular situation. +Steps to reproduce: +[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ ./a.out; echo $? +``` +It prints `0`. + +4. +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? +``` +Expected: `0` +Actual: +``` +chown: Operation not permitted +1 +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 new file mode 100644 index 000000000..3314ee07b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 @@ -0,0 +1,17 @@ + + + +user space emulation: openat() seems to defeat sysroot path translation +Description of problem: +It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. + +In particular, the sequence which fails is: +* create a file in `/tmp/`. +* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. +* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. +Steps to reproduce: +1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 +2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) +3. Try to run under `qemu-arm`. + +This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 new file mode 100644 index 000000000..a3ce6e4f0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 @@ -0,0 +1,45 @@ + + + +linux-user: sendmsg fails to send messages without iov +Description of problem: +When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux. + +A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526 + +A message without data but only ancillary data is used to set the IV. +Steps to reproduce: +See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`). + +(Test case is to be considered GPL, as I've copied bits from `ell`) + +Native: +``` +$ strace -esendmsg ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0 +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + + +Qemu (observe missing sendmsg call): +``` +$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + +For a practical reproducer: + +1. Compile and run `ell`'s `test-cipher` test case: + +``` +$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher +TEST: unsupported +TEST: aes +TEST: aes_ctr +test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed. +Aborted (core dumped) +``` + +A strace will look similar. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 new file mode 100644 index 000000000..5979c6a19 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 @@ -0,0 +1,88 @@ + + + +qemu-riscv32: Syscall LSEEK returns -14 (EFAULT) +Description of problem: +The lseek() system call returns -14 (EFAULT) if the file descriptor is correct, +which it should never do (According to the lseek(2) man page). + +Here is some demonstrative code: +``` +/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */ +.set SYS_OPENAT, 0x38 +.set SYS_CLOSE, 0x39 +.set SYS_LSEEK, 0x3e +.set SYS_READ, 0x3f +.set SYS_WRITE, 0x40 +.set SYS_EXIT, 0x5d + +.set SEEK_CUR, 1 + +/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */ +.set AT_FDCWD, (-100) + +.section .text +.global _start +_start: + +/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason. + Effectively: + s0 = open(argv[1], 0, 0644); */ +li a7, SYS_OPENAT +li a0, AT_FDCWD +lw a1, 8(sp) +li a2, 0 +li a3, 0644 +ecall + +/* Error checking. This succeeds. */ +blt a0, zero, unrelated_error + +mv s0, a0 + +/* The broken lseek() call. + Same also happens no matter the position in the file. + Effectively: + lseek(s0, 0, SEEK_CUR); */ +li a7, SYS_LSEEK +mv a0, s0 +li a1, 0 +li a2, SEEK_CUR +ecall + +/* XXX: lseek() returns -14 */ +blt a0, zero, lseek_error + +/* Close the file. */ +li a7, SYS_CLOSE +mv a0, s0 +ecall + +/* Error checking. This also succeeds. */ +blt a0, zero, unrelated_error + +/* exit(0); */ +li a7, SYS_EXIT +li a0, 0 +ecall + +/* exit(-return_value); */ +lseek_error: +li a7, SYS_EXIT +sub a0, zero, a0 +ecall + +unrelated_error: +li a7, SYS_EXIT +li a0, 128 +ecall +``` +Steps to reproduce: +1. riscv32-unknown-linux-gnu-as test.s -o test.o +2. riscv32-unknown-linux-gnu-ld test.o +3. qemu-riscv32 ./a.out test +4. echo $? # This returns 14 +Additional information: +Complete test setup: + +[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 new file mode 100644 index 000000000..1805ec8de --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 @@ -0,0 +1,64 @@ + + + +Occasional deadlock in linux-user (sh4) when running threadcount test +Description of problem: + +Steps to reproduce: +1. docker run --rm -it -u (id -u) -v $HOME:$HOME -w (pwd) qemu/debian-all-test-cross /bin/bash +2. '../../configure' '--cc=clang' '--cxx=clang++' '--disable-system' '--target-list-exclude=microblazeel-linux-user,aarch64_be-linux-user,i386-linux-user,m68k-linux-user,mipsn32el-linux-user,xtensaeb-linux-user' '--extra-cflags=-fsanitize=undefined' '--extra-cflags=-fno-sanitize-recover=undefined' +3. make; make build-tcg +4. retry.py -n 400 -c -- timeout --foreground 90 ./qemu-sh4 -plugin ./tests/plugin/libinsn.so -d plugin ./tests/tcg/sh4-linux-user/threadcount + +Failure rate on hackbox: + +``` +Results summary: +0: 397 times (99.25%), avg time 0.686 (0.00 varience/0.01 deviation) +124: 3 times (0.75%), avg time 90.559 (0.00 varience/0.01 deviation) +``` + +It seems to fail more frequently on Gitlabs CI +Additional information: +Without the timeout you end up with a deadlock. The following backtrace was found, stepping in gdb unwedges the hang: + +``` +(gdb) info threads + Id Target Id Frame +* 1 LWP 15894 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 + 2 LWP 15994 "qemu-sh4" 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 + 3 LWP 15997 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=22760, arg4=<optimized out>, arg5=<optimized out>, arg6=240, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee294b028) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee16ee37d in main (argc=-493657104, argv=0x7ffdcaf52028, envp=<optimized out>) at ../../linux-user/main.c:883 +(gdb) thread 2 +[Switching to thread 2 (LWP 15994)] +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) bt +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +#1 0x0000560ee1847bd6 in qemu_futex_wait (f=<optimized out>, val=<optimized out>) at /home/alex.bennee/lsrc/qemu.git/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=0x560ee2738974 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:481 +#3 0x0000560ee18539a2 in call_rcu_thread (opaque=<optimized out>) at ../../util/rcu.c:261 +#4 0x0000560ee1847f17 in qemu_thread_start (args=0x560ee2933eb0) at ../../util/qemu-thread-posix.c:556 +#5 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#6 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) thread 3 +[Switching to thread 3 (LWP 15997)] +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +75 cmp $-4095, %rax +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=2, arg4=<optimized out>, arg5=<optimized out>, arg6=1065340356, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee2a2c2d8) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee171728f in clone_func (arg=<optimized out>) at ../../linux-user/syscall.c:6608 +#7 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#8 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 new file mode 100644 index 000000000..e60fa91d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 @@ -0,0 +1,17 @@ + + + +qemu-x86_64 don't support unshare(CLONE_NEWUSER) +Description of problem: +Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +``` +Steps to reproduce: +1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that? diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 new file mode 100644 index 000000000..97df04d6d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 @@ -0,0 +1,4 @@ + + + +linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 new file mode 100644 index 000000000..f54a96ae3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 @@ -0,0 +1,20 @@ + + + +Unable to strace execve calls in mipsel user mode +Description of problem: +Used 6.2.0 ZIP and git to build, configured with +``` +./configure --target-list=mipsel-linux-user --static --disable-system --enable-linux-user +``` + +When trying to strace a mipsel-arch application, I cannot see traces for the `execve` syscall. It looks like the call to `safe_execve` is not returning, so the strace printout is never completed. I'm assuming this has to do with `execve` syscall not returning on success, but older versions appeared to be able to do it. I tried it with QEMU 4.2.1 from the package manager on Ubuntu and I saw the `execve` syscall (see qemu-4.2.1.log). +Steps to reproduce: +1. Build mipsel app: ` mipsel-linux-gnu-gcc -o test.mipsel test.c` (Test code is attached as `test.c`) +2. Run qemu-mipsel: `./build/qemu-mipsel -L /usr/mipsel-linux-gnu/ -strace ../test.mipsel` +3. Note that even though the app uses both `system` and `popen` to create subprocesses, no `execve` syscall is shown in the strace output. +Additional information: +[qemu-6.2.90.log](/uploads/ca03e6f40b3b0ea79a042786a123760a/qemu-6.2.90.log) +[qemu-6.2.0.log](/uploads/ca15057398377d49b396e9e77a5cb639/qemu-6.2.0.log) +[qemu-4.2.1.log](/uploads/1087250dd9fc4d8d106d2cbc58c2b14a/qemu-4.2.1.log) +[test.c](/uploads/9d242a724b10b296cfd7a945ae4d6c4d/test.c) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 new file mode 100644 index 000000000..7a39f030c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 @@ -0,0 +1,35 @@ + + + +linux-user: openat on /proc/self/exe can return a closed file descriptor +Description of problem: +`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. + +When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. + +`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. +Steps to reproduce: +This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). + +```c +#include <fcntl.h> +#include <stdio.h> + +int main(int argc, char **argv) { + int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); + if (selfexe < 0) { + perror("open self"); + return 1; + } + + int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); + if (devnull < 0) { + perror("open devnull"); + return 1; + } + + printf("%d %d\n", selfexe, devnull); +} +``` +Additional information: +Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 new file mode 100644 index 000000000..e5e185f1c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 @@ -0,0 +1,74 @@ + + + +qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code." +Description of problem: +The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is +``` +The futex facility returned an unexpected error code. +``` + +Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``. + +Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument". + + +``` +116876 get_thread_area(0x00000001) = 989882672 +116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672 + = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744 +futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000) + = 1065219744 +0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744 +116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument) + = 0 + = 116876 get_thread_area(0x3f7d4c34)1 = +116876 get_thread_area(0x00000000) = 1065219744 +926968112 +116876 get_thread_area(0x00000016) = 926968112 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000001)116876 = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112 +116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE +,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112 +1065219744 +116876 get_thread_area(0x00000001)116876 = 1065219744 +1073732112) = 116876 -1 errno=22 (Invalid argument) +futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112) +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0 +116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 + = 0 +116876 get_thread_area(0x40053a8c) = 885025072 +116876 get_thread_area(0x00000001) = 885025072 +116876 get_thread_area(0x00b4b456) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 Unknown syscall 403 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00003baa) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112 +116876 get_thread_area(0x00000018) = 926968112 +116876 get_thread_area(0x3ed5b9c8) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x0000000f) = 926968112116876 = 0 + +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112 +The futex facility returned an unexpected error code. +116876 get_thread_area(0x3f7d4c30) = 885025072 +``` + +Advice on how to do further debuggging is appreciated. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 new file mode 100644 index 000000000..7302cb49d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 @@ -0,0 +1,40 @@ + + + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1022 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1022 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1022 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1027 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1027 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1027 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1051 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1051 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1051 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1054812 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1054812 new file mode 100644 index 000000000..cc0115010 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1054812 @@ -0,0 +1,11 @@ +The bug report describes an issue where the wrong `libtool` is used during the configuration process on Darwin/OS X, leading to build failures for `libcacard` that QEMU relies on. The user suggests modifying the configure script to check for the correct `libtool` when running on Darwin. + +To classify this issue: + +- **Instruction**: This relates to a faulty instruction or step in the build process. +- **Syscall**: Not applicable, as it's not related to system calls. +- **Runtime**: Not applicable, since the error occurs during configuration, not runtime execution. + +The problem arises because the wrong `libtool` is used during configuration, which is part of the build instructions. Therefore, this bug falls under the **instruction** category. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1075 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1075 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1075 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1079080 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1079080 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1079080 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1092 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1092 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1092 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095531 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095531 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095531 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095857 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095857 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1095857 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1129571 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1129571 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1129571 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1156 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1156 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1156 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1178 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1178 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1178 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1207896 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1207896 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1207896 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1233225 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1233225 new file mode 100644 index 000000000..6b11da11f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1233225 @@ -0,0 +1,7 @@ +The issue described seems to be related to how floating-point division is handled when running the program under QEMU user mode for MIPS/MIPSEL architectures. The problem arises because the cross-compiled binary produces incorrect output (2.0 instead of 0.5) when executed in QEMU user mode, but works correctly in a fully emulated environment or when compiled and run natively within that environment. + +This suggests there might be an issue with how the floating-point division is being handled by QEMU's user-mode emulation for MIPS/MIPSEL targets. The correct output (0.5) is achieved both when running in a full VM and when using the native compiler inside the VM, indicating that the cross-compiler itself isn't the source of the problem. + +The discrepancy likely points to an issue within QEMU's handling of certain instructions or operations under user mode for these architectures. Specifically, it could involve how floating-point operations are being emulated or translated in this context. + +**category: instruction** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1245543 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1245543 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1245543 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248168 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248168 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1248168 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1251 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1251 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1251 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1254786 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1254786 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1254786 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1283519 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1283519 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1283519 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1308381 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1308381 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1308381 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1328996 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1328996 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1328996 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1339 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1339 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1339 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1368 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1368 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1368 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1370 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1370 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1370 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1371 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1371 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1371 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1372 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1372 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1372 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1373 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1373 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1373 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1374 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1374 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1374 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1375 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1375 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1375 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1376 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1376 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1376 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1377 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1377 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1377 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1397 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1397 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1397 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1404690 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1404690 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1404690 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1412 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1412 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1412 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1428352 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1428352 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1428352 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1441 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1441 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1441 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1452 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1452 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1452 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1469342 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1469342 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1469342 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1531 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1531 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1531 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1536 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1536 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1536 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1547 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1547 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1547 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1574346 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1574346 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1574346 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1590336 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1590336 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1590336 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1594069 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1594069 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1594069 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1605123 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1605123 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1605123 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1606 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1606 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1606 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1611394 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1611394 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1611394 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1612 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1612 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1612 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1613817 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1613817 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1613817 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1614348 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1614348 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1614348 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1620 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1620 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1620 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1637 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1637 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1637 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1641637 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1641637 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1641637 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1642 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1642 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1642 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1661815 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1661815 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1661815 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1713066 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1713066 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1713066 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1722 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1722 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1722 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1725267 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1725267 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1725267 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1737 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1737 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1737 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1738434 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1738434 new file mode 100644 index 000000000..6dc52ec42 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1738434 @@ -0,0 +1,12 @@ +The issue reported relates to how QEMU handles certain assembly instructions when running 32-bit code under WoW64 on a 64-bit Windows guest OS. Specifically, the problem occurs with the `call fword ptr[esp]` instruction and the use of selector 0x33h, which is not correctly handled by QEMU but works fine in real hardware and VMware. + +### Analysis: +1. **Instruction Handling**: The core issue lies in how QEMU processes the `call fword ptr[esp]` instruction when using a specific selector (0x33h). This instruction is meant to perform a far call, which involves switching segments or modes. +2. **Selector 0x33h vs. 0x23h**: Using 0x33h causes an access violation in QEMU, while 0x23h works correctly. This suggests that QEMU's handling of certain selectors (specifically those intended for switching to a different mode) is flawed. +3. **Heaven's Gate Mechanism**: The `call fword ptr[esp]` with selector 0x33h is attempting to use the "Heaven's gate" method to switch from 32-bit to 64-bit mode in WoW64. This mechanism relies on specific segment selectors, and QEMU's incorrect handling leads to crashes. +4. **Environmental Factors**: The issue occurs only under specific conditions—QEMU version 2.10.93 with Windows 7 x64 SP1 or Windows 10 v1709 as the guest OS. It works correctly on real hardware and VMware, indicating a potential bug in QEMU's emulation. + +### Conclusion: +The problem is rooted in how QEMU handles specific instructions (`call fword ptr[esp]`) and selectors (0x33h), particularly when attempting to switch modes via "Heaven's gate." This falls under the category of **instruction** handling, as the issue is directly tied to the processing of these assembly commands. + +(instruction) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1748296 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1748296 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1748296 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751422 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751422 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751422 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751494 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751494 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1751494 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1756927 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1756927 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1756927 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1761401 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1761401 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1761401 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1771 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1771 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1771 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1779 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1779 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1779 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1780 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1780 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1780 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1781281 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1781281 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1781281 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1785734 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1785734 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1785734 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1790 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1790 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1790 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793119 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793119 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793119 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793608 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793608 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1793608 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1806243 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1806243 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1806243 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1815024 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1815024 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1815024 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1818075 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1818075 new file mode 100644 index 000000000..b7f868aad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1818075 @@ -0,0 +1,5 @@ +The issue is related to QEMU's TCG (Translation Cache Generator) not supporting certain AVX instructions when emulating a Skylake CPU. The code built with AVX2 instructions causes QEMU to hang due to unsupported features. + +The problem lies in the instruction execution within the emulator, specifically handling AVX operations which are not fully supported by the current TCG implementation. + +**instruction** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1820686 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1820686 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1820686 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821430 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821430 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821430 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821515 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821515 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1821515 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1824778 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1824778 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1824778 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1826568 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1826568 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1826568 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1828867 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1828867 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1828867 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1832422 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1832422 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1832422 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833 new file mode 100644 index 000000000..20bb95a64 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833 @@ -0,0 +1,3 @@ +The issue described pertains to an incorrect implementation of the ARM64 SME ST1Q instruction within QEMU, where the helper function incorrectly handles the storage of bytes, leading to data corruption. This is categorized under instruction errors. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833668 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833668 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1833668 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1841990 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1841990 new file mode 100644 index 000000000..919c936b8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1841990 @@ -0,0 +1,5 @@ +The given bug report is about an issue with the `denbcdq` instruction not behaving as expected. The user provided test cases showing discrepancies between native execution on ppc64le and QEMU's emulation. They also mentioned confusion about potential issues related to endianness or floating-point register handling. + +Based on the description, this seems to be a problem related to how an instruction is handled in the emulator. Therefore, it falls under the **instruction** category. + +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1847467 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1847467 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1847467 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1857 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1857 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1857 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1858415 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1858415 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1858415 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1859713 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1859713 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1859713 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861404 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861404 new file mode 100644 index 000000000..d101a6db5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861404 @@ -0,0 +1,5 @@ +The bug report describes an issue with the VMOVDQU AVX instruction not handling YMM registers correctly in QEMU. The problem is that when copying data from memory to a YMM register (32 bytes) and back, only the first 16 bytes are copied instead of the full 32 bytes. This suggests that the implementation of `gen_ldo_env_A0` in `translate.c` is incorrect for YMM registers, as it currently performs two 8-byte operations, each copying half the data. + +This issue falls under the category of an instruction error since it directly relates to the faulty handling of a specific AVX instruction (VMOVDQU) when dealing with YMM registers. The problem occurs during runtime when executing this instruction, leading to incorrect behavior. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861605 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861605 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1861605 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1863247 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1863247 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1863247 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1869782 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1869782 new file mode 100644 index 000000000..1c5d2fa72 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1869782 @@ -0,0 +1,3 @@ +The issue described involves `qemu-arm-static` crashing with a segmentation fault when running "svn checkout". This is likely due to an incorrect instruction being executed by QEMU while emulating the ARM architecture. Therefore, this falls under the **instruction** category. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1873898 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1873898 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1873898 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1874888 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1874888 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1874888 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1877794 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1877794 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1877794 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1881450 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1881450 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1881450 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1883268 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1883268 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1883268 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1889288 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1889288 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1889288 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1898954 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1898954 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1898954 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1901 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1901 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1901 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1904210 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1904210 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1904210 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1905356 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1905356 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1905356 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908626 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908626 new file mode 100644 index 000000000..3036d935e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1908626 @@ -0,0 +1,7 @@ +The issue reported seems to involve the `atomic test-and-set` instruction not working correctly when running PostgreSQL or Greenplum database inside a Docker container using QEMU's user-static emulation for ARM64. The spinlock mechanism is getting stuck and causing PANIC errors, which suggests a problem with atomic operations. + +Given that the code works on a physical ARM64 server but fails in the emulated environment, it points towards an issue with how QEMU handles certain instructions or memory operations. Specifically, the `test-and-set` instruction is likely not functioning as expected under QEMU's user-mode emulation. + +The classification of this bug would fall under the **instruction** category since it involves a specific atomic instruction (`test-and-set`) that isn't behaving correctly in the emulated environment. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1909 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1909 new file mode 100644 index 000000000..d1ec63aad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1909 @@ -0,0 +1,9 @@ +The problem occurs during the execution of a test program under QEMU 8.0.0 when using the `--coverage` option. The segfault is traced to an attempt to increment a gcov counter, specifically at address `0x4fe9d0`, which corresponds to `__llvm_gcov_ctr.5`. The instruction causing the issue is `str x8, [x9, #2512]`, where `$x8` holds the value 1 and `$x9` points to `0x4fe9d0 - 2512 = 0x4fe9d0 - 0x9c0 = 0x4f40d0`. The memory at this address is mapped but appears uninitialized. + +When running the same test program under QEMU 6.2.0, it does not segfault at this point, though a different segfault occurs later due to a bug in the test program itself. + +This issue seems related to how QEMU handles certain memory operations or instructions when coverage instrumentation is enabled. The difference between versions suggests that a change in QEMU's handling of such operations might have introduced the regression. + +Given the context provided, the most likely category for this bug is **instruction** since it involves an instruction execution causing a segfault during program runtime. + +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1910 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1910 new file mode 100644 index 000000000..cd2935679 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1910 @@ -0,0 +1,7 @@ +The issue described relates to signal handling within QEMU where the stack alignment during signal handlers is incorrect, leading to crashes. The problem occurs when the `movaps` instruction is executed with an unaligned stack address. This misalignment arises because the kernel's stack adjustment for signal handlers does not adhere to the x86_64 ABI requirements. + +The kernel code provided attempts to align the stack pointer but may incorrectly adjust it, resulting in a misaligned stack when entering a signal handler. Specifically, the current implementation subtracts 8 bytes after rounding down, which can lead to an incorrect alignment for certain cases. + +To fix this issue, the stack adjustment needs to ensure that the stack pointer remains properly aligned according to the x86_64 ABI, especially when handling signals in user space applications like Ruby. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1912934 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1912934 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1912934 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1913913 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1913913 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1913913 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1914021 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1914021 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1914021 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1915327 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1915327 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1915327 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1916269 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1916269 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1916269 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1918026 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1918026 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1918026 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1922887 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1922887 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1922887 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1925512 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1925512 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1925512 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926044 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926044 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926044 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926202 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926202 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926202 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926759 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926759 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1926759 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1941 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1941 new file mode 100644 index 000000000..921c0a9fd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1941 @@ -0,0 +1,3 @@ +The problem reported involves incorrect behavior of certain VSX vector conversion instructions when handling NaN values, leading to unexpected results in integer conversions. This is related to how QEMU emulates these instructions for the PPC64 architecture. The issue falls under the emulation or instruction processing within QEMU. + +**Answer:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1955 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1955 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1955 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1967248 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1967248 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/1967248 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2072564 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2072564 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2072564 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2078 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2078 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2078 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2083 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2083 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2083 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2089 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2089 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2089 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2136 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2136 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2136 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2175 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2175 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2175 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2203 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2203 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2203 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2248 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2248 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2248 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2302 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2302 new file mode 100644 index 000000000..947aba48f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2302 @@ -0,0 +1,10 @@ +The issue described involves an "Illegal Instruction" crash when running SPEC CPU 2017 benchmarks using qemu-x86_64. The debugging output shows specific instructions being executed before the crash, which suggests that there is a problem with how certain x86-64 instructions are handled by QEMU. + +**Step-by-step explanation:** + +1. **Understanding the Error:** The error message "Illegal Instruction" indicates that QEMU encountered an instruction it couldn't execute or emulate properly. +2. **Looking at the Instructions:** The provided disassembly includes instructions like `movq`, `jmp`, and others, but there's a `.byte 0x62` which could represent a malformed or unrecognized instruction. +3. **Identifying the Category:** Since the crash is due to an invalid or unhandled instruction, it falls under the "instruction" category. + +**Answer:** +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2317 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2317 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2317 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2318 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2318 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2318 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2319 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2319 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2319 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2371 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2371 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2371 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2372 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2372 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2372 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2373 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2373 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2373 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2374 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2374 new file mode 100644 index 000000000..6d5ad3336 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2374 @@ -0,0 +1,3 @@ +The bug report describes an issue related to the handling of NaNs in the `fmopa` instruction within the QEMU emulator. Specifically, the 32-bit variant of this instruction does not generate default NaNs due to an invalid float_status pointer being passed. This is a problem with how the instruction is implemented in the emulator. + +**Category: instruction** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2375 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2375 new file mode 100644 index 000000000..4afc80912 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2375 @@ -0,0 +1,3 @@ +The bug reported is related to the behavior of an assembly instruction (`fjcvtzs`) within QEMU's implementation of AArch64 instructions. Specifically, it involves how floating-point operations are handled when certain flags in the FPCR register are set. + +**Classification:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2386 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2386 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2386 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2419 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2419 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2419 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2422 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2422 new file mode 100644 index 000000000..035284334 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2422 @@ -0,0 +1,3 @@ +The bug report describes an issue where QEMU does not set the `vill` flag as specified by the RISC-V V Spec 1.0 when using a reserved form of the `vsetvli` instruction. This is related to how instructions are handled in QEMU, specifically the vector extension (V) instructions. + +**Category:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2474 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2474 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2474 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2483 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2483 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2483 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2487 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2487 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2487 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2495 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2495 new file mode 100644 index 000000000..aaacdaae9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2495 @@ -0,0 +1,4 @@ +The problem described involves MMX instructions and how QEMU handles them when redundant REX prefixes are present. Specifically, the issue arises during the translation of certain x86-64 instructions, leading to incorrect TCG code generation. This affects instruction processing. + +**Answer:** +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2497 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2497 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2497 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2498 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2498 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2498 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2499 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2499 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2499 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2500 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2500 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2500 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2504 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2504 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2504 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2536 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2536 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2536 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2569 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2569 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2569 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2595 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2595 new file mode 100644 index 000000000..115cc6d06 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2595 @@ -0,0 +1,3 @@ +The bug report describes an issue with the incorrect behavior of SDOT and UDOT instructions in QEMU when using 64-bit SVE (Scalable Vector Extension) vectors. The problem occurs specifically when the vector length is set to 64 or higher, leading to discrepancies between the expected results and those produced by QEMU. + +**Classification:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2604 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2604 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2604 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/266 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/266 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/266 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2672 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2672 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2672 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2696 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2696 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2696 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2730 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2730 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2730 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2775 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2775 new file mode 100644 index 000000000..7b70b385a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2775 @@ -0,0 +1,3 @@ +The issue is related to an internal assertion failure during code generation for the SPARC64 architecture in QEMU. The error occurs when executing specific instructions, leading to a crash. This suggests that the problem lies within the handling of certain instructions or their translation. + +**Category:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2802 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2802 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2802 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2865 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2865 new file mode 100644 index 000000000..d808865d6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2865 @@ -0,0 +1,8 @@ +The bug reported involves an incorrect implementation of the `xvldi` instruction in QEMU's LoongArch64 emulation. The issue arises from a mistake in the vector load immediate (VLDI) instruction handling, specifically how the data is being constructed. In the provided code snippet from `insn_trans/trans_vec.c.inc`, the case for `case 1:` incorrectly computes the `data` value as `(t << 24) | (t << 8)`. This results in an incorrect pattern of bytes being replicated across the vector, leading to unexpected output when running the test program under QEMU. + +The correct computation should be `(t << (8+32)) | (t << 8)` to properly replicate the immediate value across all lanes. The problem is isolated to the instruction translation and execution within QEMU's emulation of LoongArch64 instructions, specifically the `xvldi` instruction. + +### Bug Classification +The issue pertains to an error in handling a specific instruction (`xvldi`) during its translation and execution in QEMU. This makes it fall under the category related to faulty instruction implementation. + +**Category:** instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2878 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2878 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2878 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2971 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2971 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/2971 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/312 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/312 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/312 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/333 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/333 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/333 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/361 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/361 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/361 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/364 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/364 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/364 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/381 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/381 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/381 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/390 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/390 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/390 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/422 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/422 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/422 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/427 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/427 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/427 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/494 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/494 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/494 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/508 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/508 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/508 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/514 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/514 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/514 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/625 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/625 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/625 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/645662 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/645662 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/645662 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/695 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/695 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/695 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/754 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/754 new file mode 100644 index 000000000..a5ffd6e4c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/754 @@ -0,0 +1,3 @@ +The issue appears to be related to incorrect instruction execution within QEMU's emulation of the m68020 CPU. Specifically, certain instructions are not being executed as expected, and an extra instruction is appearing in the trace. This suggests a problem with how the disassembler or translator is handling specific opcodes. + +(instruction) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/799 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/799 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/799 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/824 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/824 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/824 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/826 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/826 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/826 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/837 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/837 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/837 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/890 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/890 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/890 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/904308 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/904308 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/904308 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/947 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/947 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/947 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/952 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/952 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/952 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/984 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/984 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/984 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/993 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/993 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/993 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/998 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/998 new file mode 100644 index 000000000..9b8a572c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/instruction/998 @@ -0,0 +1 @@ +instruction \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1072 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1072 new file mode 100644 index 000000000..417f3887d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1072 @@ -0,0 +1,9 @@ +The issue described involves differences in behavior when running QEMU directly versus using a remote debugger (GDB). The problem is related to how file descriptors are handled, specifically whether `stdout` is recognized as a character special device (`S_ISCHR`). + +This seems to be related to how the file descriptor for `stdout` is set up differently when debugging. When running under GDB, certain behaviors or setups might differ compared to standalone execution. + +The category of this bug would likely fall under: + +**runtime** + +Since it's an issue that occurs during runtime and relates to file descriptor handling and behavior differences between debugged and non-debugged executions. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1156313 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1156313 new file mode 100644 index 000000000..17a35d8c1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1156313 @@ -0,0 +1,7 @@ +The bug report describes issues related to improper handling of flags on x86-64, specifically mentioning the ADX feature and providing a test case involving assembly instructions (ADOX and ADCX). The problem seems to stem from how QEMU manages CPU flags during context switches, which affects instruction execution. Therefore, it falls under the category where a faulty instruction is described. + +**instruction** + +The bug report discusses improper handling of specific x86-64 instructions (ADOX and ADCX) within the QEMU emulator. It provides an example test case that demonstrates incorrect behavior when these instructions are executed in a virtualized environment. The issue appears to be related to how QEMU manages CPU flags, leading to unexpected results or system instability. + +The category **instruction** is appropriate because the problem is directly tied to the execution of specific assembly instructions and their handling within the emulator, indicating a potential fault in how these instructions are processed by QEMU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1267955 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1267955 new file mode 100644 index 000000000..b2294aadc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1267955 @@ -0,0 +1,27 @@ +The issue involves the behavior of the XOR instruction affecting the parity flag in QEMU's i386 emulation. The bug is related to how the emulator handles specific instructions and their impact on CPU flags. + +**Step-by-step explanation:** + +1. **Reproduction Steps:** + - A program was created with machine code that includes `xor %eax, %eax` followed by other instructions. + - Running this program directly outputs `0x46`. + - Running it under QEMU's i386 emulator outputs `0x42`. + +2. **Analysis of the XOR Instruction:** + - The `xor %eax, %eax` instruction sets `%eax` to 0 and affects CPU flags. + - In this case, the parity flag (`PF`) should be set because the result is zero. + +3. **Parity Flag Behavior:** + - The parity flag is set based on whether there are an even number of 1s in the lower byte of the result. + - Zero (0x00) has all bits as 0, which results in even parity, so `PF` should be set. + +4. **Issue Identification:** + - When using `xor %eax, %eax`, QEMU does not correctly set the parity flag, leading to unexpected behavior. + - Replacing it with `sub %eax, %eax` (which also sets `%eax` to 0) works as expected. + +5. **Conclusion:** + - The problem lies in how QEMU handles the XOR instruction's effect on the parity flag compared to other instructions that produce the same result. + +**Answer:** + +The bug is classified under the `instruction` category because it relates to how a specific instruction (XOR) affects CPU flags within QEMU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1311614 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1311614 new file mode 100644 index 000000000..f2f265b0d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1311614 @@ -0,0 +1,7 @@ +The issue involves `qemu-arm` segfaulting when using GCC 4.9.0. The problem arose after upgrading from GCC 4.8.3 to 4.9.0 and was resolved by reverting to the older version. This suggests a compatibility issue between `qemu-arm` and GCC 4.9.0, likely related to how the compiler generates code or interacts with the emulator. + +Given that the segfault occurs during runtime when running commands like `rpm`, it's not an instruction-level fault nor is it directly tied to a syscall error. Instead, it's an issue that arises during the execution of programs compiled with GCC 4.9.0 within the QEMU environment. + +**runtime** + +The problem falls under the "runtime" category because it occurs during the execution of software after compilation, indicating issues in how the emulator handles the code produced by the newer compiler version. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1346769 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1346769 new file mode 100644 index 000000000..a2215794d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1346769 @@ -0,0 +1,13 @@ +The issue arises because the QEMU emulator isn't correctly handling the `/proc/self/maps` file for 32-bit guests running under a 64-bit QEMU environment. Specifically, when address sanitizer (Asan) is used in such a setup, it fails to find stack boundaries, leading to an error during initialization. + +Looking at the provided code snippet from `linux-user/syscall.c`, it seems that only certain architectures (like ARM and M68K) have support for writing stack information into `/proc/self/maps`. However, this functionality is missing for other targets like x86_32, which causes Asan to fail when trying to determine the stack boundaries. + +This problem is not isolated; there was a previous report related to system maps not being hidden properly in QEMU. The current issue likely stems from similar root causes, where the handling of process maps isn't consistent across all architectures. + +To classify this bug: + +- **Instruction:** No specific instruction-level issues are mentioned. +- **Syscall:** The problem relates to how `/proc/self/maps` is handled during syscalls, particularly when Asan relies on it for stack information. +- **Runtime:** While the error occurs at runtime, the root cause is more tied to how QEMU implements certain system calls. + +Given that the issue is centered around how QEMU manages the `/proc/self/maps` file and reports stack boundaries (or lack thereof), it falls under the `syscall` category because it involves errors in handling system call-related functionalities specific to process mapping. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1388 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1388 new file mode 100644 index 000000000..7bec862a4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1388 @@ -0,0 +1,9 @@ +The issue reported is about the absence of Windows installers for QEMU 7.2.0 on specific repositories. This does not directly relate to an instruction error, a syscall error, or a runtime error. Instead, it pertains to the availability of distribution files. + +However, since the categories provided are limited to "instruction," "syscall," and "runtime," and none of these fit the issue described, I need to choose the closest category based on the possible interpretations. + +Given that the issue is about missing installers which could be seen as a runtime problem (since it affects the installation process), I will classify it under: + +**runtime** + +This classification assumes that the absence of installers impacts the ability to run QEMU properly, even though it's more about distribution rather than an error during execution. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1416988 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1416988 new file mode 100644 index 000000000..c2397bbaa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1416988 @@ -0,0 +1,31 @@ +The issue arises because the `siginfo` structure size differs between the Linux kernel and QEMU's implementation. This leads to an incorrect handling of signals when running binaries under QEMU that rely on proper signal information, such as during stack unwinding. + +To fix this, we need to adjust how `SI_PAD_SIZE` is calculated in QEMU's header file to match the Linux kernel's definition. The correct calculation should account for the preamble size and ensure that the structure padding aligns with what the kernel expects. + +Here is the corrected patch: + +```diff +--- a/linux-user/syscall_defs.h ++++ b/linux-user/syscall_defs.h +@@ -103,7 +103,8 @@ enum target_si_code { + #define TARGET_SI_NOINFO (TARGET_SI_MAX_USER) + #endif + +-#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) ++#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) ++#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) + + #ifndef TARGET_SI_FDSIZE + #define TARGET_SI_FDSIZE (TARGET_SI_FBITS/SIZEOF_LONG) +``` + +This adjustment ensures that the `siginfo` structure within QEMU aligns with the one used by the Linux kernel, resolving the signal handling issues and preventing segmentation faults or infinite loops during stack unwinding operations. + +After applying this patch, rebuild QEMU to incorporate these changes. +</think> + +The bug report describes an issue related to incorrect signal handling in the QEMU-aarch64 emulator due to a mismatch between the `siginfo` structure sizes used by the Linux kernel and QEMU. Specifically, the size of `struct target_siginfo` in QEMU is larger than that of `struct siginfo` in the kernel, leading to problems such as segmentation faults or infinite loops when running certain applications. + +**Category: runtime** + +The issue occurs during runtime when handling signals, which is why it falls under the "runtime" category. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1462640 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1462640 new file mode 100644 index 000000000..a614464ac --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1462640 @@ -0,0 +1,3 @@ +The bug report describes an issue where `shmat()` fails when running a 32-bit guest program on a 64-bit host using QEMU. The problem arises due to conflicting `mmap` flags—specifically, the initial mapping uses `MAP_PRIVATE`, and `shmat()` attempts to use `MAP_SHARED`, which is not allowed. + +The issue can be classified as a **runtime** error because it occurs during the execution of the program when interacting with shared memory. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1533141 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1533141 new file mode 100644 index 000000000..f350b1e4e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1533141 @@ -0,0 +1 @@ +style \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1541 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1541 new file mode 100644 index 000000000..c43611b5c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1541 @@ -0,0 +1,5 @@ +The problem is related to how attributes are applied in C++. The `G_NORETURN` macro expands to `[[noreturn]]`, which is an attribute specifier. In C++, attribute specifiers must appear in specific positions, typically before the return type or after certain keywords like `extern`. Placing `extern` after `G_NORETURN` causes a syntax error because it's not valid for the attribute to come after the storage class specifier. + +To fix this, you should switch the order of `extern` and `G_NORETURN`, placing the attribute before `extern`. + +This issue is related to **instruction** as it involves incorrect usage of language features leading to compilation errors. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1550503 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1550503 new file mode 100644 index 000000000..f350b1e4e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1550503 @@ -0,0 +1 @@ +style \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1553 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1553 new file mode 100644 index 000000000..12018e306 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1553 @@ -0,0 +1,40 @@ +The problem arises during the build process when compiling `spice-core.c`. The compiler reports an implicit declaration of `qemu_close_to_socket`, indicating that this function is not declared before it's used. + +Looking into the source code, in other parts like `ui/qemu-cursor.c` and `ui/spice-display.c`, functions like `qemu_display_cursor_set` are used without prior declaration because they're declared as `extern` in `qemu-ui.h`. However, `qemu_close_to_socket` isn't declared anywhere, which leads to the error. + +The fix is straightforward: declaring `qemu_close_to_socket` as an external function in the appropriate header file ensures it's visible to all parts of the code that use it. This declaration should be added to `ui/qemu-ui.h` to resolve the implicit declaration issue. +</think> + +To fix this bug, we need to ensure that the function `qemu_close_to_socket` is properly declared before it is used in `spice-core.c`. The solution involves adding an external declaration of `qemu_close_to_socket` in the appropriate header file. + +**Step-by-step explanation:** + +1. **Identify the Missing Declaration:** + The error indicates that `qemu_close_to_socket` is not declared before it's used in `spice-core.c`. + +2. **Locate the Function Definition:** + Search through the codebase to find where `qemu_close_to_socket` is defined. + +3. **Add an External Declaration:** + Add `extern void qemu_close_to_socket(int fd);` in a header file that's included by `spice-core.c`. + +**Implementation:** + +Add the following line to `ui/qemu-ui.h`: + +```c +extern void qemu_close_to_socket(int fd); +``` + +This declaration makes `qemu_close_to_socket` visible to other source files, resolving the implicit declaration error. + +**Result:** +After this change, rebuild the project. The compiler will no longer report the implicit function declaration error since the function is now properly declared before use. + +```bash +# After making changes, rebuild +./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu +cd build && make +``` + +The build should proceed without errors related to `qemu_close_to_socket`. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1594394 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1594394 new file mode 100644 index 000000000..ffb370a0b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1594394 @@ -0,0 +1,6 @@ +The issue arises from the use of setreuid() or setegid() functions within user-mode x86_64 code execution under QEMU. These functions are implemented using a signal-based mechanism in NPTL (Native POSIX Threads Library) to invoke syscalls indirectly. Specifically, they utilize a temporary data structure (__xidcmd) and trigger a real-time signal (SIGRT1). However, when running under QEMU, this process causes a segmentation fault because __xidcmd remains uninitialized (null), leading to an invalid memory access during the signal handler execution. + +The classification of this bug is related to how system calls are handled within the user-mode emulation provided by QEMU. The problem occurs at runtime due to improper handling of the internal NPTL mechanisms used for privilege changes, resulting in a crash when attempting to manipulate thread IDs via setreuid() or setegid(). This indicates an issue with how syscalls related to user and group IDs are being processed under certain conditions within the QEMU environment. + +**Answer:** +The bug is classified under **"runtime"** as it pertains to errors occurring during runtime, specifically due to improper handling of system calls related to thread ID changes in a multi-threaded environment under QEMU's emulation. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1716767 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1716767 new file mode 100644 index 000000000..134abca00 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1716767 @@ -0,0 +1,5 @@ +The issue occurs when using `file(1)` on an SH4 QEMU user emulator with an ELF file, resulting in "Invalid argument". Debugging shows overflown values during processing. This suggests a problem within the QEMU environment rather than with `file` itself. + +**runtime** + +The error happens at runtime within the QEMU emulation context when trying to read the elf file, indicating it's not related to instruction execution or syscalls but an issue in how the emulator handles certain operations. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1724485 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1724485 new file mode 100644 index 000000000..7d88c4941 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1724485 @@ -0,0 +1,11 @@ +The issue reported relates to an invalid assertion within `arm_read_memory_func` when handling thumb2 mode instructions in a target environment set to armeb-linux. The error occurs because the code expects a little-endian configuration (`BFD_ENDIAN_LITTLE`), but this is not the case for the given target, leading to an assertion failure. + +Upon further analysis, the problem arises during program startup where `glibc's _dl_new_object` invokes `strlen`, which is implemented in thumb2 mode. This causes `print_insn_arm()` to call `arm_read_memory_func()` with a specific set of parameters that do not meet the assertion condition. + +The user has identified that removing the assertion allows execution to proceed without issues, suggesting that the assertion may be overly restrictive or incorrect for certain use cases. However, it's crucial to determine whether this assertion is necessary for other parts of the codebase and if its removal could introduce unintended side effects. + +Further investigation is needed to understand why the assertion was originally placed there and whether there are alternative solutions to handle big-endian configurations properly without compromising the integrity of the code. If the assertion is not essential, it may be safe to remove it, but this should be done cautiously after thorough testing. + +The user has also reported that with the assertion in place, QEMU stalls, indicating a potential runtime issue beyond just the assertion failure. This suggests that addressing the root cause of why the code expects little-endian when big-endian is being used might prevent the stall and ensure smooth execution across different configurations. + +In summary, while removing the assertion seems to resolve the immediate problem for the reported use case, it's essential to explore whether this change could affect other parts of the system or if there are deeper issues in how endianness is handled in `arm_read_memory_func`. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1737444 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1737444 new file mode 100644 index 000000000..d0b09673c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1737444 @@ -0,0 +1,9 @@ +The crash occurs when running a conftest program on qemu-sh4 that works correctly on a real SH7785LCR board. The issue seems to be related to how the setcontext function is handled in QEMU for the SH4 architecture. + +Looking at the provided code, it's using `ucontext.h` and `pthread.h`, which are standard libraries for context switching and threading. The test sets up a thread with TLS (Thread Local Storage) and uses `makecontext` and `setcontext` to switch execution contexts. + +The error message from QEMU indicates an "Unhandled trap: 0x180" at the instruction pointer `pc=0x7f69235e`. This suggests that during the execution of the context switch, an unexpected exception or interrupt is being triggered. On the real hardware, this doesn't happen, implying that either QEMU's emulation isn't handling the SH4 architecture correctly in this scenario or there's a bug in how the setcontext function is implemented or used. + +Given that the problem arises during runtime when executing specific instructions (the context switch), and since it works on real hardware but not in QEMU, it points towards an issue with QEMU's handling of the SH4 architecture for certain operations, possibly related to exception handling or stack switching. + +Therefore, this bug falls under the **instruction** category as it involves a problem with how instructions are executed in the emulator. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1776478 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1776478 new file mode 100644 index 000000000..8c96946ee --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1776478 @@ -0,0 +1,3 @@ +The issue seems to be related to the use of `qemu-arm-static` for cross-compiling LV2 plugins on an ARMv6 architecture (like Raspberry Pi Zero) while the code is intended for ARMv7. The error occurs when running `lv2_ttl_generator`, which is part of DISTRHO-Ports. + +The classification would be **runtime**, as the problem happens during runtime execution within QEMU, specifically related to threading and mutex operations that aren't handled correctly in the cross-compilation environment. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1777226 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1777226 new file mode 100644 index 000000000..51a82e6c4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1777226 @@ -0,0 +1,7 @@ +The problem described involves warnings emitted by `qemu-user` that interfere with userland applications' output. The user suggests that these warnings should be directed to a log file instead of stdout/stderr. + +**Category: runtime** + +Reasoning: +- This is an issue related to runtime behavior, specifically how warnings are handled during the execution of QEMU. +- It doesn't pertain to faulty instructions or syscalls but rather to runtime logging and output management. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1783362 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1783362 new file mode 100644 index 000000000..076ae9ab0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1783362 @@ -0,0 +1,5 @@ +The bug report describes an issue where `mmap` returns success (NULL, 0) instead of failure (MAP_FAILED, -1) when len==0 in QEMU-user. This is related to how syscalls are handled in the emulator. + +**syscalls** + +This is a syscall error because it involves incorrect handling of the mmap system call within the QEMU environment. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1785203 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1785203 new file mode 100644 index 000000000..b7249fd72 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1785203 @@ -0,0 +1,5 @@ +The bug report involves an assertion failure related to memory mapping during a system call (`mincore`). Specifically, it occurs when `mincore()` is called with an invalid pointer. The error originates from QEMU's handling of memory access checks in its TCG accelerator. + +**Category:** **syscall** + +This classification is based on the fact that the issue arises during the processing of a system call (`mincore`) and involves checking the validity of memory addresses, which falls under runtime system call handling. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1813398 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1813398 new file mode 100644 index 000000000..78413831d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1813398 @@ -0,0 +1,9 @@ +The given bug report describes an issue where `qemu` calls `malloc` after a `fork` in a multi-threaded process on a musl-based system. This results in undefined behavior because calling non-async-safe functions like `malloc` after `fork` can corrupt the memory state in the child process. The problem is particularly challenging to reproduce, as it requires specific concurrency between threads. + +The bug involves the use of `malloc` and `free` in a context where the parent process is multi-threaded, leading to potential corruption of the heap in the child after `fork`. This behavior is undefined under POSIX standards, which require that only async-safe functions be called in the child immediately after `fork`. + +Given the context provided, this issue pertains to the runtime environment and how memory management interacts with concurrency and system calls. Therefore, it falls under the category of: + +**runtime** + +The classification is based on the fact that the error occurs during runtime due to improper handling of memory allocation in a multi-threaded process after a `fork` operation. It does not directly involve faulty instructions or specific syscalls beyond the context provided. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1814128 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1814128 new file mode 100644 index 000000000..4df4222cc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1814128 @@ -0,0 +1,5 @@ +The provided information does not describe a specific bug report or issue related to QEMU. It appears to be an analysis of the binary structure and dynamic section of a file, likely a QEMU executable or shared object. However, without a detailed description of the bug symptoms, error messages, or problematic behavior, it is impossible to classify it into one of the given categories (instruction, syscall, runtime). + +Please provide more details about the bug you are referring to so that I can accurately classify it. + +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1821444 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1821444 new file mode 100644 index 000000000..9132306b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1821444 @@ -0,0 +1,5 @@ +The issue involves incorrect float32 arithmetic translation by `qemu-ppc (user)`. This seems to be related to how floating-point operations are emulated within QEMU, potentially involving FPU instruction handling or internal printf emulation. + +**runtime** + +The bug occurs during runtime when the program is executed under QEMU, leading to incorrect results. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1858461 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1858461 new file mode 100644 index 000000000..834190a1a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1858461 @@ -0,0 +1,5 @@ +The issue described involves adding a new syscall to QEMU for the MIPS architecture but encountering an `ENOSYS` error when the application tries to use it. The user has modified the `linux-user/mips/cpu_loop.c` file by adding a new syscall entry (`MIPS_SYS(sys_getdents64_x32, 3)`) and adjusting the code to handle syscalls beyond a certain number. However, the error persists because the check for valid syscalls is not correctly accounting for the new addition. + +The user also notes that the MIPS `cpu_loop.c` file differs significantly from its ARM counterpart, suggesting that the MIPS implementation may need similar restructuring to properly support extended syscalls as done in the ARM version. + +This issue falls under the category of a **runtime** error because it occurs during the execution of the application when attempting to use the new syscall, leading to an `ENOSYS` ( syscall not supported ) error. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1869241 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1869241 new file mode 100644 index 000000000..d178a7d63 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1869241 @@ -0,0 +1,9 @@ +The issue reported involves an error when using `svn checkout` under QEMU emulation for ARM7. The error message indicates that there's a problem reading a directory due to a value being too large for its defined data type. This suggests that somewhere in the process, QEMU is encountering or emulating a system call or instruction that leads to this overflow. + +Considering the categories provided: + +1. **Instruction**: This would involve a specific CPU instruction causing issues. The error here seems more related to how system calls are handled rather than a particular instruction. +2. **Syscall**: Errors with syscalls occur when there's an issue in handling system calls within the emulation. Given that `svn` is interacting with the file system, which involves numerous syscalls, this could be a potential category. +3. **Runtime**: This would cover other runtime errors not directly tied to instructions or syscalls. However, since the error is specifically about handling directory reads and data type sizes, it seems more aligned with how QEMU handles certain operations. + +The most fitting category here is likely **runtime**, as the issue arises during the execution of `svn` within the QEMU environment, involving file system interactions that aren't directly tied to a specific instruction or syscall but rather the overall handling of data types and sizes in the emulation. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1884719 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1884719 new file mode 100644 index 000000000..78f1cff51 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1884719 @@ -0,0 +1,3 @@ +The issue described involves an error where the `io_queue_init` function returns `-38` (ENOSYS) when using the Linux libaio library within a Docker container emulating an aarch64 architecture via QEMU. This suggests that the system call is not implemented in the emulation environment. + +To classify this bug, it falls under the category of **"syscall"** because it involves a problem with a system call (`io_queue_init` likely relies on certain kernel-level operations) not being properly handled or supported in the QEMU user-mode emulation for the foreign architecture. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1895471 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1895471 new file mode 100644 index 000000000..4a2dcd6b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1895471 @@ -0,0 +1,18 @@ +The bug report indicates that there's a compilation error related to C11 atomics when using Clang. The issue arises because the code is attempting to use atomic operations on variables that aren't correctly declared as `_Atomic` types. + +To fix this, ensure that any variable involved in atomic operations is properly declared with the `_Atomic` qualifier. For example, if `bh->flags` is used in an atomic operation, it should be defined as `_Atomic unsigned int bh_flags;`. + +Here's how you can modify your code: + +```c +typedef struct { + _Atomic unsigned int flags; + // Other members... +} BufHeader; + +// Usage: +BufHeader *bh = ...; +old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags); +``` + +By correctly declaring the variables as `_Atomic`, Clang will recognize them for atomic operations, resolving the compilation errors. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1904259 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1904259 new file mode 100644 index 000000000..787c10a84 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1904259 @@ -0,0 +1 @@ +The issue reported is about misaligned atomic operations causing performance penalties during compilation. This falls under the category of **runtime** because it relates to how code runs and performs, even though it's detected during compilation. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1906193 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1906193 new file mode 100644 index 000000000..e55247d44 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/1906193 @@ -0,0 +1,12 @@ +The issue reported involves the fork() system call not returning the expected value when running under QEMU's RISC-V32 user mode emulation. The child process exits with status 42, but the parent receives 40 instead. + +To classify this bug: +1. **Instruction**: This refers to issues with individual CPU instructions. However, the problem here is related to system calls and process management, not specific instructions. +2. **Syscall**: This category involves errors in system calls. The issue arises during the interaction between fork() and wait(), which are syscalls, making this a likely fit. +3. **Runtime**: This covers general runtime errors that don't fall into the other categories. While the error occurs at runtime, it's more specific to syscall handling. + +Given that the problem is centered around system calls (fork and wait) not behaving as expected under QEMU's emulation, the most appropriate category is: + +**syscall** + +The bug report indicates an issue with how QEMU handles these syscalls in the RISC-V32 user mode environment. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/2825 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/2825 new file mode 100644 index 000000000..95995e545 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/2825 @@ -0,0 +1,5 @@ +The issue described involves an error when using `execveat` with a file descriptor and empty filename for cross-architecture processes. This is related to how system calls are handled across different architectures, particularly when using QEMU's binfmt_misc support. + +**Category: syscall** + +The problem arises from the behavior of the `execveat` system call when handling files opened via a file descriptor on cross-architecture binaries. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/449 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/449 new file mode 100644 index 000000000..b1ab40090 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/449 @@ -0,0 +1,5 @@ +The bug report describes an assertion failure when running a Go program that uses vector instructions on s390x under QEMU. The issue is traced to specific patches applied to QEMU's master branch. The crash occurs during runtime due to an assertion in the vector instruction handling, which suggests it's related to how instructions are translated or executed. + +**Category: instruction** + +The error arises from faulty instruction translation or execution within QEMU, specifically for s390x vector operations. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/456 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/456 new file mode 100644 index 000000000..8e5d74b43 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/456 @@ -0,0 +1,8 @@ +The issue occurs when running `valheim_server.x86_64` under `qemu-x86_64`, where the process hangs on a `futex` system call, resulting in an "Function not implemented" error. + +Key points: +- The problem is specific to the QEMU emulator. +- It involves the `futex` system call not being implemented in the cross-compiling environment for ARM64 host using Ubuntu 5.2.0 version of QEMU. +- Replicated on an x86_64 Fedora host with a custom-built QEMU master branch. + +This is classified as a **runtime** issue because it occurs during the execution (runtime) when interacting with the `futex` system call, which is not properly handled in the emulator environment. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/714 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/714 new file mode 100644 index 000000000..ed8cdaf4d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/714 @@ -0,0 +1,7 @@ +The issue described relates to command-line arguments not being passed correctly when using QEMU's user-space semihosting feature. This is likely due to how QEMU handles argument passing in this mode, leading to incorrect `argc` and `argv` values. + +The appropriate classification for this bug is: + +**runtime** + +This is because the problem occurs at runtime when the program is executed under QEMU with semihosting enabled, rather than being an issue with a specific instruction or system call. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/739785 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/739785 new file mode 100644 index 000000000..d14162498 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/manual-review/739785 @@ -0,0 +1,70 @@ +The issue described involves problems when running user-mode QEMU on an ARM-based system (Pogo Plug) with Arch Linux chroot. The primary symptoms are: + +1. **Chroot Environment Failure**: When attempting to run `pacman -Suy` inside the chroot, it results in a "bash: fork: Invalid argument" error. +2. **QEMU Test Failure**: Running the QEMU user-mode test script leads to an assertion failure in the dynamic linker (`ld.so`), specifically at `_dl_check_map_versions`. + +### Analysis: + +1. **Chroot Environment**: + - The error `bash: fork: Invalid argument` suggests that there's a problem with process creation (fork) within the chroot environment. This could be due to incorrect or incomplete setup of the chroot, missing libraries, or issues with binfmt_misc registration. + +2. **QEMU Test Failure**: + - The assertion failure in `ld.so` indicates an issue during dynamic linking. This might occur if the QEMU user-mode binary is not correctly emulating the necessary environment for the target application (in this case, `ls`), or if there's a mismatch between the host and target libraries. + +### Possible Causes: + +- **Incorrect Binfmt Misc Registration**: + - The binfmt_misc configuration might be incorrect. For example, the interpreter path (`/usr/bin/qemu-i386`) might not be accessible from within the chroot, leading to issues when trying to execute binaries. + +- **Missing or Incorrect Libraries**: + - The `ld-linux.so.3` (or its symlink) copied to `/i386/lib/` might be incorrect or incomplete. This could cause dynamic linking issues for applications running under QEMU user-mode. + +- **Chroot Environment Setup Issues**: + - The chroot environment might be missing essential files or configurations required for proper process management and binary execution. For example, `/dev/pts`, `/dev/shm`, or other pseudo-devices might not be mounted correctly. + +### Steps to Diagnose: + +1. **Check Binfmt Misc Configuration**: + - Ensure that the binfmt_misc registration command is correct and that `qemu-i386` is properly registered as an interpreter for x86 binaries. + +2. **Verify Libraries in Chroot**: + - Confirm that all necessary libraries (e.g., `libc`, `ld-linux.so.3`) are present and correctly linked within the chroot environment. + +3. **Check Chroot Mounts**: + - Ensure that essential pseudo-devices like `/dev/pts` and `/dev/shm` are mounted inside the chroot. Missing mounts can cause issues with process creation and IPC. + +4. **Test QEMU User-Mode Outside of Chroot**: + - Run the QEMU user-mode test script outside of the chroot to see if it works as expected. This will help isolate whether the issue is specific to the chroot environment or a broader problem with QEMU setup. + +5. **Inspect Process Creation in Chroot**: + - Use tools like `strace` to trace process creation within the chroot and identify where the fork fails. For example, running `strace -f chroot . /bin/bash` might reveal more details about the failure. + +6. **Check for Compatibility Issues**: + - Ensure that the host kernel (`2.6.38`) supports the necessary features for QEMU user-mode emulation on x86 binaries. Some older kernels might have issues with certain emulation modes. + +### Potential Fixes: + +- **Correct Binfmt Misc Registration**: + - Double-check the binfmt_misc registration command and ensure that `qemu-i386` is correctly set as the interpreter for x86 binaries. + +- **Ensure Correct Libraries in Chroot**: + - Copy all necessary libraries from the host system to the chroot's `/lib/` directory. Verify that symlinks like `ld-linux.so.3` point to the correct version. + +- **Mount Required Pseudo-devices**: + - Mount `/dev/pts`, `/dev/shm`, and other required pseudo-devices inside the chroot environment using `mount --bind`. + +- **Update Kernel or Emulation Layer**: + - If possible, update the kernel on the host system to a more recent version that might have better support for QEMU user-mode emulation. Alternatively, check if there are newer versions of QEMU that address similar issues. + +### Conclusion: + +The primary issue appears to be related to the chroot environment setup and possibly incorrect binfmt Misc registration. The `fork` error suggests process creation is failing within the chroot, which could be due to missing mounts or configuration issues. Additionally, the dynamic linking failure in the QEMU test points to potential problems with library compatibility or availability within the chroot. + +To resolve this: + +1. Ensure all necessary pseudo-devices are mounted inside the chroot. +2. Verify that binfmt Misc is correctly configured and registered. +3. Check for missing libraries in the chroot and ensure they are properly symlinked. +4. Use debugging tools like `strace` to gain more insight into where exactly the process creation or linking is failing. + +By addressing these areas, the issues with running user-mode QEMU within the chroot should be resolved. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010484 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010484 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1010484 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1028 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1028 new file mode 100644 index 000000000..ff93c2561 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1028 @@ -0,0 +1,3 @@ +The problem arises during the execution of RISC-V RVV instructions when using `vmv.v.x` with `e64`, where the vector length (`vl`) equals `vl_max`. The assertion failure occurs because the code attempts to use a 32-bit operation for a 64-bit context, leading to an incorrect instruction generation. This issue is related to handling specific vector operations and their corresponding data types within the QEMU emulator. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1031920 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1031920 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1031920 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1034 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1034 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1034 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1041 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1041 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1041 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1044 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1044 new file mode 100644 index 000000000..7aa6d1acc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1044 @@ -0,0 +1,3 @@ +The bug report mentions an empty table of contents for libevent-loop-base.a, which seems to be related to linking or library issues during build time. However, since it's part of QEMU and not explicitly about instruction, syscall, or runtime errors, it might fall under 'runtime' as a broader category. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1059 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1059 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1059 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1066909 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1066909 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1066909 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1068900 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1068900 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1068900 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1070 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1070 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1070 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1086 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1086 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1086 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1093 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1093 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1093 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1098729 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1098729 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1098729 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1102 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1102 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1102 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1128 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1128 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1128 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1143 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1143 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1143 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1147 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1147 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1147 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1165383 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1165383 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1165383 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1172613 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1172613 new file mode 100644 index 000000000..71a765541 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1172613 @@ -0,0 +1,12 @@ +The issue appears to be related to how QEMU handles the dynamic linker and shared libraries on different architectures. Specifically, it seems that certain architectures (like powerpc64 and sparc64) are not correctly locating or loading the required shared libraries when running programs under QEMU. + +Upon closer inspection: + +- For **powerpc64**, specifying the linker explicitly with `--library-path` works but without it, there's an error. +- For **sparc64**, the program crashes with a segmentation fault unless the correct linker path is provided. + +This suggests that the problem lies in how QEMU sets up the environment for these architectures during runtime. It doesn't automatically find the necessary libraries and requires manual intervention to specify their paths, unlike the **armhf** case where it works correctly after specifying `--library-path`. + +Since this issue affects the runtime execution of programs by failing to locate required shared libraries without user干预, it falls under: + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1182490 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1182490 new file mode 100644 index 000000000..352ee4e5e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1182490 @@ -0,0 +1,3 @@ +The bug occurs during runtime when `qemu_coroutine_switch` is called with `to_=NULL`, leading to a null pointer dereference at line 47. Therefore, this is a **runtime** error. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1187319 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1187319 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1187319 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1209 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1209 new file mode 100644 index 000000000..fdd2a71aa --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1209 @@ -0,0 +1,3 @@ +The given bug report mentions that QEMU does not clear the screen when starting a VM. This issue pertains to the behavior during runtime of the virtual machine. Therefore, it falls under the **runtime** category. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/121 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/121 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/121 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1211 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1211 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1211 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/122 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/122 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/122 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1221966 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1221966 new file mode 100644 index 000000000..5deb8aa20 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1221966 @@ -0,0 +1,5 @@ +The issue seems to be related to segmentation fault during execution when running 'ls' on a SunOS 5.8 box under RHEL 6.4 using QEMU. The backtrace points to `static_code_gen_buffer` and `cpu_tb_exec`, which are parts of the CPU emulation code in QEMU. This suggests that there might be an issue with how the static code generation buffer is being handled, possibly leading to a memory access violation. + +Given the error occurs during runtime execution within the emulator, it fits into the **runtime** category. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1228 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1228 new file mode 100644 index 000000000..f398c4131 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1228 @@ -0,0 +1,13 @@ +The issue described seems to be related to how escape sequences are handled when using the curses display in QEMU. The problem occurs specifically when using `-display curses`, where escape commands like `Ctrl + X` or `Alt + 2` do not work as expected unless pressed simultaneously with the escape key. + +From the user's tests, it appears that the terminal environment (e.g., macOS Terminal vs. other clients) affects how these escape sequences are interpreted. For instance, pressing `Option + 2` in macOS Terminal sends a different sequence compared to pressing `Esc + 2`. This suggests that the issue is related to how the terminal emulator translates key presses into escape sequences. + +The fact that the same commands work when using the graphical display but not with curses implies that the problem lies in how the curses interface interprets these sequences. It might be a timing issue or an interpretation issue within the curses setup. + +Considering the possible categories: + +1. **Instruction**: This doesn't seem to be about faulty instructions in the documentation. +2. **Syscall**: The issue isn't directly related to system calls failing. +3. **Runtime**: The problem occurs during runtime when handling escape sequences, particularly with curses. + +Therefore, the most appropriate category for this bug is `runtime`. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1245703 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1245703 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1245703 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1246990 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1246990 new file mode 100644 index 000000000..90c94d39d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1246990 @@ -0,0 +1,11 @@ +The error message indicates a segmentation fault occurring within QEMU when executing the `rjsupplicant` binary. The stack trace shows that the issue is happening during code generation and execution within QEMU's CPU emulation layer (`cpu_tb_exec`). This suggests an issue with how QEMU is handling the instructions or memory access for the x86_64 target. + +Given the options: + +- **instruction**: This category would be relevant if there was a specific faulty instruction being executed. However, the stack trace points to issues within QEMU's internal code generation and execution, not necessarily a specific instruction in `rjsupplicant`. + +- **syscall**: A syscall error would typically involve issues with system calls, but the segmentation fault here is occurring during CPU emulation, not during a syscall. + +- **runtime**: This category fits because the issue occurs at runtime within QEMU's execution of the target binary. The problem seems to be related to how QEMU handles the dynamic code generation or memory access for the x86_64 instructions, leading to an unhandled segmentation fault. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254672 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254672 new file mode 100644 index 000000000..81dbcc5b6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254672 @@ -0,0 +1,7 @@ +The issue described involves a segmentation fault when running `ps` inside a chroot environment using QEMU-static for an armhf guest on an Ubuntu Precise host. The problem arises within the `procps-ng` package, but the user suspects it might be related to QEMU due to the lack of existing bug reports for `procps`. The segmentation fault occurs during runtime when executing `ps`, which is part of the procps utilities. This suggests a runtime error specific to the interaction between the guest environment and the QEMU-static emulator. + +The category that best fits this issue is: + +runtime + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254828 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254828 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1254828 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1255 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1255 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1255 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1261743 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1261743 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1261743 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1263747 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1263747 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1263747 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1267 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1267 new file mode 100644 index 000000000..3273fe7f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1267 @@ -0,0 +1,13 @@ +The issue appears to be related to how QEMU handles certain binaries, particularly those compiled for i386 architecture using TinyGo or Go. The crashes are occurring when running these binaries under `qemu-i386`, but not with `qemu-x86_64` or `qemu-arm`. The backtraces indicate problems in the translator and code generation phases, specifically pointing to functions like `cpu_ldub_code` and `translator_loop`. + +Looking at the possible categories: + +- **Instruction:** This category would apply if a specific instruction was causing the problem. However, the issue isn't tied to a particular instruction but rather to how QEMU processes binaries in general. + +- **Syscall:** The error doesn't seem to be related to system calls but rather to internal processing within QEMU. + +- **Runtime:** This category is broader and refers to errors that occur during runtime. Given that the problem arises when executing binaries and involves internal QEMU functions, this seems like the most appropriate category. + +The crash occurs at runtime when executing user-space code, which fits under "runtime" as it's an error happening during the execution of the program rather than a specific instruction or syscall issue. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/127 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/127 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/127 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1285363 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1285363 new file mode 100644 index 000000000..03c8aec03 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1285363 @@ -0,0 +1,3 @@ +The given bug report describes a segfault occurring in `qemu-aarch64-static` under specific conditions, particularly during the execution of scripts like `dh_fixperms` and `debootstrap --second-stage`. The issue is related to signal handling, specifically involving `memcpy` within the `signal.c` file. This suggests an error that occurs during runtime due to improper memory access or signal processing. + +**Category:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1287195 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1287195 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1287195 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1294898 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1294898 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1294898 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1319100 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1319100 new file mode 100644 index 000000000..889fb7c77 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1319100 @@ -0,0 +1,16 @@ +The issue described involves problems with signal handling in QEMU's user mode emulation (`qemu-arm-static`), specifically how signals are routed between threads during the termination of Mono applications. The problem causes hangs when running Mono within a chroot environment using `qemu-user-static`. + +The bug report mentions that certain signals (like SIGPWR) used during thread termination in Mono are not handled correctly by QEMU, leading to deadlocks or hangs. This affects both Mono and Java applications running under emulation. + +The analysis also points out that there's an openSUSE patch available for QEMU that addresses a similar issue related to signal handling and the `SA_RESTART` race condition. Applying this patch resolves the problem in some cases. + +This issue is not limited to Debian but impacts the upstream QEMU code as well. The reporter intends to report it to the QEMU project, referencing this bug report for further action. + +In terms of classification: +- **Instruction**: No faulty instruction per se; the issue arises from signal handling and thread communication. +- **Syscall**: There might be issues with how syscalls like `futex` or `tgkill` are handled under emulation. +- **Runtime**: The problem occurs during runtime, specifically when applications terminate and signals are processed. + +Given that the issue involves incorrect routing of signals at runtime within QEMU's user mode environment, the most appropriate category is: + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1346784 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1346784 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1346784 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1356916 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1356916 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1356916 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357206 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357206 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357206 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357226 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357226 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1357226 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361912 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361912 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1361912 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1362635 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1362635 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1362635 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/140 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/140 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/140 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1429313 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1429313 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1429313 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1435 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1435 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1435 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1471 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1471 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1471 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1478 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1478 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1478 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1494 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1494 new file mode 100644 index 000000000..6206a8729 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1494 @@ -0,0 +1,3 @@ +The issue appears to be related to how QEMU handles certain operations during its runtime, such as signal handling or memory management, leading to segmentation faults or other runtime errors. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1495 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1495 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1495 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1512 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1512 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1512 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1519037 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1519037 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1519037 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1527765 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1527765 new file mode 100644 index 000000000..95932c73f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1527765 @@ -0,0 +1,11 @@ +The issue described involves GHC segfaulting when run under qemu-sh4-static. The problem occurs randomly and can sometimes be resolved by retrying the compilation process multiple times. Additionally, the user provided information about applying specific patches to fix syscall handling in QEMU but found that the issue persists regardless of these fixes. + +Considering the categories: + +- **Instruction**: This would involve a specific instruction causing the segfault, which is not directly mentioned here. +- **Syscall**: The problem could be related to syscalls, especially since the user mentions fixing syscalls with patches. However, the issue still occurs even after applying those fixes. +- **Runtime**: The segfault happens during runtime when executing GHC under QEMU. + +Given that the issue is a runtime error occurring in QEMU while running GHC, the most appropriate category is: + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528239 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528239 new file mode 100644 index 000000000..c8dc32370 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1528239 @@ -0,0 +1,3 @@ +The issue is related to debugging PIE binaries using QEMU's gdb stub. The problem arises when trying to set breakpoints in such binaries, as GDB fails to access memory at specific addresses. This indicates an issue during runtime when interacting with the binary through QEMU. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1563612 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1563612 new file mode 100644 index 000000000..55f1febd0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1563612 @@ -0,0 +1,3 @@ +The issue involves a segmentation fault when running a PulseAudio application under QEMU, specifically related to the futex system call and an assertion failure in pa_mutex_unlock. This points to problems during runtime execution within the QEMU environment. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1568107 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1568107 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1568107 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1585840 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1585840 new file mode 100644 index 000000000..e9262dbe1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1585840 @@ -0,0 +1,11 @@ +The issue described involves problems when running a multiprocess program under `qemu arm-linux-user`. The test succeeds on real hardware (both x86_64 and ARM) but fails in multiprocess mode under QEMU. This suggests an issue with how QEMU handles certain operations, specifically related to multiprocessing or shared memory. + +Given the possible categories: + +- **Instruction**: Faulty instruction is not indicated here; the problem isn't about incorrect assembly-level instructions. +- **Syscall**: The issue could relate to syscalls, as it involves processes and shared memory (which uses syscalls like `mmap`, `shmat`). +- **Runtime**: This category covers other runtime errors. The failure might be due to improper handling of atomic operations or process synchronization in QEMU. + +The most fitting category is **runtime**, as the problem likely arises from how QEMU emulates multiprocessing and shared memory, leading to deadlocks or incorrect results. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1591611 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1591611 new file mode 100644 index 000000000..7166322da --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1591611 @@ -0,0 +1,8 @@ +The issue involves commands failing due to assertion errors when using qemu-x86_64-static on a ppc64el host. The error points to problems in the __libc_fork function related to threading and signal handling within the chroot environment. + +**Category: runtime** + +The problem occurs during runtime when executing commands inside the chroot, indicating an issue with how QEMU handles processes or threads on the target architecture. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1593 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1593 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1593 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1603734 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1603734 new file mode 100644 index 000000000..cb2d07240 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1603734 @@ -0,0 +1,3 @@ +The given bug report describes an issue where QEMU hangs during the execution of `floatx80_sqrt` function for certain input values. This is classified under the **runtime** category because it occurs while running the program and involves an infinite loop in the floating-point unit implementation. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1605443 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1605443 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1605443 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1623020 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1623020 new file mode 100644 index 000000000..9ffe57ec6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1623020 @@ -0,0 +1,4 @@ +The issue described involves running a Go program compiled for amd64 on an arm7 host using QEMU. The output shows errors related to runtime panics and memory allocation issues. These kinds of problems typically arise from how the runtime environment handles system calls or manages resources in a cross-architecture emulation scenario. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1641861 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1641861 new file mode 100644 index 000000000..d8cd05264 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1641861 @@ -0,0 +1,3 @@ +The issue reported is related to how QEMU emulates the FPSCR register in ARM user mode programs. Specifically, certain bits (bits[19, 14:13, 6:5]) of the FPSCR are supposed to be reserved and non-writeable according to the ARM manual, but QEMU allows these bits to be modified. This is an error in how the emulator handles the register's state. + +**Category:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1648 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1648 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1648 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1650 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1650 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1650 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1654137 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1654137 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1654137 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1659901 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1659901 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1659901 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1667401 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1667401 new file mode 100644 index 000000000..09ad1b3ad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1667401 @@ -0,0 +1,8 @@ +The bug report describes an issue where `qemu-ppc` experiences a segmentation fault when running a program that creates and joins a pthread. The problem is specific to PPC architecture and does not occur on x86_64. The failure occurs during the `clone()` system call with invalid arguments, which suggests an issue in how the threading is handled within QEMU for PPC targets. + +The error seems related to the handling of thread creation in the user-mode emulation provided by QEMU. The assertion failures and segmentation fault point towards issues in the translation or locking mechanisms used when emulating pthread operations on PPC. This indicates a runtime error specific to the PPC target implementation in QEMU. + +Therefore, this bug falls under the "runtime" category as it involves errors occurring during the execution of the program within the QEMU environment. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1671 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1671 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1671 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1673976 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1673976 new file mode 100644 index 000000000..afb97ae76 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1673976 @@ -0,0 +1,4 @@ +The issue described involves `locale-gen` failing due to an assertion in `glibc`'s `posix_spawn()` function when running under `qemu-arm-static`. This is likely related to how `qemu` handles certain syscalls or processes within the chroot environment, particularly with newer versions of `qemu` (e.g., 2.8). The problem occurs during runtime when attempting to generate locales. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1696353 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1696353 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1696353 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1697 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1697 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1697 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1701821 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1701821 new file mode 100644 index 000000000..0a7403013 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1701821 @@ -0,0 +1,11 @@ +The bug reports describe multiple test failures related to floating-point operations in QEMU. The issues involve traps (e.g., 0x180 and 0x1a0) occurring during execution, which suggests that there are exceptions or errors being raised when running these tests. These exceptions could be due to incorrect handling of floating-point instructions or improper state management within the emulator. + +Considering the categories provided: + +- **Instruction**: This category would apply if a specific instruction was faulty. +- **Syscall**: This would involve errors related to system calls, which is not evident here. +- **Runtime**: This covers other runtime errors, such as exceptions or incorrect behavior during execution. + +Given that the failures are due to traps (exceptions) occurring during the execution of floating-point operations, and without specific indication of faulty instructions or syscalls, the most appropriate category is: + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1704638 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1704638 new file mode 100644 index 000000000..c5c5685f5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1704638 @@ -0,0 +1,3 @@ +The issue described involves QEMU hanging when running MIPS and MIPS64 programs that use weak symbols. This occurs during runtime execution within the QEMU environment, specifically while executing user-mode processes. The problem is related to how QEMU handles weak symbol access and thread locks. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1707 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1707 new file mode 100644 index 000000000..cda9fe051 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1707 @@ -0,0 +1,17 @@ +The problem described involves running a binary compiled for x86_64 on an aarch64 or LoongArch host using QEMU's qemu-x86_64 emulator. The user reports that when they run the binary with `qemu-x86_64`, there is no output, and they suspect that a specific commit related to fixing the brk() system call caused this issue. + +The key points here are: +1. The binary is built for x86_64 (using an x86 cross-compiler) with `--static`. +2. QEMU-x86_64 is built on an aarch64 or LoongArch host. +3. Running the binary with QEMU results in no output, which suggests that either the binary isn't executing correctly, or there's an issue with how QEMU is handling the execution. + +The problem seems to relate to how the emulator interacts with the guest OS and possibly how it handles certain system calls or memory management (given the commit mentioned fixes brk()). This points towards a runtime error within QEMU when attempting to execute the binary. The issue doesn't seem to be directly about a faulty instruction in the binary itself but rather how the emulator is processing the execution. + +Based on the categories provided: +- **instruction**: Doesn't apply because there's no indication of an incorrect instruction being executed. +- **syscall**: Might be related, as brk() is a system call, but the issue seems broader than just a single syscall. +- **runtime**: This fits best because the problem occurs during the runtime execution of the binary within QEMU. + +Thus, the most appropriate category for this bug report is: + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1715162 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1715162 new file mode 100644 index 000000000..614304846 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1715162 @@ -0,0 +1,3 @@ +The issue involves QEMU segfaulting while attempting to write a core dump for another binary that also segfaulted. This suggests an error occurring during the execution of QEMU itself when handling signals or dumps. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1727737 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1727737 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1727737 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1734 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1734 new file mode 100644 index 000000000..7646e6199 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1734 @@ -0,0 +1,7 @@ +The problem involves an issue where mmap calls fail when using QEMU version 8.0 for ARM binaries on a host system, specifically when the mapped files exceed around 1GB in size. The user observed that this does not happen with older versions like 6.2. The failure seems to be related to memory addressing limits imposed by QEMU's behavior, such as the ELF binary load address. + +**Analysis:** +The issue likely stems from how QEMU handles memory mapping for ARM binaries. In version 8.0, there might be a stricter enforcement or change in the way virtual memory is allocated and mapped, leading to exhaustion of the available address space when multiple large files are mmaped. The mention of using the `-B` option to adjust the load address suggests that QEMU's memory layout configuration could be a contributing factor. + +**Category:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1735384 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1735384 new file mode 100644 index 000000000..6740a08af --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1735384 @@ -0,0 +1,3 @@ +The issue described involves the OpenJDK JVM crashing on qemu-sh4 with a segmentation fault after some recent changes, which suggests a problem during runtime execution rather than an instruction or syscall error. Therefore, it falls under the 'runtime' category. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1736 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1736 new file mode 100644 index 000000000..26546ef7d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1736 @@ -0,0 +1,3 @@ +The issue described relates to incorrect guest address logging in QEMU's debug output for translation blocks, particularly when not starting at address 0. This affects how the addresses are displayed and could potentially cause confusion or misinterpretation during debugging. + +**Category:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1740219 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1740219 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1740219 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1741 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1741 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1741 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1748612 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1748612 new file mode 100644 index 000000000..289e863f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1748612 @@ -0,0 +1,3 @@ +The issue is related to logging and debugging within QEMU, specifically involving incorrect function calls that prevented strace output from being directed properly to a file. This falls under runtime issues because it affects how the program runs and interacts with its environment during execution. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1755 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1755 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1755 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1756519 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1756519 new file mode 100644 index 000000000..50d65f55e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1756519 @@ -0,0 +1,3 @@ +The issue occurs during `do_fork()`, specifically when calling `cpu_create()`, leading to an assertion failure in QOM path canonicalization. This is related to how the CPU state is managed during process forking and thread creation. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761153 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761153 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761153 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761535 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761535 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1761535 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763536 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763536 new file mode 100644 index 000000000..5e06d3315 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1763536 @@ -0,0 +1,12 @@ +The issue occurs when running multi-threaded Go commands inside a Docker container using qemu-ppc64le-static for emulation. The problem is not isolated to Go but seems related to how QEMU handles multi-threaded applications in a static build environment. + +When building and running `go build` without limiting the number of processes or threads, the process may hang or encounter segmentation faults. This suggests that there might be an issue with how QEMU-PPC64LE-static interacts with the host's CPU architecture when handling multiple threads simultaneously. + +The problem does not occur when forcing Go to run single-threaded (`GOMAXPROCS=1 go build -p 1`), which points towards concurrency or threading as the root cause. Since this behavior is observed across different architectures (e.g., arm64 and ppc64le) using QEMU, it's likely a QEMU-related issue rather than a Go-specific problem. + +After reviewing similar issues reported against QEMU, it appears that multi-threaded applications can sometimes encounter unexpected behaviors or crashes when running under certain QEMU configurations. This could be due to incorrect handling of thread scheduling, context switches, or memory management within the emulator. + +Based on the analysis and error logs (especially the segmentation fault), this issue likely falls under the `runtime` category because it pertains to how the runtime environment (QEMU in this case) interacts with the application's execution. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1765970 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1765970 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1765970 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768246 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768246 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1768246 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1770 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1770 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1770 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1773743 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1773743 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1773743 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1774149 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1774149 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1774149 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1779634 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1779634 new file mode 100644 index 000000000..8753c025c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1779634 @@ -0,0 +1,20 @@ +The issue reported involves running x86_64 binaries on an aarch64 platform using QEMU's user mode emulation, resulting in "Synchronous External Abort" errors. This type of error typically occurs during runtime when there is an unexpected hardware exception that the software doesn't handle properly. + +**Step-by-step explanation:** + +1. **Understanding the Problem:** + - The user is trying to run x86_64 executables on an aarch64 system using QEMU. + - They've set up binfmt_misc to automatically use the QEMU interpreter for x86_64 binaries. + - Running specific Intel/Dell firmware update tools within Docker containers results in kernel errors: "Synchronous External Abort." + +2. **Analyzing the Error:** + - "Synchronous External Abort" indicates a hardware exception that occurs during execution. + - The error code (0x92000610) suggests an external abort, possibly due to an invalid memory access or instruction. + +3. **Identifying the Category:** + - This is not related to a faulty instruction (instruction category) because the issue arises from hardware exceptions during execution. + - It's also not directly related to system calls (syscall category) but rather how the program interacts with the hardware while running. + - Therefore, it falls under runtime errors. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1791763 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1791763 new file mode 100644 index 000000000..e5aa7413d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1791763 @@ -0,0 +1,3 @@ +The given bug report discusses issues with signal handling in the nios2 user-mode emulation within QEMU. Specifically, it mentions problems with system calls such as `sigaltstack()` returning errors and handlers not being invoked properly. These are related to how signals are handled during runtime in the emulation environment. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1793539 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1793539 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1793539 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1796520 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1796520 new file mode 100644 index 000000000..b19f55cde --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1796520 @@ -0,0 +1,5 @@ +The issue occurs during the execution of autogen when running on qemu-sh4-user after applying a specific commit to QEMU. The crash is triggered by an unhandled trap, which suggests that an exception or error condition occurred in the code. The bisect identified a commit related to adding checks for the FPSCR.PR register in the SH4 target. + +The problem seems to be a runtime error because it's not about compiling or executing instructions but rather how the software behaves during execution after changes to the handling of certain registers. Therefore, this bug is classified under 'runtime'. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1798 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1798 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1798 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1799200 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1799200 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1799200 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1805 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1805 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1805 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1807 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1807 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1807 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808563 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808563 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808563 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808565 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808565 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1808565 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1809546 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1809546 new file mode 100644 index 000000000..e78cf3852 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1809546 @@ -0,0 +1,5 @@ +The issue described is related to how QEMU handles writes to specific registers of the PL011 UART device. When a byte is written to an offset within a register, QEMU overwrites the entire register instead of just modifying the targeted byte. This behavior causes unexpected results in the application running on QEMU. + +This problem occurs during runtime when interacting with the hardware components simulated by QEMU. It's not related to instruction decoding or system calls but rather how the virtual device handles register writes. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812 new file mode 100644 index 000000000..88daa3d8e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812 @@ -0,0 +1,7 @@ +The problem occurs when older aarch64 programs run under qemu-aarch64 and segfault, specifically after a certain commit. The issue seems to be related to how old userspace handles recent CPU features or changes in the emulator. + +Possible categories: instruction, syscall, runtime. + +The error is not due to a faulty instruction or a specific syscall failure but rather due to runtime conditions where older programs are not compatible with newer qemu versions. This suggests it's a runtime issue. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812451 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812451 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812451 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812861 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812861 new file mode 100644 index 000000000..874e86521 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1812861 @@ -0,0 +1,4 @@ +The bug occurs during runtime when an invalid address is accessed. It's not due to a faulty instruction or a syscall issue but rather how QEMU handles this specific runtime error internally. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1818483 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1818483 new file mode 100644 index 000000000..4bbc9223d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1818483 @@ -0,0 +1,7 @@ +The issue describes a problem with how QEMU handles arguments when using binfmt_misc with specific flags. The user observes unexpected behavior where the command output includes the full path instead of just the program name. This is related to how QEMU parses command-line arguments and environment variables in certain configurations, specifically when additional flags are set. + +The root cause appears to be in how QEMU processes the arguments passed through binfmt_misc, particularly with the inclusion of an extra argument (argv[0]) which isn't expected by the current implementation. This results in incorrect handling of the command line input. + +This issue seems to fall under the **runtime** category because it's related to runtime behavior and how arguments are processed during execution rather than a problem with specific instructions or system calls. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1819 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1819 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1819 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1824344 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1824344 new file mode 100644 index 000000000..9c4d7c6d0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1824344 @@ -0,0 +1,7 @@ +The given bug report describes an issue where executing certain instructions (`retf`, `iret`, or `iretq`) in user space leads to incorrect error codes being set, causing the guest OS (Linux) to misinterpret the fault as a kernel issue instead of a user-space one. This can result in the kernel panic or termination of the process. + +The problem is related to how QEMU handles page faults when these instructions are executed with an invalid stack pointer. Specifically, the error code generated does not correctly set bit 2, which should indicate whether the fault originated from user space or kernel space. As a result, the Linux kernel mistakenly treats the fault as a kernel-space issue and triggers a bug report. + +The classification for this issue falls under "runtime" because it pertains to an error that occurs during the execution of the guest OS within QEMU, rather than being related to a specific instruction or syscall. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1829459 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1829459 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1829459 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1830 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1830 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1830 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832353 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832353 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832353 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832916 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832916 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1832916 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1834496 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1834496 new file mode 100644 index 000000000..e9d6150b2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1834496 @@ -0,0 +1,12 @@ +The issue described involves regressions when running GCC tests on an ARM target using QEMU. The problem occurs after updating to a recent version of QEMU (specifically commit 474f3938d), where previously passing tests now cause QEMU to crash with an uncaught signal 6 (Aborted). This suggests that the issue is related to how the ARM CPU or memory management is handled in the emulator. + +The user provided specific configurations, including using `--cpu cortex-a9` and running tests that previously worked. The fact that the crash occurs across multiple tests points towards a systemic issue rather than an isolated bug. + +Given the categories: +- **instruction**: This would apply if a specific instruction was causing issues. +- **syscall**: If system calls were failing. +- **runtime**: For other runtime errors not covered by the above. + +The problem seems to stem from how QEMU handles certain operations at runtime, possibly related to CPU or memory management changes introduced in the recent commit. Therefore, the most appropriate category is **runtime**. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835693 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835693 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835693 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835839 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835839 new file mode 100644 index 000000000..f68939158 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1835839 @@ -0,0 +1,11 @@ +The bug report describes an issue where `qemu-user` always reports absolute paths for `$0`, which is the shell variable representing the current script or command. This behavior differs from the expected relative path when invoking commands normally. The problem is not related to faulty instructions, syscalls, or runtime errors but pertains to how `qemu-user` handles environment variables and process information. + +Given the categories provided: + +- **instruction**: Not applicable; there's no mention of a faulty instruction. +- **syscall**: While `$0` relates to process information, the issue isn't directly tied to a syscall error. +- **runtime**: This seems more appropriate as it pertains to runtime behavior within `qemu-user`. + +Thus, the bug falls under **runtime**. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836078 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836078 new file mode 100644 index 000000000..0579aa2a8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836078 @@ -0,0 +1,3 @@ +The bug report describes regressions when running GCC tests on QEMU's arm-linux-gnueabihf target. The issue arises after applying a specific fix and results in crashes for previously passing tests. This suggests an error during runtime execution rather than issues with instructions or system calls. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836192 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836192 new file mode 100644 index 000000000..c20c9a513 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836192 @@ -0,0 +1,13 @@ +The user has provided a detailed bug report regarding regressions when running GCC tests on a QEMU target (arm926) after updating to a specific commit in the QEMU master branch. The issue involves regressions compared to QEMU version 3.1, specifically when generating arm10tdmi code with VFP support. + +The user has attached a tarball containing test binaries and a script for reproduction, which indicates that they have provided enough information for others to reproduce the issue. + +In terms of classification: +- **Instruction**: This category would apply if there was an error in how specific instructions are handled. While the issue is related to instruction generation (arm10tdmi), the problem seems broader than a single faulty instruction. +- **Syscall**: This relates to errors during system calls, which doesn't seem directly relevant here as the issue is about regression in test cases when using a specific CPU configuration. +- **Runtime**: This category fits issues that occur during runtime. Since the user mentions regressions when running tests with QEMU's --cpu arm926, it suggests that the problem arises during the execution of these tests, which falls under runtime behavior. + +Therefore, the most appropriate classification for this bug report is **runtime**, as it pertains to errors occurring during the execution of tests within the specified environment. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836558 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836558 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1836558 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1840922 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1840922 new file mode 100644 index 000000000..15e48c7ae --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1840922 @@ -0,0 +1,8 @@ +The issue appears to be related to how QEMU handles exceptions during CPU execution when running bare-metal code compiled for Cortex-M33. The crash occurs due to an unhandled CPU exception (0x8), which suggests that there might be an issue with how certain instructions or memory accesses are handled in the emulator. + +The problem is not directly tied to a specific instruction being faulty but rather to how QEMU processes exceptions during runtime, particularly when executing code compiled at different optimization levels (-O2 vs. -Os). Since the crash only happens at -Os and involves nested functions creating trampolines on the stack, it might relate to how the stack or function calls are managed in the emulator. + +Therefore, this seems to fall under a **runtime** error within QEMU's handling of the CPU context. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854 new file mode 100644 index 000000000..d6c61881d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854 @@ -0,0 +1,16 @@ +The given bug report indicates an issue where the `nolibc-test` program crashes when run under QEMU-s390x. The error message points to a specific line in `elfload.c`, suggesting a problem during the execution of the binary. + +1. **Understanding the Error**: + - The error `zero_bss: code should not be reached` occurs in `elfload.c` at line 2239. + - This suggests that QEMU encountered an unexpected condition while processing the BSS (Block Started by Symbol) section of the binary. + +2. **Analyzing the Context**: + - The issue started after a specific commit (`5f4e5b34092556ab1577e25d1262bd5975b26980`), implying that a change introduced a bug. + - Reverting this commit fixes the problem, indicating that the fix might involve correcting changes made in that commit. + +3. **Determining the Category**: + - The error occurs during runtime when running the program under QEMU. + - It is not directly related to a faulty instruction or a syscall issue but rather an internal error in QEMU's handling of the binary. + - Therefore, it falls under the "runtime" category as it pertains to errors that occur during execution. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854738 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854738 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1854738 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1857811 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1857811 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1857811 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860056 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860056 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860056 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860610 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860610 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1860610 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862167 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862167 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862167 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862986 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862986 new file mode 100644 index 000000000..436ec35a8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1862986 @@ -0,0 +1,3 @@ +The issue seems to involve QEMU crashing when running on an aarch64 Odroid Ubuntu system specifically for s390x emulation. The segfault occurs during execution, and GDB shows the crash happening in `code_gen_buffer` or `__bss_start__`. This suggests an error occurring at runtime. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1863445 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1863445 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1863445 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1869073 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1869073 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1869073 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1870477 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1870477 new file mode 100644 index 000000000..8503de714 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1870477 @@ -0,0 +1,3 @@ +The issue seems to be related to the way Go's runtime interacts with the QEMU environment when running tests. The `go run test.go` command hanging is likely due to the Go runtime not handling certain conditions properly within the QEMU simulation. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1878501 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1878501 new file mode 100644 index 000000000..016f982dd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1878501 @@ -0,0 +1,5 @@ +The bug report describes an issue where `qemu-i386` does not define the `AT_SYSINFO` auxval when running i386 Linux binaries, leading to a segmentation fault when using the i686 Bionic (Android) libc. The problem arises because the code assumes that `getauxval(AT_SYSINFO)` will return a valid function pointer, which is not the case in this environment. + +The classification of this bug should be based on when and how it occurs. Since the issue happens during runtime when executing binaries under QEMU, it falls under a runtime error rather than being related to instructions or system calls directly. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880225 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880225 new file mode 100644 index 000000000..cff1528fb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880225 @@ -0,0 +1,3 @@ +The issue reported involves an assertion failure during emulation of ARM programs using QEMU master, specifically the `probe_guest_base` function failing due to `have_guest_base` not being true. This indicates a problem related to how the guest base is handled in the user-mode emulator. Since this is an internal QEMU error and not directly related to instructions or syscalls but rather runtime processing of the program's memory, it falls under: + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880332 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880332 new file mode 100644 index 000000000..aa82b0836 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880332 @@ -0,0 +1,3 @@ +The issue involves a segmentation fault occurring during user emulation with QEMU 5.0.0 when using a specific cURL binary and TLS configuration. This suggests an error that happens at runtime, likely due to incorrect memory access or handling. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880722 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880722 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1880722 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1883784 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1883784 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1883784 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1885350 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1885350 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1885350 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1886097 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1886097 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1886097 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1887306 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1887306 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1887306 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888303 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888303 new file mode 100644 index 000000000..62780fdad --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888303 @@ -0,0 +1,3 @@ +The issue seems to involve problems during execution when using QEMU for x86_64 emulation on an aarch64 system. The segfaults and intermittent behavior suggest issues at runtime, possibly related to memory alignment or other low-level execution errors. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888728 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888728 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1888728 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1889411 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1889411 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1889411 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1890 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1890 new file mode 100644 index 000000000..616a68787 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1890 @@ -0,0 +1,3 @@ +The issue involves an error mapping a file when running QEMU, which suggests that there's a problem during execution, possibly related to how QEMU interacts with the system or the binary file. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1892081 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1892081 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1892081 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1894029 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1894029 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1894029 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895080 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895080 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895080 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895305 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895305 new file mode 100644 index 000000000..41061c01a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895305 @@ -0,0 +1,3 @@ +The issue described involves `pthread_cancel` failing when using musl libc in QEMU, leading to crashes. This is related to how the system handles threading and cancellation signals during runtime, particularly within the context of the emulator's environment. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895703 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895703 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1895703 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1906536 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1906536 new file mode 100644 index 000000000..bf1e5a767 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1906536 @@ -0,0 +1,3 @@ +The issue reported pertains to the inability to set SVE (Scalable Vector Extension) vector lengths beyond 512 bits in QEMU after a specific commit (7b6a2198). This affects testing and software compiled with larger fixed SVE vector lengths. + +**Classification:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907817 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907817 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907817 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907969 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907969 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1907969 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1908551 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1908551 new file mode 100644 index 000000000..1c077ebef --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1908551 @@ -0,0 +1,10 @@ +The issue described involves problems with SVE (Scalable Vector Extension) emulation in QEMU when running certain string functions like `strnlen` and `strrchr`. The test cases for these functions fail under specific conditions related to vector lengths, even though the code is supposed to be vector length agnostic. This suggests that the problem lies within how QEMU emulates SVE instructions or handles vector operations. + +The possible categories are: +- **instruction**: A faulty instruction in the bug report. +- **syscall**: An error with a system call. +- **runtime**: Other runtime errors. + +Given the context, the issue is related to how QEMU's SVE emulation interacts with the vectorized string functions during runtime. It does not seem to be directly caused by a specific instruction or a syscall error. Instead, it appears to be an issue with how QEMU handles SVE operations in its runtime environment. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1909921 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1909921 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1909921 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1910605 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1910605 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1910605 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1913 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1913 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1913 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1914870 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1914870 new file mode 100644 index 000000000..6d6391ac6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1914870 @@ -0,0 +1,31 @@ +The issue seems to be related to the compilation process failing when trying to build QEMU on Debian unstable. The errors are occurring during the compilation of `utils.cc` from the libvixl disassembler component. + +The error messages point to problems in `/usr/include/string.h`, specifically mentioning missing binary operators and undeclared identifiers like `size_t`. This suggests that there might be a problem with the headers being used, possibly due to an outdated or incompatible version of the C library (glibc) on the system. + +Looking at the system information provided: + +- **OS**: Debian GNU/Linux bullseye/sid +- **C Compiler**: gcc 10.2.1 +- **Linkers**: ld.bfd 2.35.1 + +These are up-to-date versions, so it's unlikely that the issue is with the compiler or linker directly. + +The errors in `string.h` could be due to: + +1. **Missing Dependencies**: Ensure that all necessary development packages (e.g., glibc-dev) are installed and up-to-date. +2. **Header File Corruption**: There might be an issue with the header files themselves. Reinstalling glibc might resolve this. +3. **Compatibility Issues**: The version of libvixl being used might not be compatible with the current glibc headers. + +Steps to troubleshoot: + +1. **Reinstall glibc Development Files**: + ```bash + sudo apt-get install --reinstall libc6-dev + ``` +2. **Check for Updated Dependencies**: + Ensure that all QEMU dependencies are up-to-date. +3. **Update libvixl**: Check if there's a newer version of libvixl that resolves compatibility issues with the current system. + +If these steps don't resolve the issue, further investigation into specific compiler flags or patches might be necessary to align libvixl with the system's headers. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915531 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915531 new file mode 100644 index 000000000..7e8d6bd7c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915531 @@ -0,0 +1,3 @@ +The problem arises because glib's memory allocation using g_slice isn't fork-safe, leading to hangs when forking processes with multiple threads. The workaround involves setting `G_SLICE=always-malloc` to avoid using glib's slice allocator, which resolves the issue. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915925 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915925 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1915925 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1916344 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1916344 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1916344 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1917184 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1917184 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1917184 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1927530 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1927530 new file mode 100644 index 000000000..1bad30b30 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1927530 @@ -0,0 +1,25 @@ +The issue involves the QEMU-aarch64 emulator failing to correctly handle memory tag mismatches when running the GCC testsuite's HWAddressSanitizer (HWASAN) tests. Specifically, when executing `bitfield-2.exe`, QEMU reports a segmentation fault (SEGV) instead of detecting and reporting a tag mismatch as expected by the test. + +Upon analyzing the error message: + +``` +==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 +==21137==The signal is caused by a UNKNOWN memory access. +``` + +It's evident that QEMU is not correctly propagating the tag mismatch information to HWASAN. The test expects an error message indicating a "tag-mismatch" at a specific address, but instead, it encounters a SEGV, which suggests an unhandled or improperly reported memory access issue. + +The problem likely stems from how QEMU handles Memory Tagging Extension (MTE) tags for AArch64. MTE is designed to detect invalid memory accesses by tagging memory regions and checking tag consistency during loads and stores. If QEMU fails to correctly implement or report tag mismatches, it can lead to such errors. + +To categorize this issue under the provided options: + +1. **Instruction**: This would pertain to a specific faulty instruction executed by QEMU. However, the error here isn't due to an incorrect instruction but rather how memory accesses are being handled and reported. + +2. **Syscall**: This category relates to errors during system calls. The issue at hand doesn't involve a syscall failure but rather runtime behavior related to memory access tagging. + +3. **Runtime**: This encompasses other runtime errors not covered by instructions or syscalls. Since the problem occurs during program execution due to improper handling of memory tags, it fits under this category. + +**Conclusion:** The issue is a runtime error in QEMU's handling of Memory Tagging Extension (MTE) for AArch64, leading to incorrect reporting of memory access errors. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1930 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1930 new file mode 100644 index 000000000..2787f6f6a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1930 @@ -0,0 +1,3 @@ +The problem occurs at runtime when trying to run the cross-compiled binary using QEMU, leading to a segmentation fault. Therefore, it falls under the **runtime** category. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1936977 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1936977 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1936977 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1952 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1952 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1952 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1953 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1953 new file mode 100644 index 000000000..407d64404 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/1953 @@ -0,0 +1,16 @@ +The issue involves a segmentation fault occurring during the compilation of an Elixir application within a QEMU environment on an x86_64 host targeting aarch64. The user has provided a GitHub Actions workflow that uses Alpine Linux 3.18 with OTP 25, which includes JIT (Just-In-Time) compilation enabled. + +Segmentation faults are typically related to invalid memory accesses or other low-level errors in the execution environment. Given that the issue occurs within QEMU, it is likely linked to how the emulator handles certain instructions or system calls when running aarch64 code on an x86_64 host. The user referenced a known QEMU issue (https://gitlab.com/qemu-project/qemu/-/issues/1034), which suggests that this problem might be related to how QEMU emulates certain behaviors. + +The error occurs during the `mix escript.install` step, which involves compiling and installing Elixir code. The segmentation fault is happening in the runtime environment of the emulation, specifically when processing aarch64 binaries on an x86_64 host via QEMU. This points to an issue with how the emulator interacts with the guest OS or handles certain operations during execution. + +Considering the categories provided: + +- **instruction**: This would involve issues directly related to specific instructions being executed incorrectly by QEMU. +- **syscall**: This relates to problems with system calls within the emulated environment. +- **runtime**: This category covers other runtime errors that do not fall into the above two, such as memory management or process handling. + +In this case, the segmentation fault is a runtime error occurring during the execution of the Elixir compilation process. It is likely due to how QEMU handles the execution of aarch64 binaries on an x86_64 host, possibly in conjunction with JIT and other runtime optimizations. Therefore, it falls under **runtime**. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2027 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2027 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2027 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2035 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2035 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2035 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2082 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2082 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2082 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2119 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2119 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2119 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2122 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2122 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2122 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2127 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2127 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2127 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2156 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2156 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2156 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2157 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2157 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2157 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2170 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2170 new file mode 100644 index 000000000..e575b83ab --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2170 @@ -0,0 +1,5 @@ +The bug involves a segmentation fault when using `pthread_getattr_np()`, which interacts with system calls and memory regions. The backtrace points to issues within QEMU's handling of self-maps and syscalls. Therefore, it falls under: + +**syscall** + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2208 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2208 new file mode 100644 index 000000000..47c34b02c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2208 @@ -0,0 +1,5 @@ +The issue reported involves the `pc` register not updating correctly when using the `-one-insn-per-tb` option with the `execlog` plugin. The problem occurs during execution where the PC value should change for each instruction but does not, leading to incorrect logging. + +This is a runtime error because it happens during the normal operation of QEMU when processing instructions, affecting the correct execution flow and register updates. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2223 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2223 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2223 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2262 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2262 new file mode 100644 index 000000000..bf55ef752 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2262 @@ -0,0 +1,18 @@ +The bug report describes an issue where `wait4` and `waitpid` return incorrect values when running a background job in a RISC-V 32-bit chroot environment under QEMU Linux-user emulation. This causes the shell to hang indefinitely. + +Key observations: + +1. **Waitid Flood**: The strace output shows repeated calls to `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. This indicates that the process is continuously checking for child process status but not receiving any events. + +2. **Infinite Hang**: When running a background job (e.g., `sleep 1000 &`), the shell hangs indefinitely instead of continuing to accept commands. + +3. **Reproducer Code**: The provided `simple_shell.c` demonstrates that when launching a background process, the shell does not handle it correctly and enters an infinite loop while checking for completed jobs. + +4. **QEMU Emulation Issue**: The problem is specific to QEMU's Linux-user mode emulation of RISC-V 32-bit systems. + +This issue appears to be related to how QEMU handles system calls like `waitid` in the RISC-V 32-bit environment, possibly leading to incorrect return values or not updating process states correctly. It affects runtime behavior by causing indefinite hangs when dealing with background processes. + +**Classification**: The problem is a **runtime** error because it occurs during the execution of the program and relates to how QEMU emulates system calls in this specific environment. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2304 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2304 new file mode 100644 index 000000000..505273cc3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2304 @@ -0,0 +1,3 @@ +The issue reported is about incorrect handling of SVE and SVE2 features when disabling SVE using `-cpu max,sve=off`. The problem arises because QEMU still advertises SVE2 as enabled even after disabling SVE, leading to an inconsistent state in the CPU feature set advertised via `getauxval`. + +**Category:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2309 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2309 new file mode 100644 index 000000000..7a785ce90 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2309 @@ -0,0 +1,9 @@ +The issue described seems to be related to how `qemu-aarch64` interacts with the upgraded version of `libc6`. Since the problem occurs during the execution of `cargo test` and manifests as a hang with 100% CPU usage, it suggests that there might be an error in handling system calls or runtime operations within QEMU when running on the upgraded environment. This could point to issues with how certain instructions are being emulated or how syscalls are being processed under the new libc version. + +Given the options: + +- **instruction**: This category would apply if a specific instruction was causing the hang, which doesn't seem to be directly indicated here. +- **syscall**: If the issue is related to system calls failing or hanging, this could fit. However, the problem seems broader than just syscall handling. +- **runtime**: This is the most general category and would encompass any runtime errors not specifically tied to instructions or syscalls. + +Since the issue occurs during runtime when running tests on `qemu-aarch64` with an upgraded `libc6`, and it doesn't seem to be isolated to a specific instruction or syscall, the best classification is **runtime**. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2336 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2336 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2336 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2353 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2353 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2353 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2376 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2376 new file mode 100644 index 000000000..b99ff04bb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2376 @@ -0,0 +1,5 @@ +The problem involves incorrect behavior in vector instructions (`vcmla.f16` and `vcmla.f32`) within the QEMU emulator, specifically where an unintended vector register is being modified. This is related to how the helper functions handle the number of elements they process, leading to out-of-bound access. + +The issue occurs during runtime when executing these instructions, causing unexpected modifications to registers that should remain unchanged. Therefore, this bug falls under the category of errors happening during runtime. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2448 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2448 new file mode 100644 index 000000000..b5abadc87 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2448 @@ -0,0 +1,3 @@ +The issue arises during the execution phase when QEMU fails to correctly handle the AT_EXECFD value, leading to incorrect file descriptor behavior. This is a runtime problem because it occurs while the program is running and affects how file descriptors are managed. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2460 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2460 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2460 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2486 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2486 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2486 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2505 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2505 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2505 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2525 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2525 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2525 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2560 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2560 new file mode 100644 index 000000000..be8fe8520 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2560 @@ -0,0 +1,4 @@ +The bug involves the Go garbage collector crashing when using `qemu-x86_64` on an AARCH64 host. The crash occurs during `lfstack.push`, which is part of Go's runtime system. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2580 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2580 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2580 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2590 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2590 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2590 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2596 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2596 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2596 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2598 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2598 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2598 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2606 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2606 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2606 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/261 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/261 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/261 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2619 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2619 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2619 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2628 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2628 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2628 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2632 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2632 new file mode 100644 index 000000000..f382b158a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2632 @@ -0,0 +1,3 @@ +The issue described relates to how TCG (Translation-Centric Execution) optimizations are affecting memory access ordering by removing dependencies between loads, leading to incorrect behavior in a multithreaded program. This is an optimization-related problem that occurs during runtime execution. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2647 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2647 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2647 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2655 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2655 new file mode 100644 index 000000000..82c7b3853 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2655 @@ -0,0 +1,15 @@ +The problem described involves unexpected behavior in the `vext_ldff()` function within QEMU's RISC-V target code. Specifically, when dealing with memory callbacks via plugins, the function seems to incorrectly limit vector load operations by setting `vl` to 1 and only loading the first element. + +This issue appears in both user-mode and system-mode simulations. The key points are: + +1. **Function Behavior**: In the loop starting at `env->vstart`, for each index `i`, if `i == 0`, it probes pages normally. For subsequent iterations (`i > 0`), it uses `probe_access_flags()`. If this function returns any flags except `TLB_WATCHPOINT`, it sets `vl = i` and breaks out of the loop. + +2. **Plugin Interaction**: When a plugin provides memory callbacks, `probe_access_flags()` can return `TLB_MMIO`, indicating that the access is to MMIO space. In such cases, the code incorrectly interprets this as an error condition, leading to early termination of the vector load operation after only the first element. + +3. **Impact**: This results in incomplete vector loads, which is incorrect behavior for vector instructions like `vle(x)ff.v`. + +4. **Proposed Fix**: The user suggests modifying `probe_access_flags()` by adding an extra parameter to adjust its behavior when dealing with MMIO or other special cases. Alternatively, the loop logic might need adjustment to correctly handle all elements even when MMIO is involved. + +This bug affects QEMU's runtime execution, specifically how vector instructions interact with memory callbacks provided by plugins. It does not stem from a faulty instruction itself but rather from incorrect handling within QEMU's vector helper functions. + +**Category:** `runtime` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2683 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2683 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2683 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/275 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/275 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/275 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/276 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/276 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/276 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2761 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2761 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2761 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/280 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/280 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/280 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2815 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2815 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2815 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2846 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2846 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/2846 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/306 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/306 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/306 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/311 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/311 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/311 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/324 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/324 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/324 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/326 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/326 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/326 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/355 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/355 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/355 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/356 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/356 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/356 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/385 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/385 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/385 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/419 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/419 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/419 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/442 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/442 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/442 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/447 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/447 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/447 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/562107 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/562107 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/562107 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/570 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/570 new file mode 100644 index 000000000..8e9171e65 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/570 @@ -0,0 +1,14 @@ +The given bug report mentions a warning related to redefining a macro "TIOCSER_TEMT" in a header file within QEMU's source code. This seems to be an issue during the build process or compilation. + +**runtime** + +However, since the user's categories are instruction, syscall, and runtime, and this is more about compilation rather than runtime behavior, none of these fit perfectly. But if I have to choose, it might fall under "runtime" as it's not a syscall or an instruction issue but affects the runtime environment indirectly. + +**runtime** + +Alternatively, since it's a redefinition warning, which can cause unexpected behavior at runtime due to conflicting definitions, "runtime" makes sense. + +**runtime** +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/602 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/602 new file mode 100644 index 000000000..ceb5b5b0f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/602 @@ -0,0 +1,3 @@ +The bug report describes an issue related to handling system calls (`IP_RECVERR` and `IPV6_RECVERR`) where the error numbers are not being translated correctly between host and target architectures. This directly impacts how system calls behave in the translated environment. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/616 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/616 new file mode 100644 index 000000000..c7c4e8cb4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/616 @@ -0,0 +1,13 @@ +The problem described involves an incorrect determination of the overflow condition code after addition on the s390x architecture when using QEMU. The issue arises during the execution of a program that uses `__builtin_add_overflow` to check for integer overflows. When compiled and run under QEMU, the overflow checks incorrectly return 'no_overflow = 1', indicating an overflow occurred, whereas the expected result is 'no_overflow = 0' (no overflow). + +The provided assembly code shows that GCC generates instructions utilizing the 'o' condition code to determine overflow. However, when executed in QEMU, this condition code is not set correctly, leading to the incorrect behavior. + +To classify this bug: + +1. **Instruction**: The problem does not stem from a faulty instruction itself but rather how QEMU handles the condition codes after an arithmetic operation. +2. **Syscall**: There are no issues related to system calls mentioned in the report. +3. **Runtime**: This issue occurs during runtime when the program is executing and checking for overflow conditions. + +Thus, the bug falls under the "runtime" category as it relates to how QEMU handles condition codes at runtime, leading to incorrect overflow detection. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/618 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/618 new file mode 100644 index 000000000..ebf6f59a6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/618 @@ -0,0 +1,5 @@ +The issue described relates to how QEMU handles the overflow condition code on the s390x architecture during subtraction operations. The problem arises because QEMU incorrectly sets the overflow bit, leading to incorrect results when using the `__builtin_sub_overflow` function. This affects both 32-bit and 64-bit integer subtractions. + +The bug is part of the runtime category because it pertains to how QEMU executes instructions on the s390x architecture during runtime, specifically regarding condition code handling after subtraction operations. The incorrect setting of the overflow bit causes unexpected behavior in programs relying on accurate overflow detection. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/633 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/633 new file mode 100644 index 000000000..f6f327f7b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/633 @@ -0,0 +1,5 @@ +The bug report describes an issue where running `apt update` fails due to GPG signature validation errors, but this is caused by a deeper problem when using QEMU's user-mode emulation. The error message `Allocating guest commpage: Operation not permitted` suggests that there's a problem with memory allocation in the guest environment. This seems related to system calls or permissions within the virtualized environment provided by QEMU. + +Given the context, this issue likely falls under the **runtime** category because it occurs during runtime when attempting to allocate memory for the guest communication page. The problem isn't due to an invalid instruction or a direct syscall error but rather an operational issue that arises while running the program in the virtualized environment. + +**runtime** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/654 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/654 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/654 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/690 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/690 new file mode 100644 index 000000000..59db9cfb7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/690 @@ -0,0 +1,8 @@ +The issue seems to be related to memory allocation during the initialization of the guest space in QEMU. The problem occurs when trying to allocate a range for the guest, specifically failing due to an `Operation not permitted` error. This suggests that there might be restrictions or changes in how memory is being managed or mapped by the host kernel, possibly influenced by sysctl parameters like `vm.mmap_min_addr`. + +The fact that this issue started appearing after specific commits and affects certain distributions (like Arch Linux) but not others indicates it could be tied to how different kernels handle memory mappings. The varying outcomes based on `vm.mmap_min_addr` values further point towards a problem with how QEMU is interacting with the host's memory management system. + +Given that the error occurs at runtime when trying to allocate memory for the guest, this seems like an issue during the execution of QEMU rather than a build-time or instruction-level problem. Therefore, it falls under runtime errors. +</think> + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/693 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/693 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/693 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/697 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/697 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/697 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/698 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/698 new file mode 100644 index 000000000..b279743fd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/698 @@ -0,0 +1,5 @@ +The issue appears to be related to memory mapping discrepancies between the emulated environment and the host system when using QEMU user-mode emulation for 32-bit ARM builds. The problem occurs when trying to access specific memory addresses that are either not mapped or incorrectly mapped in the host process, leading to errors such as "Input/output error" when reading from `/proc/self/mem`. + +This issue is related to how QEMU handles memory mappings and interacts with the host system's memory management. It is a runtime error because it occurs during the execution of the program when attempting to access certain memory addresses that are not correctly handled by the emulation layer. + +**Category:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/704 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/704 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/704 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/754635 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/754635 new file mode 100644 index 000000000..d603a8395 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/754635 @@ -0,0 +1,9 @@ +The bug report describes an issue where the `-d in_asm` option outputs incorrect information about memory sections when running QEMU versions 0.14.0 and later compared to earlier versions like 0.12.5. The user provided a patch that corrects the output by modifying how addresses are calculated in `exec.c`. + +The problem arises from changes in how memory regions are walked, specifically in the calculation of guest addresses. In QEMU 0.14.0, the address is shifted by `V_L1_SHIFT`, which is 10 bits for i386, whereas the correct shift should include both `V_L1_SHIFT` and `TARGET_PAGE_BITS` (which is 12 bits) to properly align memory regions. + +The user's patch adjusts the calculation in `walk_memory_regions_1` to use `(abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS)` instead of just shifting by `V_L1_SHIFT`. This correction ensures that the memory sections are correctly aligned and displayed, matching the behavior observed in QEMU 0.12.5. + +The issue is related to how QEMU handles memory regions during runtime, particularly when logging guest address spaces. Therefore, it falls under a **runtime** error since it pertains to incorrect behavior during the execution of the program rather than an instruction-level fault or a syscall issue. + +**Answer:** runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/796480 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/796480 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/796480 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/805 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/805 new file mode 100644 index 000000000..5ecbba045 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/805 @@ -0,0 +1,3 @@ +The error occurs when trying to map a 32-bit binary into memory on a 64-bit system using QEMU's Hexagon emulator. This suggests an issue with how the emulator handles 32-bit binaries in a 64-bit environment. The problem is likely related to how file mappings are handled during runtime. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/817 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/817 new file mode 100644 index 000000000..e6a663370 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/817 @@ -0,0 +1,3 @@ +The given bug report mentions an issue with `waitid` leaving target `siginfo` uninitialized when `info.si_pid` is zero. This problem occurs during the execution of QEMU and relates to how system calls handle signal information. Therefore, this falls under a **runtime** error because it's an issue that arises during the runtime execution of the program. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/834 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/834 new file mode 100644 index 000000000..be7152f13 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/834 @@ -0,0 +1,4 @@ +The problem described involves signals not being delivered as expected when running under QEMU. The issue arises during the use of `pselect()`, where signals that should be caught by the program are not being handled properly. This suggests an issue related to how QEMU handles system calls or signal delivery in its runtime environment. + +**Answer:** +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/866 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/866 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/866 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/886621 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/886621 new file mode 100644 index 000000000..626f09f31 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/886621 @@ -0,0 +1,3 @@ +The given text appears to be a detailed system information dump from macOS, including hardware specifications, memory usage, loaded libraries, and external modifications. It does not describe a specific bug or issue related to QEMU. Therefore, it cannot be classified into any of the provided categories (instruction, syscall, runtime). However, if forced to choose based on the structure and content, it might fall under "runtime" as it describes system state during runtime. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/909 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/909 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/909 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/922 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/922 new file mode 100644 index 000000000..57a48f3a8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/922 @@ -0,0 +1,19 @@ +The issue involves running `grep` via `qemu-arm-static`, leading to random segmentation faults. The problem is reproducible across several QEMU versions (6.2, 5.2, 5.1) but not in version 5.0. This suggests a regression introduced in the newer versions of QEMU. + +The segmentation fault indicates that during execution, the program accesses an invalid memory location, which is often related to how the CPU or memory management unit (MMU) handles instructions and memory access. Since `grep` is a tool that parses text files, it's possible that certain patterns or edge cases in the input file trigger this issue. + +Given that the problem occurs when running ARM binaries on an x86_64 host using QEMU, it might be related to how QEMU emulates the ARM architecture. Specifically, the fault could arise from incorrect handling of certain instructions or memory operations by the emulator. + +The categories provided are: + +1. **instruction**: A faulty instruction is described in the bug report. +2. **syscall**: An error with a syscall. +3. **runtime**: Other errors which happen in runtime. + +Considering the information: + +- The segmentation fault occurs during runtime, not necessarily due to a specific faulty instruction or a syscall issue. It seems more like an unexpected behavior that arises during normal execution of `grep`. + +Therefore, the most appropriate category is **runtime**. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/939 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/939 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/939 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/95 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/95 new file mode 100644 index 000000000..9e1976b33 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/95 @@ -0,0 +1 @@ +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/967 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/967 new file mode 100644 index 000000000..30b13f64f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/967 @@ -0,0 +1,5 @@ +The given output appears to be a memory map (process status) from QEMU running on Ubuntu. The user has provided information about their system setup, including the installed version of QEMU and compiler details. However, no specific bug report or issue is described in the query. To classify a bug report, more context or symptoms of the bug would be needed. + +Since there's no specific bug report mentioned, I'll assume this is related to runtime issues as it shows process memory usage. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/979 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/979 new file mode 100644 index 000000000..42c3e95f1 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/runtime/979 @@ -0,0 +1,3 @@ +The bug report describes an issue with floating point conversion functions on s390x architecture in QEMU. This falls under the category of runtime errors because it pertains to incorrect handling during runtime execution rather than issues related to instructions or syscalls. + +runtime \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1007 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1007 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1007 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1012 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1012 new file mode 100644 index 000000000..9fa25062d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1012 @@ -0,0 +1,3 @@ +The problem arises from the use of `newfstatat` instead of `fstat`, leading to ENOENT errors when handling here-documents on 9p mounts. This is related to system calls and how they interact with file operations. + +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1033 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1033 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1033 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1052857 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1052857 new file mode 100644 index 000000000..ed43429bc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1052857 @@ -0,0 +1,11 @@ +The issue described seems to be related to how QEMU handles certain signals or exceptions during execution when running in a chroot environment on a 64-bit host. The assertion failure points to an issue within the `signal.c` file at line 4341, specifically with setting up the frame for signal handling. This suggests that there might be a problem with how QEMU is translating or emulating system calls (syscalls) and exceptions in this specific setup. + +Considering the possible categories provided: + +- **Instruction**: This would involve an issue with how individual CPU instructions are handled by QEMU, which doesn't seem to be the case here. +- **Syscall**: Since the error occurs during signal handling, which involves system calls and exception management, this category fits well. +- **Runtime**: While it's a runtime error, the specific cause is related to signal handling, making "syscall" more precise. + +Given that the problem arises when interacting with the chroot environment and specifically points to signal handling code, the most appropriate classification is: + +**syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1054831 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1054831 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1054831 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075272 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075272 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075272 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075339 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075339 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1075339 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1076445 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1076445 new file mode 100644 index 000000000..730922914 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1076445 @@ -0,0 +1,7 @@ +The issue described involves `qemu-i386` failing when executing a cross-compiled program that uses the `system()` function. This problem does not occur with other architectures like ARM or MIPS. The user has tried both i386 and x86_64 toolchains, both resulting in failure, while other architectures work fine. + +The classification of this bug is likely related to how QEMU handles system calls on specific architectures when using a cross-compiled environment. Since the problem arises with `system()`, which invokes a shell command, it suggests an issue with how the cross-toolchain interacts with QEMU's emulation for x86 architectures. The failure could be due to missing or incorrectly implemented syscalls in QEMU's i386 and x86_64 emulators when dealing with certain system calls. + +Therefore, this bug falls under the category of: + +**syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1111 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1111 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1111 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1238 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1238 new file mode 100644 index 000000000..fb946450c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1238 @@ -0,0 +1,12 @@ +The issue involves problems with `coreutils-9*`, specifically `install` and `cp`, encountering errors related to `fadvise64` and `fallocate` when using QEMU for MIPS N32 systems. The strace output shows that these operations result in "Invalid argument" errors, which are likely due to compatibility issues with the ext4 filesystem on MIPS N32 under QEMU. + +The bug report points to a problem during runtime where system calls (`fadvise64` and `fallocate`) fail with an invalid argument error. This suggests that the issue is related to how these syscalls are being handled or emulated within the QEMU environment for MIPS N32 architectures. + +Considering the categories provided: +- **instruction**: Not applicable, as there's no mention of specific CPU instructions causing issues. +- **syscall**: Directly relevant because the errors occur during system calls (`fadvise64` and `fallocate`) with invalid arguments. +- **runtime**: While the issue does occur at runtime, it is more specifically tied to syscall failures. + +Therefore, the most accurate classification for this bug report is: + +**syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1261 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1261 new file mode 100644 index 000000000..b56647277 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1261 @@ -0,0 +1,3 @@ +The problem described involves an issue where the `faccessat2` system call (number 439) is not implemented in QEMU for the LoongArch64 architecture. This leads to incorrect behavior when checking file access permissions using `[[ -r test.sh ]]`. The error occurs during runtime and affects the functionality of user-space applications running under QEMU. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1394 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1394 new file mode 100644 index 000000000..1fe127941 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1394 @@ -0,0 +1,3 @@ +The problem involves incorrect byte ordering when calling `getresuid()` in a sparc64 guest under QEMU. This suggests an issue in how the system call is handled, particularly regarding endianness and data alignment. The unexpected output indicates that the system call is not returning the expected values due to a byte-swapping error. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1457275 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1457275 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1457275 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1470170 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1470170 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1470170 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1516408 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1516408 new file mode 100644 index 000000000..cc32d252c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1516408 @@ -0,0 +1,3 @@ +The issue reported involves an unsupported system call (number 186) when running a sh4 target on QEMU. This falls under the handling of system calls within the emulator, specifically for the sh4 architecture where this particular syscall is not implemented. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1617929 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1617929 new file mode 100644 index 000000000..e4e21be61 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1617929 @@ -0,0 +1,3 @@ +The issue seems to involve QEMU hanging during the `pselect` system call, as evidenced by the backtrace and strace logs provided. This suggests that there might be an error or problem related to how QEMU handles syscalls, specifically `pselect`, leading to a hang in certain conditions. + +**syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1619896 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1619896 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1619896 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1643619 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1643619 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1643619 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1689367 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1689367 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1689367 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1696773 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1696773 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1696773 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701808 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701808 new file mode 100644 index 000000000..34a0f73fe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701808 @@ -0,0 +1,3 @@ +The issue involves the `recvmsg` system call causing stack smashing when run under QEMU's user mode for AArch64. On native hardware, it works fine, but under emulation, it leads to a crash. The problem is related to how memory is managed during this system call. + +**Category: syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701971 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701971 new file mode 100644 index 000000000..5939dc61c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701971 @@ -0,0 +1,7 @@ +The issue reported involves multithreading not functioning correctly under QEMU user mode for SH4, specifically related to thread termination and `pthread_join`. The problem arises when running a program that works on other architectures but hangs when using QEMU's SH4 emulation. + +Upon analysis, the stack traces indicate issues with futex syscalls (`safe_futex`), which are used in thread synchronization. The main thread is stuck waiting for worker threads to terminate, and the extra threads seem to be related to RCU (RCU call ready event) handling. + +This points towards a problem within QEMU's handling of certain syscalls or thread management on the SH4 architecture, rather than an issue with individual instructions. Therefore, it falls under the category of a **syscall** error. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701973 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701973 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701973 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701974 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701974 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1701974 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1716292 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1716292 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1716292 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1726394 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1726394 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1726394 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1728116 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1728116 new file mode 100644 index 000000000..6b90a5124 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1728116 @@ -0,0 +1,16 @@ +The bug report describes an issue where the file `/proc/self/auxv` returns zero bytes when read using QEMU's user mode emulation, causing tools like `cat` and procps-ng to malfunction or segfault. The problem was introduced in a specific commit and affects newer versions of QEMU. + +From the analysis: +- **Symptom**: Reading from `/proc/self/auxv` yields 0 bytes instead of the expected data. +- **Impact**: Tools relying on this file may crash or enter infinite loops. +- **Investigation**: A `git bisect` identified a specific commit as the source, and logging showed unexpected values for `len`, possibly due to an integer overflow or sign issue. + +**Key Analysis**: +1. The affected code is part of QEMU's user-mode emulation, specifically in handling syscalls related to `/proc/self/auxv`. +2. The issue manifests during runtime when accessing the file. +3. The problem likely stems from a logic error (e.g., incorrect length calculation or sign handling) rather than an instruction-level fault. + +**Categorization**: +The bug primarily relates to how QEMU handles syscalls, particularly in intercepting and providing content for `/proc/self/auxv`. It involves incorrect behavior during runtime due to a faulty system call implementation. + +**Answer**: syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1729 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1729 new file mode 100644 index 000000000..db48ceef5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1729 @@ -0,0 +1,5 @@ +The issue described involves `mremap` failing due to an overlap with the stack guard during the execution of a program that uses `pthread_getattr_np`. This problem is encountered when running 32-bit user-static on a 64-bit host using QEMU. + +To classify this bug, it's important to determine where the issue originates. Since the problem arises from the behavior of the `mremap` system call and its interaction with the stack guard in QEMU, it falls under an error related to a system call rather than an instruction or runtime error specific to the application or musl-libc. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1734792 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1734792 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1734792 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1738545 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1738545 new file mode 100644 index 000000000..a0a425fbb --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1738545 @@ -0,0 +1,19 @@ +The bug report describes an issue where Go binaries panic with "mmap errno 9" when run under QEMU's user-mode emulation (qemu-user). The problem does not occur on real hardware, suggesting it is specific to the QEMU environment. + +**Analysis:** + +1. **Issue Symptom:** The error occurs during the execution of a simple Go program, specifically when using `gccgo-7` to compile and run on an ARMEL system under QEMU. +2. **Error Details:** The panic message points to a problem with `mmap`, indicating that the program is unable to map memory properly in this environment. +3. **Reproducibility:** The issue consistently occurs under QEMU but works fine on real hardware, pointing towards an issue within QEMU's handling of certain operations. + +**Possible Categories:** + +- **Instruction:** Relates to faulty or misinterpreted instructions. +- **Syscall:** Errors during system calls, such as `mmap`. +- **Runtime:** Other runtime-related issues beyond syscalls. + +**Classification:** + +The error arises from a problem with the `mmap` system call within QEMU's user-mode emulation. This suggests that QEMU is not correctly handling or emulating this syscall for ARMEL targets. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1749393 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1749393 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1749393 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756807 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756807 new file mode 100644 index 000000000..017b158d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1756807 @@ -0,0 +1,17 @@ +The issue reported involves performance regression when using `qemu-user` and `proot` on Ubuntu 18.04 compared to Ubuntu 16.04. The user is encountering significant slowdowns when executing commands within an ARM chroot environment, specifically noting that a simple `grep` command takes over 24 seconds on the newer system versus less than 0.1 seconds on the older setup. + +From the details provided: + +- **System Differences**: The systems differ in hardware specs (higher-end CPU and more RAM on System 1 vs. lower specs on System 2), but the performance discrepancy is far beyond what would be expected from hardware differences alone. +- **Software Versions**: On Ubuntu 16.04, `qemu-arm` version 2.10.1 (from a cloud repo) is used, while on Ubuntu 18.04, it's `qemu-arm` version 2.11.1 from the standard repository. +- **Proot Version**: Both systems use proot 5.1.0, so it's unlikely to be the cause of the issue. + +The problem is likely related to changes in the QEMU implementation between versions 2.10 and 2.11 that affect performance when running user-mode emulation with `proot`. Possible areas of concern could include: + +- **Emulation Overheads**: Changes in how QEMU handles system calls or emulates the ARM architecture might introduce overheads not present in earlier versions. +- **syscall Handling**: Issues in handling syscalls efficiently, leading to increased CPU usage (as seen in the user and sys times). +- **Runtime Performance Bottlenecks**: Other runtime optimizations or regressions that impact the overall execution speed. + +Given these observations, the issue seems to stem from how QEMU is processing system calls or emulating the ARM environment in version 2.11.1 compared to 2.10.1. This suggests a potential problem with how syscalls are being handled in the newer version of QEMU. + +**Classification**: syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1760 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1760 new file mode 100644 index 000000000..ce120f23a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1760 @@ -0,0 +1,6 @@ +The problem described involves incorrect decoding of system call arguments for the `_NR_mmap` ( syscall number 90) in a 32-bit environment when using `qemu-i386`. The user has provided code snippets and outputs from both native execution (`strace`) and under QEMU, showing discrepancies in how the `mmap` system call is handled. Specifically, the arguments passed to the `mmap` syscall are not being decoded correctly by QEMU. + +This issue falls under the **"syscall"** category because it directly relates to an error in handling a system call within the QEMU emulator. The problem is specifically about how the arguments for the `mmap` system call are interpreted, which is essential for correct emulation of 32-bit binaries. +</think> + +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1791796 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1791796 new file mode 100644 index 000000000..fa2697fda --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1791796 @@ -0,0 +1,3 @@ +The issue involves problems with specific system calls (`set_robust_list` and `clone`) being reported as unimplemented. This indicates an error related to system call handling within QEMU. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1805913 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1805913 new file mode 100644 index 000000000..32045ca3d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1805913 @@ -0,0 +1,3 @@ +The issue arises because when running 32-bit user-static QEMU on a 64-bit host, the `getdents64` system call returns 64-bit inode numbers and offsets which exceed the 32-bit limits expected by the C standard in glibc's `readdir()` function. This causes `readdir()` to return `NULL` with `errno=EOVERFLOW`. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1810433 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1810433 new file mode 100644 index 000000000..6cb8e2fd3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1810433 @@ -0,0 +1,3 @@ +The bug report describes an issue with the `pwrite` system call emulation in QEMU's aarch64-linux-user mode. The inconsistency arises when `buf` is `NULL` and `len` is 0, leading to different results compared to native environments. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1813307 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1813307 new file mode 100644 index 000000000..b26147fe2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1813307 @@ -0,0 +1,63 @@ +The issue reported pertains to how the `follow_path()` function handles the root directory ("/") and its implications on `__getcwd` within QEMU's implementation. This is a problem that occurs during runtime when handling system calls such as `lstat`. + +**Category: syscall** + +The bug involves incorrect handling of file system paths, specifically at the root level, which impacts system call operations like `lstat`. The inconsistency in mapping "/" to the appropriate root directory leads to failures in determining the current working directory correctly. This issue affects how QEMU interacts with the host's file system when running processes within a chroot or sysroot environment. + +**Analysis:** + +1. **Problem Identification:** + - When `__lstat("/")` is called, QEMU maps "/" to `QEMU_LD_PREFIX`, which is intended as a way to handle sysroots. + - Subsequent calls using `lstat("..")` attempt to traverse up the directory tree but fail to recognize when they've reached the true root ("/"), leading to incorrect behavior in `__getcwd`. + +2. **Impact:** + - This inconsistency causes processes running under QEMU, such as gdbserver, to malfunction because their understanding of the file system hierarchy is flawed. + - The issue is critical for applications that rely on accurate path resolution and current working directory information. + +3. **Possible Solutions:** + - Adjust `follow_path()` so that "/" consistently maps to the actual root ("/") rather than `QEMU_LD_PREFIX`. + - Evaluate whether there are valid reasons for the existing behavior (e.g., supporting sysroots) and consider alternative approaches that maintain compatibility while resolving the inconsistency. + +4. **Testing Considerations:** + - After modifying `follow_path()`, thorough testing is required to ensure that both sysroot and non-sysroot scenarios function correctly. + - Test cases should verify that `__getcwd` returns the expected paths and that processes like gdbserver operate as intended within QEMU. + +**Conclusion:** + +The root cause of the issue lies in how `follow_path()` handles the "/" directory, leading to inconsistencies in system calls related to file system navigation. Addressing this requires revisiting the logic in `follow_path()` to ensure proper handling of the root directory, thereby restoring correct behavior for applications relying on accurate path resolution within QEMU. + +```fix +diff --git a/util/path.c b/util/path.c +--- a/util/path.c ++++ b/util/path.c +@@ -123,7 +123,7 @@ char *follow_path(const char *base, const char *relative, + } + } else if (relative[0] == '/') { + /* Absolute path */ +- p = relative; ++ p = relative; // TODO: Handle "/" properly + base = NULL; + } + +@@ -132,7 +132,14 @@ char *follow_path(const char *base, const char *relative, + } + + if (base) { +- p = qemu_get_datadir(); ++ // If base is the sysroot and relative is "/", map to the actual root ++ if (strncmp(base, QEMU_LD_PREFIX, strlen(QEMU_LD_PREFIX)) == 0 && relative[0] == '/' && relative[1] == '\0') { ++ p = "/"; ++ } else { ++ p = qemu_get_datadir(); ++ } ++ + } else { + p = relative; + } +``` + +**Final Answer:** + +The bug is categorized under **syscalls**, as it pertains to the incorrect handling of file system paths during system calls like `lstat`, leading to failures in processes running within QEMU. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1821006 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1821006 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1821006 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1837 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1837 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1837 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1860053 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1860053 new file mode 100644 index 000000000..08595c94b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1860053 @@ -0,0 +1,11 @@ +The issue reported is related to the behavior of QEMU's user-mode emulation of the ppc64le architecture when handling vDSO calls to `clock_gettime()`. The problem causes time-based functions like `time.NewTicker()` and `time.Sleep()` in Go programs to malfunction, leading to sleeps or ticks that do not respect sub-second granularities. This suggests an issue with how QEMU handles these specific system calls or the virtual dynamic shared object (vDSO) mechanism. + +Given the categories provided: + +1. **instruction**: Refers to issues with individual machine instructions. +2. **syscall**: Relates to errors in handling system calls. +3. **runtime**: Covers other runtime-related issues not specifically tied to instructions or syscalls. + +This issue is centered around how QEMU emulates `clock_gettime()` via vDSO, which is a system call mechanism. The problem arises during the execution of these syscalls within the user-mode emulation, leading to incorrect timing behavior. Therefore, this falls under **syscall** because it involves errors in handling system calls, specifically those related to timekeeping. + +Answer: syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1861341 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1861341 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1861341 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1876373 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1876373 new file mode 100644 index 000000000..b0c984a66 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1876373 @@ -0,0 +1,11 @@ +The issue described involves an unexpected segmentation fault when using `mremap` within QEMU for certain architectures (i386 and 32-bit ARM). The problem does not occur when running natively on x86_64 or when resizing to a different size, indicating it might be specific to how QEMU handles the `mremap` system call in these contexts. + +**Analysis:** +- The segmentation fault occurs during the `mremap` syscall. +- It's reproducible with both i386 and 32-bit ARM emulations but not on native x86_64 or when resizing to a different size (e.g., 12288). +- Debugging with `-singlestep` confirms that the segfault happens during `mremap`. + +**Conclusion:** +The issue is related to how QEMU handles the `mremap` system call for specific architectures, leading to an unexpected segmentation fault. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1893010 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1893010 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1893010 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1894361 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1894361 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1894361 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926246 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926246 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926246 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926521 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926521 new file mode 100644 index 000000000..2ac0003d0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926521 @@ -0,0 +1,12 @@ +The issue reported is related to how QEMU handles the `madvise` system call, specifically when using `MADV_DONTNEED`. The user provided a reproducer that demonstrates the problem where the application's assertion fails when run under QEMU but works correctly on native Linux. + +Upon reviewing the QEMU source code (as linked), there is a comment indicating that `MADV_DONTNEED` is being ignored with a return of success. However, according to the man pages for `madvise`, `MADV_DONTNEED` changes the semantics of memory access, which can affect application behavior. + +This suggests that QEMU's current implementation does not correctly handle the `MADV_DONTNEED` advice, leading to incorrect program execution in certain cases. The problem arises during system call handling within QEMU, as it does not properly process this specific `madvise` operation. + +Therefore, the bug falls under the **syscall** category because it involves an error with how a system call (`madvise`) is being handled by QEMU. +</think> + +The issue relates to how QEMU handles the `MADV_DONTNEED` advice during the `madvise` system call. The problem occurs in the runtime when executing applications that rely on this specific behavior, which is not correctly implemented in QEMU. + +**syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926996 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926996 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/1926996 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2101 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2101 new file mode 100644 index 000000000..511393877 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2101 @@ -0,0 +1,3 @@ +The issue involves running an x86_64 binary on an aarch64 platform using QEMU, and it results in incorrect output when listing files with `ls`. This suggests that there might be a problem with how system calls are being handled or translated by QEMU. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2112 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2112 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2112 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2123 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2123 new file mode 100644 index 000000000..f3eed77e2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2123 @@ -0,0 +1,3 @@ +The issue is related to how QEMU handles process spawning when executing a non-existent command. The program expects an error but instead gets a child process ID. This indicates a problem in how QEMU manages subprocesses or interacts with system calls. + +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2168 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2168 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2168 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2197 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2197 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2197 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2333 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2333 new file mode 100644 index 000000000..1969c7e55 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2333 @@ -0,0 +1,3 @@ +The issue appears to be related to how VDSO (Virtual Dynamic Shared Object) handles certain system calls on armeb architecture within QEMU. The crash occurs during `__clock_gettime64()`, which is triggered by `time()` in the provided code. The problem does not occur when VDSO is disabled, suggesting that the issue lies within the handling of VDSO syscalls in QEMU for big-endian ARM. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2390 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2390 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2390 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2410 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2410 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2410 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2446 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2446 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2446 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2485 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2485 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2485 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2553 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2553 new file mode 100644 index 000000000..81401def7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2553 @@ -0,0 +1,7 @@ +The issue described pertains to how the `setsockopt` system call is handled when emulating 64-bit Linux platforms using QEMU. Specifically, there's an incorrect marshaling of the `struct ip_mreqn` structure, which leads to the `imr_ifindex` field being improperly processed. This results in a failure when joining IP multicast groups under emulation due to the kernel interpreting the structure incorrectly. + +The problem arises because the definition of `struct target_ip_mreqn` in QEMU's `linux-user/syscall_defs.h` uses an `abi_long` for `imr_ifindex`, whereas on Linux, this field is a 32-bit integer. This mismatch causes the size and alignment of the structure to differ from what the host kernel expects, leading to unexpected behavior or errors. + +Additionally, there's concern about how QEMU handles the size validation of the `ip_mreq`/`ip_mreqn` structures. The current check allows sizes between those of `target_ip_mreq` (8 bytes) and `target_ip_mreqn` (16 bytes), which might lead to passing uninitialized memory or incorrect structure interpretations, further contributing to the issue. + +**Category: syscall** \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2592 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2592 new file mode 100644 index 000000000..15d4cfb0a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2592 @@ -0,0 +1,3 @@ +The issue seems to be related to how `qemu-aarch64` handles certain system calls required by Python's `time.time()` function. When running Python under `qemu-aarch64`, it results in an error that doesn't occur on a native AArch64 machine or with `qemu-arm`. This suggests a problem with the emulation of system calls specific to the AArch64 architecture in QEMU. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/263 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/263 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/263 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2738 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2738 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/2738 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/470 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/470 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/470 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/577 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/577 new file mode 100644 index 000000000..7eb6a2073 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/577 @@ -0,0 +1,3 @@ +The issue seems to be related to how QEMU handles system calls when running in user mode on Linux/alpha. Specifically, the `getdtablesize()` function returns an incorrect value, leading to invalid file descriptors. This suggests that there might be a problem with the implementation of this syscall in QEMU for the alpha architecture. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/578 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/578 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/578 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/579 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/579 new file mode 100644 index 000000000..7c7c2d70c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/579 @@ -0,0 +1,3 @@ +The issue involves the `chown()` system call failing when it should succeed under QEMU user mode on Linux/sparc64. The classification is based on the error occurring during the execution of a system call. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/829 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/829 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/829 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/833 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/833 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/833 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/836 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/836 new file mode 100644 index 000000000..99591622d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/836 @@ -0,0 +1,3 @@ +The problem involves an issue where the `lseek()` system call returns `-14` (EFAULT), which should not occur according to the man page. This indicates a problem with how the system call is handled by QEMU. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/856 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/856 new file mode 100644 index 000000000..0fad228d9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/856 @@ -0,0 +1,3 @@ +The issue seems to involve deadlocks and futex operations within QEMU's SH4 Linux user mode emulation when running a threadcount test. The backtrace indicates that threads are waiting on futex calls, which are part of system calls. Therefore, the bug is related to system call handling. + +**Answer:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/871 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/871 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/871 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/885 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/885 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/885 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/911 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/911 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/911 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/927 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/927 new file mode 100644 index 000000000..2d078d092 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/927 @@ -0,0 +1 @@ +syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/957 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/957 new file mode 100644 index 000000000..a6e6ab61b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/957 @@ -0,0 +1,3 @@ +The issue reported involves Python crashing during a rebuild when using QEMU-M68k, specifically encountering an error related to the futex facility returning an unexpected error code ("Invalid argument"). The problem seems to stem from system calls (syscalls) within the futex mechanism, as evidenced by the logs showing multiple threads interacting with futex operations and resulting in errors. This suggests that there is a problem with how certain syscalls are being handled or emulated in the QEMU environment. + +**Category:** syscall \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/982 b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/982 new file mode 100644 index 000000000..c663b5979 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/reasoning/syscall/982 @@ -0,0 +1,3 @@ +The issue described involves incorrect decoding of arguments for the `writev` system call when using `--strace` on 64-bit binaries running on a 32-bit machine with QEMU. This suggests that the problem lies in how QEMU handles or traces syscalls, specifically `writev`, across different architectures. + +**Category:** syscall \ No newline at end of file |