diff options
Diffstat (limited to 'results/classifier/deepseek-2-tmp/output/mistranslation')
415 files changed, 11947 insertions, 0 deletions
diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1024 b/results/classifier/deepseek-2-tmp/output/mistranslation/1024 new file mode 100644 index 000000000..f42623c85 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1024 @@ -0,0 +1,11 @@ + +Unable to build QEMU with dbus display support on Windows +Description of problem: +When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears: + +`ERROR: Modules are not available for Windows` +Steps to reproduce: +1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support +Additional information: +Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows: +`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1042561 b/results/classifier/deepseek-2-tmp/output/mistranslation/1042561 new file mode 100644 index 000000000..127c7c1ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1042561 @@ -0,0 +1,35 @@ + +Guest has no "xsave" feature with parameter "-cpu qemu64,+xsave" in qemu command line. + +Environment: +------------ +Host OS (ia32/ia32e/IA64):ia32e +Guest OS (ia32/ia32e/IA64):ia32e +Guest OS Type (Linux/Windows):Linux +kvm.git Commit:1a577b72475d161b6677c05abe57301362023bb2 +qemu-kvm Commit:98f1f30a89901c416e51cc70c1a08d9dc15a2ad4 +Host Kernel Version:3.5.0-rc1 +Hardware:Romley-EP, Ivy-bridge + + +Bug detailed description: +-------------------------- +Guest has no "xsave" feature when create guest with parameter "-cpu qemu64,+xsave,+avx" in qemu command line, but the guest has avx feature. +When starting a guest with parameter "-cpu host" in qemu command line, the guest has 'avx' and 'xsave' features (as /proc/cpuinfo shows). + +This is not a recent regression; it exists for a long time. + +Reproduce steps: +---------------- +1. qemu-system-x86_64 -m 1024 -smp 2 -hda rhel6u3.img -cpu qemu64,+xsave +2. cat /proc/cpuinfo | grep xsave ( check guest's xsave feature) + +Current result: +---------------- +The guest has no xsave feature + +Expected result: +---------------- +The guest has xsave feature + +Basic root-causing log: \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1052857 b/results/classifier/deepseek-2-tmp/output/mistranslation/1052857 new file mode 100644 index 000000000..4c3575a89 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1052857 @@ -0,0 +1,16 @@ + +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/deepseek-2-tmp/output/mistranslation/1054831 b/results/classifier/deepseek-2-tmp/output/mistranslation/1054831 new file mode 100644 index 000000000..96f83a255 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1054831 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1066909 b/results/classifier/deepseek-2-tmp/output/mistranslation/1066909 new file mode 100644 index 000000000..f41cd76ec --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1066909 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/1068900 b/results/classifier/deepseek-2-tmp/output/mistranslation/1068900 new file mode 100644 index 000000000..9b2085f25 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1068900 @@ -0,0 +1,6 @@ + +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/deepseek-2-tmp/output/mistranslation/1075 b/results/classifier/deepseek-2-tmp/output/mistranslation/1075 new file mode 100644 index 000000000..eafaaa056 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1075 @@ -0,0 +1,17 @@ + +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/deepseek-2-tmp/output/mistranslation/1075272 b/results/classifier/deepseek-2-tmp/output/mistranslation/1075272 new file mode 100644 index 000000000..bf9ee5bb1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1075272 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1076445 b/results/classifier/deepseek-2-tmp/output/mistranslation/1076445 new file mode 100644 index 000000000..a6a010cd2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1076445 @@ -0,0 +1,46 @@ + +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/deepseek-2-tmp/output/mistranslation/1077116 b/results/classifier/deepseek-2-tmp/output/mistranslation/1077116 new file mode 100644 index 000000000..3542260ba --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1077116 @@ -0,0 +1,54 @@ + +automoc4 segfaults when building in an armhf pbuilder on an amd64 host + +When trying to build kde4libs in an armhf pbuilder created with the pbuilder-scripts running on an amd64 host automoc4 recieves a segmentation fault and I can't get any useful information out of it: + +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# /usr/bin/automoc4 kdeui_automoc.cpp ../../kdeui/ . moc-qt4 cmake +unable to dump 00102c00 +Segmentation fault (core dumped) +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# gdb /usr/bin/automoc4 qemu_automoc4_20121108-211818_15839.core +GNU gdb (GDB) 7.5-ubuntu +Copyright (C) 2012 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 "arm-linux-gnueabihf". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/automoc4...done. +BFD: Warning: /tmp/kde4libs-4.9.3/build/kdeui/qemu_automoc4_20121108-211818_15839.core is truncated: expected core file size >= 5150720, found: 974848. +[New LWP 15839] +[New LWP 15866] +Cannot access memory at address 0xf67fe954 +Cannot access memory at address 0xf67fe950 +(gdb) bt +#0 0xf6630306 in ?? () +#1 0xf6415ff8 in ?? () +#2 0xf6415ff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + +automoc4 runs fine when building on a nexus7 so this sounds like an issue in qemu. +Tested in quantal and raring. + +ProblemType: Bug +DistroRelease: Ubuntu 13.04 +Package: qemu-user-static 1.2.0-2012.09-0ubuntu1 +Uname: Linux 3.6.2-030602-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.2-0ubuntu3 +Architecture: amd64 +Date: Fri Nov 9 19:29:28 2012 +EcryptfsInUse: Yes +InstallationDate: Installed on 2011-10-08 (398 days ago) +InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007) +MarkForUpload: True +ProcEnviron: + SHELL=/bin/bash + TERM=xterm + PATH=(custom, user) + LANG=en_US.UTF-8 + LANGUAGE=en_US.UTF-8 +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1079 b/results/classifier/deepseek-2-tmp/output/mistranslation/1079 new file mode 100644 index 000000000..47a22ee70 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1079 @@ -0,0 +1,33 @@ + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Description of problem: +I am trying to build `arm64` image on my `x86_64` machine using `buildx` and I have encountered `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Error. <br> +# +Steps to reproduce: +1. Create a Dockerfile +``` +FROM python:3.8-slim + +ENV PYTHONDONTWRITEBYTECODE=1 + +# Install packages +RUN apt update +RUN apt-get install -y python3-pip +``` +2. Run binfmt container +``` +docker run --privileged --rm tonistiigi/binfmt --install all +``` +3. Setup new builder +``` +$ docker buildx create --name mybuilder +$ docker buildx use mybuilder +$ docker buildx inspect --bootstrap +``` +4. Build Image +``` +$ docker buildx build --platform linux/amd64,linux/arm64 --push -t user/failure-case . +``` +# +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1079080 b/results/classifier/deepseek-2-tmp/output/mistranslation/1079080 new file mode 100644 index 000000000..07054d7c5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1079080 @@ -0,0 +1,12 @@ + +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/deepseek-2-tmp/output/mistranslation/1084148 b/results/classifier/deepseek-2-tmp/output/mistranslation/1084148 new file mode 100644 index 000000000..1db4da718 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1084148 @@ -0,0 +1,44 @@ + +Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf + +Steps +1) pbuilder-dist quantal armhf create +2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder +2.0) pbuilder-dist quantal armhf login +2.1) apt-get install software-properties-common +2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1 +2.3) apt-get update +3) apt-get install qtbase qtdeclarative qttools bzr +4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash +5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled + +Expected Result: +Would execute 'ls' + +Actual result: +# ./untitled +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Note: this code works on i386, amd64 and armel. + +Packages: +$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1.2.0-2012.09-0ubuntu1 + Candidate: 1.2.0-2012.09-0ubuntu1 + Version table: + *** 1.2.0-2012.09-0ubuntu1 0 + 500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages + 100 /var/lib/dpkg/status + 1.2.0-2012.09-0ubuntu1~linaro1 0 + 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages + +# apt-cache policy qtbase +qtbase: + Installed: 5.0-release~beta+20120831-1ubuntu54 + Candidate: 5.0-release~beta+20120831-1ubuntu54 + Version table: + *** 5.0-release~beta+20120831-1ubuntu54 0 + 500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages + 100 /var/lib/dpkg/status \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1095531 b/results/classifier/deepseek-2-tmp/output/mistranslation/1095531 new file mode 100644 index 000000000..937e1d27b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1095531 @@ -0,0 +1,58 @@ + +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/deepseek-2-tmp/output/mistranslation/1095857 b/results/classifier/deepseek-2-tmp/output/mistranslation/1095857 new file mode 100644 index 000000000..19254e78a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1095857 @@ -0,0 +1,12 @@ + +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/deepseek-2-tmp/output/mistranslation/1098729 b/results/classifier/deepseek-2-tmp/output/mistranslation/1098729 new file mode 100644 index 000000000..b693708ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1098729 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/1102 b/results/classifier/deepseek-2-tmp/output/mistranslation/1102 new file mode 100644 index 000000000..7313e56d8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1102 @@ -0,0 +1,39 @@ + +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/deepseek-2-tmp/output/mistranslation/1105670 b/results/classifier/deepseek-2-tmp/output/mistranslation/1105670 new file mode 100644 index 000000000..715ba39da --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1105670 @@ -0,0 +1,47 @@ + +Converting vpc image to raw results in an image that is smaller than it should be. + +When using qemu-img to convert a 3GB dynamic vhd image to raw, the resultant image was smaller than what I was expecting. I was expecting a new raw image of size 3221225472bytes but the size generated was 3220955136bytes. I had similar results when I used a fixed vhd image and explicitly specified the format as vpc. + +Details about my configuration +OS: Centos 5.4, 64bit +Qemu used 1.1.1-1, but also saw the same behavior on 1.3.3 and the development build. + +Command used for dynamic vhd image file: +qemu-img convert -O raw inputDynamic.vhd outputFromDynamic.raw + +Command used for fixed vhd image file: +qemu-img convert f vpc -O raw inputFixed.vhd outputFromFixed.raw + +Both images were first created on hyperv running on windows 2008 r2 using the hyperv manager interface. I think I tried their diskpart utility and had the same results. + +Output from the following commands (I saw this on Bug#893956) +$ hexdump -C -n 512 image.VHD +00000000 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +00000010 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +00000020 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +00000030 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +00000040 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +00000050 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +00000200 + +$ hexdump -C -n 512 -s $(($(ls -l image.VHD | awk '{ print $5 }') - 512)) image.VHD +56057e00 63 6f 6e 65 63 74 69 78 00 00 00 02 00 01 00 00 |conectix........| +56057e10 00 00 00 00 00 00 02 00 18 25 da 57 77 69 6e 20 |.........%.Wwin | +56057e20 00 06 00 01 57 69 32 6b 00 00 00 00 c0 00 00 00 |....Wi2k........| +56057e30 00 00 00 00 c0 00 00 00 18 61 10 3f 00 00 00 03 |.........a.?....| +56057e40 ff ff ee b1 83 34 83 78 26 0a 13 4f 99 9c 9e e9 |.....4.x&..O....| +56057e50 dc 93 21 d1 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............| +56057e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* +56058000 +----- +When I investigated this a bit further I found that the disk geometry calculations needed to be one cylinder more than the information stored in the footer size information. The disk size information in the file was 3221225472 bytes, and the disk geometry was cylinders 6241, heads 10, sectors per cylinder 63. Multiplying that together and with a sector size of 512 gives 3220955136bytes...the size qemu made the image as, but the new image is now smaller than the original image. + +When I added one to the cylinder size I got a size larger than I was expecting, but large enough to hold all of the data from the original image. + +My suggested fix for this is to add one to the cylinder size when reading a vhd image file. And subtracting one when writing out to a vhd file. I've attached a patch with the suggested fix. + +Please let me know if you need additional information. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1119686 b/results/classifier/deepseek-2-tmp/output/mistranslation/1119686 new file mode 100644 index 000000000..5027bb2b3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1119686 @@ -0,0 +1,16 @@ + +Incorrect handling of icebp + +Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. + +To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: + + exception.c:202: exception 0: 80000004 flags:0 addr:003F0000 + exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001 + exception.c:214: this is the last test seen before the exception + exception: unhandled exception 80000004 at 003F0000 + exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9 + exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004 + exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 + +Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1128 b/results/classifier/deepseek-2-tmp/output/mistranslation/1128 new file mode 100644 index 000000000..4d642fbe4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1128 @@ -0,0 +1,25 @@ + +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/deepseek-2-tmp/output/mistranslation/1129571 b/results/classifier/deepseek-2-tmp/output/mistranslation/1129571 new file mode 100644 index 000000000..d2108a421 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1129571 @@ -0,0 +1,15 @@ + +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/deepseek-2-tmp/output/mistranslation/1156313 b/results/classifier/deepseek-2-tmp/output/mistranslation/1156313 new file mode 100644 index 000000000..3761928f4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1156313 @@ -0,0 +1,71 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1157 b/results/classifier/deepseek-2-tmp/output/mistranslation/1157 new file mode 100644 index 000000000..b68d7d208 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1157 @@ -0,0 +1,14 @@ + +aarch64: enabling MMU causes instruction abort +Description of problem: +The title describes the problem pretty accurately, we get an instruction abort when enabling the MMU with a pretty simple set of page tables. This has been regressed from qemu 6.x. +Steps to reproduce: +1. Run the provided Kernel binary with the command line specified above. +2. Notice the hang after 'Initialize MMU'. I traced it down to being an instructions abort after the write to the SCTLR_EL1 register. +3. Try to run with qemu 6.x, and notice that it works. +Additional information: +This does work on actual hardware, so it has to be a qemu bug. + +A binary of the Serenity Kernel has been attached to the issue. The source of that binary can be found at commit ca0e32e59fcf67a662e5d3a994d44cd7c941624a of [SerenityOS](https://github.com/SerenityOS/serenity). + +[Kernel](/uploads/f731edbf81d8e575035e9693b0a51dbf/Kernel) diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1163065 b/results/classifier/deepseek-2-tmp/output/mistranslation/1163065 new file mode 100644 index 000000000..769b37871 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1163065 @@ -0,0 +1,19 @@ + +target-i386 cpu_get_phys_page_debug checks bits in wrong order + +In target-i386 cpu_get_phys_page_debug, the CR4_PAE bit is checked before CR0_PG. This means that if paging is disabled but the PAE bit has been set in CR4, cpu_get_phys_page_debug will return the wrong result (it will try to translate the address as virtual rather than using it as a physical address). + +Although this might seem like an unusual case, it in fact happens consistently when booting Linux on amd64 (from linux-2.6.32.60/arch/x86/boot/compressed/head_64.S): + + /* Enable PAE mode */ + xorl %eax, %eax + orl $(X86_CR4_PAE), %eax + movl %eax, %cr4 +[... code to set up page tables omitted ...] + /* Enter paged protected Mode, activating Long Mode */ + movl $(X86_CR0_PG | X86_CR0_PE), %eax /* Enable Paging and Protected mode */ + movl %eax, %cr0 + +The most noticeable effect of this bug is that using the disassembler during this time will fetch the wrong data by trying to read from page tables that aren't there. One symptom is that booting Linux amd64 with -d in_asm will result in several "Disassembler disagrees with translator over instruction decoding" messages. + +Attached is a patch that moves the CR0_PG check to the beginning. I'm still not 100% certain that the logic of cpu_get_phys_page_debug matches cpu_x86_handle_mmu_fault, but it's a start. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1181 b/results/classifier/deepseek-2-tmp/output/mistranslation/1181 new file mode 100644 index 000000000..357f21ca2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1181 @@ -0,0 +1,2 @@ + +Question for AVR experts... diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1186984 b/results/classifier/deepseek-2-tmp/output/mistranslation/1186984 new file mode 100644 index 000000000..84f91005e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1186984 @@ -0,0 +1,24 @@ + +large -initrd can wrap around in memory causing memory corruption + +We don't use large -initrd in libguestfs any more, but I noticed that a large -initrd file now crashes qemu spectacularly: + +$ ls -lh /tmp/kernel /tmp/initrd +-rw-r--r--. 1 rjones rjones 273M Jun 3 14:02 /tmp/initrd +lrwxrwxrwx. 1 rjones rjones 35 Jun 3 14:02 /tmp/kernel -> /boot/vmlinuz-3.9.4-200.fc18.x86_64 + +$ ./x86_64-softmmu/qemu-system-x86_64 -L pc-bios \ + -kernel /tmp/kernel -initrd /tmp/initrd -hda /tmp/test1.img -serial stdio \ + -append console=ttyS0 + +qemu crashes with one of several errors: + +PFLASH: Possible BUG - Write block confirm + +qemu: fatal: Trying to execute code outside RAM or ROM at 0x00000000000b96cd + +If -enable-kvm is used: + +KVM: injection failed, MSI lost (Operation not permitted) + +In all cases the SDL display fills up with coloured blocks before the crash (see the attached screenshot). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1201446 b/results/classifier/deepseek-2-tmp/output/mistranslation/1201446 new file mode 100644 index 000000000..b9a4391ec --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1201446 @@ -0,0 +1,27 @@ + +Instructions not supported by targeted CPU do not throw SIGILL + +We encountered a bug in another package that caused it to include CMOV instructions when targetting i486, resulting in an inability to run the package on real i486 and i586 hardware. We then attempted to use QEMU to reproduce the bug for easier debugging, since most developers have long since got rid of such old hardware. + +QEMU appears to continue to support *all* instructions when -cpu=486 is selected, regardless of what is advertised in CPUID to the guest. CPUID describes the host environment as a reasonably close approximation to a late-model i486, with very few instruction extensions - specifically excluding CMOV, which on real hardware is an optional extension to the i686 architecture. + +The result was that we could not reproduce the bug using QEMU, and must therefore attempt to debug it using a very limited stock of real hardware, which also has very limited performance for rebuilding the package. This completely defeats one of the main uses of QEMU, in our opinion. + +If this bug extends to other CPU architectures, it would affect all developers wishing to check whether their code conforms to restrictions imposed by any older or more restrictive ISA specification than the latest that QEMU supports, including the distinctions between ARMv7-A-NEON, ARMv7-A-VFPv3, ARMv7-A-VFPv3-d16, ARMv7-R, ARMv7-M, ARMv6-VFPv2, ARMv5-TE, ARMv4-T... all of which are currently shipping in new devices. + +Attached is a small C program which can easily be compiled to include CMOV instructions. It can be used to reproduce the bug: + +$ gcc -march=i486 -O2 -c minmax.c -o minmax +$ ./minmax +No arguments! +$ ./minmax 5 6 7 +max: 7 min: 5 +$ gcc -march=pentium2 -O2 -c minmax.c -o minmax-p2 +$ ./minmax-p2 +No arguments! +$ ./minmax-p2 5 6 7 +[Expected, occurs on real i4/586 hardware:] Illegal instruction +[Actual, within QEMU v1.2.0 with -cpu=486:] max: 7 min: 5 +$ + +The bug is likely not limited to CMOV, but would also apply to more recent ISA extensions - so 3DNow! instructions would appear to run on Intel guest CPUs, AVX on a Pentium-2, and other such weirdness. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1211910 b/results/classifier/deepseek-2-tmp/output/mistranslation/1211910 new file mode 100644 index 000000000..e79750866 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1211910 @@ -0,0 +1,9 @@ + +Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor + +I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens. +But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests. + +Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow. + +I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1211943 b/results/classifier/deepseek-2-tmp/output/mistranslation/1211943 new file mode 100644 index 000000000..f970f151a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1211943 @@ -0,0 +1,4 @@ + +#GP and aligned move instruction + +When the operand of movaps, movapd or movdqa instruction isn't aligned, general-protection exception should be generated. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1221966 b/results/classifier/deepseek-2-tmp/output/mistranslation/1221966 new file mode 100644 index 000000000..f5cdf4e70 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1221966 @@ -0,0 +1,35 @@ + +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/deepseek-2-tmp/output/mistranslation/123 b/results/classifier/deepseek-2-tmp/output/mistranslation/123 new file mode 100644 index 000000000..d2bf831a6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/123 @@ -0,0 +1,2 @@ + +qemu-cris segfaults upon loading userspace binary diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1233225 b/results/classifier/deepseek-2-tmp/output/mistranslation/1233225 new file mode 100644 index 000000000..152bb9af8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1233225 @@ -0,0 +1,25 @@ + +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/deepseek-2-tmp/output/mistranslation/1245543 b/results/classifier/deepseek-2-tmp/output/mistranslation/1245543 new file mode 100644 index 000000000..fdd7f401b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1245543 @@ -0,0 +1,24 @@ + +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/deepseek-2-tmp/output/mistranslation/1246990 b/results/classifier/deepseek-2-tmp/output/mistranslation/1246990 new file mode 100644 index 000000000..74f73798a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1246990 @@ -0,0 +1,39 @@ + +[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/deepseek-2-tmp/output/mistranslation/1248168 b/results/classifier/deepseek-2-tmp/output/mistranslation/1248168 new file mode 100644 index 000000000..4a44f9466 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1248168 @@ -0,0 +1,25 @@ + +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/deepseek-2-tmp/output/mistranslation/1254672 b/results/classifier/deepseek-2-tmp/output/mistranslation/1254672 new file mode 100644 index 000000000..9cccd53e1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1254672 @@ -0,0 +1,42 @@ + +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/deepseek-2-tmp/output/mistranslation/1254786 b/results/classifier/deepseek-2-tmp/output/mistranslation/1254786 new file mode 100644 index 000000000..ba4129c21 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1254786 @@ -0,0 +1,43 @@ + +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/deepseek-2-tmp/output/mistranslation/1263747 b/results/classifier/deepseek-2-tmp/output/mistranslation/1263747 new file mode 100644 index 000000000..b7667a9b7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1263747 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/1267955 b/results/classifier/deepseek-2-tmp/output/mistranslation/1267955 new file mode 100644 index 000000000..d916e7fe3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1267955 @@ -0,0 +1,43 @@ + +[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/deepseek-2-tmp/output/mistranslation/1277 b/results/classifier/deepseek-2-tmp/output/mistranslation/1277 new file mode 100644 index 000000000..01975a5d4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1277 @@ -0,0 +1,2 @@ + +two instructions has executed twice diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1287195 b/results/classifier/deepseek-2-tmp/output/mistranslation/1287195 new file mode 100644 index 000000000..fc7009d17 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1287195 @@ -0,0 +1,4 @@ + +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/deepseek-2-tmp/output/mistranslation/1303 b/results/classifier/deepseek-2-tmp/output/mistranslation/1303 new file mode 100644 index 000000000..fc1db7610 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1303 @@ -0,0 +1,2 @@ + +tcg/cputlb: code path is reachable in load_memop/store_memop() diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1305402 b/results/classifier/deepseek-2-tmp/output/mistranslation/1305402 new file mode 100644 index 000000000..e3f5a71ae --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1305402 @@ -0,0 +1,34 @@ + +libvirt fails to start VirtualMachines + +I've created several kvm based machines with the 'trusty' designation using virtual machine manager. They have operated well over the last 4 days without issue. I did an apt-get upgrade, and qemu was in the list of updates. + +After upgrading, I am unable to start any of the provisioned virtual machines with the following error output + +virsh # start node2 +error: Failed to start domain node2 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + +virsh # start node3 +error: Failed to start domain node3 +error: internal error: process exited while connecting to monitor: qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! + + + +$ dpkg -l | grep kvm +ii qemu-kvm 2.0.0~rc1+dfsg-0ubuntu3 amd64 QEMU Full virtualization on x86 hardware (transitional package) + +Log snippet from vm 'media' that was verified working, and fails to start after the upgrade. + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +char device redirected to /dev/pts/13 (label charserial0) +qemu: terminating on signal 15 from pid 31688 +2014-04-10 03:36:54.593+0000: shutting down +2014-04-10 03:59:25.487+0000: starting up +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name media -S -machine trusty,accel=kvm,usb=off -m 1548 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 60b20f7b-6d20-bcb3-f4fc-808a9b2fe0d0 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/media.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=off,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/media.img,if=none,id=drive-virtio-disk0,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/home/charles/iso/ubuntu-desktop-12.04.4-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a0:69:d9,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 +qemu-system-x86_64: -machine trusty,accel=kvm,usb=off: Unsupported machine type +Use -machine help to list supported machines! +2014-04-10 03:59:25.696+0000: shutting down \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1307225 b/results/classifier/deepseek-2-tmp/output/mistranslation/1307225 new file mode 100644 index 000000000..3324d863a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1307225 @@ -0,0 +1,23 @@ + +Running a virtual machine on a Haswell system produces machine check events + +I'm running a virtual Windows SBS 2003 installation on a Xeon E3 Haswell system running Gentoo Linux. First, I used Qemu 1.5.3 (the latest stable version on Gentoo). I got a lot of machine check events ("mce: [Hardware Error]: Machine check events logged") in dmesg that always looked like (using mcelog): + +Hardware event. This is not a software error. +MCE 7 +CPU 2 BANK 0 +TIME 1390267908 Tue Jan 21 02:31:48 2014 +MCG status: +MCi status: +Corrected error +Error enabled +MCA: Internal parity error +STATUS 90000040000f0005 MCGSTATUS 0 +MCGCAP c09 APICID 6 SOCKETID 0 +CPUID Vendor Intel Family 6 Model 60 + +I found this discussion on the vmware community: https://communities.vmware.com/thread/452344 + +It seems that this is (at least partly) caused by the Qemu machine. I switched to Qemu 1.7.0, the first version to use "pc-i440fx-1.7". With this version, the errors almost disappeared, but from time to time, I still get machine check events. Anyways, they so not seem to affect neither the vm, nor the host. + +I created the virtual machine on an older Core 2 Duo machine and ran it for several weeks without a single error message, so I think this is actually some problem with the Haswell architecture. The errors didn't show up until I copied the virtual machine to my new machine. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1310324 b/results/classifier/deepseek-2-tmp/output/mistranslation/1310324 new file mode 100644 index 000000000..b04b8f8cd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1310324 @@ -0,0 +1,22 @@ + +Commit 0f842f8a introduces regression when using tcg-interpreter + +Hi. + +Commit 0f842f8a246f2b5b51a11c13f933bf7a90ae8e96 apparently introduces a regression when using --enable-tcg-interpreter. The regression is manifested as follows: + + 1. Checkout any qemu commit later or equal that the one said above. Beside that one, I tested v1.7.1, v2.0.0 and a few other commits suggested to my by git bisect. + 2. Possibly cherry-pick commit a32b12741bf45bf3f46bffe5a79cb2548a060cd8, which fixes a compilation bug with --enable-tcg-interpreter. + 3. Compile with: ./configure --target-list=i386-softmmu --enable-tcg-interpreter && make -j8 + 4. Create an empty virtual disk and try to install Windows XP on it booting from Windows CD-ROM. After the loading program, the installer immediately crashes with blue screen (it should instead show the installation confirmation dialog and then the EULA acceptance dialog, if it worked correctly). + +I'm mentioning Windows XP because it is the problem I found. Probably other operating systems would fail as well. I can test others, if you think it would be helpful. I can also give you access to the very exact CD-ROM image I'm using. + +The exact command line I'm using is: +build_location/i386-softmmu/qemu-system-i386 -m 512 -drive file=winxp_test.img -cdrom wipxp_cdrom.iso + +Attached is the blue screen that I see (unfortunately it is Italian, but that's a standard error message and I hope this is not a problem). + +I'm not able to understand the nature of the commit to identify what could be the problem. My nose tells me that it may be some stupid mistake, for example in some offset constant, that nobody ever saw because tcg-interpreter is not much used. + +Thanks, Giovanni. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1311614 b/results/classifier/deepseek-2-tmp/output/mistranslation/1311614 new file mode 100644 index 000000000..fb02c9afa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1311614 @@ -0,0 +1,48 @@ + +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/deepseek-2-tmp/output/mistranslation/1318281 b/results/classifier/deepseek-2-tmp/output/mistranslation/1318281 new file mode 100644 index 000000000..2d07cc823 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1318281 @@ -0,0 +1,35 @@ + +linux-user: x86_64 target fails to call sys_futex() + +I'm building the latest QEMU (06b4f00d53637f2c16a62c2cbaa30bffb045cf88) on ARM to run some x86_64 executables in user mode. This is my configuration: + +./configure \ + --prefix=/root/qemu-x86_64 \ + --target-list=x86_64-linux-user \ + --disable-system \ + --disable-tools + +The following program is used for testing: + +https://gist.github.com/hujiajie/e8cff43b574b399c8f59#file-test-c + +I compile the test program in Debian-7.5-amd64 like this: + +gcc -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --static --libs glib-2.0` -static + +and launch the program on ARM with + +qemu-x86_64 test + +The test crashes with the following message: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +The output of `strace qemu-x86_64 test` is here: + +https://gist.github.com/hujiajie/88d1d5e580d432d11b2d#file-test-strace-log + +It seems that the error is caused by the failure of the futex syscall. + +qemu-i386 could launch the 32-bit test perfectly, the problem only happens on a x86_64 target. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1319100 b/results/classifier/deepseek-2-tmp/output/mistranslation/1319100 new file mode 100644 index 000000000..6d319fc88 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1319100 @@ -0,0 +1,70 @@ + +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/deepseek-2-tmp/output/mistranslation/1328996 b/results/classifier/deepseek-2-tmp/output/mistranslation/1328996 new file mode 100644 index 000000000..61559c0e9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1328996 @@ -0,0 +1,4 @@ + +[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/deepseek-2-tmp/output/mistranslation/1350435 b/results/classifier/deepseek-2-tmp/output/mistranslation/1350435 new file mode 100644 index 000000000..8cbd2e8ce --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1350435 @@ -0,0 +1,17 @@ + +tcg.c:1693: tcg fatal error + +this started happening after the launchpad buildd trusty deploy +https://code.launchpad.net/~costamagnagianfranco/+archive/ubuntu/firefox/+build/6224439 + + +debconf-updatepo +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error +/build/buildd/qemu-2.0.0+dfsg/tcg/tcg.c:1693: tcg fatal error + +this seems to be the patch needed +https://patches.linaro.org/32473/ \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1356969 b/results/classifier/deepseek-2-tmp/output/mistranslation/1356969 new file mode 100644 index 000000000..e459b90af --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1356969 @@ -0,0 +1,14 @@ + +qemu-io: the 'map' command hangs on the fuzzed image + +Sequence: + 1. Unpack the attached archive, make a copy of test.img + 2. Put copy.img and backing_img.vdi in the same directory + 3. Execute + +qemu-io copy.img -c map + +Result: qemu-io processes part of the image and then hangs loading 100% of CPU time. + + +qemu.git HEAD 2d591ce2aeebf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1357206 b/results/classifier/deepseek-2-tmp/output/mistranslation/1357206 new file mode 100644 index 000000000..7c78e11ad --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1357206 @@ -0,0 +1,60 @@ + +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/deepseek-2-tmp/output/mistranslation/1359930 b/results/classifier/deepseek-2-tmp/output/mistranslation/1359930 new file mode 100644 index 000000000..380948c86 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1359930 @@ -0,0 +1,44 @@ + +[ARMv5] Integrator/CP regression when reading FPSID register + +There seems to be a regression in QEMU 2.1.0 which demonstrates itself +when running the attached HelenOS Integrator/CP (i.e. ARMv5) image. The +offending instruction seems to be: + + vmrs r0, fpsid + +Upon its execution, HelenOS kernel receives an Undefined instruction +exception (which it does not anticipate at that point) and crashes. + +QEMU 2.0.0 was not affected by this issue. + +Command line to reproduce with QEMU 2.1.0: + +$ qemu-system-arm -M integratorcp -kernel image.boot -s -S & +$ /usr/local/cross/arm32/bin/arm-linux-gnueabi-gdb +... +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +warning: Can not parse XML target description; XML support was disabled at compile time +0x00000000 in ?? () +(gdb) symbol-file kernel/kernel.raw +Reading symbols from /home/jermar/software/HelenOS.mainline/kernel/kernel.raw...done. +(gdb) break ras_check +Breakpoint 1 at 0x80a021bc: file arch/arm32/src/ras.c, line 67. +(gdb) c +Continuing. + +Breakpoint 1, ras_check (n=1, istate=0x813e7f70) at arch/arm32/src/ras.c:67 +67 { +(gdb) set radix 16 +Input and output radices now set to decimal 16, hex 10, octal 20. +(gdb) print istate->pc +$1 = 0x80a02458 +(gdb) disassemble 0x80a02458 +Dump of assembler code for function fpsid_read: + 0x80a02454 <+0>: vmrs r0, fpsid <======= UNDEFINED EXCEPTION INSTRUCTION + 0x80a02458 <+4>: mov pc, lr +End of assembler dump. + + +The Undefined instruction exception is not expected at this point when executing the VMRS r0,fpsid instruction. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1361912 b/results/classifier/deepseek-2-tmp/output/mistranslation/1361912 new file mode 100644 index 000000000..c9871715f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1361912 @@ -0,0 +1,10 @@ + +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/deepseek-2-tmp/output/mistranslation/1363641 b/results/classifier/deepseek-2-tmp/output/mistranslation/1363641 new file mode 100644 index 000000000..4e6c6a688 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1363641 @@ -0,0 +1,15 @@ + +Build of v2.1.0 fails on armv7l due to undeclared __NR_select + +After `make clean` and `git clean -x -f -d` `git checkout v2.1.0 && configure --prefix=/home/user/prefix-qemu-2.1.0 && make` fails due to missing declarations + + CC qemu-seccomp.o + qemu-seccomp.c:28:1: error: '__NR_select' undeclared here (not in a function) + qemu-seccomp.c:36:1: error: '__NR_mmap' undeclared here (not in a function) + qemu-seccomp.c:57:1: error: '__NR_getrlimit' undeclared here (not in a function) + qemu-seccomp.c:96:1: error: '__NR_time' undeclared here (not in a function) + GEN qmp-marshal.c + qemu-seccomp.c:186:1: error: '__NR_alarm' undeclared here (not in a function) + make: *** [qemu-seccomp.o] Error 1 + +Same errors for master 8b3030114a449e66c68450acaac4b66f26d91416. `configure`should not succeed for a failing build. `config.log` for v2.1.0 and 8b303011... attached. I'm building on a debian 7.6 chroot on Synology DSM 5.0. `uname -a` says `Linux diskstatation 3.2.40 #4493 SMP Thu Aug 21 21:43:02 CST 2014 armv7l GNU/Linux`. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1395958 b/results/classifier/deepseek-2-tmp/output/mistranslation/1395958 new file mode 100644 index 000000000..0d10e6afb --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1395958 @@ -0,0 +1,26 @@ + +boost managed_shared_memory segment on arm emulator crashes + +The following code segment crashes when run: + +#include <boost/interprocess/managed_shared_memory.hpp> +#include <boost/interprocess/allocators/allocator.hpp> +#include <boost/interprocess/containers/map.hpp> +#include <boost/interprocess/containers/vector.hpp> +#include <boost/interprocess/containers/string.hpp> + +using namespace boost::interprocess; + +int main(int argc, char** argv) +{ + namespace bi = boost::interprocess; + const char* name = "foobar"; + bi::shared_memory_object::remove(name); + bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +} + +using qemu-arm-static +qemu-arm version 1.5.0 (Debian 1.5.0-2013.06+git74+20130802+ef1b0ae-3linaroprecise1), Copyright (c) 2003-2008 Fabrice Bellard + + +Any idea? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/140 b/results/classifier/deepseek-2-tmp/output/mistranslation/140 new file mode 100644 index 000000000..d617b56ff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/140 @@ -0,0 +1,2 @@ + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1402802 b/results/classifier/deepseek-2-tmp/output/mistranslation/1402802 new file mode 100644 index 000000000..ad4591266 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1402802 @@ -0,0 +1,14 @@ + +target-tricore/translate.c:3812: possible bad expression ? + + +From a run of cppcheck, a static analysis checker, over the +source code of qemu trunk, dated 20141215, is the new error: + +[qemu/target-tricore/translate.c:3812]: (style) Expression '(X & 0x3f) == 0x6f' is always false. + +Source code is + + if (unlikely((op1 & 0x3f) == OPCM_32_BRN_JTT)) { + +Suggest code rework. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1404690 b/results/classifier/deepseek-2-tmp/output/mistranslation/1404690 new file mode 100644 index 000000000..514cbe7a6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1404690 @@ -0,0 +1,39 @@ + +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/deepseek-2-tmp/output/mistranslation/1407813 b/results/classifier/deepseek-2-tmp/output/mistranslation/1407813 new file mode 100644 index 000000000..bf4dea406 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1407813 @@ -0,0 +1,10 @@ + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1414293 b/results/classifier/deepseek-2-tmp/output/mistranslation/1414293 new file mode 100644 index 000000000..9b349e2b2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1414293 @@ -0,0 +1,6 @@ + +target-lm32/translate.c:336: bad ? : operator + +[qemu/target-lm32/translate.c:336]: (style) Same expression in both branches of ternary operator. + + int rY = (dc->format == OP_FMT_RR) ? dc->r0 : dc->r0; \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1416988 b/results/classifier/deepseek-2-tmp/output/mistranslation/1416988 new file mode 100644 index 000000000..e263a424e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1416988 @@ -0,0 +1,33 @@ + +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/deepseek-2-tmp/output/mistranslation/1452062 b/results/classifier/deepseek-2-tmp/output/mistranslation/1452062 new file mode 100644 index 000000000..1be2110d2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1452062 @@ -0,0 +1,33 @@ + +qemu-img will fail to convert images in 2.3.0 + +Hello guys, + + There seems to be a bug in qemu-img with 2.3.0 that wasn't there in 2.2.1 .... qemu convert will always fail converting. See the output below: + + +Started by upstream project "Create windows image" build number 73 +originally caused by: + Started by user anonymous +Building remotely on builder (builder lab) in workspace /var/lib/jenkins/remote/workspace/Prepare windows Image +[Prepare WS2008R2 Image] $ /bin/sh -xe /tmp/hudson4138890034689910617.sh ++ sudo bash -x /var/images/prepare_windows.sh WS2008R2 ++ set +x + +Preparing: windows +Virtio CD: virtio-win-0.1.96.iso + +Sparsifying... +qemu-img: error while compressing sector 11131648: Input/output error +virt-sparsify: error: external command failed: qemu-img convert -f +qcow2 -O 'qcow2' -c -o 'compat=0.10' '/tmp/sparsifyb459a0.qcow2' +'/var/images/generated/WS2008R2.qcow2' + +virt-sparsify: If reporting bugs, run virt-sparsify with debugging +enabled (-v) and include the complete output. +Build step 'Execute shell' marked build as failure +Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered +Finished: FAILURE + +Thanks, +Dave \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1463172 b/results/classifier/deepseek-2-tmp/output/mistranslation/1463172 new file mode 100644 index 000000000..e01ff04af --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1463172 @@ -0,0 +1,4 @@ + +destination arm board hangs after migration from x86 source + +The qemu destination on an arm board hangs after migration from a x86 source. With qemu emulating Arch, the migration works fine while the vm is still in the boot selection screen, but if the machine is booted, then the destination arm board vm hangs indefinitely after migrating from the x86 source. This bug does not occur the other way around, meaning a booted vm originally run on arm board will continue to work after migrating to a x86 destination. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1463338 b/results/classifier/deepseek-2-tmp/output/mistranslation/1463338 new file mode 100644 index 000000000..f914159fd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1463338 @@ -0,0 +1,15 @@ + +qemu-system-arm injects #UND exception with wrong PC + +Usually all accesses to coprocessor registers are only possible in PL1 or higher. When accessing a coprocessor register in user mode, QEMU generates a trap and the PC of the trapping instruction is passed to the OS with an offset of+ 4. Some coprocessor registers can be configured to allow access to them in usermode (PL0). The latest qemu-git (ee09f84e6bf5383a23c9624115c26b72aa1e076c) seems to add an offest of 8 instead of four if such a register is accessed from user mode. This happens only if the coprocessors register that is accessed might also be accessed from PL0. In case all accesses to the coprocessor register from PL0 cause a trap, qemu injects the #UND trap with the correct PC value. + +Attached is a small test program that installs a signal handler for "SIGILL". On a pandaboard the progam prints "Val=0x2 Val2=0x2" whereas on the latest "qemu-system-arm" the output is : "Val=0x1 Val2=0x2" + +Qemu was configured with: "./configure --python=`which python2.7` --target-list=arm-softmmu" +The test can be compiled with: "gcc -g -static test2.c -o test2" + +If further information is needed, feel free to ask. + +Regards, + +Robert \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1463812 b/results/classifier/deepseek-2-tmp/output/mistranslation/1463812 new file mode 100644 index 000000000..a0da98b4f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1463812 @@ -0,0 +1,5 @@ + +qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption + +copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again. +Run the image on qemu 1.5.3, no problem. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1469342 b/results/classifier/deepseek-2-tmp/output/mistranslation/1469342 new file mode 100644 index 000000000..f16a1b935 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1469342 @@ -0,0 +1,4 @@ + +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/deepseek-2-tmp/output/mistranslation/1470170 b/results/classifier/deepseek-2-tmp/output/mistranslation/1470170 new file mode 100644 index 000000000..bd241792d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1470170 @@ -0,0 +1,41 @@ + +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/deepseek-2-tmp/output/mistranslation/1470481 b/results/classifier/deepseek-2-tmp/output/mistranslation/1470481 new file mode 100644 index 000000000..f688dab43 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1470481 @@ -0,0 +1,8 @@ + +qemu-img converts large vhd files into only approx. 127GB raw file causing the VM to crash + +I have a VHD file for Windows 2014 server OS. I use the following command to convert VHD file (20GB) to a RAW file for KVM. + +qemu-img convert -f vpc -O raw WIN-SNRGCQV6O3O.VHD disk.img + +The output file is about 127GB. When install the VM and boot it up, the OS crashes with STOP error after the intial screen. I found on the internet that the file limit of 127GB is an existing bug. Kindly fix the problem. The workaround to use a Hyper-V to convert to fixed disk is not a feasible solution. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1477683 b/results/classifier/deepseek-2-tmp/output/mistranslation/1477683 new file mode 100644 index 000000000..471f9195b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1477683 @@ -0,0 +1,6 @@ + +FPU in qemu-system-i386 works incorrectly + +FPU bug in qemu-system-i386 makes software which use floating point numbers work incorrectly. For instance, the one included in attachment prints out 0 instead of 2147483648. The same code works ok in qemu-system-x86_64. + +I have this issue in QEMU 2.3.0 on two different x86 guests (Parabola GNU/Linux-libre and libreCMC). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1480562 b/results/classifier/deepseek-2-tmp/output/mistranslation/1480562 new file mode 100644 index 000000000..4a3dfef2c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1480562 @@ -0,0 +1,16 @@ + +register values in sp804 timer + +In the arm_timer.c, when first reading the load register, I got 0. + +... +case 0: /* TimerLoad */ +... + +According to the specification at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0271d/index.html, +"The minimum valid value for TimerXLoad is 1". Is the initial value supposed to be 0xffffffff? + + +When the 5th and 7th bit in Control Register are set, RIS and MIS remain 0. But should they be enabled (i.e., 0x1 and 0x1) as both interrupt and timer module are set. + +Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1486911 b/results/classifier/deepseek-2-tmp/output/mistranslation/1486911 new file mode 100644 index 000000000..aa7297e4d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1486911 @@ -0,0 +1,47 @@ + +Error compilation qemu 2.3.1 on raspberry pi (RASPBIAN(debian)) + +When compiling from source occurs to me incomprehensible error. +Operation ./configure runs without problems, but among the logs make see this: + CP i386-softmmu / hw / i386 / acpi-dsdt.hex + CP i386-softmmu / hw / i386 / q35-acpi-dsdt.hex + CP i386-softmmu / hw / i386 / ssdt-tpm.hex + CC i386-softmmu / target-i386 / translate.o + CC m68k-softmmu / tcg / tcg-op.o + CC m68k-softmmu / tcg / optimize.o +In file included from /home/pi/Zagruzki/qemu-2.3.1/include/qapi/error.h:16:0, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu/option.h:31, + from /home/pi/Zagruzki/qemu-2.3.1/include/qemu-common.h:44, + from /home/pi/Zagruzki/qemu-2.3.1/tcg/optimize.c:31: +/home/pi/Zagruzki/qemu-2.3.1/qapi-types.h:196:8: error: unknown type name '$ uint64_t' +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «tcg / optimize.o» +make [1]: *** [tcg / optimize.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-m68k-softmmu» +make: *** [subdir-m68k-softmmu] Error 2 +make: *** Waiting for jobs ... + +When you try to create a package using checkinstall is such error: +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c: In function 'helper_msa_copy_s_df': +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: error: unrecognizable insn: +(insn 123 122 124 3 (set (subreg: SI (reg: DI 169) 0) + (sign_extend: SI (mem / s / j: QI (plus: SI (reg: SI 167) + (const_int 440 [0x1b8])) [0 env_8 (D) -> active_fpu.fpr [ws_9 (D)]. wr.b S1 A8]))) /home/pi/Zagruzki/qemu-2.3.1/target- mips / msa_helper.c: 1253 -1 + (nil)) +/home/pi/Zagruzki/qemu-2.3.1/target-mips/msa_helper.c:1269:1: internal compiler error: in extract_insn, at recog.c: 2109 +Please submit a full bug report, +with preprocessed source if appropriate. +See <file: ///usr/share/doc/gcc-4.6/README.Bugs> for instructions. +Preprocessed source stored into /tmp/cc1quRqL.out file, please attach this to your bugreport. +/home/pi/Zagruzki/qemu-2.3.1/rules.mak:57: Error the recipe for the purpose of «target-mips / msa_helper.o» +make [1]: *** [target-mips / msa_helper.o] Error 1 +Makefile: 173: error is the recipe for the purpose of «subdir-mips64-softmmu» +make: *** [subdir-mips64-softmmu] Error 2 + +**** Installation unsuccessful. It cancels the creation of the package. + +Cleared ... OK + +Good luck. + +Log make, checkinstall from the terminal http://rghost.ru/7SK6y4bs6 +cc1quRqL.out applications \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1487 b/results/classifier/deepseek-2-tmp/output/mistranslation/1487 new file mode 100644 index 000000000..a7026deb5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1487 @@ -0,0 +1,6 @@ + +Mac OS X 10.4-10.6 i386/x86_64 not working on Apple Silicon +Description of problem: +Mac OS X panics early in the boot process. There are no issues using later versions of macOS or the PPC architecture +Steps to reproduce: +1. trying to boot 10.4/10.5/10.6 using i368/x86_64 emulation on apple silicon diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1519037 b/results/classifier/deepseek-2-tmp/output/mistranslation/1519037 new file mode 100644 index 000000000..49c2c86b1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1519037 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/1527765 b/results/classifier/deepseek-2-tmp/output/mistranslation/1527765 new file mode 100644 index 000000000..392d3096c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1527765 @@ -0,0 +1,73 @@ + +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/deepseek-2-tmp/output/mistranslation/1529226 b/results/classifier/deepseek-2-tmp/output/mistranslation/1529226 new file mode 100644 index 000000000..aec8a1a99 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1529226 @@ -0,0 +1,12 @@ + +qemu-i386-user on 32-bit Linux: uncaught target signal 11 + +Even though the command I'm trying to run (a wrapper script for qemu-i386-user running rustc, the rust compiler) produces the expected compiled output, the build process is interrupted: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +i686-unknown-linux-gnu/stage0/bin/rustc: line 1: 7474 Segmentation fault /usr/local/bin/qemu-i386 -cpu qemu32 /home/petevine/stage0/rustc.bin -C target-cpu=pentium2 -L /home/petevine/unpacked/rust-master/i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/ "$@" +make: *** [i686-unknown-linux-gnu/stage0/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.rustc_back] Error 139 + +The stamp file is not being created so this could be about forking bash after finishing the wrapper script. + +Qemu was compiled from the latest git source. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1535497 b/results/classifier/deepseek-2-tmp/output/mistranslation/1535497 new file mode 100644 index 000000000..4f8bebaf1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1535497 @@ -0,0 +1,21 @@ + +Guest can not boot up when assigned more than 20 vcpus with option "-no-acpi" + +Environment: + ------------------------------- + KVM commit/branch: da3f7ca3/next + Qemu commit/branch: 7b8a354d/master + Host OS: RHEL7.2 ia32e + Host Kernel: 4.4-rc2 + Guest OS: RHEL7.2 ia32e + +Description: + -------------------------------- +When assign more than 20 vpcus with option "-no-acpi", guest can not boot up. + +Reproduce: + ---------------- + 1.qemu-system-x86_64 --enable-kvm -m 1024 -smp 20 -no-acpi -device virtio-net-pci,netdev=nic0,mac=00:16:3e:17:9b:4c -netdev tap,id=nic0,script=/etc/kvm/qemu-ifup -drive file=/root/7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + + +Bisect show the bad commit is 9ee2e2625 of seabios. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1550503 b/results/classifier/deepseek-2-tmp/output/mistranslation/1550503 new file mode 100644 index 000000000..ea65b42c0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1550503 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1552549 b/results/classifier/deepseek-2-tmp/output/mistranslation/1552549 new file mode 100644 index 000000000..b4e9edfea --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1552549 @@ -0,0 +1,6 @@ + +qemu-system-i386 verison 2.5.50 fails at lmsw instruction + +I cloned qemu source code from github.com, and compiled it on my Kubuntu 15.10 laptop to run my little OS. When booting my little OS, the virtual machine's screen keep blinking, I guess it's the virtual machine rebooting on and on automatically for some unknown reason, but there is no further information shown on Kubuntu's terminal. I'm pretty sure this problem is not caused by my little OS, because it works just fine in qemu-system-i386 version 2.5.0. + +I debugged my OS and find this problem happens when executing instruction "lmsw ax". Is this a bug, can anyone help me out? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1563612 b/results/classifier/deepseek-2-tmp/output/mistranslation/1563612 new file mode 100644 index 000000000..9f1e4bcee --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1563612 @@ -0,0 +1,51 @@ + +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/deepseek-2-tmp/output/mistranslation/1568107 b/results/classifier/deepseek-2-tmp/output/mistranslation/1568107 new file mode 100644 index 000000000..920003b06 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1568107 @@ -0,0 +1,10 @@ + +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/deepseek-2-tmp/output/mistranslation/1572329 b/results/classifier/deepseek-2-tmp/output/mistranslation/1572329 new file mode 100644 index 000000000..25c6deadd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1572329 @@ -0,0 +1,6 @@ + +ARM bootloader does not set r0 to 0 + +# arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb + +My code shows r0 = 0x31 while it should be 0. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1574346 b/results/classifier/deepseek-2-tmp/output/mistranslation/1574346 new file mode 100644 index 000000000..01f55e51c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1574346 @@ -0,0 +1,13 @@ + +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/deepseek-2-tmp/output/mistranslation/1577841 b/results/classifier/deepseek-2-tmp/output/mistranslation/1577841 new file mode 100644 index 000000000..e4395691d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1577841 @@ -0,0 +1,14 @@ + +target-mips/helper.c:542: bad sizeof ? + +Recent versions of gcc say this: + +qemu/target-mips/helper.c:542:9: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size] + +Source code is + + memset(env->CP0_WatchLo, 0, sizeof(*env->CP0_WatchLo)); + +Maybe better code + + memset(env->CP0_WatchLo, 0, 8 * sizeof(target_ulong)); \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1578192 b/results/classifier/deepseek-2-tmp/output/mistranslation/1578192 new file mode 100644 index 000000000..2228cb57b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1578192 @@ -0,0 +1,57 @@ + +GTK+ interface doesn't translate keycodes properly with Wayland backend + +I already posted this on the mailing list (https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00119.html) but I decided to do a formal bug report so it can be tracked and doesn't get lost. + +... I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.c:gd_key_event callback function, which calls ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the Qemu keycode before sending it on using qemu_input_event_send_key_number. The problem is that gd_map_keycode is incomplete when GTK+ is running on a backend other than X11. + +static int gd_map_keycode(GtkDisplayState *s, GdkDisplay *dpy, int gdk_keycode) +{ + int qemu_keycode; + +#ifdef GDK_WINDOWING_WIN32 + if (GDK_IS_WIN32_DISPLAY(dpy)) { + qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC); + switch (qemu_keycode) { + case 103: /* alt gr */ + qemu_keycode = 56 | SCANCODE_GREY; + break; + } + return qemu_keycode; + } +#endif + + if (gdk_keycode < 9) { + qemu_keycode = 0; + } else if (gdk_keycode < 97) { + qemu_keycode = gdk_keycode - 8; +#ifdef GDK_WINDOWING_X11 + } else if (GDK_IS_X11_DISPLAY(dpy) && gdk_keycode < 158) { + if (s->has_evdev) { + qemu_keycode = translate_evdev_keycode(gdk_keycode - 97); + } else { + qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97); + } +#endif + } else if (gdk_keycode == 208) { /* Hiragana_Katakana */ + qemu_keycode = 0x70; + } else if (gdk_keycode == 211) { /* backslash */ + qemu_keycode = 0x73; + } else { + qemu_keycode = 0; + } + + return qemu_keycode; +} + +In my case, I'm using GTK+'s Wayland backend, so keycodes 97 through 157 (this includes KEY_HOME(102), KEY_PAGEUP(104), KEY_PAGEDOWN(109), KEY_END(107), etc.) are never translated into a qemu_keycode, and the final 'else' block is hit, causing gd_map_keycode to return 0, which is an invalid keycode and thus cannot be handled by xen-kbdfront. At least that's my best guess as to what is happening. + +The solution that comes to mind is provide an alternative to translate_{evdev,xfree86}_keycode that is compatable with Wayland/libinput, but I don't know exactly which API would provide this functionality, much less do I have a patch. Intuition tells me that translate_evdev_keycode would probably work under Wayland because Weston uses libinput which uses evdev as its backend, but I don't know this for a fact, and I don't know if it would be the Right Way (i.e. Wayland or libinput might provide an API for this purpose, but I don't know). + +I may try to do some testing with translate_evdev_keycode on Wayland and also look into any possible APIs for keycode translation, but I just wanted to put it out there and get some feedback awhile. + +Qemu 2.2.1 from Xen 4.6.1 (relevant code appears unchanged in Qemu master) +GTK+ 3.18.7 +Wayland 1.9.0 +Weston 1.9.0 +libinput 1.2.3 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1585840 b/results/classifier/deepseek-2-tmp/output/mistranslation/1585840 new file mode 100644 index 000000000..9edd28f3f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1585840 @@ -0,0 +1,10 @@ + +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/deepseek-2-tmp/output/mistranslation/1587535 b/results/classifier/deepseek-2-tmp/output/mistranslation/1587535 new file mode 100644 index 000000000..5c52c0aae --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1587535 @@ -0,0 +1,31 @@ + +Incorrect MAS1_TSIZE_SHIFT in ppce500_spin.c causes incorrectly sized TLB. + +When e500 PPC is booted multi-core, the non-boot cores are started via +the spin table. ppce500_spin.c:spin_kick() calls +mmubooke_create_initial_mapping() to allocate a 64MB TLB entry, but +the created TLB entry is only 256KB. + +The root cause is that the function computing the size of the TLB +entry, namely booke206_page_size_to_tlb assumes MAS1.TSIZE as defined +by latter PPC cores, specifically n to the power of FOUR * 1KB. The +result is then used by mmubooke_create_initial_mapping using +MAS1_TSIZE_SHIFT, but MAS1_TSIZE_SHIFT is defined assuming TLB entries +are n to the power of TWO * 1KB. I.e., a difference of shift=7 or +shift=8. + +Simply changing MAS1_TSIZE_SHIFT from 7 to 8 is not appropriate since +the macro is used elsewhere. + +Removing the ">>1" from: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> return ctz32(size >> 10) >> 1; + +and adding an appropriate comment is what I used as a work around: + +> static inline hwaddr booke206_page_size_to_tlb(uint64_t size) +> { +> // resulting size is based on MAS1_TSIZE_SHIFT=7 TLB size. +> return ctz32(size >> 10); \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1588328 b/results/classifier/deepseek-2-tmp/output/mistranslation/1588328 new file mode 100644 index 000000000..777902b39 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1588328 @@ -0,0 +1,72 @@ + +Qemu 2.6 Solaris 9 Sparc Segmentation Fault + +Hi, +I tried the following command to boot Solaris 9 sparc: +qemu-system-sparc -nographic -boot d -hda ./Spark9.disk -m 256 -cdrom sol-9-905hw-ga-sparc-dvd.iso -serial telnet:0.0.0.0:3000,server + +It seems there are a few Segmentation Faults, one from the starting of the boot. Another at the beginning of the commandline installation. + +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +Configuration device id QEMU version 1 machine id 32 +Probing SBus slot 0 offset 0 +Probing SBus slot 1 offset 0 +Probing SBus slot 2 offset 0 +Probing SBus slot 3 offset 0 +Probing SBus slot 4 offset 0 +Probing SBus slot 5 offset 0 +Invalid FCode start byte +CPUs: 1 x FMI,MB86904 +UUID: 00000000-0000-0000-0000-000000000000 +Welcome to OpenBIOS v1.1 built on Apr 18 2016 08:19 + Type 'help' for detailed information +Trying cdrom:d... +Not a bootable ELF image +Loading a.out image... +Loaded 7680 bytes +entry point is 0x4000 +bootpath: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2,0:d + +Jumping to entry point 00004000 for type 00000005... +switching to new context: +SunOS Release 5.9 Version Generic_118558-34 32-bit +Copyright 1983-2003 Sun Microsystems, Inc. All rights reserved. +Use is subject to license terms. +WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@0,0 (sd0): + Corrupt label; wrong magic number + +Segmentation Fault +Configuring /dev and /devices +NOTICE: Couldn't set value (../../sun/io/audio/sada/drv/audiocs/audio_4231.c, Line #1759 0x00 0x88) +audio may not work correctly until it is stopped and restarted +Segmentation Fault +Using RPC Bootparams for network configuration information. +Skipping interface le0 +Searching for configuration file(s)... +Search complete. + +.... + +What type of terminal are you using? + 1) ANSI Standard CRT + 2) DEC VT52 + 3) DEC VT100 + 4) Heathkit 19 + 5) Lear Siegler ADM31 + 6) PC Console + 7) Sun Command Tool + 8) Sun Workstation + 9) Televideo 910 + 10) Televideo 925 + 11) Wyse Model 50 + 12) X Terminal Emulator (xterms) + 13) CDE Terminal Emulator (dtterm) + 14) Other +Type the number of your choice and press Return: 3 +syslog service starting. +savecore: no dump device configured +Running in command line mode +/sbin/disk0_install[109]: 143 Segmentation Fault +/sbin/run_install[130]: 155 Segmentation Fault \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1590336 b/results/classifier/deepseek-2-tmp/output/mistranslation/1590336 new file mode 100644 index 000000000..e2c646d0f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1590336 @@ -0,0 +1,16 @@ + +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/deepseek-2-tmp/output/mistranslation/1591 b/results/classifier/deepseek-2-tmp/output/mistranslation/1591 new file mode 100644 index 000000000..0f1496117 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1591 @@ -0,0 +1,2 @@ + +test-mmap (4096 byte pages) on arm fails on ppc64le host diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1605123 b/results/classifier/deepseek-2-tmp/output/mistranslation/1605123 new file mode 100644 index 000000000..bdc242999 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1605123 @@ -0,0 +1,29 @@ + +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/deepseek-2-tmp/output/mistranslation/1605611 b/results/classifier/deepseek-2-tmp/output/mistranslation/1605611 new file mode 100644 index 000000000..4ec706c4b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1605611 @@ -0,0 +1,49 @@ + +memsave returns invalid addr when trying to read a 64 bits address + +I am trying to read the first 16 bytes of the System Process on a Windows XP x64 SP2 using the memsave monitor command. + +I cloned the latest release of QEMU, v2.6.0, configured it with +./configure --target-list=i386-softmmu,x86_64-softmmu --enable-sdl +and compiled it. + +I first tried to use memsave against Windows XP SP3 32 bits. +This is the procedure i used : + +1 - start the VM with : +./i386-softmmu/qemu-system-i386 --enable-kvm -monitor stdio -hda ~/vm/winxp.qcow2 +and wait for the desktop +2 - take a physical memory dump with : +pmemsave 0 134217728 dump.raw +3 - call rekall on this memory dump to identify running processes : +rekall -f dump.raw pslist +_EPROCESS Name PID PPID Thds Hnds Sess Wow64 Start Exit +---------- -------------------- ----- ------ ------ -------- ------ ------ ------------------------ ------------------------ +0x80e8fa00 System 4 0 46 148 - False - - +4 - read the first 16 bytes of the System PROCESS struct : +memsave 0x80e8fa00 16 system +5 - check the content with hexdump : +00000000 03 00 1b 00 00 00 00 00 08 fa e8 80 08 fa e8 80 +you can recognize here the beginning of an EPROCESS struct. + +So on a 32 bits Windows XP OS, it works. + +But when i tried on Windows XP SP2 64 bits, rekall gave me the following output : + _EPROCESS Name PID PPID Thds Hnds Sess Wow64 Start Exit +-------------- -------------------- ----- ------ ------ -------- ------ ------ ------------------------ ------------------------ +0xfadffd71d040 System 4 0 51 398 - False - - +And when i tried to read the memory with memsave : +memsave 0xfadffd71d040 16 system + +I had the following error : +Invalid addr 0x0000fadffd71d040/size 16 specified + +This address is supposed to be valid because I am reading the System EProcess struct, which should not be in the paged pool memory I think. +Also i disabled the paging file to be sure and the bug is still present. + +Furthermore the bug is reproducible on the latest QEMU (01a720125f5e2f0a23d2682b39dead2fcc820066). + +Can you confirm that this is a bug ? +Should i check something ? + +Thanks ! \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1611394 b/results/classifier/deepseek-2-tmp/output/mistranslation/1611394 new file mode 100644 index 000000000..f4f37ec57 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1611394 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/1613817 b/results/classifier/deepseek-2-tmp/output/mistranslation/1613817 new file mode 100644 index 000000000..a80d8e119 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1613817 @@ -0,0 +1,57 @@ + +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/deepseek-2-tmp/output/mistranslation/1619896 b/results/classifier/deepseek-2-tmp/output/mistranslation/1619896 new file mode 100644 index 000000000..a32b53320 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1619896 @@ -0,0 +1,51 @@ + +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/deepseek-2-tmp/output/mistranslation/1622547 b/results/classifier/deepseek-2-tmp/output/mistranslation/1622547 new file mode 100644 index 000000000..7282d6a82 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1622547 @@ -0,0 +1,29 @@ + +qemu-system-sparc fatal error Trap 0x29 on Solaris 2.6 + +When trying to install Solaris 2.6 from original CDROM, qemu fail with the following error : + +qemu: fatal: Trap 0x29 while interrupts disabled, Error state +pc: f0041280 npc: f0041284 +%g0-7: 00000000 f0281800 08000000 ffffffff 00000000 f0243b88 00000001 f0244020 +%o0-7: 40400ce2 40400ce2 00000000 404000e2 f0243b88 00000000 f023ffd8 f0057914 +%l0-7: 40000cc2 f009645c f0096460 00000002 00000209 00000004 00000007 f023ff90 +%i0-7: 00000042 404000e3 00000000 404000e3 e0000000 f028192a f0240038 f0096448 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +psr: 40400cc2 (icc: -Z-- SPE: SP-) wim: 00000002 +fsr: 00000000 y: 00000000 + +The command line was : + +qemu-system-sparc -nographic -bios ./openbios-sparc32 -M SS-20 -hda ./36G.disk -m 512 -cdrom Solaris_2.6_Software_05_98.img -boot d -serial telnet:0.0.0.0:3000,server -smp 2,cores=2 -monitor null + +It fails with a similar output when using bios ss20_v2.25_rom. + +▶ qemu-system-sparc --version +QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers + +▶ uname -a +Linux xxx 4.7.1-1-ARCH #1 SMP PREEMPT Wed Aug 17 08:13:35 CEST 2016 x86_64 GNU/Linux \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1623020 b/results/classifier/deepseek-2-tmp/output/mistranslation/1623020 new file mode 100644 index 000000000..0c5e81717 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1623020 @@ -0,0 +1,56 @@ + +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/deepseek-2-tmp/output/mistranslation/1625987 b/results/classifier/deepseek-2-tmp/output/mistranslation/1625987 new file mode 100644 index 000000000..ce40737e4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1625987 @@ -0,0 +1,12 @@ + +target-arm/translate-a64.c:2028: possible coding error ? + +target-arm/translate-a64.c:2028:37: warning: ?: using integer constants in boolean context [-Wint-in-bool-context] + +Source code is + + bool iss_sf = opc == 0 ? 32 : 64; + +Maybe better code + + bool iss_sf = (opc == 0) ? 32 : 64; \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1631 b/results/classifier/deepseek-2-tmp/output/mistranslation/1631 new file mode 100644 index 000000000..038afe0ca --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1631 @@ -0,0 +1,18 @@ + +[8.0.0] Host MacOS 13.3.1 – does not work or works incorrectly +Description of problem: +WINXP x86 - freezes before logging in on ARM macOS 13.3.1 host + +WINXP x86 - works but slowly x86_64 macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after start on ARM macOS 13.3.1 host + +Fedora 37 x86_64 - freezes after selecting grub boot option + +**On qemu 7.2.1 all works perfectly!!!** +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1636126 b/results/classifier/deepseek-2-tmp/output/mistranslation/1636126 new file mode 100644 index 000000000..88e08f5af --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1636126 @@ -0,0 +1,20 @@ + +qemu-system-arm segfaults on "smulbb r7, r5, r5" + +I'll attach a binary that runs fine with qemu-system-arm V2.2.0 but V2.7.0 segfaults. +By stepping through with gdb I found that the segfaults happens when executing the line "smulbb r7, r5, r5" (where r7=0x1, r5=0x12). +I'll also attach a debugger screenshot. + +call and output: + +/opt/qemu-system-arm -M integratorcp -cpu cortex-m3 -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFW_SafetyFunctions_ParameteruP1_CUNIT.elf + +------------ CUnit_MFW_SafetyFunctions_Parameter ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFW_SafetyFunctions_Parameter + Test: MFW_SafetyFunctions_Parameter_PositionLimiter ... Segmentation fault (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1641861 b/results/classifier/deepseek-2-tmp/output/mistranslation/1641861 new file mode 100644 index 000000000..f2dc4bbe1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1641861 @@ -0,0 +1,37 @@ + +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/deepseek-2-tmp/output/mistranslation/1652333 b/results/classifier/deepseek-2-tmp/output/mistranslation/1652333 new file mode 100644 index 000000000..17ba9d073 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1652333 @@ -0,0 +1,10 @@ + +TCG mode fails to boot Linux kernel with qemu 2.6.0 and libvirt 2.0.0 + +Trying to boot a Cirros (minimal Linux) VM with qemu 2.6.0 and libvirt 2.0.0 in TCG mode fails for me. The VM gets stuck in "Starting up ..." and never moves on. The command line used to boot the VM was: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=instance-00000002,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-00000002/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=tcg,usb=off -cpu SandyBridge,+osxsave,+hypervisor,+xsaveopt -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c -smbios 'type=1,manufacturer=Red Hat,product=OpenStack Compute,version=14.0.2-7.el7ost,serial=edd3a67d-6ce5-4c36-8f20-085d1097abb7,uuid=ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-00000002/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/ae38b0e1-b3ae-41ec-8e50-c89669a2ec1c/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=28,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:27:73,bus=pci.0,addr=0x3 -add-fd set=1,fd=31 -chardev file,id=charserial0,path=/dev/fdset/1,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on + +A qcow2 image can be downloaded from http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img to reproduce the issue. I've seen a similar failure with a CentOS 7.2 image. + +I am also attaching the libvirt log from the failed VM. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1655708 b/results/classifier/deepseek-2-tmp/output/mistranslation/1655708 new file mode 100644 index 000000000..0ae9c72f3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1655708 @@ -0,0 +1,16 @@ + +target/ppc/int_helper.c:2806: strange expression ? + +target/ppc/int_helper.c:2806:25: warning: ‘*’ in boolean context, suggest ‘&&’ instead [-Wint-in-bool-context] + +Source code is + + zone_digit = (i * 2) ? b->u8[BCD_DIG_BYTE(i * 2)] >> 4 : zone_lead; + +Which I read as + + zone_digit = (i * 2) ? (b->u8[BCD_DIG_BYTE(i * 2)] >> 4) : zone_lead; + +so I think the compiler warning is for the i * 2 lhs of the ?. + +I am not sure what to suggest as a bugfix. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1657538 b/results/classifier/deepseek-2-tmp/output/mistranslation/1657538 new file mode 100644 index 000000000..93cc8a175 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1657538 @@ -0,0 +1,31 @@ + +qemu 2.7.x 2.8 softmmu dont work on BE machine + +Build on Be machine qemu 2.7.1 and 2.8 in pure softmmu (tgc) dont work on big endian hardware . +tested with ppc-softmmu,i386-softmmu,arm-softmmu same result: + +with : + ./qemu-system-i386 +Gtk-Message: Failed to load module "overlay-scrollbar" +qemu-system-i386: Trying to execute code outside RAM or ROM at 0x000a0000 +This usually means one of the following happened: + +(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine) +(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end +(3) Your guest kernel has a bug and crashed by jumping off into nowhere + +This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine. +If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point. + +Execution cannot continue; stopping here. + + +I try to add the -L option with ../pc-bios/bios.bin +and have the same result. + +note the ppc-softmmu and ppc64-softmmu work in kvm mode only emulated mode have issue. + + +tested on my hardware a Qriq P5040 and G5 4x970MP with Ubuntu Mate 16.10 +thanks +Luigi \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1658120 b/results/classifier/deepseek-2-tmp/output/mistranslation/1658120 new file mode 100644 index 000000000..4f75339e7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1658120 @@ -0,0 +1,26 @@ + +building with gcc-aarch64-linux-gnu + +Hi, while trying to build qemu v2.8.0 with gcc-aarch64-linux-gnu cross-compiler I'm getting the following : + + +In file included from /usr/include/x86_64-linux-gnu/sys/syscall.h:31:0, + from /root/qemu/util/compatfd.c:21: +/root/qemu/util/compatfd.c: In function 'qemu_signalfd': +/root/qemu/util/compatfd.c:103:19: error: '__NR_signalfd' undeclared (first use in this function) + ret = syscall(SYS_signalfd, -1, mask, _NSIG / 8); + ^ +/root/qemu/util/compatfd.c:103:19: note: each undeclared identifier is reported only once for each function it appears in +/root/qemu/rules.mak:59: recipe for target 'util/compatfd.o' failed +make: *** [util/compatfd.o] Error 1 + + +I had configured it with : + +../configure --target-list=x86_64-linux-user --static --cpu=aarch64 + +And I'm on : + +Linux ubuntu-512mb-fra1-01 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + +Thanks \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1659901 b/results/classifier/deepseek-2-tmp/output/mistranslation/1659901 new file mode 100644 index 000000000..968166d33 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1659901 @@ -0,0 +1,10 @@ + +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/deepseek-2-tmp/output/mistranslation/1660010 b/results/classifier/deepseek-2-tmp/output/mistranslation/1660010 new file mode 100644 index 000000000..f9baabd6c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1660010 @@ -0,0 +1,12 @@ + +AArch64 system emulation cannot execute virt uefi in 2.7 or 2.8 + +The UEFI firmware file is retrieved from http://snapshots.linaro.org/components/kernel/linaro-edk2/latest/release/qemu64/QEMU_EFI.fd . + +The error is: +``` +TODO /var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg_qemu_tb_exec() +/var/lib/abbs/build/tmp.p2dMBBlJ0D/qemu-2.7.0/tci.c:1049: tcg fatal error +``` + +(both 2.7.0 and 2.8.0 are tested to fail, 2.6.1 works) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1663287 b/results/classifier/deepseek-2-tmp/output/mistranslation/1663287 new file mode 100644 index 000000000..0af901d84 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1663287 @@ -0,0 +1,22 @@ + +Illegal delay slot code causes abort on mips64 + +During some randomised testing of an experimental MIPS implementation I found an instruction sequence that also causes aborts on mainline qemu's MIPS support. The problem is triggered by an MSA branch instruction appearing in a delay slot when emulating a processor without MSA support. + +For example, with the current repository HEAD (f073cd3a2bf1054135271b837c58a7da650dd84b) configured for mips64-softmmu, if I run the attached binary using + + mips64-softmmu/qemu-system-mips64 -bios ../abort2.bin -machine mipssim -nographic + +it will report + + unknown branch 0x13000 + Aborted (core dumped) + +The binary contains the following two instructions: + + 00200008 jr at + 47081e61 bz.b w8,0xffffffffbfc0798c + +The jr sets up a jump, and hflags is set accordingly in gen_compute_branch (in target/mips/translate.c). When processing the bz.b, check_insn generates an exception because the instruction isn't support, but gen_msa_branch skips the usual delay slot check for the same reason, and sets more bits in hflags, leading to an abort in gen_branch because the hflags are now invalid. + +I suspect the best fix is to remove the instruction set condition from the delay slot check in gen_msa_branch. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1667401 b/results/classifier/deepseek-2-tmp/output/mistranslation/1667401 new file mode 100644 index 000000000..d2ecbb7ca --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1667401 @@ -0,0 +1,68 @@ + +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/deepseek-2-tmp/output/mistranslation/1668041 b/results/classifier/deepseek-2-tmp/output/mistranslation/1668041 new file mode 100644 index 000000000..cced05ba4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1668041 @@ -0,0 +1,11 @@ + +x86 Floating point exceptions - incorrect support? + +It seems that qemu does not correctly emulate the x86 support for optionally causing a floating-point exception (#FP) when, for example, dividing by zero. Reports such as: + +https://github.com/cloudius-systems/osv/issues/855 +http://stackoverflow.com/questions/15134189/qemu-div-by-zero-mxcsr-register + +suggest that setting the exception mask in the fpu cw or mxcsr (e.g., using a function like feenableexcept() in the guest OS) does not generate floating point exceptions on divide by zero. The problem only happens on pure QEMU - when a QEMU/KVM combination is used, the actual hardware does the floating point work, and does throw the exception on divide by zero if so requested. + +Looking at the qemu (2.8.0) source code, it seems to me it really lacks support for generating fpu exceptions: For example, helper_fdiv() in target-i386/fpu_helper.c, when it notices the divisor is zero, seems to set the divide-by-zero exception bit, but doesn't seem to check whether it needs to trigger an exception (when the right bits on the x87 or SSE control words are enabled). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1670170 b/results/classifier/deepseek-2-tmp/output/mistranslation/1670170 new file mode 100644 index 000000000..1db4c7034 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1670170 @@ -0,0 +1,39 @@ + +`qemu-system-sparc64 -M Niagara` Aborted (core dumped) + +> qemu-system-sparc64 -M Niagara +qemu: fatal: Trap 0x0064 while trap level (6) >= MAXTL (6), Error state +pc: 0000000000004c80 npc: 0000000000004c84 +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%l0-3: 0000000007f00000 000001ff00000000 000001fff0080000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000414 ccr: 44 (icc: -Z-- xcc: -Z--) asi: 00 tl: 6 pil: 0 +cansave: 6 canrestore: 0 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 7 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 + +Aborted (core dumped) + +> qemu-system-sparc64 -M help +Supported machines are: +Niagara Sun4v platform, Niagara +none empty machine +sun4u Sun4u platform (default) +sun4v Sun4v platform + +> qemu-system-sparc64 -version +QEMU emulator version 2.8.0(Virtualization:Staging / SLE_12_SP2) + +from https://build.opensuse.org/package/show/Virtualization:Staging/qemu on openSUSE Leap 42.2. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1673957 b/results/classifier/deepseek-2-tmp/output/mistranslation/1673957 new file mode 100644 index 000000000..13031a0d2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1673957 @@ -0,0 +1,18 @@ + +virtfs: mapped-xattr on mount point + +With + -virtfs local,path="/tmp",security_model=mapped-xattr,mount_tag="shared2" +in the qemu command line, + shared2 on /mnt/testbis type 9p (rw,sync,dirsync,relatime,trans=virtio,version=9p2000.L,msize=262144) +in the guest mount points, and + tmpfs on /tmp type tmpfs (rw,nosuid,nodev) +in the host mount points (with CONFIG_TMPFS_XATTR=y according to zgrep /proc/config.gz), running qemu as user "vm-test", trying to "touch a" in /mnt/testbis on the VM fails with "Operation not supported". In addition, no file or directory actually present in the host's /tmp can be seen in the guest's /mnt/testbis. + +When trying to replace "/tmp" with "/tmp/aaa" on the host, with /tmp/aaa owned by root:root, still running qemu as vm-test, trying to run "ls" in the guest's /mnt/testbis fails with the weird "ls: reading directory '.': Cannot allocate memory", while the directory is empty. + +After a "chown vm-test /tmp/aaa", the guest can list the files (despite the permissions already allowing it to do so before), but still not write new files: "cannot touch 'b': Operation not supported". + +Do you have a pointer as to what is happening? + +PS: complete setup is running all this inside a qemu VM that I use for testing, I guess it shouldn't matter but saying it just in case \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1673976 b/results/classifier/deepseek-2-tmp/output/mistranslation/1673976 new file mode 100644 index 000000000..2a0e3998f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1673976 @@ -0,0 +1,12 @@ + +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/deepseek-2-tmp/output/mistranslation/1675549 b/results/classifier/deepseek-2-tmp/output/mistranslation/1675549 new file mode 100644 index 000000000..cf48e2bef --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1675549 @@ -0,0 +1,15 @@ + +tcg softmmu i386 crashes on BE hardware + +Hi, +today i try to test qemu 2.9rc 1 with qemu-system-i386 if i set display as sdl and i push a key on keyboard qemu exit with an error + +translate-common.c:34:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) + +This issue was not present on qemu 2.8.0 + +Test Machine PowerMac G5 Quad Fedora 25 Server PPC64 +Qemu build with target-list=i386-softmuu --with-sdlabi=2.0 + +Ciao +Luigi \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1678 b/results/classifier/deepseek-2-tmp/output/mistranslation/1678 new file mode 100644 index 000000000..5ac2840fa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1678 @@ -0,0 +1,9 @@ + +Running Qemu on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Description of problem: +Running QemuV8.0 on windows arm64 host, and use qemu-system-x86_64 to emulate an ubuntu OS, but it didn't work. +Steps to reproduce: +1.qemu-img.exe create hdd.img 10G +2.qemu-system-x86_64.exe -m 8096 hdd.img -cdrom ubuntu22.04-desktop-amd64.iso -machine pc +Additional information: +both Use qemu v8.0 and qemu v8.1 to test, but failed also diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1682093 b/results/classifier/deepseek-2-tmp/output/mistranslation/1682093 new file mode 100644 index 000000000..9b6334646 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1682093 @@ -0,0 +1,16 @@ + +aarch64-softmmu "bad ram pointer" crash + +I am developing a piece of software called SimBench which is a benchmarking system for full system simulators. I am currently porting this to aarch64, using QEMU as a test platform. + +I have encountered a 'bad ram pointer' crash. I've attempted to build a minimum test case, but I haven't managed to replicate the behaviour in isolation, so I've created a branch of my project which exhibits the crash: https://bitbucket.org/Awesomeclaw/simbench/get/qemu-bug.tar.gz + +The package can be compiled using: + +make + +and then run using: + +qemu-system-aarch64 -M virt -m 512 -cpu cortex-a57 -kernel out/armv8/virt/simbench -nographic + +I have replicated the issue in both qemu 2.8.1 and in 2.9.0-rc3, on Fedora 23. Please let me know if you need any more information or any logs/core dumps/etc. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1686170 b/results/classifier/deepseek-2-tmp/output/mistranslation/1686170 new file mode 100644 index 000000000..317822b10 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1686170 @@ -0,0 +1,112 @@ + +qemu-system-x86_64+gdb: unable to correctly disassemble "real mode" (i8086) instructions after attaching to QEMU started with "-S -s" options + +OS: Void Linux x86_64 (glibc) +QEMU version: 2.9.0 +GDB version: 7.12.1 + +Problem description: + +After I updated QEMU from version 2.8.1 to 2.9.0, I found that when I try to connect GDB to a running QEMU and try to debug Real mode machine code, I can no longer set architecture to 'i8086'. +To be able to connect to QEMU from GDB at all, I have to specify one of the 64 bit architectures, which among other things leads to incorrect disassembly listings. This makes debugging Real mode bootloaders, bootsectors and BIOS code much more difficult. + +Steps to reproduce: + +- Run QEMU +- In another terminal, run GDB +- In GDB, connect to QEMU +- In GDB, disassemble some Real mode machine code. + +Expected results (from QEMU version 2.8.1): + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built + into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x0000fff0 in ?? () + (gdb) x/i $cs*16+$eip + 0xffff0: ljmp $0xf000,$0xe05b + +Actual results: + + [terminal #1] + $ qemu-system-x86_64 -S -s + + [terminal #2] + $ gdb -q + (gdb) set architecture i8086 + warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration + of GDB. Attempting to continue with the default i8086 settings. + + The target architecture is assumed to be i8086 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + +Workarounds tried: + + - Try different architecures + (gdb) set architecture i386:intel + The target architecture is assumed to be i386:intel + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + Remote 'g' packet reply is too long: + [..snip..] + (gdb) set architecture i386:x86-64 + The target architecture is assumed to be i386:x86-64 + (gdb) target remote :1234 + Remote debugging using :1234 + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x000000000000fff0 in ?? () + +The last try finally allowed me to connect to QEMU, but as can be expected from using an incorrect architecture setting, disassembly output is complete gibberish: + + (gdb) x/10i $cs*16+$rip + 0xffff0: (bad) + 0xffff1: pop %rbx + 0xffff2: loopne 0xffff4 + 0xffff4: lock xor %dh,(%rsi) + 0xffff7: (bad) + 0xffff8: xor (%rbx),%dh + 0xffffa: (bad) + 0xffffb: cmp %edi,(%rcx) + 0xffffd: add %bh,%ah + 0xfffff: add %al,(%rax) + +Discussion: + +I think I've traced the problem to the following commit: "x86: Fix x86_64 'g' packet response to gdb from 32-bit mode."[1]. +While I admire the effort to make life for people using GDB to debug QEMU VMs, I think the problem here is with GDB and can't be fixed entirely from the side of QEMU without breaking other features. + +In fact, there is a well-known workaround to this problem published on OSDev Wiki (Workaround #1)[2] which doesn't require patching either QEMU or GDB. This workaround has worked for me using several previous versions of QEMU. + + $ gdb -q + (gdb) set architecture i8086 + (gdb) target remote :1234 + (gdb) break some_breakpoint_in_32_bit_or_64_bit_code + (gdb) continue + [...] + Remote 'g' packet reply is too long: [...] + (gdb) disconnect # IMPORTANT STEP #1 + (gdb) set architecture i386:x86-64 + (gdb) target remote :1234 # IMPORTANT STEP #2 + (gdb) continue + +[1]: http://git.qemu.org/?p=qemu.git;a=commit;h=e3592bc9d841c397eeda87f0019fab94ff71004b +[2]: http://wiki.osdev.org/QEMU_and_GDB_in_long_mode#Workaround_1:_Reconnecting \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1687 b/results/classifier/deepseek-2-tmp/output/mistranslation/1687 new file mode 100644 index 000000000..ec5c5a3ac --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1687 @@ -0,0 +1,54 @@ + +Memory leak for x86 guest on macOS ARM host +Description of problem: +QEMU is used by docker to run `x86` binaries on Apple silicon. Then using `mmap` followed by `munmap` results in a memory leak manifested by continuously growing RSS memory usage when running `mmap` and `munmap` in a loop, e.g., when running the following binary: + +``` +#include <stdio.h> +#include <unistd.h> +#include <sys/mman.h> + +const int page = 4096; + +int work(int N) { + int *ptr = mmap(NULL, N * sizeof(int), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); + + if (ptr == MAP_FAILED) { + printf("Mapping Failed\n"); + return 1; + } + + for(int i = 0; i < N; i++) { + ptr[i] = i * 10; + } + + int err = munmap(ptr, N * sizeof(int)); + if (err != 0) { + printf("UnMapping Failed\n"); + return 1; + } + + return 0; +} + +int main() { + int N = page * 1024; + + while (1) { + int res = work(N); + if (res) { + return res; + } + printf(".\n"); + } + + return 0; +} +``` +Steps to reproduce: +``` +$ LEAK=$(docker run --platform linux/amd64 -d -it martin2718/mmap-leak ./a.out) +$ docker exec -it $LEAK top # you should observe that RES for a.out keeps growing +$ docker exec -it $LEAK pmap -x 1 # you should see a single memory mapping whose RSS memory usage keeps growing +$ docker kill $LEAK # abort the experiment +``` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1689367 b/results/classifier/deepseek-2-tmp/output/mistranslation/1689367 new file mode 100644 index 000000000..f65f8b112 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1689367 @@ -0,0 +1,27 @@ + +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/deepseek-2-tmp/output/mistranslation/1699867 b/results/classifier/deepseek-2-tmp/output/mistranslation/1699867 new file mode 100644 index 000000000..5d29985bc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1699867 @@ -0,0 +1,22 @@ + +x86_64 qemu crashes at far call into long-mode + +I am experimenting with this OS https://github.com/phil-opp/blog_os and spotted a weird behavior with qemu. + +I am looking at code that does transition from 32bit mode to 64bit mode. Right now it does 'jmp $SELECTOR,64bitfunction'. https://github.com/phil-opp/blog_os/blob/557c6a58ea11e31685b9d014d307002d64df5c22/src/arch/x86_64/boot.asm#L32 + +This code works fine with qemu/kvm/vmware. + +To transition from 32 to 64 bit code it is possible to use 'call' operation. So I am trying to replace that code with 'call $SELECTOR,64bitfunction'. It works fine with kvm and wmware. But it fails with Qemu emulation. See the interrup debug log attached. qemu crashes at 10302c (far call mnemonic). + + + 103016: e8 18 00 00 00 callq 103033 <set_up_page_tables> + 10301b: e8 5c 00 00 00 callq 10307c <enable_paging> + 103020: e8 ec 00 00 00 callq 103111 <set_up_SSE> + 103025: 0f 01 15 28 00 10 00 lgdt 0x100028(%rip) # 203054 <GCC_except_table2+0xdb5f8> + 10302c: 9a (bad) + 10302d: 40 31 10 rex xor %edx,(%rax) + 103030: 00 08 add %cl,(%rax) + + +As the code works at hardware I expect it to work with qemu. Thus current qemu behavior looks like a bug. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1701971 b/results/classifier/deepseek-2-tmp/output/mistranslation/1701971 new file mode 100644 index 000000000..6677c7867 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1701971 @@ -0,0 +1,46 @@ + +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/deepseek-2-tmp/output/mistranslation/1701974 b/results/classifier/deepseek-2-tmp/output/mistranslation/1701974 new file mode 100644 index 000000000..87b72d8d3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1701974 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1704658 b/results/classifier/deepseek-2-tmp/output/mistranslation/1704658 new file mode 100644 index 000000000..5f421560e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1704658 @@ -0,0 +1,21 @@ + +O_CLOEXEC not handled in dup3 system call in user mode + +In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag. + +When the attached program runs, the expected output is: +errno=9=EBADF + +How to reproduce on hppa: +- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa +- Set environment variables for running qemu-hppa. +- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed + +How to reproduce on sparc64: +- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64 +- Set environment variables for running qemu-sparc64. +- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64 +errno=22=EINVAL +testdup3.c:54: assertion 'errno == EBADF' failed \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1705 b/results/classifier/deepseek-2-tmp/output/mistranslation/1705 new file mode 100644 index 000000000..440931b05 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1705 @@ -0,0 +1,67 @@ + +Illegal instruction when I want to numactl --cpubind=0 --membind=1 to CXL Memory +Description of problem: +I ran QEMU for simulating CXL DRAM and when I tried to run `numactl --cpubind=0 --membind=1 ls` , I got `Illegal instruction` +The numa node 1 was the CXL DRAM simulated by QEMU. + +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 free: 31325 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 + +When I ran on numa node 1, no failed + +> root@8003:~# numactl --membind=0 ls +> ndctl + +When I ran on numa node 1(CXL DRAM),it failed. + +> root@8003:~# numactl --membind=1 ls +> [ 913.975032] traps: ls[667] trap invalid opcode ip:7fdec255d180 sp:7ffd3c507288 error:0 in ld-linux-x86-64.so.2[7fdec2546000+2a000] +> **Illegal instruction** +Steps to reproduce: +1. start the guest +2. cxl list (we could see the simulated CXL DRAM) +> root@8003:~# cxl list +> [ +> { +> "memdev":"mem0", +> "ram_size":34359738368, +> "serial":0, +> "host":"0000:0d:00.0" +> } +> ] +3. cxl create-region -t ram -d decoder0.0 -m mem0 +4. daxctl reconfigure-device dax0.0 --mode=system-ram +5. numactl -H +> root@8003:~# numactl -H +> available: 2 nodes (0-1) +> node 0 cpus: 0 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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 +> node 0 size: 32090 MB +> node 0 fr +> ee: 31254 MB +> node 1 cpus: +> node 1 size: 32768 MB +> node 1 free: 32768 MB +> node distances: +> node 0 1 +> 0: 10 20 +> 1: 20 10 +6. numactl --membind=1 ls +> root@8003:~# numactl --membind=1 ls +> [38441.892140] **traps: ls[861] trap invalid opcode ip:7f15db6ac180 sp:7ffc648755c8 **error:0 in ld-linux-x86-64.so.2[7f15db695000+2a000] +> **Illegal instruction** +Additional information: +When I run dmesg, I found an error. +> root@8003:~# dmesg|grep error +> [ 2.321130] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 + +Since my CPU is a Xeon III, not a Xeon IV with CXL support, **I'm wondering if it's because the CPU doesn't support CXL instructions, or if the Xeon III can emulate it, just because my settings don't make sense**. If this is my settings problem, could you help me to deal this? Or it just caused by my Xeon III,I will update it to Xeon IV. diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1706825 b/results/classifier/deepseek-2-tmp/output/mistranslation/1706825 new file mode 100644 index 000000000..6abad1925 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1706825 @@ -0,0 +1,13 @@ + +qemu-user fails to run wineserver on ppc64el host + +When attempting to run wineserver on a 64-bit ppc64el host via QEMU's user-mode i386 emulation, a file locking operation fails. + +Command line: +qemu-i386-static /usr/lib/wine-development/wineserver32 + +Output: +wineserver: fcntl /tmp/.wine-0/server-17-14d21bf/lock: Invalid argument + +Relevant portion of strace: +fcntl(6, F_SETLK64, 0x3fffe8802218) = -1 EINVAL (Invalid argument) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1707 b/results/classifier/deepseek-2-tmp/output/mistranslation/1707 new file mode 100644 index 000000000..d3a5ee08f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1707 @@ -0,0 +1,24 @@ + +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/deepseek-2-tmp/output/mistranslation/1711828 b/results/classifier/deepseek-2-tmp/output/mistranslation/1711828 new file mode 100644 index 000000000..1cda39273 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1711828 @@ -0,0 +1,4 @@ + +lock mov non generated #UD + +qemu 2.8.1 debian 9.1 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1713066 b/results/classifier/deepseek-2-tmp/output/mistranslation/1713066 new file mode 100644 index 000000000..d3608fd2d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1713066 @@ -0,0 +1,20 @@ + +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/deepseek-2-tmp/output/mistranslation/1714 b/results/classifier/deepseek-2-tmp/output/mistranslation/1714 new file mode 100644 index 000000000..760880b47 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1714 @@ -0,0 +1,28 @@ + +QEMU crashes on ARMv7 since at least commit 493c9b19 +Description of problem: +I'm trying to build QEMU for Android, Arm64 versions work well, but **Armv7** builds began to crash nearly since this series of commits (QEMU 7.2.50), related to 'TCG_TARGET_HAS_direct_jump' removal by @rth7680. +More precisely, this commit still works: + +https://gitlab.com/qemu-project/qemu/-/commit/82df11e78d0baef7ffb7e7933c6fb830ffed087c + +and this one crashes: + +https://gitlab.com/qemu-project/qemu/-/commit/493c9b19a7fb7f387c4fcf57d3836504d5242bf5 + +(I tracked commits of 'tcg' subfolder and didn't bisect finer, but it's possible if needed). + +Both qemu-system-x86_64 and qemu-system-i386 emulators crash. + +**The crash is related to translation buffer size** : if I don't specify "-accel tcg,thread=single **,tb-size=256** ", the machine works. + +The problem is that I can not run debugger on a phone, and crash dump does not show any useful information, just "segfault" reason ("Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe19b8000"). + +Even more, the Linux starts and runs, but it crashes only when I'm trying to run the GIMP, between splash screen and main interface appearance. + +I know that 1) Android is not officially supported and 2) 32-bit hosts were considered deprecated recently, but maybe it's possible to do something with these crashes? + +Recent master (https://gitlab.com/qemu-project/qemu/-/commit/5692a39f329413a00020a61fff95aff6b9884a73) doesn't work as well. +All 8.0.x Arm64 builds are runnable. + +Thanks in advance. diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1716292 b/results/classifier/deepseek-2-tmp/output/mistranslation/1716292 new file mode 100644 index 000000000..8c339b7a2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1716292 @@ -0,0 +1,31 @@ + +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/deepseek-2-tmp/output/mistranslation/1716767 b/results/classifier/deepseek-2-tmp/output/mistranslation/1716767 new file mode 100644 index 000000000..8ab7eea8b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1716767 @@ -0,0 +1,35 @@ + +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/deepseek-2-tmp/output/mistranslation/1719 b/results/classifier/deepseek-2-tmp/output/mistranslation/1719 new file mode 100644 index 000000000..3c9953006 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1719 @@ -0,0 +1,8 @@ + +Allow TCG plugins to read memory +Additional information: +* `include/qemu/plugin.h` +* `include/qemu/qemu-plugin.h` +* `plugin/api.c` + +PANDA implemented this already (not sure if this solution is acceptable for the mainline QEMU): https://github.com/qemu/qemu/commit/72c661a7f141ab41fbce5e95eb3593b69f40e246 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1719984 b/results/classifier/deepseek-2-tmp/output/mistranslation/1719984 new file mode 100644 index 000000000..2bf9ca2b2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1719984 @@ -0,0 +1,7 @@ + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1724485 b/results/classifier/deepseek-2-tmp/output/mistranslation/1724485 new file mode 100644 index 000000000..8a0aa8d83 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1724485 @@ -0,0 +1,19 @@ + +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/deepseek-2-tmp/output/mistranslation/1725267 b/results/classifier/deepseek-2-tmp/output/mistranslation/1725267 new file mode 100644 index 000000000..72719bd2f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1725267 @@ -0,0 +1,32 @@ + +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/deepseek-2-tmp/output/mistranslation/1728116 b/results/classifier/deepseek-2-tmp/output/mistranslation/1728116 new file mode 100644 index 000000000..f95413098 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1728116 @@ -0,0 +1,48 @@ + +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/deepseek-2-tmp/output/mistranslation/1728448 b/results/classifier/deepseek-2-tmp/output/mistranslation/1728448 new file mode 100644 index 000000000..69eb2949d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1728448 @@ -0,0 +1,15 @@ + +qemu-system-arm segmentation fault with cpu cortex-m* + +I try to run an emulation with qemu-system-arm under a cpu cortex-m3 but any execution under the processor result by a segmentation fault. + +My command is : qemu-system-arm -m 256 -M versatilepb -cpu cortex-m3 -kernel ~/qemu/wheezy/vmlinuz-3.2.0-4-versatile -initrd ~/qemu/wheezy/initrd.img-3.2.0-4-versatile -hda ~/qemu/wheezy/hda.img -append 'root=/dev/sda1' + +If a lauch the emulation without specifying a cpu equivalent to cortex-m*, the vm opens up well and works but I absolutely need to run it under cortex-m3. + + +Do you have any idea why I have this problem only with this type of processor ? + +I also try with other boards different from versatilepb but I have the same result. + +I am under ubuntu 17 64bits during my test. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1732981 b/results/classifier/deepseek-2-tmp/output/mistranslation/1732981 new file mode 100644 index 000000000..f5e422465 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1732981 @@ -0,0 +1,6 @@ + +usb-net on aarch64 has wrong class IDs, isn't recognized by Windows + +If I run qemu-system-aarch64 with "-device usb-net,...", the resulting USB device will be seen in the guest as class 0x2, subclass 0x2, protocol 0xFF, instead of the expected class 0xe0, subclass 0x1, protocol 0x3. This prevents Windows' in-box class driver from binding to the device. On x86 and x64 Windows, this is not an issue, as another driver will bind to the device, but in Windows for ARM64, that driver is unavailable, so the USB device is incorrectly recognized as a serial port. + +Installing a modified version of the inbox driver in "Disable Driver Signature Enforcement" mode solves the issue, but it's not a very clean solution. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1734792 b/results/classifier/deepseek-2-tmp/output/mistranslation/1734792 new file mode 100644 index 000000000..ac9dfd9ff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1734792 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/1735384 b/results/classifier/deepseek-2-tmp/output/mistranslation/1735384 new file mode 100644 index 000000000..538cbbfb0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1735384 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1737444 b/results/classifier/deepseek-2-tmp/output/mistranslation/1737444 new file mode 100644 index 000000000..96f026d37 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1737444 @@ -0,0 +1,94 @@ + +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/deepseek-2-tmp/output/mistranslation/1738434 b/results/classifier/deepseek-2-tmp/output/mistranslation/1738434 new file mode 100644 index 000000000..843a55b43 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1738434 @@ -0,0 +1,29 @@ + +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/deepseek-2-tmp/output/mistranslation/1738545 b/results/classifier/deepseek-2-tmp/output/mistranslation/1738545 new file mode 100644 index 000000000..8f51502e7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1738545 @@ -0,0 +1,32 @@ + +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/deepseek-2-tmp/output/mistranslation/1738771 b/results/classifier/deepseek-2-tmp/output/mistranslation/1738771 new file mode 100644 index 000000000..dcc02961b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1738771 @@ -0,0 +1,20 @@ + +qemu user does not provide AT_SECURE auxiliary vector entry + +When executing an android native binary using qemu in user mode, the program fail with the message + +FATAL: kernel did not supply AT_SECURE + +Android uses bionic libc.The linker requires that AT_SECURE is provided in the auxiliary vector, but qemu does not provide the entry. + +The issue can be reproduced using the commands: + +mkdir -p /tmp/android/system +cd /tmp/android +curl -O https://dl.google.com/android/repository/sys-img/google_apis/sysimg_x86-21_r15.zip +unzip sysimg_x86-21_r15.zip +mount -o loop x86/system.img system +qemu-i386 -L /tmp/android/ system/bin/ls + + +I've provided a patch (https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg03667.html) to fix the issue, but it was not reviewed yet. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1741 b/results/classifier/deepseek-2-tmp/output/mistranslation/1741 new file mode 100644 index 000000000..c49a21c6e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1741 @@ -0,0 +1,2 @@ + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1743 b/results/classifier/deepseek-2-tmp/output/mistranslation/1743 new file mode 100644 index 000000000..4675a3962 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1743 @@ -0,0 +1,17 @@ + +QEm+Android emulator crashes on x86 host (but not mac M1) +Description of problem: +Using QEmu+Android emulator crashes when using tflite on x86 hosts (but not M1 macs). +Steps to reproduce: +1. Install android toolchain, including emulator (sdkmanager, adb, avdmanager etc) +2. Start android emulator on an x86 host +3. Follow instructions to download and run tflite benchmarking tool [here](https://www.tensorflow.org/lite/performance/measurement) +4. Crashes with the following error + +``` +06-27 17:38:28.093 8355 8355 F ndk_translation: vendor/unbundled_google/libs/ndk_translation/intrinsics/intrinsics_impl_x86_64.cc:86: CHECK failed: 524288 == 0 +``` + +We have tried with many different models and the result is always the same. The same models run fine when the emulator runs on a mac M1 host. +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1743214 b/results/classifier/deepseek-2-tmp/output/mistranslation/1743214 new file mode 100644 index 000000000..533a76c83 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1743214 @@ -0,0 +1,7 @@ + +OS/2 Warp 3 support broken in 2.11 + +Hello, I used to run OS/2 Warp 3 on QEMU with the following command line: qemu-system-i386 -vga cirrus -soundhw sb16 -hda os2warp3v2.img -boot c. It runs OK on QEMU 2.10, but immediately gives TRAP 0006 (invalid opcode?) on QEMU 2.11 (see screenshot). +If it is important I have Fixpack 40 and GRADD installed in OS/2. +Here is the image: +https://drive.google.com/open?id=15umPecy7JlPLKUP6520MB_87CfrCDWO5 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1746943 b/results/classifier/deepseek-2-tmp/output/mistranslation/1746943 new file mode 100644 index 000000000..d3b23ecdc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1746943 @@ -0,0 +1,11 @@ + +qemu-aarch64-static: qemu: uncaught target signal 11 for ps/top cmd + +In a docker container created from an aarch64 image, injects qemu-aarch64-static (in /usr/bin) + run ps/top cmd inside this container + + reports "qemu: uncaught target signal 11 (Segmentation fault)" + +Tried qemu-aarch64-static from fedora 27 / ubuntu artful / debian unstable (i.e. qemu version 2.10 - 2.11) + +The aarch64 dock image is fedora 27(and with qemu-aarch64-static Fedora 27), hence I opened a related bug here https://bugzilla.redhat.com/show_bug.cgi?id=1541252 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1748296 b/results/classifier/deepseek-2-tmp/output/mistranslation/1748296 new file mode 100644 index 000000000..d91d960f6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1748296 @@ -0,0 +1,26 @@ + +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/deepseek-2-tmp/output/mistranslation/1748612 b/results/classifier/deepseek-2-tmp/output/mistranslation/1748612 new file mode 100644 index 000000000..c268be4f5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1748612 @@ -0,0 +1,16 @@ + +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/deepseek-2-tmp/output/mistranslation/1749016 b/results/classifier/deepseek-2-tmp/output/mistranslation/1749016 new file mode 100644 index 000000000..e4443e3e3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1749016 @@ -0,0 +1,38 @@ + +VHDX BAT and Metadata Region Header Required Bit Not Set + +When converting a VMDK to VHDX the resulting VHDX's Region table has a small error. According to the VHDX specification the BAT and Metadata entries for the region header required bit should be set to 1. In a VHDX created by qemu-img, this bit is not set. + +See Table 4: Known Region Properties of the VHDX specification. + +The structure format is as following from Structure 4: Region Table Entry: + +struct VHDX_REGION_TABLE_ENTRY { +GUID Guid; +UINT64 FileOffset; +UINT32 Length; +UINT32 Required:1; +UINT32 Reserved:31; +} + +The Required bit for VHDX specified BAT and Metadata Regions Required bit in the entry is not set as required in the current specification. + +VHDX Region Table in a valid VHDX + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 01 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 01 00 00 00 + +VHDX Region Table in a VHDX converted by qemu-img from VMDK + +Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F +0x00030000 72 65 67 69 AE 8C 6B C6 02 00 00 00 00 00 00 00 +0x00030010 66 77 C2 2D 23 F6 00 42 9D 64 11 5E 9B FD 4A 08 +0x00030020 00 00 30 00 00 00 00 00 00 00 10 00 00 00 00 00 +0x00030030 06 A2 7C 8B 90 47 9A 4B B8 FE 57 5F 05 0F 88 6E +0x00030040 00 00 20 00 00 00 00 00 00 00 10 00 00 00 00 00 + +The fist bit at 0x0003002A and 0x0003004A should be set to 1. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1751422 b/results/classifier/deepseek-2-tmp/output/mistranslation/1751422 new file mode 100644 index 000000000..630651b30 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1751422 @@ -0,0 +1,5 @@ + +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/deepseek-2-tmp/output/mistranslation/1754295 b/results/classifier/deepseek-2-tmp/output/mistranslation/1754295 new file mode 100644 index 000000000..6a523ac91 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1754295 @@ -0,0 +1,17 @@ + +Incorrect en-us keymap in QEMU 2.11 + +I'm using the latest Arch Linux installation ISO as a live system and start QEMU with the following command: + +$ qemu-system-x86_64 -enable-kvm -boot d -cdrom ~/isos/archlinux-2018.03.01-x86_64.iso -m 512 -vnc :0 -k en-us + +Then I use Vinagre to connect to the guest system, boot the default bootloader option, and type the character '<' at the command prompt. The guest prints the character '>' instead of the '<' I typed. + +I believe this is caused by the updated en-us keymap in QEMU 2.11. [1] + +If I start QEMU with `-k en-gb` (or without the -k switch at all), I can type '<' and get the same character to appear on the guest's command line. The issue happens with the updated en-us keymap. It is also fixed if I replace /usr/share/qemu/keymaps/en-us with the old keymap file (before commit a7815faf). + +This problem was originally reported against Packer because we were seeing '>' characters in place of '<' when using it with the QEMU builder. [2] + +[1] https://github.com/qemu/qemu/commit/a7815faffb2bd594b92aa3542d7b799cc89c5414 +[2] https://github.com/hashicorp/packer/issues/5769 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1755 b/results/classifier/deepseek-2-tmp/output/mistranslation/1755 new file mode 100644 index 000000000..7ecdbeb81 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1755 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1755479 b/results/classifier/deepseek-2-tmp/output/mistranslation/1755479 new file mode 100644 index 000000000..78ee0848a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1755479 @@ -0,0 +1,26 @@ + +Cortex M:qemu abort with optimized code and icount + +A basic program runs fine if compiled with flag -O0 with gcc, but triggers a qemu abort when compiled with -O1 and run with icount: +"qemu: fatal: IO on conditional branch instruction" + +I also noticed the problem on C source like this with -O0: +"int foo = *bar; bar++;" : OK +"int foo = *bar++;" : FAIL (!!!) + +Optimized binary attached to this ticket. + +command line: +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4 +(working fine without icount) + +version: +QEMU emulator version 2.11.50 (v2.11.0-2146-gd9bbfea-dirty) + +Compilation options: +./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native + +I have also tested previous versions: +- stock qemu-system-arm 2.5.0 from ubuntu 16.04: OK +- git version: QEMU emulator version 2.10.0 (v2.10.2-dirty): OK +- git version: QEMU emulator version 2.10.90 (v2.11.0-rc0-dirty): FAIL \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1756 b/results/classifier/deepseek-2-tmp/output/mistranslation/1756 new file mode 100644 index 000000000..5ed106bb0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1756 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/1757363 b/results/classifier/deepseek-2-tmp/output/mistranslation/1757363 new file mode 100644 index 000000000..3e8b91215 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1757363 @@ -0,0 +1,34 @@ + +infinite loop due to improper deal with "eret" on mips32 + +1.qemu 2.9.1 release on the official web build with tcg +2.cmd: qemu-system-mips -kernel kernelfile +3. host: ubuntu 16.04.1 with linux kernel 4.6.2 x86_64 + guest: mips bigendian 32bit (tplink firmware) + + +detail: + +static inline void exception_return(CPUMIPSState *env) +{ + debug_pre_eret(env); + if (env->CP0_Status & (1 << CP0St_ERL)) { + set_pc(env, env->CP0_ErrorEPC); + env->CP0_Status &= ~(1 << CP0St_ERL); + } else { + set_pc(env, env->CP0_EPC); + env->CP0_Status &= ~(1 << CP0St_EXL);====================> ISSUE???? + } + compute_hflags(env); + debug_post_eret(env); +} + +void helper_eret(CPUMIPSState *env) +{ + exception_return(env); + env->lladdr = 1; +} + + +In the Issue Line, there is no check CP0_Status whether int is disabled (should not enter int routine), +that result in the cpu can not jump out the int routine. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1759333 b/results/classifier/deepseek-2-tmp/output/mistranslation/1759333 new file mode 100644 index 000000000..77bcf371a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1759333 @@ -0,0 +1,8 @@ + +Illegal Instruction with HVF when encountering SSE instructions in the emulator + +The latest version of QEMU doesn't seem to support emulated SSE instructions with HVF acceleration on macOS. +The decoder will treat SSE instructions as invalid, get the instruction sizes wrong and quickly crash the guest OS because of illegal instructions. +After having a quick look at target/i386/hvf/x86_decode.c, it seems that SSE instruction emulation isn't implemented in the current version of the x86 emulator. + +A way to reproduce the issue is to run a macOS 10.13 guest with HVF acceleration enabled, this will crash once it's loading up the GUI. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1760 b/results/classifier/deepseek-2-tmp/output/mistranslation/1760 new file mode 100644 index 000000000..d1e452a2f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1760 @@ -0,0 +1,54 @@ + +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/deepseek-2-tmp/output/mistranslation/1761153 b/results/classifier/deepseek-2-tmp/output/mistranslation/1761153 new file mode 100644 index 000000000..4319fa9cd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1761153 @@ -0,0 +1,24 @@ + +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/deepseek-2-tmp/output/mistranslation/1763536 b/results/classifier/deepseek-2-tmp/output/mistranslation/1763536 new file mode 100644 index 000000000..a317d5b50 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1763536 @@ -0,0 +1,84 @@ + +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/deepseek-2-tmp/output/mistranslation/1765970 b/results/classifier/deepseek-2-tmp/output/mistranslation/1765970 new file mode 100644 index 000000000..0c95d7640 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1765970 @@ -0,0 +1,62 @@ + +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/deepseek-2-tmp/output/mistranslation/1768246 b/results/classifier/deepseek-2-tmp/output/mistranslation/1768246 new file mode 100644 index 000000000..0da5b9c93 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1768246 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1768295 b/results/classifier/deepseek-2-tmp/output/mistranslation/1768295 new file mode 100644 index 000000000..dad2b71dc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1768295 @@ -0,0 +1,37 @@ + +VLLDM/VLSTM trigger UsageFault in the Secure Mode + +The VLLDM/VLSTM instructions trigger UsageFault when they are supposed to behave as NOP. + +Version: +$ qemu-system-arm --version QEMU emulator version 2.11.93 + +VLLDM and VLSTM are instructions newly added to ARMv8-M Mainline Profile. Although they are FP instructions and the FP support of the M profile is not implemented by QEMU, the Armv8-M Architecture Reference Manual specifies that they should behave as NOP even in this case: + +C2.4.268 VLLDM: + +> If the Floating-point Extension is not implemented, this instruction is available in Secure state, but behaves as a NOP. + +C2.4.269 VLSTM: + +> If the Floating-point Extension is not implemented, this instruction is available in Secure state, but behaves as a NOP. + +VLLDM and VLSTM are generated automatically by the compiler to save and restore the floating point registers (in a lazy manner) during a Non-Secure function call. An example is shown below: + +10000064 <__gnu_cmse_nonsecure_call>: +10000064: e92d 4fe0 stmdb sp!, {r5, r6, r7, r8, r9, sl, fp, lr} +10000068: 4627 mov r7, r4 +1000006a: 46a0 mov r8, r4 +1000006c: 46a1 mov r9, r4 +1000006e: 46a2 mov sl, r4 +10000070: 46a3 mov fp, r4 +10000072: 46a4 mov ip, r4 +10000074: b0a2 sub sp, #136 ; 0x88 +10000076: ec2d 0a00 vlstm sp +1000007a: f384 8800 msr CPSR_f, r4 +1000007e: 4625 mov r5, r4 +10000080: 4626 mov r6, r4 +10000082: 47a4 blxns r4 +10000084: ec3d 0a00 vlldm sp +10000088: b022 add sp, #136 ; 0x88 +1000008a: e8bd 8fe0 ldmia.w sp!, {r5, r6, r7, r8, r9, sl, fp, pc} \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1770 b/results/classifier/deepseek-2-tmp/output/mistranslation/1770 new file mode 100644 index 000000000..893c07807 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1770 @@ -0,0 +1,23 @@ + +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/deepseek-2-tmp/output/mistranslation/1771948 b/results/classifier/deepseek-2-tmp/output/mistranslation/1771948 new file mode 100644 index 000000000..362fd3a8a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1771948 @@ -0,0 +1,20 @@ + +aarch64 msr CNTFRQ_EL0 + +Hello, + +I'm running qemu 2.12 on a raspberry pi 3 with the command: + +qemu-system-aarch64 -M raspi3 -serial stdio -kernel executable.bin + +On my start file (right in the beginning with the highest EL), the following instructions: + +ldr x0 , =19200000 +msr CNTFRQ_EL0, x0 + + +and qemu halts on the "msr CNTFRQ_EL0, x0" instruction. + +I believe this is not a normal behavior. + +Thank you \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1774149 b/results/classifier/deepseek-2-tmp/output/mistranslation/1774149 new file mode 100644 index 000000000..cc2818941 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1774149 @@ -0,0 +1,77 @@ + +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/deepseek-2-tmp/output/mistranslation/1776096 b/results/classifier/deepseek-2-tmp/output/mistranslation/1776096 new file mode 100644 index 000000000..bb8067121 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1776096 @@ -0,0 +1,61 @@ + +qemu 2.12.0 qemu-system-ppc illegal instruction on ppc64le, crashes emulator + +% uname -a +Linux tim.floodgap.com 4.16.14-300.fc28.ppc64le #1 SMP Tue Jun 5 15:59:48 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +STR: +Start QEMU and boot Mac OS X 10.4.11. +Download the current version of TenFourFox (I used G3 so that AltiVec was not a confounder). +Try to start TenFourFox in safe mode (hold down Option as you double-click while the icon bounces in the Dock). + +Expected: +TenFourFox starts. + +Actual: +The entire emulator exits with an illegal instruction error. + +Trace of session (including some disassembly so you can see where TCG went wrong): + +tim:/home/spectre/src/qemu-2.12.0/ppc-softmmu/% gdb --args ./qemu-system-ppc -M mac99,accel=tcg -m 2048 -prom-env boot-args=-v -boot c -drive file=tigerhd.img,format=raw,cache=none -netdev user,id=mynet0 -device usb-net,netdev=mynet0 -usb -device usb-tablet + +GNU gdb (GDB) Fedora 8.1-15.fc28 +[...] +Reading symbols from ./qemu-system-ppc...done. +(gdb) run +[...] + +Thread 6 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff242ea30 (LWP 7017)] +0xfffffffffffffffc in ?? () +#0 0xfffffffffffffffc in () +#1 0x00007fffd4edec00 in code_gen_buffer () +#2 0x00000000100c9e20 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:169 +#3 0x00000000100c9e20 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:626 +#4 0x00000000100c9e20 in cpu_exec (cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:734 +#5 0x000000001007decc in tcg_cpu_exec (cpu=0x11774e10) + at /home/spectre/src/qemu-2.12.0/cpus.c:1362 +(gdb) disas 0x00007fffd4edebf0, 0x00007fffd4edec10 +Dump of assembler code from 0x7fffd4edebf0 to 0x7fffd4edec10: + 0x00007fffd4edebf0 <code_gen_buffer+284027700>: addi r0,r4,3 + 0x00007fffd4edebf4 <code_gen_buffer+284027704>: rlwinm r0,r0,0,0,19 + 0x00007fffd4edebf8 <code_gen_buffer+284027708>: cmplw cr7,r0,r12 + 0x00007fffd4edebfc <code_gen_buffer+284027712>: bnel cr7,0x7fffd4ed8b64 <code_gen_buffer+284002984> + 0x00007fffd4edec00 <code_gen_buffer+284027716>: lwbrx r14,r3,r4 + 0x00007fffd4edec04 <code_gen_buffer+284027720>: stw r14,40(r27) + 0x00007fffd4edec08 <code_gen_buffer+284027724>: clrldi r4,r14,32 + 0x00007fffd4edec0c <code_gen_buffer+284027728>: rlwinm r3,r4,25,19,26 +End of assembler dump. +(gdb) disas 0x7fffd4ed8b60, 0x7fffd4ed8b70 +Dump of assembler code from 0x7fffd4ed8b60 to 0x7fffd4ed8b70: + 0x00007fffd4ed8b60 <code_gen_buffer+284002980>: bctrl + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 +End of assembler dump. +(gdb) i reg ctr +ctr 0xffffffffffffffff 18446744073709551615 + +It appears that the branch at 0x00007fffd4edebfc caused a jump back (a return?) through CTR, but CTR has -1 in it, hence setting PC to 0xfffffffffffffffc. I am not sure how to debug this further. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1779634 b/results/classifier/deepseek-2-tmp/output/mistranslation/1779634 new file mode 100644 index 000000000..93bc07f44 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1779634 @@ -0,0 +1,36 @@ + +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/deepseek-2-tmp/output/mistranslation/1781281 b/results/classifier/deepseek-2-tmp/output/mistranslation/1781281 new file mode 100644 index 000000000..681dd761e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1781281 @@ -0,0 +1,29 @@ + +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/deepseek-2-tmp/output/mistranslation/1783362 b/results/classifier/deepseek-2-tmp/output/mistranslation/1783362 new file mode 100644 index 000000000..fef58cffc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1783362 @@ -0,0 +1,48 @@ + +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/deepseek-2-tmp/output/mistranslation/1783422 b/results/classifier/deepseek-2-tmp/output/mistranslation/1783422 new file mode 100644 index 000000000..8d2d75d54 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1783422 @@ -0,0 +1,30 @@ + +qemu_clock_get_ns does not take into account icount_time_shift + +Hello, + +If you check the qemu/util/qemu-timer.c you will find the following function: + +597: int64_t qemu_clock_get_ns(QEMUClockType type) +598: { +.... +602: switch (type) { +.... +606: case QEMU_CLOCK_VIRTUAL: +607: if (use_icount) { +608: return cpu_get_icount(); + + +Now on line 606, in case we requested QEMU_CLOCK_VIRTUAL, and we are using icount, the value of cpu_get_icount(); will be returned. + +However if I understand correctly, in order to convert icount to ns, you must use take into account the icount shift -- as defined in the documentation: "The virtual cpu will execute one instruction every 2^N ns of virtual time.". + +Therefor, the correct value to return would be cpu_icount_to_ns(cpu_get_icount()), where cpu_icount_to_ns is defined in cpus.c: + +296: int64_t cpu_icount_to_ns(int64_t icount) +297: { +298: return icount << icount_time_shift; +299: } + +Best Regards, +Humberto "SilverOne" Carvalho \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1783437 b/results/classifier/deepseek-2-tmp/output/mistranslation/1783437 new file mode 100644 index 000000000..ddac93789 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1783437 @@ -0,0 +1,10 @@ + +read-modify-write page faults error code has write bit unset + +Consider the attached C file, which does a read-modify-write of the form `add [mem], reg`, where `mem` points to a non-present page. In the resulting page fault, the W/R bit is not set, while real hardware does set this bit. + +% gcc -m32 qemu-bug1.c&& ./a.out && qemu-i386 ./a.out +page fault: addr=0x70000000 err=0x6 +page fault: addr=0x70000000 err=0x4 + +Tested on the qemu-3.0.0-rc1 release. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1785203 b/results/classifier/deepseek-2-tmp/output/mistranslation/1785203 new file mode 100644 index 000000000..aae9a15ca --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1785203 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/1787002 b/results/classifier/deepseek-2-tmp/output/mistranslation/1787002 new file mode 100644 index 000000000..b0df46d72 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1787002 @@ -0,0 +1,20 @@ + +disas/i386.c compile error + +QEMU Version: 2.12.1, 3.0.0-rc4 +Compiling with GCC 8.2.0 +System: Plop Linux, 32 bit + +Error: + CC disas/i386.o +/tmp/ccK8tHRs.s: Assembler messages: +/tmp/ccK8tHRs.s:53353: Error: can't resolve `L0' {*ABS* section} - `obuf' {.bss section} + + +The problematic line is in 'disas/i386.c' in the function 'INVLPG_Fixup (int bytemode, int sizeflag)': +strcpy (obuf + strlen (obuf) - 6, alt); + +If I comment out this line, then compiling works without problems. + + +The error comes only on 32 bit. On 64 bit, compiling works without problems. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1788 b/results/classifier/deepseek-2-tmp/output/mistranslation/1788 new file mode 100644 index 000000000..31c85b48a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1788 @@ -0,0 +1,30 @@ + +Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic. +Description of problem: +Rounding of long double gives unexpected result. Simple code as example: +``` +#include <math.h> +int main(void) +{ + long double value = -8.5L; + long rounded_value = lrintl(value); + if( -8 == rounded_value ) + { + return 0; + } + return 1; +} +``` +Steps to reproduce: +1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm) +2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve +3. Build project +4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test + +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. +Additional information: +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1790018 b/results/classifier/deepseek-2-tmp/output/mistranslation/1790018 new file mode 100644 index 000000000..c765163fe --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1790018 @@ -0,0 +1,55 @@ + +Assertion failure (or segmentation fault) running 32-bit x86 Linux guest on 64-bit PowerPC host + +Qemu 2.12.1 (also tried 2.12.0) +Linux gwyn 4.14.48-mc8-easy #1 SMP Sat Jun 30 23:29:01 CDT 2018 ppc64 GNU/Linux +gcc (Adelie 6.4.0-r9) 6.4.0 +GNU assembler (GNU Binutils) 2.30 +musl libc (powerpc64) Version 1.1.19 + +64-bit, 64-thread (16-core) POWER9 server in Big endian mode: +processor : 0 +cpu : POWER9, altivec supported +clock : 3000.000000MHz +revision : 2.2 (pvr 004e 1202) + +Scenario: + +Attempting to install Adélie Linux 32-bit x86 guest on 64-bit PowerPC host using qemu-system-i386. + + +Command line: + +/usr/bin/qemu-system-i386 -cdrom adelie-live-pmmx-1.0-beta1-20180807.iso -hda /dev/gwyn/x86 -m 512 -cpu pentium3 + + +Environment reproduction: + +CD image can be obtained at https://distfiles.adelielinux.org/adelie/1.0-beta1/iso/adelie-live-pmmx-1.0-beta1-20180807.iso +/dev/gwyn/x86 is an LVM2 logical volume, 4 GB in size, on NVMe storage +Qemu was built from sources on this machine, with some distribution patches applied for musl support (does not affect tcg/ppc/* code); patches and build recipe (which was modified: https://bpaste.net/show/1bbb1d07d7f2 for recipe patch) can be found at: https://code.foxkit.us/adelie/packages/blob/master/user/qemu/APKBUILD + + +Without --enable-debug-tcg: + +Thread 5 "qemu-system-i38" received signal SIGSEGV, Segmentation fault. +[Switching to LWP 14090] +0x39fb04787f63db78 in ?? () +(gdb) +(gdb) bt +#0 0x39fb04787f63db78 in () +#1 0x00003ffff1cdb160 in code_gen_buffer () +#2 0x0000000100362048 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:169 +#3 0x0000000100362048 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:626 +#4 0x0000000100362048 in cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/accel/tcg/cpu-exec.c:734 +#5 0x00000001003211b4 in tcg_cpu_exec (cpu=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1362 +#6 0x00000001003211b4 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /usr/src/packages/user/qemu/src/qemu-2.12.1/cpus.c:1461 +#7 0x00003ffff7fa275c in start (p=0x3fffedb6a810) at src/thread/pthread_create.c:147 +#8 0x00003ffff7fae4c8 in __clone () at src/thread/powerpc64/clone.s:43 + + + +With --enable-debug-tcg: + +Assertion failed: disp == (int16_t) disp (/usr/src/packages/user/qemu/src/qemu-2.12.1/tcg/ppc/tcg-target.inc.c: reloc_pc14_val: 204) +zsh: abort qemu-system-i386 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1790260 b/results/classifier/deepseek-2-tmp/output/mistranslation/1790260 new file mode 100644 index 000000000..ed6ca1b21 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1790260 @@ -0,0 +1,12 @@ + +binfmt support not working for x86 host and x86_64 guest + +this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere else. the version i checked is the current github mirror https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh + +i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run some applications that are only available as x86_64 packages. i use multiarch and qemu and it works for simple applications like cacafire. however i want to run the application natively from the shell without having to use qemu-x86_64 <path>. i also installed the binfmt-support package. when i run update-binfmts --display then an extry for x86_64 is missing and transparent execution is not working. + +the problem seems to be in the qemu-binfmt-conf.sh script. it disables the creation of entries for cpus of the same family. this is not a problem if you are using a 64bit cpu because 32bit binaries run on it natively but it doesnt work in the opposite way. hacking line 310 to + + if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ; then + +and running it with the --systemd ALL parameter causes a x86_64 config file to be created. it still doesnt work but that might have different causes. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1791763 b/results/classifier/deepseek-2-tmp/output/mistranslation/1791763 new file mode 100644 index 000000000..0fc3bd437 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1791763 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1793119 b/results/classifier/deepseek-2-tmp/output/mistranslation/1793119 new file mode 100644 index 000000000..041f7b3b8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1793119 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/1793608 b/results/classifier/deepseek-2-tmp/output/mistranslation/1793608 new file mode 100644 index 000000000..75432dd3e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1793608 @@ -0,0 +1,17 @@ + +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/deepseek-2-tmp/output/mistranslation/1795148 b/results/classifier/deepseek-2-tmp/output/mistranslation/1795148 new file mode 100644 index 000000000..04f94a10d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1795148 @@ -0,0 +1,14 @@ + +address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache ->len - addr' failed + +When running OpenBSD-current as a guest, the following assertion is hit after a few seconds, resulting in the virtual machine to crash: + +``` +qemu-system-x86_64: /build/qemu/src/qemu-3.0.0/include/exec/memory_ldst_cached.inc.h:85: address_space_stw_le_cached: Assertion `addr < cache->len && 2 <= cache->len - addr' failed. +``` + +Host is Arch Linux stable, running on x86_64. + +Qemu version is 3.0.0, installed via the standard Arch Linux package. + +Version 2.12.1 didn't exhibit this behavior. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1796520 b/results/classifier/deepseek-2-tmp/output/mistranslation/1796520 new file mode 100644 index 000000000..97d23c2ea --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1796520 @@ -0,0 +1,37 @@ + +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/deepseek-2-tmp/output/mistranslation/1798780 b/results/classifier/deepseek-2-tmp/output/mistranslation/1798780 new file mode 100644 index 000000000..91a9c1e37 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1798780 @@ -0,0 +1,14 @@ + +hw/usb/dev-mtp.c:1616: bad test ? + +hw/usb/dev-mtp.c:1616:52: warning: logical ‘or’ of collectively exhaustive tests is always true [-Wlogical-op] + +Source code is + + if ((ret == -1) && (errno != EINTR || errno != EAGAIN || + errno != EWOULDBLOCK)) { + +Maybe better code + + if ((ret == -1) && (errno != EINTR && errno != EAGAIN && + errno != EWOULDBLOCK)) { \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1799200 b/results/classifier/deepseek-2-tmp/output/mistranslation/1799200 new file mode 100644 index 000000000..1d9f61b0d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1799200 @@ -0,0 +1,41 @@ + +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/deepseek-2-tmp/output/mistranslation/1803160 b/results/classifier/deepseek-2-tmp/output/mistranslation/1803160 new file mode 100644 index 000000000..366f8b834 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1803160 @@ -0,0 +1,56 @@ + +qemu-3.1.0-rc0: tcg.c crash in temp_load + +QEMU version: +------------- + +qemu-3.1.0-rc0 compiled from sources (earlier versions also affected) + +Summary: +-------- + +TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash. + +The issue has been reproduced in two scenarios: + +Ubuntu x64 host running Debian x86 guest with the following command line: qemu-system-x86_64 -m 4G debian.qcow + +When the attached ELF file is executed inside the guest, QEMU crashes. + +It can also be reproduced from the command line: + +$ qemu-i386 tcg_crash.elf +/home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863: tcg fatal error +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +zsh: segmentation fault (core dumped) ../qemu-3.1.0-rc0/build/i386-linux-user/qemu-i386 tcg_crash.elf + +GDB backtrace: + +(gdb) bt +#0 0x0000000060206488 in raise () +#1 0x0000000060206b8a in abort () +#2 0x0000000060007016 in temp_load (s=s@entry=0x607a2780 <tcg_init_ctx>, ts=ts@entry=0x607a3178 <tcg_init_ctx+2552>, desired_regs=<optimized out>, allocated_regs=allocated_regs@entry=16400) + at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:2863 +#3 0x000000006000a4d9 in tcg_reg_alloc_op (op=0x62808c20, s=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3070 +#4 tcg_gen_code (s=<optimized out>, tb=tb@entry=0x607ac040 <static_code_gen_buffer+4144>) at /home/alberto/Documents/qemu-3.1.0-rc0/tcg/tcg.c:3598 +#5 0x000000006003ef9a in tb_gen_code (cpu=cpu@entry=0x627e0010, pc=pc@entry=134512724, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=cflags@entry=0) + at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/translate-all.c:1752 +#6 0x000000006003d979 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:404 +#7 cpu_exec (cpu=cpu@entry=0x627e0010) at /home/alberto/Documents/qemu-3.1.0-rc0/accel/tcg/cpu-exec.c:724 +#8 0x000000006006e1a0 in cpu_loop (env=env@entry=0x627e82c0) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/i386/cpu_loop.c:93 +#9 0x00000000600037c5 in main (argc=2, argv=0x7fffffffdd28, envp=<optimized out>) at /home/alberto/Documents/qemu-3.1.0-rc0/linux-user/main.c:819 +(gdb) + +Testcase: +--------- + +Find ELF file attached, and also in the following hexdump: + +$ hexdump -C tcg_crash.elf +00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| +00000010 02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 |........T...4...| +00000020 00 00 00 00 00 00 00 00 34 00 20 00 01 00 00 00 |........4. .....| +00000030 00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 |................| +00000040 00 80 04 08 64 00 00 00 64 00 00 00 05 00 00 00 |....d...d.......| +00000050 00 10 00 00 d2 dc a8 45 31 ca f0 35 d9 4d 8f 18 |.......E1..5.M..| +00000060 05 2e 6f 9f |..o.| \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1804678 b/results/classifier/deepseek-2-tmp/output/mistranslation/1804678 new file mode 100644 index 000000000..01d404b90 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1804678 @@ -0,0 +1,56 @@ + +qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions + +QEMU version: +------------- + +qemu-3.1.0-rc0 compiled from sources (earlier versions also affected) + +Summary: +-------- + +QEMU MIPS system emulation hangs when trying to execute the following invalid instructions: + +71c5a9bf sdbbp 0x716a6 +2c4745aa sltiu a3, v0, 0x45aa +f47539fb sdc1 f21, 0x39fb(v1) +5fa5e284 invalid + +qemu-system-mips falls under an infinite loop condition and it needs to be ended. + +The issue has been reproduced in Ubuntu x64 host running Debian MIPS 32-bits guest with the following command line: + +qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0" + +It can also be reproduced using mips-linux-user, in which case throws the following exception: + +qemu-mips mips_loop_static.elf +qemu: unhandled CPU exception 0x10 - aborting +pc=0x004a9da0 HI=0x00000003 LO=0x00000002 ds 00e2 004a9da0 0 +GPR00: r0 00000000 at fffffff8 v0 004a9da0 v1 004ad000 +GPR04: a0 00000001 a1 7fffefc4 a2 7fffefcc a3 00000000 +GPR08: t0 004ab854 t1 0ffffffe t2 81010100 t3 2f2f2f2f +GPR12: t4 7ffff1ad t5 004ab090 t6 004ab06c t7 004ab07c +GPR16: s0 00000000 s1 452ac505 s2 00400db4 s3 00400d38 +GPR20: s4 00000000 s5 00000000 s6 00000000 s7 00000000 +GPR24: t8 004ab0a8 t9 004a9da0 k0 00000000 k1 00000000 +GPR28: gp 004b25a0 sp 7fffeec0 s8 7fffeec0 ra 0040041c +CP0 Status 0x24000010 Cause 0x00000000 EPC 0x00000000 + Config0 0x80008482 Config1 0x9e190c8f LLAddr 0xffffffffffffffff + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x602dbad8 + +Testcase: +--------- + +C program to reproduce the problem: + +unsigned char code[] = "\x71\xC5\xA9\xBF\x2C\x47\x45\xAA\xF4\x75\x39\xFB\x5F\xA5\xE2\x84"; +main() +{ + int (*ret)() = (int(*)())code; + ret(); +} + +Also, find a statically compiled ELF attached. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1805445 b/results/classifier/deepseek-2-tmp/output/mistranslation/1805445 new file mode 100644 index 000000000..9a200c5c2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1805445 @@ -0,0 +1,19 @@ + +QEMU arm virt machine was stopped by STMFD command while debug process + +Hello, i have a big problem with QEMU arm virtual machine. So... +I run QEMU machine with bare-metal ThreadX fullflash from Texet TM-333 phone (Spreadtrum platform) +[CODE]qemu-system-arm -S -gdb tcp::1234,ipv4 -drive file=C:\cygwin64\home\flash.bin,if=mtd,format=raw -M palmetto-bmc -cpu arm926 -m 64M[/CODE] +I use palmetto-bmc platform because it have ARM926EJ-S core and support SPI Flash. +Then, i attach to gdb qemu process from IDA and run code step-by-step. +[IMG]https://pp.userapi.com/c847218/v847218546/13ec1c/iSIcre5-js4.jpg[/IMG] + +When the IDA run 00032534 STR R11, [R10] command +[IMG]https://pp.userapi.com/c846416/v846416708/133f60/GQzxORvf4Tg.jpg[/IMG] + +instead of store R11 on R10 adress, it jump 000328DC STMFD SP!, {R0-R12,LR} instruction... +[IMG]https://pp.userapi.com/c847218/v847218546/13ec26/32A0VcaJywg.jpg[/IMG] +and virt machine not execute new instruction... +[IMG]https://pp.userapi.com/c850624/v850624111/528f3/N7FTpgloWVU.jpg[/IMG] + +and why i did not change flash from n25q256a to n25q032a11 in aspeed.c without rebuild qemu? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1807675 b/results/classifier/deepseek-2-tmp/output/mistranslation/1807675 new file mode 100644 index 000000000..c70def465 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1807675 @@ -0,0 +1,31 @@ + +qemu commit 80422b0: tcg.c crash in temp_load + +As discussed in #1803160 I'm opening a new ticket for the new bug. + +QEMU version: +------------- + +qemu from git, master branch commit 80422b00196a7af4c6efb628fae0ad8b644e98af + +Summary: +-------- + +TCG crashes in i386 and x86_64 when it tries to execute some specific illegal instructions. When running full OS emulation, both the guest system and QEMU crash. + +$ qemu-i386 tcg_crash1.elf +/home/alberto/Documents/qemu/tcg/tcg.c:2863: tcg fatal error +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +zsh: segmentation fault (core dumped) ./qemu/build/i386-linux-user/qemu-i386 tcg_crash1.elf + +Invalid instructions: + +f0 invalid +40 inc eax +a7 cmpsd dword [esi], dword ptr es:[edi] +48 dec eax + +Testcase: +--------- + +Find ELF file attached. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1808563 b/results/classifier/deepseek-2-tmp/output/mistranslation/1808563 new file mode 100644 index 000000000..a80c575a0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1808563 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1810433 b/results/classifier/deepseek-2-tmp/output/mistranslation/1810433 new file mode 100644 index 000000000..29912e5d0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1810433 @@ -0,0 +1,48 @@ + +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/deepseek-2-tmp/output/mistranslation/1810545 b/results/classifier/deepseek-2-tmp/output/mistranslation/1810545 new file mode 100644 index 000000000..c01a4c22d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1810545 @@ -0,0 +1,16 @@ + +[alpha] Strange exception address reported + +For some reason the SIGILL handler receives a different address under qemu than it used to on real hardware. I don't know specifics about the hardware used back then – it was some sort of 21264a somewhere between 600-800 MHz –, and I cannot say anything about the kernel as well, but I know that it delivered the faulting address +4, while under qemu it receives +8. I know because CACAO, an early Java JIT compiler extracts the address from the SIGILL handler and inspects the code at the faulting site, and it has substracted 4 from the handler address since the dawn of time, and this used to produce the desired result on the Alpha hardware. It actually ran on two different Alpha machines over the years, and both behaved identically. + +The handler looks like this: +void handler_sigill(int sig, siginfo_t *siginfo, void *_p) +{ + uintptr_t trap_address = (uintptr_t) (((ucontext_t*) _p)->uc_mcontext.sc_pc) - 4; +} + +(paraphrasing, the actual code is here: https://bitbucket.org/cacaovm/cacao-staging/src/c8d3fbab864c3243f97629fcfa8d84ba71f38157/src/vm/jit/alpha/linux/md-os.cpp?at=default&fileviewer=file-view-default#md-os.cpp-65) + +I don't know much about the qemu source code and cannot say where this is coming from at first glance. The gen_invalid function uses pc_next, which sounds like the next instruction, not the next-to-next ;). In theory it could actually be the kernel's fault, although I consider this unlikely. + +This is qemu-system-alpha with apparently the last Debian which existed for Alpha (lenny). The kernel is 2.6.26-2-alpha-generic (Debian 2.6.26-29). Observed with qemu git 1b3e80082b, but I guess it is the same with any version. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1811720 b/results/classifier/deepseek-2-tmp/output/mistranslation/1811720 new file mode 100644 index 000000000..1e90009b8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1811720 @@ -0,0 +1,8 @@ + +storage physical_block_size is restricted to uint16_t + +It is desirable to set -global scsi-hd.physical_block_size=4194304 for RBD-backed storage. + +But unfortunatelly, this values is restricted with uint16_t, i.e. 65536 maximum. + +For example, scsi-hd.discard_granularity=4194304 is not so restricted (and works as expected) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1813034 b/results/classifier/deepseek-2-tmp/output/mistranslation/1813034 new file mode 100644 index 000000000..56ffc3c8b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1813034 @@ -0,0 +1,4 @@ + +create_elf_tables() doesn't set AT_PLATFORM for 32bit ARM platforms + +The dynamic linker uses AT_PLATFORM from getauxval to substitute $PLATFORM in certain places (man ld.so). It would be nice if it was set to 'v6l', 'v7l' and whatever other platforms there are according to the chosen CPU or via an environment variable. AT_PLATFORM is not guaranteed to be set, so this isn't a major bug, but this is one case where it makes things difficult. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1813307 b/results/classifier/deepseek-2-tmp/output/mistranslation/1813307 new file mode 100644 index 000000000..ead96217c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1813307 @@ -0,0 +1,22 @@ + +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/deepseek-2-tmp/output/mistranslation/1813460 b/results/classifier/deepseek-2-tmp/output/mistranslation/1813460 new file mode 100644 index 000000000..fcc2f4061 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1813460 @@ -0,0 +1,12 @@ + +qemu/target/arm/translate-a64.c:2039: bad test ? + +qemu/target/arm/translate-a64.c:2039]: (warning) Logical disjunction always evaluates to true: op3 != 2 || op3 != 3. + +Source code is + + if (op3 != 2 || op3 != 3) { + +Maybe better code + + if (op3 != 2 && op3 != 3) { \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1815024 b/results/classifier/deepseek-2-tmp/output/mistranslation/1815024 new file mode 100644 index 000000000..d4a4f99e3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1815024 @@ -0,0 +1,16 @@ + +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/deepseek-2-tmp/output/mistranslation/1815423 b/results/classifier/deepseek-2-tmp/output/mistranslation/1815423 new file mode 100644 index 000000000..94864ec30 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1815423 @@ -0,0 +1,65 @@ + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined" \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1818122 b/results/classifier/deepseek-2-tmp/output/mistranslation/1818122 new file mode 100644 index 000000000..7aa042d0f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1818122 @@ -0,0 +1,89 @@ + +QEMU 3.1 makes libxslt to crash on ppc64 + +Host: clean Ubuntu Disco with QEMU 3.1 + +Guest: Alpine Linux edge with xmlto + +Steps to set up guest: +curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/vmlinuz-vanilla +curl -O http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/initramfs-vanilla +qemu-system-ppc64 -m 1G -kernel vmlinuz-vanilla -initrd initramfs-vanilla -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/edge/main/ modloop=http://dl-cdn.alpinelinux.org/alpine/edge/releases/ppc64le/netboot/modloop-vanilla" -device virtio-rng-pci -nographic +This brings up an VM with an in-memory Alpine Linux. + +Steps to reproduce: +Login as root and execute the following commands. +apk add xmlto +ntpd -nqp time.google.com // For TLS OCSP +wget https://ddosolitary.org/manpage-base.xsl +wget https://ddosolitary.org/shadowsocks-libev.xml +xmlto -m manpage-base.xsl man shadowsocks-libev.xml +The downloaded files are from this project: https://github.com/shadowsocks/shadowsocks-libev The former is directly taken from the "doc" directory and the latter is an intermediate build output generated by asciidoc from doc/shadowsocks-libev.asciidoc + +Expected behavior: The command silently succeeds producing shadowsocks-libev.8 + +Actual behavior: +runtime error: file file:///usr/share/xml/docbook/xsl-stylesheets-1.79.1/manpages/tbl.xsl line 450 element text +xsltApplySequenceConstructor: A potential infinite template recursion was detected. +You can adjust xsltMaxDepth (--maxdepth) in order to raise the maximum number of nested template calls and variables/params (currently set to 3000). +Templates: +#0 name process.colspan +#1 name process.colspan +#2 name process.colspan +#3 name process.colspan +#4 name process.colspan +#5 name process.colspan +#6 name process.colspan +#7 name process.colspan +#8 name process.colspan +#9 name process.colspan +#10 name process.colspan +#11 name process.colspan +#12 name process.colspan +#13 name process.colspan +#14 name process.colspan +Variables: +#0 +type +colspan +#1 +colspan +#2 +type +colspan +#3 +colspan +#4 +type +colspan +#5 +colspan +#6 +type +colspan +#7 +colspan +#8 +type +colspan +#9 +colspan +#10 +type +colspan +#11 +colspan +#12 +type +colspan +#13 +colspan +#14 +type +colspan +error: file /root/shadowsocks-libev.xml +xsltRunStylesheet : run failed + +Note: +I tried increasing --maxdepth as suggested in the error output but that will result in a segfault. +This error doesn't occur with an older QEMU (I tested QEMU 2.12 on Ubuntu Cosmic) or different architectures on QEMU 3.1 (I tested x86, x86_64, arm, aarch64, s390x). Also it didn't help to use an older Alpine Linux (I tested v3.8). So I think it is caused by a bug in QEMU rather than the distro/package. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1818483 b/results/classifier/deepseek-2-tmp/output/mistranslation/1818483 new file mode 100644 index 000000000..4c77a69e9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1818483 @@ -0,0 +1,43 @@ + +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/deepseek-2-tmp/output/mistranslation/1820686 b/results/classifier/deepseek-2-tmp/output/mistranslation/1820686 new file mode 100644 index 000000000..30520b375 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1820686 @@ -0,0 +1,6 @@ + +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/deepseek-2-tmp/output/mistranslation/1821006 b/results/classifier/deepseek-2-tmp/output/mistranslation/1821006 new file mode 100644 index 000000000..124ec6a6b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1821006 @@ -0,0 +1,36 @@ + +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/deepseek-2-tmp/output/mistranslation/1821131 b/results/classifier/deepseek-2-tmp/output/mistranslation/1821131 new file mode 100644 index 000000000..40369393b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1821131 @@ -0,0 +1,29 @@ + +VM running under latest Qemu receives 2, 3, 8, and = when sent the keysyms for @, #, *, and + respectively + +Git commit hash where bug was reproduced: 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2 + +A user of my application bVNC reported that when he connects to his VMs running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8 appear in the VM respectively. I built the latest Qemu from source, and reproduced the issue. + +bVNC converts keycodes or unicode characters that the Android keyboard sends it to corresponding keysyms. For example, it sends keysym 64 for @ rather than sending SHIFT+2. + +A debug log of the application sending the keysyms shows metaState == 0, indicating lack of modifier keys. + +When 2 appears in place of @: + +03-21 00:11:21.761 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 64. keysym:64, metaState: 0 +03-21 00:11:21.763 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 64. keysym:64, metaState: 0 + +When 3 appears in place of #: + +03-21 00:11:08.947 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 35. keysym:35, metaState: 0 +03-21 00:11:08.950 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 35. keysym:35, metaState: 0 + +When 0 appears instead of *: + +03-21 00:11:28.586 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 42. keysym:42, metaState: 0 +03-21 00:11:28.588 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 42. keysym:42, metaState: 0 + +When = appears instead of +: +03-21 01:05:40.021 10061 10061 I RemoteKeyboard: Sending key. Down: true, key: 43. keysym:43, metaState: 0 +03-21 01:05:40.022 10061 10061 I RemoteKeyboard: Sending key. Down: false, key: 43. keysym:43, metaState: 0 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1821430 b/results/classifier/deepseek-2-tmp/output/mistranslation/1821430 new file mode 100644 index 000000000..0bd4cddd1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1821430 @@ -0,0 +1,33 @@ + +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/deepseek-2-tmp/output/mistranslation/1821444 b/results/classifier/deepseek-2-tmp/output/mistranslation/1821444 new file mode 100644 index 000000000..67509821c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1821444 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/1821515 b/results/classifier/deepseek-2-tmp/output/mistranslation/1821515 new file mode 100644 index 000000000..ef634e8ec --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1821515 @@ -0,0 +1,39 @@ + +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/deepseek-2-tmp/output/mistranslation/1824344 b/results/classifier/deepseek-2-tmp/output/mistranslation/1824344 new file mode 100644 index 000000000..438a32ddc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1824344 @@ -0,0 +1,46 @@ + +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/deepseek-2-tmp/output/mistranslation/1824768 b/results/classifier/deepseek-2-tmp/output/mistranslation/1824768 new file mode 100644 index 000000000..e4129af28 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1824768 @@ -0,0 +1,29 @@ + +Qemu ARMv7 TCG MultiThreading for i386 guest doesn't work + +Using any Linux image (in this case Alpine Linux iso) and want to use all cores of my Raspberry with --accel,thread=multi. I know there is a probably still problem with memory ordering of the host but I have also seen some very old commits which could potentially help with it. + +But anyway, with version qemu-i386 version 3.1.0 (Debian 1:3.1+dfsg-7) +I can see OpenRC starting up services and then the kernel crash. + +With version QEMU emulator version 3.1.93 (v4.0.0-rc3-dirty) +The whole machine crash with this error: +Illegal instruction + + +Using command: +./qemu-system-i386 -cdrom alpine.iso --accel tcg,thread=multi + +Full Console Output: +qemu-system-i386: warning: Guest expects a stronger memory ordering than the host provides +This may cause strange/hard to debug errors +Illegal instruction + + +Kernel: +Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux + +CPU: +ARMv7 Processor rev 5 (v7l) +Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm +4 cores \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1824853 b/results/classifier/deepseek-2-tmp/output/mistranslation/1824853 new file mode 100644 index 000000000..db0757731 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1824853 @@ -0,0 +1,51 @@ + +4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed + +I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278, datestamp 20190411) inside my arm64-gentoo installation under qemu-system-aarch64. + +Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with only --target-list=aarch64-softmmu,aarch64-linux-user and compiled using gcc "version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)". + +Executable created from gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c compiled with -O2 crashed the whole qemu-system. + +To investigate a bit I also manually run +~/gcc/inst/trunk/bin/gcc ~/gcc/src/trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c +with different options like: +-O0 -lm -o d0.exe +-O1 -lm -o d1.exe +-O2 -lm -o d2.exe +-O0 -static -lm -o s0.exe +-O1 -static -lm -o s1.exe +-O2 -static -lm -o s2.exe + +So, now I have 6 different arm64 executables created with different optimization levels. O0 and O1 versions run ok. +Three sN.exe static executables I've also tried in qemu user mode (with same -cpu), no issue in user mode. + +And inside qemu-system I can see that +running "d2.exe" (attached) gives: +tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed. + +And running "s2.exe" gives: +tcg/tcg.c:320: set_jmp_reset_offset: Assertion `s->tb_jmp_reset_offset[which] == off' failed. + +It seems like this test is an counter-example for logic that "tcg_ctx->nb_ops < 4000" implies tcg will fit into 16-bit signed size (see tcg_op_buf_full comments). + +Richard's changes in abebf92597186 and 9f754620651d were not enough, translation block must be smaller, or we have to find some proper way to bail out when buffer overflows. +I don't know why this situation is not caught by code_gen_highwater logic in tcg.c + +I've also tried this "bail out" patch + +diff --git a/tcg/tcg.c b/tcg/tcg.c +--- a/tcg/tcg.c ++++ b/tcg/tcg.c +@@ -3949,7 +3949,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb) + size_t off = tcg_current_code_size(s); + s->gen_insn_end_off[num_insns] = off; + /* Assert that we do not overflow our stored offset. */ +- assert(s->gen_insn_end_off[num_insns] == off); ++ if (s->gen_insn_end_off[num_insns] != off) ++ return -1; + } + num_insns++; + for (i = 0; i < TARGET_INSN_START_WORDS; ++i) { + +But then running "d2.exe" just hangs the whole qemu-system. It seems that when tcg_gen_code return -1 (like in highwater logic mentioned before), we just re-call it again and again. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1826568 b/results/classifier/deepseek-2-tmp/output/mistranslation/1826568 new file mode 100644 index 000000000..29c23b1b9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1826568 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1828429 b/results/classifier/deepseek-2-tmp/output/mistranslation/1828429 new file mode 100644 index 000000000..3a936ee01 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1828429 @@ -0,0 +1,16 @@ + +qemu-system-aarch64 crashes with assertion failed while running GCC 9 test suite + +I am using QEMU 4.0.0 on an x86_64 Linux 4.19.0 host, the guest is an Aarch64 linux 5.0.0 system. The same issue occurred on QEMU 3.1.0. + +While running the GCC 9.1 test suite on the guest system, QEMU crashes with: + +qemu-system-aarch64: [...]/qemu-4.0.0/tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed. + +I am able to reproduce the issue reliably, which is encouraging. The full QEMU command line is: + +qemu-system-aarch64 -kernel kernel-5.0.0cbl1 -append "root=/dev/vda1 ro init=/sbin/init console=ttyAMA0" -name guest=cbl -drive file=cbl.qcow2,index=0,media=disk,format=qcow2 -drive file=swap.qcow2,index=1,media=disk,format=qcow2 -machine virt -cpu cortex-a57 -smp 4,sockets=1,cores=2,threads=2 -m size=8192 -netdev tap,id=network0,ifname=tapcbl2,script=no,downscript=no -device virtio-net-device,netdev=network0,mac=aa:bb:cc:dd:ee:02 -nographic + +The specific GCC test that causes QEMU to crash is vldX.c run from advsimd-intrinsics.exp; I can reproduce via "make check-gcc RUNTESTFLAGS=advsimd-intrinsics.exp=vldX.c" + +If there is anything I can do to further triage the issue, or gain more insight into what is going on, please let me know! I am eager to help however I can. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1828867 b/results/classifier/deepseek-2-tmp/output/mistranslation/1828867 new file mode 100644 index 000000000..4ad75b83b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1828867 @@ -0,0 +1,9 @@ + +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/deepseek-2-tmp/output/mistranslation/1830 b/results/classifier/deepseek-2-tmp/output/mistranslation/1830 new file mode 100644 index 000000000..49cb73611 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1830 @@ -0,0 +1,27 @@ + +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/deepseek-2-tmp/output/mistranslation/1830031 b/results/classifier/deepseek-2-tmp/output/mistranslation/1830031 new file mode 100644 index 000000000..d4a79bb8d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1830031 @@ -0,0 +1,82 @@ + +fatal error: float32nan on QEmu 3.1 + +Docker throws float32nan errors when running alpine container on a CentOS 7.6 ppc64le Distro VM, when using Fedora 30 Host qemu 3.1. I Compiled qemu 2.11.2 on the Fedora 30 and using this qemu-system-ppc64 we don't see the error. Even using qemu 3.1 and machine 2.11 we still get the same issue. + +Nothing changed on the OS level on the two runs. just the qemu-system-ppc64 used to run the virtual machine. + + Docker on CentOS 7: docker.ppc64le 2:1.13.1-96 + +Running with qemu 2.11.2 behavior and machine 2.11: +[root@machine ~]# /usr/local/bin/qemu-system-ppc64 -version +QEMU emulator version 2.11.2(qemu-2.11.2-5.fc30) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +[root@powericp ~]# docker run -i -t alpine /bin/sh +/ # exit +[root@powericp ~]# uname -a +Linux powericp 3.10.0-957.12.2.el7.ppc64le #1 SMP Tue May 14 22:24:22 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux +[root@powericp ~]# docker version +Client: + Version: 1.13.1 + API version: 1.26 + Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.ppc64le + Go version: go1.10.3 + Git commit: b2f74b2/1.13.1 + Built: Wed May 1 15:05:41 2019 + OS/Arch: linux/ppc64le +… +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 +################################################################################################# +#Running with qemu3.1 +################################################################################################# +[root@machine ~]# qemu-system-ppc64 -version +QEMU emulator version 3.1.0 (qemu-3.1.0-8.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +[root@powericp ~]# docker run -i -t alpine /bin/sh +/usr/bin/docker-current: Error response from daemon: oci runtime error: error running hook: exit status 4, stdout: , stderr: fatal error: float32nan +runtime: panic before malloc heap initialized + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +panic during panic + +runtime stack: +fatal error: gentraceback before goexitPC initialization +runtime: panic before malloc heap initialized +stack trace unavailable. +[root@powericp ~]# lscpu +Architecture: ppc64le +Byte Order: Little Endian +CPU(s): 16 +On-line CPU(s) list: 0-15 +Thread(s) per core: 1 +Core(s) per socket: 1 +Socket(s): 16 +NUMA node(s): 1 +Model: 2.0 (pvr 004e 1200) +Model name: POWER8 (architected), altivec supported +Hypervisor vendor: KVM +Virtualization type: para +L1d cache: 32K +L1i cache: 32K +NUMA node0 CPU(s): 0-15 + + +strace attached. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1830415 b/results/classifier/deepseek-2-tmp/output/mistranslation/1830415 new file mode 100644 index 000000000..d519f8bcc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1830415 @@ -0,0 +1,15 @@ + +linux-user elf loader issue + +all versions up to 4.0 (I didn't test others) +file affected linux-user/elfload.c +function load_elf_image + +if (phdr[i].p_type == PT_LOAD) { + +- abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; ++ abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; + if (a < loaddr) { + loaddr = a; + +To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1830864 b/results/classifier/deepseek-2-tmp/output/mistranslation/1830864 new file mode 100644 index 000000000..179707485 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1830864 @@ -0,0 +1,75 @@ + +Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(&cpu_->isar); })' failed + +The following assertion: + + assert(no_aa32 || cpu_isar_feature(arm_div, cpu)); + +introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some +asserts on aarch32 support", 2018-11-02), fails for me. I intended to +launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host +(APM Mustang A3). + +Libvirt generated the following QEMU command line: + +> LC_ALL=C \ +> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \ +> QEMU_AUDIO_DRV=none \ +> /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \ +> -name guest=f28.32bit,debug-threads=on \ +> -S \ +> -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes \ +> -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \ +> -cpu host,aarch64=off \ +> -drive file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \ +> -drive file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \ +> -m 8192 \ +> -realtime mlock=off \ +> -smp 8,sockets=8,cores=1,threads=1 \ +> -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \ +> -no-user-config \ +> -nodefaults \ +> -chardev socket,id=charmonitor,fd=27,server,nowait \ +> -mon chardev=charmonitor,id=monitor,mode=control \ +> -rtc base=utc \ +> -no-shutdown \ +> -boot strict=on \ +> -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 \ +> -device pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \ +> -device pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \ +> -device pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \ +> -device pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \ +> -device pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \ +> -device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \ +> -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \ +> -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \ +> -drive file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on \ +> -drive file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap \ +> -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on \ +> -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \ +> -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile= \ +> -chardev pty,id=charserial0 \ +> -serial chardev:charserial0 \ +> -chardev socket,id=charchannel0,fd=31,server,nowait \ +> -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ +> -device usb-tablet,id=input0,bus=usb.0,port=1 \ +> -device usb-kbd,id=input1,bus=usb.0,port=2 \ +> -vnc 127.0.0.1:0 \ +> -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \ +> -object rng-random,id=objrng0,filename=/dev/urandom \ +> -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0 \ +> -msg timestamp=on + +and then I got: + +> qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986: +> arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); +> isar_feature_arm_div(&cpu_->isar); })' failed. + +QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch +'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging", +2019-05-23). + +(Originally reported on the mailing list in the following thread: +<http://<email address hidden>>.) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1830872 b/results/classifier/deepseek-2-tmp/output/mistranslation/1830872 new file mode 100644 index 000000000..8d492488e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1830872 @@ -0,0 +1,75 @@ + +AARCH64 to ARMv7 mistranslation in TCG + +The following guest code: + + https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S + +implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI +Development Kit II) library function. (CopyMem() basically has memmove() +semantics, to provide a standard C analog here.) The relevant functions +are InternalMemCopyMem() and __memcpy(). + +When TCG translates this aarch64 code to x86_64, everything works fine. + +When TCG translates this aarch64 code to ARMv7, the destination area of +the translated CopyMem() function becomes corrupted -- it differs from +the intended source contents. Namely, in every 4096 byte block, the +8-byte word at offset 4032 (0xFC0) is zeroed out in the destination, +instead of receiving the intended source value. + +I'm attaching two hexdumps of the same destination area: + +- "good.txt" is a hexdump of the destination area when CopyMem() was + translated to x86_64, + +- "bad.txt" is a hexdump of the destination area when CopyMem() was + translated to ARMv7. + +In order to assist with the analysis of this issue, I disassembled the +aarch64 binary with "objdump". Please find the listing in +"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at +hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180. + +And, I ran the guest on the ARMv7 host with "-d +in_asm,op,op_opt,op_ind,out_asm". Please find the log in +"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached. + +The TBs that correspond to (parts of) the InternalMemCopyMem() and +__memcpy() functions are scattered over the TCG log file, but the offset +between the "nice" disassembly from "DxeCore.objdump", and the in-RAM +TBs in the TCG log, can be determined from the fact that there is a +single prfm instruction in the entire binary. The instruction's offset +is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy() +function --, and its RAM address is 0x472d2180 in the TCG log. Thus the +difference (= the load address of DxeCore.efi) is 0x472a7000. + +QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch +'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21). + +The reproducer command line is (on an ARMv7 host): + + qemu-system-aarch64 \ + -display none \ + -machine virt,accel=tcg \ + -nodefaults \ + -nographic \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \ + -drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \ + -cpu cortex-a57 \ + -chardev stdio,signal=off,mux=on,id=char0 \ + -mon chardev=char0,mode=readline \ + -serial chardev:char0 + +The apparent symptom is an assertion failure *in the guest*, such as + +> ASSERT [DxeCore] +> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090): +> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength + +but that is only a (distant) consequence of the CopyMem() +mistranslation, and resultant destination area corruption. + +Originally reported in the following two mailing list messages: +- http://<email address hidden> +- http://<email address hidden> \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1831362 b/results/classifier/deepseek-2-tmp/output/mistranslation/1831362 new file mode 100644 index 000000000..272dc45d1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1831362 @@ -0,0 +1,28 @@ + +European keyboard PC-105 deadkey + +With a freshly compiled version of qemu 4.0.50 on Windows 10 (host) + +I am using 3 different Belgian keyboards and I have the same behaviour +- 2 USB keyboards (Logitech and HP) and +- the keyboard of my laptop (HP) + +3 characters on the same key cannot be used (the key seams to be dead): +< (less than), +> (greater than) used with the combination of LShift or RShift +\ (backslash) used with the combination of AltGr + +Using grub command mode from an archlinux installation (5.1.4) +The keyboard seams to be a mix of azerty and qwerty keyboard +all letters are correctly mapped but all numbers and special +characters are not + +Using sendkey in monitor +"sendkey <" results in : \ +"sendkey shift-<" results in : | +"sendkey ctrl-alt-<" results in : nothing + +REM: VirtualBox can handle this key and with the showkey command + from the archlinux kbd package, it shows : + keycode 86 press + keycode 86 release \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1831545 b/results/classifier/deepseek-2-tmp/output/mistranslation/1831545 new file mode 100644 index 000000000..1dfada3ec --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1831545 @@ -0,0 +1,22 @@ + +"accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host + +As described in https://lists.gnu.org/archive/html/qemu-devel//2019-05/msg07362.html I run into TCG regression in qemu-git. + +Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-effective for my case. + +For reproduction (on 32-bit x86 host, in my case Slackware with gcc 5.5.0): + +./configure --target-list=x86_64-softmmu --disable-werror --enable-debug-tcg + +make (-j5 in my case) + +try to boot any 64-bit kernel: + +x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg + +result is - qemu appear to hang right after "Booting the kernel" line. Decompression (xz) was ok. + +Tested with qemu-git commit e2a58ff493a2e00db3e963c1839c5374500110f2 + +32-bit OS can be booted fine, and -enable-kvm also allow 64 bit kernel/os to boot. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1832281 b/results/classifier/deepseek-2-tmp/output/mistranslation/1832281 new file mode 100644 index 000000000..7134389a5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1832281 @@ -0,0 +1,52 @@ + +tcg bug master / 4.0.0 v8 operation >>> and |= + +vm guest is linux, executed with tcg +running this Node.js snippet leads to + +$ node +> a = undefined +undefined +> a >>> 0 +4294967295 + +host node +$ node +> a = undefined +undefined +> a >>> 0 +0 + +same with |= + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> let buffer +undefined +> buffer |= 0 +0 + +vm with tcg: + +$ ./out/Release/node --version +v12.4.0 +./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);" +-1 + + +vm guest is debian x86_64 latest release +vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img + +git tag v4.0.0 and master, commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-x86_64 was used. + +Node.js as compiled on the vm guest (v12.4.0 / master) + + +see also +https://github.com/nodejs/node/issues/19348#issuecomment-500465502 + +I need further assistance to track down the cause of the bug. + +Kind regards +Manuel \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1832353 b/results/classifier/deepseek-2-tmp/output/mistranslation/1832353 new file mode 100644 index 000000000..d9167fe16 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1832353 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1832422 b/results/classifier/deepseek-2-tmp/output/mistranslation/1832422 new file mode 100644 index 000000000..a0d83051e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1832422 @@ -0,0 +1,10 @@ + +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/deepseek-2-tmp/output/mistranslation/1832535 b/results/classifier/deepseek-2-tmp/output/mistranslation/1832535 new file mode 100644 index 000000000..1d9040654 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1832535 @@ -0,0 +1,13 @@ + +[riscv/regression] Missing tlb flush introduced in refactoring + +Hello, + +In qemu-system-riscv64, following a QEMU update, I get all sort of weird and not easily reproducible crashes in my risc-v guest. + +I have bissected this issue to commit c7b951718815694284501ed01fec7acb8654db7b. +Some TLB flushes were removed in the following places: +target/riscv/cpu_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) +target/riscv/op_helper.c: `csr_write_helper(env, s, CSR_MSTATUS);` -> `env->mstatus = s;` (twice) + +Adding TLB flushes in all 4 places fixes the issues for me. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1832914 b/results/classifier/deepseek-2-tmp/output/mistranslation/1832914 new file mode 100644 index 000000000..b8d9924ec --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1832914 @@ -0,0 +1,12 @@ + +Wrong error log when drive is specified qcow but qcow2 image file used. + +On archlinux qemu version 4.0.0 when I type: + +$ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ... + +I get this output in stderr + +qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3 + +image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1833668 b/results/classifier/deepseek-2-tmp/output/mistranslation/1833668 new file mode 100644 index 000000000..9ea0cc03b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1833668 @@ -0,0 +1,28 @@ + +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/deepseek-2-tmp/output/mistranslation/1834051 b/results/classifier/deepseek-2-tmp/output/mistranslation/1834051 new file mode 100644 index 000000000..2819847ff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1834051 @@ -0,0 +1,12 @@ + +IRQ2 ignored under KVM when using IOAPIC + +When using KVM, and an OS that supports the IOAPIC, interrupts mapped on IRQ2 (for instance, routing an HPET timer on interrupt 2) will cause the interrupts to never be delivered. This is because QEmu, when setting up the KVM interrupt routes, will not set one up for IRQ2[0]. When running without KVM, IRQ2 is identity-mapped to GSI2. + +My understanding is that IRQs should be identity mapped to their equivalent GSI unless a redirection entry is present in the MADT. This is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override Structure, which claims: "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources.". + +I stumbled across this while working on my own custom OS, got very confused why the HPET wasn't triggering any interruption - and even more confused why the behavior only happened in KVM and not in non-KVM. + +[0]: https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40 + +[1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1834496 b/results/classifier/deepseek-2-tmp/output/mistranslation/1834496 new file mode 100644 index 000000000..77859a1c0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1834496 @@ -0,0 +1,28 @@ + +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/deepseek-2-tmp/output/mistranslation/1834613 b/results/classifier/deepseek-2-tmp/output/mistranslation/1834613 new file mode 100644 index 000000000..f79ffbf41 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1834613 @@ -0,0 +1,49 @@ + +Crypto related operations failing on Alpine Linux on QEMU 4.0 + +I'm unable to boot the netboot image of Alpine Linux using QEMU 4.0. + +Steps to reproduce: + +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/vmlinuz-vanilla +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/initramfs-vanilla +qemu-system-ppc64 -kernel vmlinuz-vanilla -initrd initramfs-vanilla -nographic -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/v3.10/main" + +The init script will automatically download and install an in-memory Alpine Linux environment. However, with QEMU 4.0, the installation process will fail with "BAD SIGNATURE" errors: + + + + * Installing packages to root filesystem: fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/ppc64le/APKINDEX.tar.gz +(1/20) Installing musl (1.1.22-r2) +ERROR: musl-1.1.22-r2: BAD signature (2/20) Installing busybox (1.30.1-r2) +ERROR: busybox-1.30.1-r2: BAD signature (3/20) Installing alpine-baselayout (3.1.2-r0) +Executing alpine-baselayout-3.1.2-r0.pre-install ERROR: alpine-baselayout-3.1.2-r0.pre-install: script exited with error 127 +ERROR: alpine-baselayout-3.1.2-r0: BAD signature (4/20) Installing openrc (0.41.2-r1) +ERROR: openrc-0.41.2-r1: BAD signature (5/20) Installing alpine-conf (3.8.3-r0) +ERROR: alpine-conf-3.8.3-r0: BAD signature (6/20) Installing libcrypto1.1 (1.1.1c-r0) +ERROR: libcrypto1.1-1.1.1c-r0: BAD signature (7/20) Installing libssl1.1 (1.1.1c-r0) +ERROR: libssl1.1-1.1.1c-r0: BAD signature (8/20) Installing ca-certificates-cacert (20190108-r0) +ERROR: ca-certificates-cacert-20190108-r0: BAD signature (9/20) Installing libtls-standalone (2.9.1-r0) +ERROR: libtls-standalone-2.9.1-r0: BAD signature (10/20) Installing ssl_client (1.30.1-r2) +ERROR: ssl_client-1.30.1-r2: BAD signature (11/20) Installing zlib (1.2.11-r1) +ERROR: zlib-1.2.11-r1: BAD signature (12/20) Installing apk-tools (2.10.4-r1) +ERROR: apk-tools-2.10.4-r1: BAD signature (13/20) Installing busybox-suid (1.30.1-r2) +ERROR: busybox-suid-1.30.1-r2: BAD signature (14/20) Installing busybox-initscripts (3.1-r7) +ERROR: busybox-initscripts-3.1-r7: BAD signature (15/20) Installing scanelf (1.2.3-r0) +ERROR: scanelf-1.2.3-r0: BAD signature (16/20) Installing musl-utils (1.1.22-r2) +ERROR: musl-utils-1.1.22-r2: BAD signature (17/20) Installing libc-utils (0.7.1-r0) +ERROR: libc-utils-0.7.1-r0: BAD signature (18/20) Installing alpine-keys (2.1-r2) +ERROR: alpine-keys-2.1-r2: BAD signature (19/20) Installing alpine-base (3.10.0-r0) +ERROR: alpine-base-3.10.0-r0: BAD signature (20/20) Installing openssl (1.1.1c-r0) +ERROR: openssl-1.1.1c-r0: BAD signature 20 errors; 0 MiB in 0 packages +ok. +grep: /sysroot/etc/inittab: No such file or directory +/sbin/init not found in new root. Launching emergency recovery shell +Type exit to continue boot. +sh: can't access tty; job control turned off +/ # + + +If I boot up a disk image created by a previous version QEMU, crypto related operations like verifying a RSA signature using the "openssl" command will also fail. + +I didn't see these errors on previous QEMU versions or other architectures on QEMU 4.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1835693 b/results/classifier/deepseek-2-tmp/output/mistranslation/1835693 new file mode 100644 index 000000000..32e22fb4c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1835693 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1835839 b/results/classifier/deepseek-2-tmp/output/mistranslation/1835839 new file mode 100644 index 000000000..c209ba4d2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1835839 @@ -0,0 +1,22 @@ + +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/deepseek-2-tmp/output/mistranslation/1836078 b/results/classifier/deepseek-2-tmp/output/mistranslation/1836078 new file mode 100644 index 000000000..583ac8e77 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1836078 @@ -0,0 +1,23 @@ + +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/deepseek-2-tmp/output/mistranslation/1836558 b/results/classifier/deepseek-2-tmp/output/mistranslation/1836558 new file mode 100644 index 000000000..143fdff85 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1836558 @@ -0,0 +1,49 @@ + +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/deepseek-2-tmp/output/mistranslation/1838 b/results/classifier/deepseek-2-tmp/output/mistranslation/1838 new file mode 100644 index 000000000..6fbe10810 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1838 @@ -0,0 +1,2 @@ + +Win9x on qemu 8.0.3 - Impossible to launch a win32 app diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1838312 b/results/classifier/deepseek-2-tmp/output/mistranslation/1838312 new file mode 100644 index 000000000..5abe2ebb7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1838312 @@ -0,0 +1,32 @@ + +Qemu virt-manager Segmentation fault + +Hi! + +I installed all these packages: + +sudo apt install qemu +sudo apt install ipxe-qemu-256k-compat-efi-roms libspice-server1 libbluetooth3 +sudo apt install libbrlapi0.6 libcacard0 libfdt1 libusbredirparser1 libvirglrenderer0 libxen-4.9 libxenstore3.0 +sudo apt install cpu-checker ibverbs-providers ipxe-qemu libibverbs1 libiscsi7 libnl-route-3-200 librados2 librbd1 librdmacm1 msr-tools sharutils +sudo apt install qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui qemu-utils +sudo apt install --no-install-recommends qemu-kvm qemu-system-x86 +sudo apt install libauparse0 ebtables gir1.2-gtk-vnc-2.0 gir1.2-libosinfo-1.0 gir1.2-libvirt-glib-1.0 gir1.2-spiceclientglib-2.0 gir1.2-spiceclientgtk-3.0 libvde0 libvdeplug2 libgovirt-common libgovirt2 libgtk-vnc-2.0-0 libgvnc-1.0-0 libosinfo-1.0-0 libphodav-2.0-0 libphodav-2.0-common libspice-client-glib-2.0-8 libspice-client-gtk-3.0-5 libusbredirhost1 libvirt-clients libvirt-daemon libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt-glib-1.0-0 libvirt0 osinfo-db python3-libvirt python3-libxml2 spice-client-glib-usb-acl-helper vde2 vde2-cryptcab virt-viewer virtinst virt-manager + +without the i386 packages for Qemu because I want only 64 bit. + +I installed all these packages without error, but when I run + +# virt-manager + +Output: ...shows me: + +Segmentation fault + + +My hardware is 100% ok. +Maybee a broken lib? + + + +How can I fix that? \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1839325 b/results/classifier/deepseek-2-tmp/output/mistranslation/1839325 new file mode 100644 index 000000000..272337fe2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1839325 @@ -0,0 +1,72 @@ + +Go programs crash on qemu-sh4 due to issues with atomics + +After #1738545 [1] was fixed, Go applications work fine on qemu-arm but still crash on qemu-sh4. From the backtrace, it looks like an issue with the atomics in qemu-sh4: + +(sid-sh4-sbuild)root@epyc:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +(sid-sh4-sbuild)root@epyc:/# gccgo-9 hello.go -o hello +(sid-sh4-sbuild)root@epyc:/# ./hello +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack +panic: ( runtime runtime.errorString) (0x7f74527c,0x80a038) +fatal error: panic on system stack + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 + +goroutine 1 [running]: + goroutine running on other thread; stack unavailable + +runtime stack: +runtime..z2finternal..z2fatomic.Load64 + ../../../src/libgo/go/runtime/internal/atomic/atomic.c:37 +runtime_mstart + ../../../src/libgo/runtime/proc.c:596 +(sid-sh4-sbuild)root@epyc:/# + +The same sample Go program runs fine on my SH7785LCR SH4 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:~> cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} + +root@tirpitz:~> gccgo-9 hello.go -o hello +root@tirpitz:~> ./hello +hello world +root@tirpitz:~> + +Please note: In order to be able to reproduce this, one also needs to revert commit 61dedf2af7 [2], otherwise the Go application crashes differently: + +(sid-sh4-sbuild)root@epyc:/# ./hello +Unhandled trap: 0x180 +pc=0x7e5f7f9e sr=0x00000000 pr=0x7ee3d582 fpscr=0x00080004 +spc=0x00000000 ssr=0x00000000 gbr=0x7e590480 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7e5f7f60 fpul=0x00034f3b +r0=0x008007d4 r1=0x00000000 r2=0xfffe0b2a r3=0x00000002 +r4=0x008006e4 r5=0x00872000 r6=0x00200000 r7=0x00000000 +r8=0x7f7bca7c r9=0x7fffebd4 r10=0x00800480 r11=0x7f7bc0f0 +r12=0x7f7a3fa4 r13=0x008004c0 r14=0x7f7b2238 r15=0x7fffebd0 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@epyc:/# + +> [1] https://bugs.launchpad.net/bugs/1738545 +> [2] https://bugs.launchpad.net/bugs/1796520 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1840922 b/results/classifier/deepseek-2-tmp/output/mistranslation/1840922 new file mode 100644 index 000000000..c3962208b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1840922 @@ -0,0 +1,22 @@ + +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/deepseek-2-tmp/output/mistranslation/1841442 b/results/classifier/deepseek-2-tmp/output/mistranslation/1841442 new file mode 100644 index 000000000..ef6e653f5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1841442 @@ -0,0 +1,56 @@ + +floating point emulation can fail to set FE_INEXACT + +Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. + +On ppc64le native: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +On x86_64: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x30 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-system-ppc64 +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x8000000 +FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-x86_64: +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x0 + +0x0000000000000000 0.000000 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1841990 b/results/classifier/deepseek-2-tmp/output/mistranslation/1841990 new file mode 100644 index 000000000..edb7c3ceb --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1841990 @@ -0,0 +1,39 @@ + +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/deepseek-2-tmp/output/mistranslation/1843133 b/results/classifier/deepseek-2-tmp/output/mistranslation/1843133 new file mode 100644 index 000000000..b51198e15 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1843133 @@ -0,0 +1,77 @@ + +Possibly incorrect branch in qemu-system-hppa + +I plan to release a new GNU Lightning soon. +I no longer have access to any physical HPPA, but code that +was tested some years ago did work on HPPA/HP-UX, and now it +appears qemu-system-hppa incorrectly branches in code generated +by GNU Lightning. Currently only 32 bit hppa jit generation +supported. + +In the lightning check/test tool, the code would be: + +.code + prolog + movi %r0 0x7fffffff + movi %r1 1 + boaddr L0 %r0 %r1 + calli @abort +L0: + ret + epilog + +The code/debug information looks like this: + movi r4 0x7fffffff + 0xf8ef5018 ldil L%7ffff800,r4 + 0xf8ef501c ldo 7ff(r4),r4 + movi r5 0x1 + 0xf8ef5020 ldi 1,r5 + boaddr L1 r4 r5 + 0xf8ef5024 addb,sv,n r5,r4,0xf8ef5044 :a.tst:291 + 0xf8ef5028 nop + calli 0xf8eeb68a + [...] + L1: + +Apparently it is not understanding 0x7fffffff + 1 is a signed overflow. + +Tested in Fedora with qemu-system-hppa-3.1.1-2.fc30.x86_64 and using +the debian-10 image. + +To make it a bit easier to test (partially transformed the +not so optimized code generated by lightning to gcc -S output): +# cat a.s + .LEVEL 1.1 + .text + .align 4 +.globl main + .type main, @function +main: + .PROC + .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3 + .ENTRY + copy %r3,%r1 + copy %r30,%r3 + stwm %r1,64(%r30) + zdepi -1,31,31,%r23 + ldi 1,%r24 + addb,sv,n %r24,%r23,.L0 + nop + ldi 1,%r28 + b,n .L1 + nop +.L0: + ldi 0,%r28 +.L1: + ldo 64(%r3),%r30 + ldwm -64(%r30),%r3 + bv,n %r0(%r2) + .EXIT + .PROCEND + .size main, .-main + +# gcc a.s +# ./a.out; echo $? +1 + +It should have returned 0. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1843205 b/results/classifier/deepseek-2-tmp/output/mistranslation/1843205 new file mode 100644 index 000000000..266f14b89 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1843205 @@ -0,0 +1,103 @@ + +Inaccurate Fmod on i386 + +# Qemu Version + +```bash +$ qemu-i386 --version +qemu-i386 version 3.0.1 (qemu-3.0.1-4.fc29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +``` + +# Failing Source Code (C) + +```c +#include <math.h> +#include <stdio.h> + +int main() +{ + double x = 29860476080414620.0; + double y = 17.0; + double z = fmod(x, y); + printf("%f\n", z); + return 0; +} +``` + +The code was compiled with GCC (8.3.1) on x86-64 with the flags `-O3 -m32 -lm -static`. + +# Emitted (Annotated) Assembly + +In order to facilitate debugging the issue, the following assembly was generated to show nothing unusual occurred during compilation. The assembly was generated with flags `-S -O3 -m32 -lm`, and then annotated to show the operands to fmod. + +```asm + .file "a.c" + .text + .section .rodata.str1.1,"aMS",@progbits,1 +.LC2: + .string "%f\n" + .section .text.startup,"ax",@progbits + .p2align 4,,15 + .globl main + .type main, @function +main: +.LFB16: + .cfi_startproc + leal 4(%esp), %ecx + .cfi_def_cfa 1, 0 + andl $-16, %esp + pushl -4(%ecx) + pushl %ebp + .cfi_escape 0x10,0x5,0x2,0x75,0 + movl %esp, %ebp + pushl %ecx + .cfi_escape 0xf,0x3,0x75,0x7c,0x6 + subl $4, %esp + pushl $1076953088 ; high 32-bits of double for y + pushl $0 ; low 32-bits of double for y + pushl $1130005884 ; high 32-bits of double for x + pushl $2003187687 ; low 32-bits of double for x + call fmod + movl $.LC2, (%esp) + fstpl 4(%esp) + call printf + movl -4(%ebp), %ecx + .cfi_def_cfa 1, 0 + addl $16, %esp + xorl %eax, %eax + leave + .cfi_restore 5 + leal -4(%ecx), %esp + .cfi_def_cfa 4, 4 + ret + .cfi_endproc +.LFE16: + .size main, .-main + .ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)" + .section .note.GNU-stack,"",@progbits +``` + +# Result + +Running the compiled binary on x86_64 produces the expected value of `15.000000`, while using `qemu-i386 <binary>` produces the unexpected result of `-4.000000`. + +This was tested against: + +1. Qemu 3.0.1 for Fedora 29. +2. Qemu 4.1.0 built from source, downloaded from https://download.qemu.org/qemu-4.1.0.tar.xz +3. Qemu built-from-source against commit 90b1e3afd33226b6078fec6d77a18373712a975c. + +# Building Qemu + +Qemu built-from-source was compiled as follows: + +```bash +mkdir build && cd build +../configure --disable-kvm --target-list="i386-linux-user" +make -j 5 +``` + +# Results + +All built versions of Qemu running the 32-bit failed to produce the accurate result. Using qemu-x86_64 against an x86_64 binary built from the same C source code produces correct results. Running the 32-bit binary natively produces the correct result. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1843651 b/results/classifier/deepseek-2-tmp/output/mistranslation/1843651 new file mode 100644 index 000000000..689a82fff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1843651 @@ -0,0 +1,81 @@ + +m68k fpu bug + +On gcc123 cfarm machine, +I was testing m68k executables generated by Free Pascal Compiler. + +muller@gcc123:~/pas/check$ cat inf.pp +function get_double(x : double):double; + begin + get_double:=x; + end; + + +var + y : double; + py : pbyte; + i : byte; +begin + y:=1.0/0.0; + py:=@y; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; + y:=get_double(y)+1; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; +end. +muller@gcc123:~/pas/check$ ppc68k inf +Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k +Copyright (c) 1993-2019 by Florian Klaempfl and others +Target OS: Linux for m68k +Compiling inf.pp +Assembling program +Linking inf +33 lines compiled, 0.1 sec +muller@gcc123:~/pas/check$ ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ qemu-m68k ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf +qemu-m68k qemu-m68k-fixed +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf +big endian y=7FF0000000000000 +big endian y=7FF0000000000000 + +~/sys-root/bin/qemu-m68k is 4.1.0 release, +~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change: + +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define floatx80_infinity_low LIT64(0x0000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define floatx80_infinity_low LIT64(0x8000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif + +the M68K branch value is set to the same value as the other branch. + +The problem of the M68K specific floatx86_infinity_low values +is that is enters in conflict with +muller@gcc123:~/pas/check$ grep -nA6 invalid_enc /home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h +752:static inline bool floatx80_invalid_encoding(floatx80 a) +753-{ +754- return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0; +755-} + +And thus the m68k variant of floatx80 representing +Infinity is +considered as an invalid encoding, and thus converted into a NaN 7FFFFFFFFFFFFFFF \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1847232 b/results/classifier/deepseek-2-tmp/output/mistranslation/1847232 new file mode 100644 index 000000000..8f92d9da5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1847232 @@ -0,0 +1,14 @@ + +qemu TCG in s390x mode issue with calculating HASH + +When using go on s390x on Debian x64 (buster) (host) and debian s390x (sid) (guest) I run into the following problem : + +The following occurs while trying to build a custom project : + +go: <email address hidden>: Get https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: local error: tls: bad record MAC + +Doing a git bisect I find that this problem only occurs on and after commit 08ef92d556c584c7faf594ff3af46df456276e1b + +Before that commit, all works fine. Past this commit, build always fails. + +Without any proof, It looks like a hash calculation bug related to using z/Arch vector facilities... \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1847467 b/results/classifier/deepseek-2-tmp/output/mistranslation/1847467 new file mode 100644 index 000000000..44db87523 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1847467 @@ -0,0 +1,17 @@ + +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/deepseek-2-tmp/output/mistranslation/1849879 b/results/classifier/deepseek-2-tmp/output/mistranslation/1849879 new file mode 100644 index 000000000..7ecba8b4c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1849879 @@ -0,0 +1,11 @@ + +qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile + +I've noticed that qemu-arm for cortex-M considers +vmrs apsr_nzcv, fpscr +as an illegal instruction. + +In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. + +I posted a small patch: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg06978.html \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1851939 b/results/classifier/deepseek-2-tmp/output/mistranslation/1851939 new file mode 100644 index 000000000..f5e29bc12 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1851939 @@ -0,0 +1,17 @@ + +RISC-V mstatus TSR bit not correctly implemented + +Hi, + +since qemu 4.1.0 the TSR bit in mstatus register is supported. But it does not allow for executing sret in m-mode. + +From the RISC-V specifications: +"When TSR=1, attempts to execute SRET while executing in S-mode will raise an illegal instruction +exception. When TSR=0, this operation is permitted in S-mode." + +This means an exception should only be raised when executing in S-mode, but not in M-mode, hence you should change the condition in helper_sret (target/riscv/op_helper.c) from: + if (env->priv_ver >= PRIV_VERSION_1_10_0 && + get_field(env->mstatus, MSTATUS_TSR)) +to: + if (env->priv_ver >= PRIV_VERSION_1_10_0 && + get_field(env->mstatus, MSTATUS_TSR) && !(env->priv >= PRV_M)) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1852781 b/results/classifier/deepseek-2-tmp/output/mistranslation/1852781 new file mode 100644 index 000000000..c737b3b04 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1852781 @@ -0,0 +1,33 @@ + +qemu s390x on focal - applications breaking + +Running qemu-system-s390x (1:4.0+dfsg-0ubuntu10) on an x86-64 Focal host with an upgrade of a Eoan s390x VM to a Focal s390x is triggering random breakage, for example: + +sudo apt-get update && sudo apt-get dist-upgrade + +... +... + +Unpacking debianutils (4.9) over (4.8.6.3) ... +Setting up debianutils (4.9) ... +Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 43. +(Reading database ... 83640 files and directories currently installed.) +Preparing to unpack .../bash_5.0-5ubuntu1_s390x.deb ... +Unpacking bash (5.0-5ubuntu1) over (5.0-4ubuntu1) ... +Setting up bash (5.0-5ubuntu1) ... +[12124.788618] User process fault: interruption code 0007 ilc:3 in bash[2aa3d780000+149000] +dpkg: error processing package bash (--configure): + installed bash package post-installation script subprocess was killed by signal (Floating point exception), core du +mped +Errors were encountered while processing: + bash +E: Sub-process /usr/bin/dpkg returned an error code (1) + +And now bash is completely broken: + +cking@eoan-s390x:~$ bash +[12676.204389] User process fault: interruption code 0007 ilc:3 in bash[2aa14780000+149000] + +Floating point exception (core dumped) + +The upgrade works OK on a s390x, so I'm assuming it's something to do with the qemu emulation. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1856837 b/results/classifier/deepseek-2-tmp/output/mistranslation/1856837 new file mode 100644 index 000000000..f482afe7d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1856837 @@ -0,0 +1,41 @@ + +qemu 4.2.0 arm segmentation fault with gcc 9.2 + +As discussed with f4bug yesterday on IRC here comes the bug description. + +I'm building/configured qemu-4.2.0 on an x86_64 (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) with target-list "arm-softmmu,arm-linux-user" and debug enabled. I use the arm-linux-user variant, "qemu-arm". + +Then i'm trying to cross-compile (arm gcc) an old version of googles v8 (as i need this version of the lib for binary compatibility) which uses qemu during build. + +It worked with gcc 5.4.0 but not with 9.2.0. I also tried with 6.5.0, 7.4.0 and 8.3.0 but those are also causing the same segmentation fault. + +The executed command wich breaks qemu is: + + qemu-arm /tmp/build/out/arm.release/mksnapshot.arm --log-snapshot-positions --logfile /tmp/build/out/arm.release/obj.host/v8_snapshot/geni/snapshot.log --random-seed 314159265 /tmp/build/out/arm.release/obj.host/v8_snap + +The printed error message is: + +ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Calling qemu with gdb gives the following information: + + Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. + 0x0000555555d63d11 in static_code_gen_buffer () + +and + + (gdb) bt + #0 0x0000555555d63d11 in static_code_gen_buffer () + #1 0x0000555555628d58 in cpu_tb_exec (itb=<optimized out>, cpu=0x555557c33930) at + /tmp/build/qemu/accel/tcg/cpu-exec.c:172 + #2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x555557c33930) at /tmp/build/qemu/accel/tcg/cpu-exec.c:618 + #3 cpu_exec (cpu=cpu@entry=0x555557c2b660) at /tmp/build/qemu/accel/tcg/cpu-exec.c:731 + #4 0x0000555555661578 in cpu_loop (env=0x555557c33930) at /tmp/build/qemu/linux-user/arm/cpu_loop.c:219 +#5 0x00005555555d6d76 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /tmp/build/qemu/linux-user/main.c:865 + +Calling qemu-arm with debug switch "-d in_asm,int,op_opt" shows the log in the attached file. + +Thanks for any hints! +Fabian \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1858461 b/results/classifier/deepseek-2-tmp/output/mistranslation/1858461 new file mode 100644 index 000000000..0a7e41c54 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1858461 @@ -0,0 +1,24 @@ + +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/deepseek-2-tmp/output/mistranslation/1859291 b/results/classifier/deepseek-2-tmp/output/mistranslation/1859291 new file mode 100644 index 000000000..74ce5f55c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1859291 @@ -0,0 +1,4 @@ + +RISC-V incorrect exception generated + +When using 'ecall' from supervisor mode, user exception is raised instead of supervisor exception. The problem is located under 'target/riscv/insn_trans/trans_priviledged.inc.c' in function 'static bool trans_ecall(DisasContext *ctx, arg_ecall *a)'. Best regards, Serge Teodori \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1860053 b/results/classifier/deepseek-2-tmp/output/mistranslation/1860053 new file mode 100644 index 000000000..350e85f2c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1860053 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1860056 b/results/classifier/deepseek-2-tmp/output/mistranslation/1860056 new file mode 100644 index 000000000..7f810b236 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1860056 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1860553 b/results/classifier/deepseek-2-tmp/output/mistranslation/1860553 new file mode 100644 index 000000000..11bcfc3a7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1860553 @@ -0,0 +1,15 @@ + +cmake crashes on qemu-alpha-user with Illegal Instruction + +I tried building cmake on Debian unstable for Alpha today using qemu-user and the compiled cmake binary crashed with "Illegal Instruction": + +g++ -Wl,-z,relro -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/<<PKGBUILDDIR>>/Build/Bootstrap.cmk -I/<<PKGBUILDDIR>>/Source -I/<<PKGBUILDDIR>>/Source/LexerParser -I/<<PKGBUILDDIR>>/Utilities cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBreakCommand.o cmBuildCommand.o cmCMakeMinimumRequired.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCustomCommand.o cmCustomCommandGenerator.o cmDefinePropertyCommand.o cmDefinitions.o cmDepends.o cmDependsC.o cmDisallowedCommand.o cmDocumentationFormatter.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportSetMap.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobalUnixMakefileGenerator3.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmProperty.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmStateDirectory.o cmStateSnapshot.o cmStringReplaceHelper.o cmStringCommand.o cmSubdirCommand.o cmSystemTools.o cmTarget.o cmTargetCompileDefinitionsCommand.o cmTargetCompileFeaturesCommand.o cmTargetCompileOptionsCommand.o cmTargetIncludeDirectoriesCommand.o cmTargetLinkLibrariesCommand.o cmTargetPropCommandBase.o cmTargetPropertyComputer.o cmTargetSourcesCommand.o cmTest.o cmTestGenerator.o cmTimestamp.o cmTryCompileCommand.o cmTryRunCommand.o cmUnexpectedCommand.o cmUnsetCommand.o cmUVHandlePtr.o cmUVProcessChain.o cmVersion.o cmWhileCommand.o cmWorkingDirectory.o cmake.o cmakemain.o cmcmd.o cm_string_view.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmExprLexer.o cmExprParser.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o uv-src-strscpy.c.o uv-src-timer.c.o uv-src-uv-common.c.o uv-src-unix-cmake-bootstrap.c.o uv-src-unix-core.c.o uv-src-unix-fs.c.o uv-src-unix-loop.c.o uv-src-unix-loop-watcher.c.o uv-src-unix-no-fsevents.c.o uv-src-unix-pipe.c.o uv-src-unix-poll.c.o uv-src-unix-posix-hrtime.c.o uv-src-unix-posix-poll.c.o uv-src-unix-process.c.o uv-src-unix-signal.c.o uv-src-unix-stream.c.o -ldl -lrt -o cmake +make[2]: Leaving directory '/<<PKGBUILDDIR>>/Build/Bootstrap.cmk' +loading initial cache file /<<PKGBUILDDIR>>/Build/Bootstrap.cmk/InitialCacheFlags.cmake +Illegal instruction +--------------------------------------------- +Error when bootstrapping CMake: +Problem while running initial CMake +--------------------------------------------- + +I'm working on creating a chroot for download to reproduce the issue. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1860920 b/results/classifier/deepseek-2-tmp/output/mistranslation/1860920 new file mode 100644 index 000000000..3630a49a3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1860920 @@ -0,0 +1,24 @@ + +qemu-s390x-softmmu: crash + +Trying to compile and use rust programs on an s390x emulated machine, crash in qemu/target/s390x/translate.c line 3894 + +Steps to reproduce: +on a amd64 PC, installed debian on s390x emulated by qemu, seems to work fine (installed some packages, etc.) +installed rust cargo (both from rustup and from debian) +cargo install anything makes *qemu* crash when beginning to compile + +Technical details: +* host: amd64 Linux +* qemu v4.2.0 (recompiled from git with debug options using configure --target-list=s390x-softmmu --enable-debug) (problem appears also with older versions of qemu from git, with default compilation options, with qemu from debian, etc.) +* compiled with gcc 9.2 +* command line, relevant part: qemu-system-s390x -snapshot -machine s390-ccw-virtio -cpu max,zpci=on -serial mon:stdio -display none -m 512 +(tested with -smp 4 -m 4096 as well and without snapshotting) +* command line, less relevant part: -drive file=./debian.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-ccw,devno=fe.0.0001,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,scsi=off -netdev user,id=mynet0,hostfwd=tcp::2223-:22 -device virtio-net-pci,netdev=mynet0 +* core dump: abort in qemu/target/s390x/translate.c line 3894 ; s->field: op has value 0xEC and op2 has value 0x54 +(more info available if needed) + +Tried to patch source to add 0x54 case to no avail. +Tried other cpu variants to no avail as well. + +Reporting this in security as well since it also looks very much like a DoS (albeit somewhat minor), feel free to tell me to report the bug somewhere else. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1861161 b/results/classifier/deepseek-2-tmp/output/mistranslation/1861161 new file mode 100644 index 000000000..b3080d01e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1861161 @@ -0,0 +1,60 @@ + +qemu-arm-static stuck with 100% CPU when cross-compiling emacs + +Hello, + +I'm trying to build multi-arch docker images for https://hub.docker.com/r/silex/emacs. + +Here is the machine I'm building on: + +root@ubuntu-4gb-fsn1-1:~# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 18.04.3 LTS +Release: 18.04 +Codename: bionic +root@ubuntu-4gb-fsn1-1:~# uname -a +Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + +Whenever I try to build the following alpine Dockerfile https://gitlab.com/Silex777/docker-emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile with this command: + +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build --pull -t test --platform arm . + +It builds fine until this: + +root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu +root 26473 26465 99 14:26 pts/0 01:59:58 /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el + +This is supposed to take a few seconds, but in practice it takes 100% CPU and never ends. When I strace the process I see this: + +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) + +It happens with all the QEMU versions I tested: +- 2.11.1 (OS version) +- 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1) +- 4.2.0-2 (from multiarch/qemu-user-static) + +Any ideas of what I could do to debug it further? + +Kind regards, +Philippe \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1861341 b/results/classifier/deepseek-2-tmp/output/mistranslation/1861341 new file mode 100644 index 000000000..981b86aad --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1861341 @@ -0,0 +1,31 @@ + +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/deepseek-2-tmp/output/mistranslation/1861404 b/results/classifier/deepseek-2-tmp/output/mistranslation/1861404 new file mode 100644 index 000000000..fa672792f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1861404 @@ -0,0 +1,51 @@ + +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/deepseek-2-tmp/output/mistranslation/1863247 b/results/classifier/deepseek-2-tmp/output/mistranslation/1863247 new file mode 100644 index 000000000..7bb480bfd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1863247 @@ -0,0 +1,9 @@ + +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/deepseek-2-tmp/output/mistranslation/1863445 b/results/classifier/deepseek-2-tmp/output/mistranslation/1863445 new file mode 100644 index 000000000..f99870de0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1863445 @@ -0,0 +1,17 @@ + +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/deepseek-2-tmp/output/mistranslation/1863508 b/results/classifier/deepseek-2-tmp/output/mistranslation/1863508 new file mode 100644 index 000000000..72e9609d5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1863508 @@ -0,0 +1,26 @@ + +qemu-system-arm stops with SIGSEGV in helper_gvec_eq16 + +Segmentation fault when trying to start FreeBSD-arm system with qemu-system-arm (version 4.1.1 on Fedora 31) + +Commandline: +gdb -q --args /bin/qemu-system-arm \ + -name FreeBSD12,debug-threads=on \ + -m 1536 -machine virt -smp 2 \ + -M virt,highmem=off -serial mon:stdio -monitor telnet::45452,server,nowait \ + -machine virt,accel=tcg,usb=off,dump-guest-core=off,gic-version=2 \ + -overcommit mem-lock=off -no-reboot -device virtio-rng-device \ + -bios u-boot-qemu.bin \ + -drive file=FreeBSD-12.1-RELEASE-arm-armv7-CUBIEBOARD2.img,if=none,id=drive0,format=raw \ + -device ich9-ahci,id=ahci -device ide-drive,drive=drive0,bus=ahci.0 + +Results: +.... +Mounting local filesystems:. + +Thread 4 "CPU 1/TCG" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7fffcedfe700 (LWP 53608)] +0x00005555558d9332 in helper_gvec_eq16 (d=0x5555566748d8, a=0x5555566748e0, b=0x5555566748d0, desc=0) at /usr/src/debug/qemu-4.1.1-1.fc31.x86_64/accel/tcg/tcg-runtime-gvec.c:948 +948 DO_CMP2(16) + +Tested different versions of qemu. qemu-3.0.1 worked, but qemu-3.1.1 failed with the same error. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1865188 b/results/classifier/deepseek-2-tmp/output/mistranslation/1865188 new file mode 100644 index 000000000..bfa375453 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1865188 @@ -0,0 +1,12 @@ + +Switching from the monitor to the emulated machine with a French keyboard (AZERTY) + +Hi, +I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french AZERTY. + +sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr -boot d -drive if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom ../../distri/11iv1/'HP-UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS _Install&Recovery_B6821-10046.iso' -net nic,model=tulip -net tap + +When I want to use the monitor (to change cdrom during the hp-ux installation process), the characters I type are misinterpreted. For example, I enter "2" at hp-ux prompt, I see : "412691;82;22". Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and Ctrl+Alt+2. + +I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options -alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal than hp-ux. Nothing works. +Best regards. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1866577 b/results/classifier/deepseek-2-tmp/output/mistranslation/1866577 new file mode 100644 index 000000000..e239cedf7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1866577 @@ -0,0 +1,14 @@ + +powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with Reply contains invalid hex digit 79 + +I am using powerpc-none-eabi-gdb with qemu 4.2, but it comes with +the following error: + +undefinedC:\CI-Tools\msys64\powerpc-none-eabi\usr\local\bin\powerpc-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. + +```Not implemented stop reason (assuming exception): undefined``` +The target architecture is assumed to be powerpc:603 + +``` +Reply contains invalid hex digit 79 +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1869073 b/results/classifier/deepseek-2-tmp/output/mistranslation/1869073 new file mode 100644 index 000000000..91fc5f190 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1869073 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/1869782 b/results/classifier/deepseek-2-tmp/output/mistranslation/1869782 new file mode 100644 index 000000000..5399f3bce --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1869782 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/1870477 b/results/classifier/deepseek-2-tmp/output/mistranslation/1870477 new file mode 100644 index 000000000..b7508a659 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1870477 @@ -0,0 +1,34 @@ + +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/deepseek-2-tmp/output/mistranslation/1872644 b/results/classifier/deepseek-2-tmp/output/mistranslation/1872644 new file mode 100644 index 000000000..a82ab16b9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1872644 @@ -0,0 +1,37 @@ + +MacOS host qemu-system-x86_64 -cpu host not working + +MacOS: 10.15.4 +uname -a: Linux door 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +I am using qemu on mac host, with ubuntu client. + +I used to have "-cpu host" in my qemu command as follow:- + +qemu-system-x86_64 \ +-no-user-config \ +-nodefaults \ +-name u64d01 \ +-show-cursor \ +-M q35,accel=hvf,usb=off,vmport=off \ +-cpu host \ +-m 8192M \ +-smp 4 \ +-rtc base=utc,clock=host \ +-device virtio-blk-pci,drive=ssd1 \ +-drive id=ssd1,file=/Users/js/code/vm/qemu/u64d01.qcow2,if=none,format=qcow2 \ +-device virtio-net-pci,netdev=nic1,mac=52:54:98:76:54:33 \ +-netdev user,id=nic1,ipv4=on,ipv6=on,hostname=u64d01,hostfwd=tcp::2222-:22 \ +-device virtio-tablet-pci \ +-device virtio-vga \ +-device ich9-intel-hda,id=snd,msi=on \ +-device hda-output,id=snd-codec0,bus=snd.0,cad=0,audiodev=snd0 \ +-audiodev coreaudio,id=snd0 + +Base on log of one of the vm, it was definitely working on 2020-01-17(base on journal inside vm), with qemu 4.2.0, which I installed with brew. + +The only way to make it work is to remove "-cpu host". + +Already tried with 4.1.1, 4.2 and 5.0rc2. Same result. + +To reproduce, try above with a Ubuntu 18.04 installation cd. Client will crash during kernel loading. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1874888 b/results/classifier/deepseek-2-tmp/output/mistranslation/1874888 new file mode 100644 index 000000000..2f97d0923 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1874888 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/1875702 b/results/classifier/deepseek-2-tmp/output/mistranslation/1875702 new file mode 100644 index 000000000..b29ee7b07 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1875702 @@ -0,0 +1,8 @@ + +madvise reports success, but doesn't implement WIPEONFORK. + +The implementation of madvise (linux-user/syscall.c:11331, tag v5.0.0-rc4) always returns zero (i.e. success). However, an application requesting (at least) MADV_WIPEONFORK may need to know whether the call was actually successful. If not (because the kernel doesn't support WIPEONFORK) then it will need to take other measures to provide fork-safety (such as drawing entropy from the kernel in every case). But, if the application believes that WIPEONFORK is supported (because madvise returned zero), but it actually isn't (as in qemu), then it may forego those protections on the assumption that WIPEONFORK will provide fork-safety. + +Roughly, the comment in qemu that says "This is a hint, so ignoring and returning success is ok." is no longer accurate in the presence of MADV_WIPEONFORK. + +(This is not purely academic: BoringSSL is planning on acting in this way. We found the qemu behaviour in pre-release testing and are planning on making an madvise call with advice=-1 first to test whether unknown advice values actually produce EINVAL.) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1877136 b/results/classifier/deepseek-2-tmp/output/mistranslation/1877136 new file mode 100644 index 000000000..ba74eac3b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1877136 @@ -0,0 +1,57 @@ + +Qemu GDB Arm core registers XML description not valid for M-profile + +When trying to debug an armv7-m binary running on Qemu, GDB makes some mistakes due to mistakenly believing the target is not M-profile. + +One observable is that backtraces over signal handlers are not handled correctly -- since the special M-profile EXC_RETURN value is not recognised. That happens because GDB doesn't think the target is M-profile. + +This happens because GDB sees a reported feature set from the Qemu remote connection that includes the feature `org.gnu.gdb.arm.core`. + +As described in the GDB online docs, for "M-profile targets (e.g. Cortex-M3), the ‘org.gnu.gdb.arm.core’ feature is replaced by ‘org.gnu.gdb.arm.m-profile’" +https://sourceware.org/gdb/current/onlinedocs/gdb/ARM-Features.html + +From a scan of the Qemu source code on commit ea1329bb3a8d5cd25b70e3dbf73e7ded4d5ad756 it seems that when emulating an arm core it uses `arm-core.xml` unconditionally for `CPUClass->gdb_core_xml_file`, and that means the only feature provided is `org.gnu.gdb.arm.core`. + +Note that even though there is a command to set the architecture in GDB, setting the target architecture to an M-profile core is still not a valid workaround. +This is because the target description overrides everything in setting the `is_m` attribute within GDB. + +Reproduction of the observable: +Using the examples here https://git.linaro.org/people/peter.maydell/m-profile-tests.git/tree/ . +Build the examples, and run +``` +qemu-system-arm -s -S -no-reboot -M lm3s6965evb -m 16 -serial stdio -display none -net nic -net user,restrict=on -d guest_errors,unimp -kernel test3-kern.bin +``` + +Then in a GDB session +``` +vshcmd: > arm-none-eabi-gdb -q +(gdb) +vshcmd: > file test3-kern.elf +Reading symbols from test3-kern.elf... +(gdb) +vshcmd: > target remote localhost:1234 +Remote debugging using localhost:1234 +_start () at init-m.S:53 +53 mov r0, #0 +(gdb) +vshcmd: > show architecture +The target architecture is set automatically (currently armv7) +(gdb) +vshcmd: > break svc +Breakpoint 1 at 0x6fc: svc. (2 locations) +(gdb) +vshcmd: > cont +Continuing. + +Breakpoint 1, svc () at test3.c:16 +16 int test = SEQ(); +(gdb) +vshcmd: > bt +#0 svc () at test3.c:16 +#1 0xfffffff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) +vshcmd: > print/x $lr +$1 = 0xfffffff9 +(gdb) +``` \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1877706 b/results/classifier/deepseek-2-tmp/output/mistranslation/1877706 new file mode 100644 index 000000000..f651f7acc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1877706 @@ -0,0 +1,25 @@ + + [Feature request] qemu does not support for Octeon MIPS64 on X86 + +Description of problem: + +I use mips64-octeon-linux-gnu-gcc cross toolchain on X86,and generate binary file. + +> mips64-octeon-linux-gnu-gcc hello.c -static +> file a.out +> a.out: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, not stripped + +I execute it with mips64-linux-user mode in qemu, it is invalid. + +> ./qemu-5.0.0/mips64-linux-user/qemu-mips64 a.out +> a.out: Invalid ELF image for this architecture + +when I choose mips-linux-user mode, it regards as illegal instruction. + +> ./qemu-5.0.0/mips-linux-user/qemu-mips a.out +> qemu: uncaught target signal 4 (Illegal instruction) - core dumped +> Illegal instruction (core dumped) + +I would like to know, is this due to my problem or does qemu not support Octeon MIPS64 on X86? + +if qemu has supported Octeon MIPS64 on X86, how can I emulate it. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1877794 b/results/classifier/deepseek-2-tmp/output/mistranslation/1877794 new file mode 100644 index 000000000..6206662fc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1877794 @@ -0,0 +1,4 @@ + +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/deepseek-2-tmp/output/mistranslation/1879587 b/results/classifier/deepseek-2-tmp/output/mistranslation/1879587 new file mode 100644 index 000000000..05b82f8ad --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1879587 @@ -0,0 +1,21 @@ + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1879955 b/results/classifier/deepseek-2-tmp/output/mistranslation/1879955 new file mode 100644 index 000000000..1bd265220 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1879955 @@ -0,0 +1,24 @@ + +target/i386/seg_helper.c: 16-bit TSS struct format wrong? + +In target/i386/seg_helper.c:switch_tss_ra() we have the following code to load registers from a 16-bit TSS struct: + + /* 16 bit */ + new_cr3 = 0; + new_eip = cpu_lduw_kernel_ra(env, tss_base + 0x0e, retaddr); + new_eflags = cpu_lduw_kernel_ra(env, tss_base + 0x10, retaddr); + for (i = 0; i < 8; i++) { + new_regs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x12 + i * 2), + retaddr) | 0xffff0000; + } + for (i = 0; i < 4; i++) { + new_segs[i] = cpu_lduw_kernel_ra(env, tss_base + (0x22 + i * 4), + retaddr); + } + new_ldt = cpu_lduw_kernel_ra(env, tss_base + 0x2a, retaddr); + +This doesn't match up with the structure described here: https://www.sandpile.org/x86/tss.htm -- which has only 2-byte slots for the segment registers. It also makes the 3rd segreg use the same offset as the LDTR, which is very suspicious. I suspect that this should use "(0x22 + i * 2)". + +The code later in the same function that stores the segment registers to the struct has the same bug. + +Found by code inspection; I don't have a test case to check this. As a non-x86-expert I'm just going to file a bug report in case somebody else feels like confirming the issue and sending a patch. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1880225 b/results/classifier/deepseek-2-tmp/output/mistranslation/1880225 new file mode 100644 index 000000000..7e77f6dd4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1880225 @@ -0,0 +1,138 @@ + +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/deepseek-2-tmp/output/mistranslation/1880287 b/results/classifier/deepseek-2-tmp/output/mistranslation/1880287 new file mode 100644 index 000000000..0a3f12d57 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1880287 @@ -0,0 +1,12 @@ + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1880722 b/results/classifier/deepseek-2-tmp/output/mistranslation/1880722 new file mode 100644 index 000000000..30179753b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1880722 @@ -0,0 +1,15 @@ + +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/deepseek-2-tmp/output/mistranslation/1881004 b/results/classifier/deepseek-2-tmp/output/mistranslation/1881004 new file mode 100644 index 000000000..3da0caeb0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1881004 @@ -0,0 +1,51 @@ + +fpu/softfloat.c: error: bitwise negation of a boolean expression + +Last time I built QEMU was on commit d5c75ec500d96f1d93447f990cd5a4ef5ba27fae, +I just pulled to fea8f3ed739536fca027cf56af7f5576f37ef9cd and now get: + + CC lm32-softmmu/fpu/softfloat.o +fpu/softfloat.c:3365:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3423:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~ ( ( (uint64_t) ( absZ1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3483:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + absZ0 &= ~(((uint64_t)(absZ1<<1) == 0) & roundNearestEven); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3606:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x40 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3760:13: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig &= ~ ( ( ( roundBits ^ 0x200 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:3987:21: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4003:22: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig0 &= ~ ( ( (uint64_t) ( zSig1<<1 ) == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +fpu/softfloat.c:4273:18: error: bitwise negation of a boolean expression; did you mean logical negation? [-Werror,-Wbool-operation] + zSig1 &= ~ ( ( zSig2 + zSig2 == 0 ) & roundNearestEven ); + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ! +8 errors generated. + +$ clang -v +clang version 10.0.0-4ubuntu1 +Target: aarch64-unknown-linux-gnu + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04 LTS +Release: 20.04 +Codename: focal \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1881506 b/results/classifier/deepseek-2-tmp/output/mistranslation/1881506 new file mode 100644 index 000000000..2c71872c4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1881506 @@ -0,0 +1,6 @@ + +TCG doesn't support a lot of features that should be supported + +This is quite odd, and I'm not sure about how to get around it. I'm writing an OS in Rust and require APIC support. When I boot my kernel with qemu-system-x86_64, however, it dumps out a [lot] of warnings; it claims that TCG doesn't support FMA, X2APIC, AVX, F16C, AVX2, RDSEED, SHA-NI, FXSR-OPT, misalignsse, 3dnowprefetch, osvw, topoext, perfctr-core, clzero, xsaveerptr, ibpb, nrip-save, xsavec, and xsaves, but prints these warnings over 80 times before finally doing what I told it to do. Running QEMU 5.0.0 (unknown commit hash), as follows: +qemu-system-x86_64 -drive format=raw,file=target\x86_64-kernel-none\debug\bootimage-kernel.bin -serial stdio -no-reboot -hdb disk.img -s -m 4G -usb -rtc base=utc,clock=host -cpu EPYC-v3,+acpi,+apic,+rdrand,+rdseed,+sse,+sse2,+sse4.1,+sse4.2,+sse4a,+ssse3,+syscall,+x2apic -smp cpus=8 -soundhw all +I would run using HAXM, but my kernel requires RDRAND, and QEMU does not, to my knowledge, automatically support RDRAND (and I don't know how to enable it). \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1881552 b/results/classifier/deepseek-2-tmp/output/mistranslation/1881552 new file mode 100644 index 000000000..6c9478b9a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1881552 @@ -0,0 +1,54 @@ + +potential AArch64 ABI bug wrt handling of 128-bit bit-fields + +After upgrading to Ubuntu 20.04 LTS, GCC 9.3 displays a lot of notes: + +hw/block/pflash_cfi01.c: In function ‘pflash_mem_read_with_attrs’: +hw/block/pflash_cfi01.c:663:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 663 | static MemTxResult pflash_mem_read_with_attrs(void *opaque, hwaddr addr, uint64_t *value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/block/pflash_cfi01.c: In function ‘pflash_mem_write_with_attrs’: +hw/block/pflash_cfi01.c:677:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 677 | static MemTxResult pflash_mem_write_with_attrs(void *opaque, hwaddr addr, uint64_t value, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_dma_mem_valid’: +hw/nvram/fw_cfg.c:475:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 475 | static bool fw_cfg_dma_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_data_mem_valid’: +hw/nvram/fw_cfg.c:483:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 483 | static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_ctl_mem_valid’: +hw/nvram/fw_cfg.c:501:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 501 | static bool fw_cfg_ctl_mem_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~~~~ +hw/nvram/fw_cfg.c: In function ‘fw_cfg_comb_valid’: +hw/nvram/fw_cfg.c:521:13: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 521 | static bool fw_cfg_comb_valid(void *opaque, hwaddr addr, + | ^~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_do_hyp_read’: +hw/intc/arm_gic.c:1996:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1996 | static MemTxResult gic_do_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_thiscpu_hyp_read’: +hw/intc/arm_gic.c:1979:20: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 1979 | static MemTxResult gic_thiscpu_hyp_read(void *opaque, hwaddr addr, uint64_t *data, + | ^~~~~~~~~~~~~~~~~~~~ +hw/intc/arm_gic.c: In function ‘gic_get_current_pending_irq’: +hw/intc/arm_gic.c:419:17: note: parameter passing for argument of type ‘MemTxAttrs’ {aka ‘struct MemTxAttrs’} changed in GCC 9.1 + 419 | static uint16_t gic_get_current_pending_irq(GICState *s, int cpu, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This seems related to: +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 +https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=c590597c45 + + This is pretty unlikely in real code, but similar to Arm, the AArch64 + ABI has a bug with the handling of 128-bit bit-fields, where if the + bit-field dominates the overall alignment the back-end code may end up + passing the argument correctly. This is a regression that started in + gcc-6 when the ABI support code was updated to support overaligned + types. The fix is very similar in concept to the Arm fix. 128-bit + bit-fields are fortunately extremely rare, so I'd be very surprised if + anyone has been bitten by this. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1882123 b/results/classifier/deepseek-2-tmp/output/mistranslation/1882123 new file mode 100644 index 000000000..0f4ff6b8a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1882123 @@ -0,0 +1,59 @@ + +ARM cpu emulation regression on QEMU 4.2.0 + +[*] Summary + +Latest QEMU has an ARM CPU emulation regression. +Regression is reproducible by building any C# project with .NET Core SDK 3.1.300 on Debian 10 armhf. + +Affected releases: QEMU 4.2.0, 5.0.0 +Not affected releases: QEMU 4.1.0, QEMU 4.1.1 + + +[*] Detail + +qemu-system-arm fails to run .NET Core SDK 3.1 on Debian 10 armhf. + +I occasionally test my C# projects on the virtual armhf/arm64 system emulated by QEMU. +MSBuild, a build engine of the .NET Core SDK, crashes on QEMU 4.2.0 or later. +The crash only happens when MSBuild tries to do any JIT compiling (dotnet build / dotnet test). + +I attached MSBuild crash logs. MSBuild always crashes with SEHException, which means it tried to call C binary from .NET binary. + +The issue affects QEMU 4.2.0 and 5.0.0. +QEMU 4.1.0, 4.1.1, and real Raspberry Pi 2 machine is not affected by this issue, and .NET Core SDK works completely fine. +Thus, I think an ARM CPU regression happened between QEMU 4.1.1 ~ QEMU 4.2.0. + + +[*] Environment + +[Host OS] +Distribution: Linux Mint 19.3 amd64 +CPU: AMD Ryzen 5 3600 +Kernel: Ubuntu 5.3.0-51-generic + +[QEMU Arguments] +qemu-system-arm \ + -smp 3 -M virt -m 4096 \ + -kernel vmlinuz-4.19.0-9-armmp-lpae \ + -initrd initrd.img-4.19.0-9-armmp-lpae \ + -append "root=/dev/vda2" \ + -drive if=none,file=debian_arm.qcow2,format=qcow2,id=hd \ + -device virtio-blk-device,drive=hd \ + -netdev user,id=mynet,hostfwd=tcp::<PORT>-:22 \ + -device virtio-net-device,netdev=mynet \ + -device virtio-rng-device\ + +[QEMU Guest OS] +Distribution: Debian 10 Buster armhf +Kernel: Debian 4.19.0-9-armmp-lpae +.NET Core SDK: 3.1.300 + +[Raspberry Pi 2] +Distribution: Raspberry Pi OS Buster armhf (20200527) + +[Tested C# Projects] +This is a list of C# projects I have tested on QEMU and RPI2. +- https://github.com/ied206/Joveler.DynLoader +- https://github.com/ied206/Joveler.Compression +- https://github.com/ied206/ManagedWimLib \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1883268 b/results/classifier/deepseek-2-tmp/output/mistranslation/1883268 new file mode 100644 index 000000000..77025fecb --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1883268 @@ -0,0 +1,38 @@ + +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/deepseek-2-tmp/output/mistranslation/1883784 b/results/classifier/deepseek-2-tmp/output/mistranslation/1883784 new file mode 100644 index 000000000..74178a0dd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1883784 @@ -0,0 +1,10 @@ + +[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/deepseek-2-tmp/output/mistranslation/1883984 b/results/classifier/deepseek-2-tmp/output/mistranslation/1883984 new file mode 100644 index 000000000..1c5715670 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1883984 @@ -0,0 +1,27 @@ + +QEMU S/390x sqxbr (128-bit IEEE 754 square root) crashes qemu-system-s390x + +In porting software to guest Ubuntu 18.04 and 20.04 VMs for S/390x, I discovered +that some of my own numerical programs, and also a GNU configure script for at +least one package with CC=clang, would cause an instant crash of the VM, sometimes +also destroying recently opened files, and producing long strings of NUL characters +in /var/log/syslog in the S/390 guest O/S. + +Further detective work narrowed the cause of the crash down to a single IBM S/390 +instruction: sqxbr (128-bit IEEE 754 square root). Here is a one-line program +that when compiled and run on a VM hosted on QEMUcc emulator version 4.2.0 +(Debian 1:4.2-3ubuntu6.1) [hosted on Ubuntu 20.04 on a Dell Precision 7920 +workstation with an Intel Xeon Platinum 8253 CPU], and also on QEMU emulator +version 5.0.0, reproducibly produces a VM crash under qemu-system-s390x. + +% cat bug-sqrtl-one-line.c +int main(void) { volatile long double x, r; x = 4.0L; __asm__ __volatile__("sqxbr %0, %1" : "=f" (r) : "f" (x)); return (0);} + +% cc bug-sqrtl-one-line.c && ./a.out +Segmentation fault (core dumped) + +The problem code may be the function float128_sqrt() defined in qemu-5.0.0/fpu/softfloat.c +starting at line 7619. I have NOT attempted to run the qemu-system-s390x executable +under a debugger. However, I observe that S/390 is the only CPU family that I know of, +except possibly for a Fujitsu SPARC-64, that has a 128-bit square root in hardware. +Thus, this instruction bug may not have been seen before. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1884719 b/results/classifier/deepseek-2-tmp/output/mistranslation/1884719 new file mode 100644 index 000000000..3798d87ef --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1884719 @@ -0,0 +1,133 @@ + +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/deepseek-2-tmp/output/mistranslation/1888303 b/results/classifier/deepseek-2-tmp/output/mistranslation/1888303 new file mode 100644 index 000000000..559d7a1c2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1888303 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1888918 b/results/classifier/deepseek-2-tmp/output/mistranslation/1888918 new file mode 100644 index 000000000..c1ed5dbe9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1888918 @@ -0,0 +1,74 @@ + +qemu-system-ppc: Floating point instructions do not properly generate the SPE/Embedded Floating-Point Unavailable interrupt + +When emulating certain floating point instructions or vector instructions on PowerPC machines, QEMU does not properly generate the SPE/Embedded Floating-Point Unavailable interrupt. + +As described in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0, available at https://www.nxp.com/docs/en/reference-manual/SPEPEM.pdf: + +> An SPE/embedded floating-point unavailable exception occurs on an attempt to execute any of the +> following instructions and MSR[SPV] is not set: +> * SPE instruction (except brinc) +> * An embedded scalar double-precision instruction +> * A vector single-precision floating-point instructions +> It is not used by embedded scalar single-precision floating-point instructions + +This behavior was partially reported in Bug #1611394, however the issue is larger than what is described in that bug. As mentioned in that bug, some single-precision instructions generate the exception (while they should not), which is incorrect but does not typically produce an incorrect output. What is more of an issue is that several double-precision and vector instructions do not generate the exception (while they should), and this break support for lazy FPU/vector context switching in Linux (for example). + +The upper 32-bit of the double-precision/vector registers (which are in fact hidden in the general purpose registers) is not properly saved/restored, and this causes arithmetic errors. This was observed very frequently on a commercial project that does a lot of double-precision computations. The application works perfectly fine on an MPC8548 CPU, but fails often with QEMU. + +The issue can be reproduced using the attached Linux program "spe-bug.c". This program properly prints the number 42 (as the result of some very simple double-precision computation) on real PowerPC hardware, but prints an incorrect result (typically 0) on QEMU. + +This issue was first discovered in an older version of QEMU, but is also reproduced in the latest: + +# git rev-parse HEAD +7adfbea8fd1efce36019a0c2f198ca73be9d3f18 +# ppc-softmmu/qemu-system-ppc --version +QEMU emulator version 5.0.91 (v5.1.0-rc1-28-g7adfbea8fd-dirty) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +Upon further analysis a total of 39 instructions are misbehaving: + +efsabs: raised: 1, expected: 0 +efsnabs: raised: 1, expected: 0 +efsneg: raised: 1, expected: 0 +efdcfs: raised: 0, expected: 1 +efdcfsf: raised: 0, expected: 1 +efdcfsi: raised: 0, expected: 1 +efdcfuf: raised: 0, expected: 1 +efdcfui: raised: 0, expected: 1 +efdctsf: raised: 0, expected: 1 +efdctsi: raised: 0, expected: 1 +efdctsiz: raised: 0, expected: 1 +efdctuf: raised: 0, expected: 1 +efdctui: raised: 0, expected: 1 +efdctuiz: raised: 0, expected: 1 +efscfd: raised: 0, expected: 1 +evfscfsf: raised: 0, expected: 1 +evfscfsi: raised: 0, expected: 1 +evfscfuf: raised: 0, expected: 1 +evfscfui: raised: 0, expected: 1 +evfsctsf: raised: 0, expected: 1 +evfsctsi: raised: 0, expected: 1 +evfsctsiz: raised: 0, expected: 1 +evfsctuf: raised: 0, expected: 1 +evfsctui: raised: 0, expected: 1 +evfsctuiz: raised: 0, expected: 1 +brinc: raised: 0, expected: 1 +efsadd: raised: 1, expected: 0 +efsdiv: raised: 1, expected: 0 +efsmul: raised: 1, expected: 0 +efssub: raised: 1, expected: 0 +evsplatfi: raised: 0, expected: 1 +evsplati: raised: 0, expected: 1 +efscmpeq: raised: 1, expected: 0 +efscmpgt: raised: 1, expected: 0 +efscmplt: raised: 1, expected: 0 +efststeq: raised: 1, expected: 0 +efststgt: raised: 1, expected: 0 +efststlt: raised: 1, expected: 0 +evsel: raised: 0, expected: 1 + +When "raised" is 0 and "expected" is 1, this means that the SPE/Embedded Floating-Point Unavailable interrupt was not generated while it should have. +When "raised" is 1 and "expected" is 0, this means that the SPE/Embedded Floating-Point Unavailable interrupt was generated while it should not have (Bug #1611394). + +A comprehensive program testing all the instructions listed in the Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0 is posted in the comments of this ticket, and can be used to reproduce the issue, and validate the future fix. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1889288 b/results/classifier/deepseek-2-tmp/output/mistranslation/1889288 new file mode 100644 index 000000000..6647c0d16 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1889288 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/1893003 b/results/classifier/deepseek-2-tmp/output/mistranslation/1893003 new file mode 100644 index 000000000..487d34489 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1893003 @@ -0,0 +1,39 @@ + +qemu linux-user doesn't translate host/target data for iovec I/O + +When using iovec I/O functions (like `readv`), no data translation happens. I'm hitting this issue with libevent upon constructing a bufferevent over an inotify descriptor, and then building for either ppc64 or s390x (both big-endian) on x86_64 (little-endian) and running resulting code with qemu-ppc64 or qemu-s390x on Gentoo using latest QEMU version available (5.0.0-r2). + +The code in question is in https://github.com/transmission/transmission/blob/master/libtransmission/watchdir-inotify.c (`tr_watchdir_inotify_new`, `tr_watchdir_inotify_on_event`). + +While `read` syscall is handled properly, `readv` (which libevent is using in my case) doesn't have any logic to call `host_to_target_data_inotify` or any other translation function, leaving inotify data unchanged (with values in little-endian), which then leads to unit test failures. Quoting `do_syscall1` implementation bits for the reference: + +---8<---begin--- + case TARGET_NR_read: + if (arg2 == 0 && arg3 == 0) { + return get_errno(safe_read(arg1, 0, 0)); + } else { + if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0))) + return -TARGET_EFAULT; + ret = get_errno(safe_read(arg1, p, arg3)); + if (ret >= 0 && + fd_trans_host_to_target_data(arg1)) { + ret = fd_trans_host_to_target_data(arg1)(p, ret); + } + unlock_user(p, arg2, ret); + } + return ret; +... + case TARGET_NR_readv: + { + struct iovec *vec = lock_iovec(VERIFY_WRITE, arg2, arg3, 0); + if (vec != NULL) { + ret = get_errno(safe_readv(arg1, vec, arg3)); + unlock_iovec(vec, arg2, arg3, 1); + } else { + ret = -host_to_target_errno(errno); + } + } + return ret; +---8<---end--- + +To reiterate, the issue is not only with `readv` but with other iovec functions as well. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1893667 b/results/classifier/deepseek-2-tmp/output/mistranslation/1893667 new file mode 100644 index 000000000..2d7d4e996 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1893667 @@ -0,0 +1,30 @@ + +Btrfs commands don't work when using user-space emulation of other architectures + +Description of problem: +When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. + +This is especially important for being able to do cross-arch image builds. + +How reproducible: +Always (on Fedora 33 with qemu-5.1.0-2.fc33) + +Steps to Reproduce: + +$ sudo dnf install mock qemu-user-static wget +$ sudo usermod -a -G mock $USER +$ newgrp mock +$ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux +$ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' + + +Actual results: +Fails with errors like "ERROR: cannot create subvolume: Function not implemented" + +Expected results: +Succeeds and creates subvolumes properly. + +Additional info: +There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... + +https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1894029 b/results/classifier/deepseek-2-tmp/output/mistranslation/1894029 new file mode 100644 index 000000000..a17150e8b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1894029 @@ -0,0 +1,40 @@ + +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/deepseek-2-tmp/output/mistranslation/1896 b/results/classifier/deepseek-2-tmp/output/mistranslation/1896 new file mode 100644 index 000000000..fd6e6fd00 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1896 @@ -0,0 +1,55 @@ + +Use `qemu_exit()` function instead of `exit()` +Additional information: +I just saw the similar refactoring for the GDB part of QEMU and thought it might be useful in more general case too: https://lore.kernel.org/qemu-devel/20230907112640.292104-1-chigot@adacore.com/T/#m540552946cfa960b34c4d76d2302324f5de8627f + +``` +$ rg "exit\(0" -t c -l +gdbstub/gdbstub.c +qemu-edid.c +subprojects/libvhost-user/libvhost-user.c +semihosting/arm-compat-semi.c +softmmu/async-teardown.c +softmmu/device_tree.c +softmmu/vl.c +softmmu/runstate.c +os-posix.c +dtc/util.c +dtc/dtc.c +dtc/tests/dumptrees.c +qemu-keymap.c +qemu-io.c +contrib/ivshmem-server/main.c +contrib/rdmacm-mux/main.c +tests/qtest/vhost-user-blk-test.c +tests/qtest/fuzz/fuzz.c +tests/qtest/fuzz/generic_fuzz.c +tests/unit/test-seccomp.c +tests/unit/test-rcu-list.c +tests/unit/rcutorture.c +tests/bench/qht-bench.c +tests/bench/atomic64-bench.c +tests/bench/atomic_add-bench.c +tests/unit/test-iov.c +tests/tcg/multiarch/linux/linux-test.c +tests/tcg/aarch64/mte-3.c +tests/tcg/aarch64/pauth-2.c +tests/tcg/aarch64/mte-5.c +tests/tcg/aarch64/mte-6.c +tests/tcg/aarch64/mte-2.c +tests/tcg/cris/libc/check_glibc_kernelversion.c +tests/tcg/cris/libc/check_lz.c +tests/tcg/s390x/signals-s390x.c +tests/tcg/i386/hello-i386.c +tests/tcg/cris/bare/sys.c +tests/tcg/ppc64/mtfsf.c +qemu-nbd.c +net/net.c +hw/nvram/eeprom93xx.c +hw/arm/allwinner-r40.c +hw/rdma/rdma_backend.c +hw/watchdog/watchdog.c +trace/control.c +hw/pci/pci.c +hw/misc/sifive_test.c +``` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1896561 b/results/classifier/deepseek-2-tmp/output/mistranslation/1896561 new file mode 100644 index 000000000..4da677fe0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1896561 @@ -0,0 +1,27 @@ + +EFI GOP Mode 1366x768 + +When using the EFI firmware from https://www.kraxel.org/repos/jenkins/edk2/ (https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20200919.1453.g7faece6985.noarch.rpm) (OVMF-pure-efi.fd and OVMF_VARS-pure-efi.fd) then using the GOP, setting the mode to 1366x768, QEMU uses a width of 1360 instead. + +I am using QEMU for windows (https://qemu.weilnetz.de/) on a Windows 10 machine. + +To verify, while in the EFI firmware loaded code (within BOOTx64.EFI) and before ExitBootServices(), I choose the 1360x768 mode. I then took notice of where the host window was and how many pixels it occupied. I then reset the emulation (without quitting) and chose the 1366x768 mode. QEMU set the host window to the exact same width as the 1360 mode. i.e.: The same exact pixels where shown in the host background. The window did not expand the extra 6 pixels. + +I allowed the firmware to run its course to my test environment when using mode 1366x768, all pixels are 6 pixels off to the right. i.e.: 6 pixels down the Frame Buffer. If my test environment changes its HORZ WIDTH and PIXELS PER SCANLINE to 1360 while using this (1366x768) mode, the display is correct. + +This told me that it could be a few things. +1) Since most (I didn't check them all) of the other modes have the width value's bits 2:0 clear, mode 1366x768 is the only mode the EDK2 firmware has with a width where bits 2:0 are not zero. Could EDK2 or QEMU (which for the Windows version may use SDL2 so it must be considered here) be clearing these bits? The value of 1366 when clearing bits 2:0 is 1360. + +2) Could there be a typo in the code EDK2 where the width should have been 1366? +(I went looking at both QEMU (for Windows) and EDK2 and after looking at many lines of code, I could not find anywhere where this might happen. + +By the way, in /ui/sdl2-2d.c (QEMU Windows version only?), there is a typo in a comment, missing the second 'e': + +Line 156: * the native ones. Thes are the ones I have tested. + +3) Could EDK2 be sending 1360 instead of 1366? +4) Could QEMU (passing it on to SDL2 in SDL_SetWindowSize()?) be destroying the value (bottom three bits)? + +Anyway, using the latest version of the EDK2 from the URL listed above, choosing the 1366x768 mode, does not set QEMU (for Windows) to 1366 pixels in width. + +Ben \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1897783 b/results/classifier/deepseek-2-tmp/output/mistranslation/1897783 new file mode 100644 index 000000000..b995ff90c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1897783 @@ -0,0 +1,26 @@ + +avocado tests not running on aarch64 host + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +$ make check-venv + VENV /home/phil/qemu/build/tests/venv + PIP /home/phil/qemu/tests/requirements.txt + ERROR: Command errored out with exit status 1: + command: /home/phil/qemu/build/tests/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"'; __file__='"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ic25ctcg + cwd: /tmp/pip-install-w1h2bh4a/pycdlib/ + Complete output (6 lines): + usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] + or: setup.py --help [cmd1 cmd2 ...] + or: setup.py --help-commands + or: setup.py cmd --help + + error: invalid command 'bdist_wheel' + ---------------------------------------- + ERROR: Failed building wheel for pycdlib +$ \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1898011 b/results/classifier/deepseek-2-tmp/output/mistranslation/1898011 new file mode 100644 index 000000000..352a9dc40 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1898011 @@ -0,0 +1,31 @@ + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM + +Run this program: + +#include <sys/mman.h> +#include <stdio.h> +int main() { + for (int i = 30; i <= 44; i++) { + fprintf(stderr, "trying 2**%d\n", i); + mmap((void*)0x600000000000,1ULL << i, + PROT_NONE, + MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0); + } +} + +(tried qemu-x86_64 and qemu-aarch64, 4.2.1 and trunk/5.1.50) + +On each iteration qemu will consume 2x more physical RAM, +e.g. when mapping 2^42 it will have RSS of 16Gb. + +On normal linux it works w/o consuming much RAM, due to MAP_NORESERVE. + +Also: qemu -strace prints 0 instead of the correct size starting from size=2^32 +and prints -2147483648 for size=2^31. + +mmap(0x0000600000000000,1073741824,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,-2147483648,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,0,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1898215 b/results/classifier/deepseek-2-tmp/output/mistranslation/1898215 new file mode 100644 index 000000000..ae31eccdd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1898215 @@ -0,0 +1,42 @@ + +[git][archlinux]Build process is busted in spice-display.c + +Linux distribution: Archlinux. Crash log added is based on a build from scratch. + +Gcc version: 10.2.0 + +Configure options used: + +configure \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --extra-ldflags="$LDFLAGS" \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + --enable-slirp=system \ + --enable-xfsctl \ + --audio-drv-list="pa alsa sdl" + +Crash log: + +../ui/spice-display.c: In function 'interface_client_monitors_config': +../ui/spice-display.c:682:25: error: 'VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE' undeclared (first use in this function); did you mean 'VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS'? + 682 | if (mc->flags & VD_AGENT_CONFIG_MONITORS_FLAG_PHYSICAL_SIZE) { + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | VD_AGENT_CONFIG_MONITORS_FLAG_USE_POS +../ui/spice-display.c:682:25: note: each undeclared identifier is reported only once for each function it appears in +../ui/spice-display.c:683:13: error: unknown type name 'VDAgentMonitorMM' + 683 | VDAgentMonitorMM *mm = (void *)&mc->monitors[mc->num_of_monitors]; + | ^~~~~~~~~~~~~~~~ +../ui/spice-display.c:684:37: error: request for member 'width' in something not a structure or union + 684 | info.width_mm = mm[head].width; + | ^ +../ui/spice-display.c:685:38: error: request for member 'height' in something not a structure or union + 685 | info.height_mm = mm[head].height; + | ^ +make: *** [Makefile.ninja:2031: libcommon.fa.p/ui_spice-display.c.o] Error 1 +make: *** Waiting for unfinished jobs.... \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1898883 b/results/classifier/deepseek-2-tmp/output/mistranslation/1898883 new file mode 100644 index 000000000..7d9ee2db2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1898883 @@ -0,0 +1,10 @@ + +qemu-system-riscv64 failed to load binary kernel into memory + +QEMU Version: 5.1.0 +Compiled in Ubuntu 20.04 for riscv64, following the guide https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html. + +In qemu-system-riscv64, code at 0x80000000 will be executed by virtual CPU. +For example, using `qemu-system-riscv64 -nographic -machine virt -bios none -kernel vmlinux -S -s`, my homebrew kernel(ELF file) will load at 0x80000000. If I strip the kernel using `riscv64-linux-gnu-objcopy -O binary vmlinux Image`, qemu-system-riscv64 will not load the binary machine code into the riscv64 load address, but `-bios Image` will. + +In `qemu-system-aarch64` compiled by Ubuntu team, I can use `qemu-system-aarch64 -M raspi3 -kernel Image_aarch64 -S -s` to load a specific machine code binary into 0x80000. And the elf kernel can be loaded to that address, too. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1900779 b/results/classifier/deepseek-2-tmp/output/mistranslation/1900779 new file mode 100644 index 000000000..2ded3f03c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1900779 @@ -0,0 +1,44 @@ + +xp /16i on arm mixes DWords + +I was working with qemuand wanted to understag ATAG structure. +In Monitor mode I used xp /16i 0x100 and I got really confused. +with xp /16i 0x100: +At address 0x120 the DWords are 0x00000000, 0x00000004, 0x54410009, 0x74736574 +with xp /16x 0x100: +At address 0x120 the DWords are 0x54410001, 0x00000001, 0x00000001, 0x00000000 + +from my Terminal: + +(qemu) xp /16x 0x100 +0000000000000100: 0x00000005 0x54410001 0x00000001 0x00001000 +0000000000000110: 0x00000000 0x00000004 0x54410002 0x3c000000 +0000000000000120: 0x00000000 0x00000004 0x54410009 0x74736574 +0000000000000130: 0x00000000 0x00000000 0x00000000 0x00000000 +(qemu) xp /16i 0x100 +0x00000100: 00000005 andeq r0, r0, r5 +0x00000104: 54410001 strbpl r0, [r1], #-1 +0x00000108: 00000001 andeq r0, r0, r1 +0x0000010c: 00001000 andeq r1, r0, r0 +0x00000110: 00000000 andeq r0, r0, r0 +0x00000114: 00000004 andeq r0, r0, r4 +0x00000118: 54410002 strbpl r0, [r1], #-2 +0x0000011c: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x00000120: 54410001 strbpl r0, [r1], #-1 +0x00000124: 00000001 andeq r0, r0, r1 +0x00000128: 00001000 andeq r1, r0, r0 +0x0000012c: 00000000 andeq r0, r0, r0 +0x00000130: 00000004 andeq r0, r0, r4 +0x00000134: 54410002 strbpl r0, [r1], #-2 +0x00000138: 3c000000 .byte 0x00, 0x00, 0x00, 0x3c +0x0000013c: 00000000 andeq r0, r0, r0 +(increasing length only results in more 00000000 andeq r0, r0, r0 Lines) + +Version: +4.2.1Debian 1:4.2-3ubuntu6.6 +Commandline: +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./vmlinuz --append "test" +./vmlinuz is a x64 linux kernel. I didn't care about architecture because i just wanted to see ATAG structure. +I also tried +qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./overview.pdf --append "test" +same result. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1902451 b/results/classifier/deepseek-2-tmp/output/mistranslation/1902451 new file mode 100644 index 000000000..259811c71 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1902451 @@ -0,0 +1,22 @@ + +incorrect cpuid feature detection + +Hello, + +I am currently developing a x64 kernel and I wanted to check through cpuid if some features are available in the guest. When I try to enable cpu features like vmcb_clean or constant_tsc qemu is saying that my host doesn't support the requested features. However cat /proc/cpuinfo tells a different story: + +model name: AMD Ryzen 5 3500U +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme pti ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca + +I also checked it myself by running cpuid and check the bits as in the AMD Manual. Everything checks out but qemu still fails. + +QEMU version: QEMU emulator version 4.2.0 + +$ qemu-system-x86_64 -cpu host,+vmcb_clean,enforce -enable-kvm -drive format=raw,file=target/x86_64-os/debug/bootimage-my_kernel.bin -serial stdio -display none +qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.8000000AH:EDX.vmcb-clean [bit 5] +qemu-system-x86_64: Host doesn't support requested features + +or + +$ qemu-system-x86_64 -cpu host,+constant_tsc,enforce -enable-kvm -drive format=raw,file=target/x86_64-os/debug/bootimage-my_kernel.bin -serial stdio -display none +qemu-system-x86_64: Property '.constant_tsc' not found \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1904210 b/results/classifier/deepseek-2-tmp/output/mistranslation/1904210 new file mode 100644 index 000000000..1a11daa3e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1904210 @@ -0,0 +1,52 @@ + +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/deepseek-2-tmp/output/mistranslation/1905356 b/results/classifier/deepseek-2-tmp/output/mistranslation/1905356 new file mode 100644 index 000000000..b2798b026 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1905356 @@ -0,0 +1,13 @@ + +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/deepseek-2-tmp/output/mistranslation/1906193 b/results/classifier/deepseek-2-tmp/output/mistranslation/1906193 new file mode 100644 index 000000000..3ea808469 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1906193 @@ -0,0 +1,58 @@ + +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/deepseek-2-tmp/output/mistranslation/1906516 b/results/classifier/deepseek-2-tmp/output/mistranslation/1906516 new file mode 100644 index 000000000..676fd517e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1906516 @@ -0,0 +1,92 @@ + +[RISCV] sfence.vma need to end the translation block + +QEMU emulator version 5.0.0 + +sfence.vma will flush the tlb, so after this instruction, the translation block should be end. The following code will only work in single step mode: +``` +relocate: + li a0, OFFSET + + la t0, 1f + add t0, t0, a0 + csrw stvec, t0 + + la t0, early_pgtbl + srl t0, t0, PAGE_SHIFT + li t1, SATP_SV39 + or t0, t1, t0 + + csrw satp, t0 +1: + sfence.vma + la t0, trap_s + csrw stvec, t0 + ret +``` + +In this code, I want to relocate pc to virtual address with the OFFSET prefix, before writing to satp, pc run at physic address, stvec has been set a label 1 with a virtual prefix and virtual address has been mapping in early_pgtbl, after writing satp, there will throw a page fault, and pc will set to virtual address of label 1. + +The problem is that, in this situation, the translation block will not end after sfence.vma, and stvec will be set to trap_s, + +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000dc: 00a080b3 add ra,ra,a0 +0x00000000800000e0: 00007297 auipc t0,28672 # 0x800070e0 +0x00000000800000e4: f2028293 addi t0,t0,-224 +0x00000000800000e8: 00c2d293 srli t0,t0,12 +0x00000000800000ec: fff0031b addiw t1,zero,-1 +0x00000000800000f0: 03f31313 slli t1,t1,63 +0x00000000800000f4: 005362b3 or t0,t1,t0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero +0x0000000080000100: 00000297 auipc t0,0 # 0x80000100 +0x0000000080000104: 1c828293 addi t0,t0,456 +0x0000000080000108: 10529073 csrrw zero,stvec,t0 + +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +riscv_raise_exception: 12 +... +``` + +So, the program will crash, and the program will work in single step mode: +``` +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000f8: 18029073 csrrw zero,satp,t0 + +---------------- +IN: +Priv: 1; Virt: 0 +0x00000000800000fc: 12000073 sfence.vma zero,zero + +riscv_raise_exception: 12 +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff800000fc: 12000073 sfence.vma zero,zero + +---------------- +IN: +Priv: 1; Virt: 0 +0xffffffff80000100: 00000297 auipc t0,0 # 0xffffffff80000100 + +``` +The pc will set to label 1, instead of trap_s. + +I try to patch the code in fence.i in trans_rvi.inc.c to sfence.vma: +``` + tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn); + exit_tb(ctx); + ctx->base.is_jmp = DISAS_NORETURN; +``` +This codes can help to end the tranlate block, since I'm not a qemu guy, I'm not sure if this is a corret method. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1907969 b/results/classifier/deepseek-2-tmp/output/mistranslation/1907969 new file mode 100644 index 000000000..8dc2991ab --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1907969 @@ -0,0 +1,59 @@ + +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/deepseek-2-tmp/output/mistranslation/1908551 b/results/classifier/deepseek-2-tmp/output/mistranslation/1908551 new file mode 100644 index 000000000..a18ddc401 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1908551 @@ -0,0 +1,55 @@ + +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/deepseek-2-tmp/output/mistranslation/1908626 b/results/classifier/deepseek-2-tmp/output/mistranslation/1908626 new file mode 100644 index 000000000..30476f8aa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1908626 @@ -0,0 +1,66 @@ + +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/deepseek-2-tmp/output/mistranslation/1909823 b/results/classifier/deepseek-2-tmp/output/mistranslation/1909823 new file mode 100644 index 000000000..93d753b08 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1909823 @@ -0,0 +1,8 @@ + +RDPMC check on PCE is backwards + +At [this line](https://github.com/qemu/qemu/blob/75ee62ac606bfc9eb59310b9446df3434bf6e8c2/target/i386/tcg/misc_helper.c#L225) the check on CR4_PCE_MASK is backwards: it's raising an exception if the flag is set (and CPL != 0) rather than if the flag is clear. + +It's low priority at the moment because the instruction isn't implemented, so you get an illegal opcode exception when expecting a GPF, or vice versa, but it's a time bomb for if it is ever implemented. + +The Intel docs also indicate that CR0.PE influences the protection; I don't know if that's already reflected in env->hflags & HF_CPL_MASK. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1910605 b/results/classifier/deepseek-2-tmp/output/mistranslation/1910605 new file mode 100644 index 000000000..967e82b35 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1910605 @@ -0,0 +1,17 @@ + +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/deepseek-2-tmp/output/mistranslation/1912065 b/results/classifier/deepseek-2-tmp/output/mistranslation/1912065 new file mode 100644 index 000000000..28f14045f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1912065 @@ -0,0 +1,33 @@ + +Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +QEMU segfaults to NULL dereference in tcg/optimize.c:212 semi-randomly after commit 7c79721606be11b5bc556449e5bcbc331ef6867d + +Exception Type: EXC_BAD_ACCESS (SIGSEGV) +Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000020 +Exception Note: EXC_CORPSE_NOTIFY + +... + +Thread 4 Crashed: +0 qemu-system-ppc 0x0000000109cd26d2 tcg_opt_gen_mov + 178 (optimize.c:212) +1 qemu-system-ppc 0x0000000109ccf838 tcg_optimize + 5656 +2 qemu-system-ppc 0x0000000109c27600 tcg_gen_code + 64 (tcg.c:4490) +3 qemu-system-ppc 0x0000000109c17b6d tb_gen_code + 493 (translate-all.c:1952) +4 qemu-system-ppc 0x0000000109c16085 tb_find + 41 (cpu-exec.c:454) [inlined] +5 qemu-system-ppc 0x0000000109c16085 cpu_exec + 2117 (cpu-exec.c:810) +6 qemu-system-ppc 0x0000000109c09ac3 tcg_cpus_exec + 35 (tcg-cpus.c:57) +7 qemu-system-ppc 0x0000000109c75edd rr_cpu_thread_fn + 445 (tcg-cpus-rr.c:217) +8 qemu-system-ppc 0x0000000109e41fae qemu_thread_start + 126 (qemu-thread-posix.c:521) +9 libsystem_pthread.dylib 0x00007fff2038e950 _pthread_start + 224 +10 libsystem_pthread.dylib 0x00007fff2038a47b thread_start + 15 + +Here the crash is in tcg/optimize.c line 212: + + mask = si->mask; + +"si" is NULL. The NULL value arises from tcg/optimize.c line 198: + + si = ts_info(src_ts); + +I did not attempt to determine the root cause of this issue, however. It clearly is related to the "tcg/optimize" changes in this commit. The previous commit c0dd6654f207810b16a75b673258f5ce2ceffbf0 doesn't crash. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1912107 b/results/classifier/deepseek-2-tmp/output/mistranslation/1912107 new file mode 100644 index 000000000..6dbc2897f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1912107 @@ -0,0 +1,9 @@ + +Option to constrain linux-user exec() to emulated CPU only + +When trying to reproduce a bug someone reported on an actual AMD K10[1], I tried to directly throw `qemu_x86-64 -cpu +phenom path/to/wrongly-labelled-instruction-set/gcc 1.c` at the problem, but failed to get an "illegal instruction" as expected. A quick investigation reveals that the error is actually caused by one of gcc's child processess, and that the said process is being ran directly on the host. A similar problem happens with trying to call stuff with /usr/bin/env. + + [1]: https://github.com/Homebrew/brew/issues/1034 + +Since both the host and the guest are x86_64, I deemed binfmt inapplicable to my case. I believe that QEMU should offer a way to modify exec() and other spawning syscalls so that execution remains on an emulated CPU in such a case. Call it an extra layer of binfmt, if you must. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1912790 b/results/classifier/deepseek-2-tmp/output/mistranslation/1912790 new file mode 100644 index 000000000..75db47ea2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1912790 @@ -0,0 +1,64 @@ + +qemu-aarch64-static segfaults python3 + +qemu-aarch64-static is segfaulting in a debian build process using debootstrap. + +``` +Type "apropos word" to search for commands related to "word"... +Reading symbols from /usr/bin/qemu-aarch64-static... +Reading symbols from /usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug... +[New LWP 21817] +[New LWP 21819] + +warning: Corrupted shared library list: 0xd5f140 != 0x0 +Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed +Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/python3.9 -c import imp; print(imp.get_ta'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +43 return mmap_lock_count > 0 ? true : false; +[Current thread is 1 (LWP 21817)] +(gdb) bt +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +#1 0x000000000058eb2c in page_set_flags (start=start@entry=4194304, end=end@entry=26451968, flags=flags@entry=8) at ../../accel/tcg/translate-all.c:2568 +#2 0x00000000005638cd in target_mmap (start=start@entry=4194304, len=<optimized out>, len@entry=22257160, target_prot=target_prot@entry=0, flags=16434, + fd=fd@entry=-1, offset=offset@entry=0) at ../../linux-user/mmap.c:602 +#3 0x000000000057042d in load_elf_image (image_name=0x7ffff7b7e8d8 "/usr/bin/python3.9", image_fd=3, info=info@entry=0x7ffff7b7ce70, + pinterp_name=pinterp_name@entry=0x7ffff7b7cbd0, bprm_buf=bprm_buf@entry=0x7ffff7b7d080 "\177ELF\002\001\001") at ../../linux-user/elfload.c:2700 +#4 0x0000000000570b9c in load_elf_binary (bprm=bprm@entry=0x7ffff7b7d080, info=info@entry=0x7ffff7b7ce70) at ../../linux-user/elfload.c:3104 +#5 0x00000000005c2fdb in loader_exec (fdexec=fdexec@entry=3, filename=<optimized out>, argv=argv@entry=0x2622910, envp=envp@entry=0x2686340, + regs=regs@entry=0x7ffff7b7cf70, infop=infop@entry=0x7ffff7b7ce70, bprm=<optimized out>) at ../../linux-user/linuxload.c:147 +#6 0x00000000004027f7 in main (argc=<optimized out>, argv=0x7ffff7b7d638, envp=<optimized out>) at ../../linux-user/main.c:810 + +(gdb) i r +rax 0x0 0 +rbx 0x400000 4194304 +rcx 0x7a95d2 8033746 +rdx 0x8 8 +rsi 0x193a000 26451968 +rdi 0x400000 4194304 +rbp 0x400000 0x400000 +rsp 0x7ffff7b7c978 0x7ffff7b7c978 +r8 0xffffffff 4294967295 +r9 0x0 0 +r10 0x4032 16434 +r11 0x206 518 +r12 0x193a000 26451968 +r13 0x8 8 +r14 0x8 8 +r15 0x193a000 26451968 +rip 0x562f20 0x562f20 <have_mmap_lock> +eflags 0x10206 [ PF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 + +``` + +Python3.9 is run as part of the installation of python3-minimal and the segfaults happens reliably here. Debian versionn bullseye (testing) + +Version: qemu-aarch64 version 5.2.0 (Debian 1:5.2+dfsg-3) + +Host is a qemu-system-x86_64: Linux runner 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1912934 b/results/classifier/deepseek-2-tmp/output/mistranslation/1912934 new file mode 100644 index 000000000..0be6f924b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1912934 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1913315 b/results/classifier/deepseek-2-tmp/output/mistranslation/1913315 new file mode 100644 index 000000000..ad69a0775 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1913315 @@ -0,0 +1,49 @@ + +qemu-system-x86_64 crash: in memory_region_access_valid+0x13 + +Recently we started to get intermittent qemu crashes. There is catchsegv report: + +``` ++ qemu-system-x86_64 -m 77766M -smp 8 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-rt-buildroot/boot/vmlinuz-4.19.165-rt-alt1.rt70 -initrd /usr/src/tmp/initramfs-4.19.165-rt-alt1.rt70.img -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr quiet panic=-1 no_timer_check' +*** signal 11 +Register dump: + + RAX: 0000000000000000 RBX: 0000034000000340 RCX: 0000000000000001 + RDX: 0000000000000004 RSI: 0000000000000300 RDI: 0000034000000340 + RBP: 0000000000000300 R8 : 0000000000000000 R9 : 0000034000000340 + R10: 0000000000000370 R11: 0000000000000002 R12: 0000000000000004 + R13: 0000000000000004 R14: 000055b473fef5e0 R15: 0000000000000002 + RSP: 00007fd7edffae90 + + RIP: 000055b4717ef653 EFLAGS: 00010206 + + CS: 0033 FS: 0000 GS: 0000 + + Trap: 0000000e Error: 00000004 OldMask: 7ffbfa77 CR2: 00000388 + + FPUCW: 0000037f FPUSW: 00000000 TAG: 00000000 + RIP: 00000000 RDP: 00000000 + + ST(0) 0000 0000000000000000 ST(1) 0000 0000000000000000 + ST(2) 0000 0000000000000000 ST(3) 0000 0000000000000000 + ST(4) 0000 0000000000000000 ST(5) 0000 0000000000000000 + ST(6) 0000 0000000000000000 ST(7) 0000 0000000000000000 + mxcsr: 1fa0 + XMM0: 00000000000000000000000000000000 XMM1: 00000000000000000000000000000000 + XMM2: 00000000000000000000000000000000 XMM3: 00000000000000000000000000000000 + XMM4: 00000000000000000000000000000000 XMM5: 00000000000000000000000000000000 + XMM6: 00000000000000000000000000000000 XMM7: 00000000000000000000000000000000 + XMM8: 00000000000000000000000000000000 XMM9: 00000000000000000000000000000000 + XMM10: 00000000000000000000000000000000 XMM11: 00000000000000000000000000000000 + XMM12: 00000000000000000000000000000000 XMM13: 00000000000000000000000000000000 + XMM14: 00000000000000000000000000000000 XMM15: 00000000000000000000000000000000 + +Backtrace: +qemu-system-x86_64(memory_region_access_valid+0x13)[0x55b4717ef653] +qemu-system-x86_64(memory_region_dispatch_write+0x48)[0x55b4717ef8c8] +qemu-system-x86_64(+0x69fdfc)[0x55b471851dfc] +qemu-system-x86_64(helper_le_stl_mmu+0x2c5)[0x55b471858995] +[0x7feaed070925] + +``` +QEMU release 5.2.0. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1913913 b/results/classifier/deepseek-2-tmp/output/mistranslation/1913913 new file mode 100644 index 000000000..ebcffcd19 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1913913 @@ -0,0 +1,19 @@ + +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/deepseek-2-tmp/output/mistranslation/1914021 b/results/classifier/deepseek-2-tmp/output/mistranslation/1914021 new file mode 100644 index 000000000..e0081016a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1914021 @@ -0,0 +1,28 @@ + +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/deepseek-2-tmp/output/mistranslation/1915327 b/results/classifier/deepseek-2-tmp/output/mistranslation/1915327 new file mode 100644 index 000000000..ac6a4a6a1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1915327 @@ -0,0 +1,35 @@ + +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/deepseek-2-tmp/output/mistranslation/1915925 b/results/classifier/deepseek-2-tmp/output/mistranslation/1915925 new file mode 100644 index 000000000..78adc58f6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1915925 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/1916269 b/results/classifier/deepseek-2-tmp/output/mistranslation/1916269 new file mode 100644 index 000000000..b5172529c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1916269 @@ -0,0 +1,20 @@ + +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/deepseek-2-tmp/output/mistranslation/1917591 b/results/classifier/deepseek-2-tmp/output/mistranslation/1917591 new file mode 100644 index 000000000..4e9bf7c01 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1917591 @@ -0,0 +1,29 @@ + +qemu-i386 under aarch64: Segfaulting on Steamcmd + +I am trying to set up a Valheim server on my Raspberry Pi. I have installed the aarch64 image of Arm Arch Linux. + +I installed qemu-user-static from the AUR: https://aur.archlinux.org/packages/qemu-user-static/ +I have correctly set up binfmt support: https://aur.archlinux.org/packages/binfmt-qemu-static-all-arch/ + +This allows me to successfully run i386 and amd64 docker images: + +[alarm@server ~]$ sudo docker run --rm i386/debian uname -a +WARNING: The requested image's platform (linux/386) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 9fd8d345b0aa 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 i686 GNU/Linux + +and + +[alarm@server ~]$ sudo docker run --rm amd64/debian uname -a +WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 4f50fd228ab6 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 x86_64 GNU/Linux + +However, when I try to run the docker image that is going to host the server, the download of Valheim never succeeds because the used steamcmd application segfaults: + +The following command successfully runs the server: sudo docker run -d --name valheim-server -p 2456-2458:2456-2458/udp -e SERVER_NAME="My Server" -e WORLD_NAME="Neotopia" -e SERVER_PASS="secret" lloesche/valheim-server + +However, when we look into the container's logs via this command: sudo docker logs valheim-server + +We see the following entry in the log file: ./steamcmd.sh: line 38: 86 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@" + +This means that the download never completes, and therefor the Valheim server is never actually started. Any help would be much appreciated. If there is anything unclear or if you need more details, please let me know! \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1918026 b/results/classifier/deepseek-2-tmp/output/mistranslation/1918026 new file mode 100644 index 000000000..6152f98cc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1918026 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/1918149 b/results/classifier/deepseek-2-tmp/output/mistranslation/1918149 new file mode 100644 index 000000000..2bcf5901d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1918149 @@ -0,0 +1,11 @@ + +qemu-user reports wrong fault_addr in signal handler + +When a SEGV signal occurs and si_addr of the info struct is nil, qemu still tries to translate the address from host to guest (handle_cpu_signal in accel/tcg/user-exec.c). This means, that the actual signal handler, will receive a fault_addr that is something like 0xffffffffbf709000. + +I was able to get this to happen, by branching to a non canonical address on aarch64. +I used 5.2 (commit: 553032db17). However, building from source, this only seems to happen, if I use the same configure flags as the debian build: + +../configure --static --target-list=aarch64-linux-user --disable-system --enable-trace-backends=simple --disable-linux-io-uring --disable-pie --extra-cflags="-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --extra-ldflags="-Wl,-z,relro -Wl,--as-needed" + +Let me know, if you need more details. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1920913 b/results/classifier/deepseek-2-tmp/output/mistranslation/1920913 new file mode 100644 index 000000000..52c3f089b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1920913 @@ -0,0 +1,32 @@ + +Openjdk11+ fails to install on s390x + +While installing openjdk11 or higher from repo, it crashes while configuring ca-certificates-java. +Although `java -version` passes, `jar -version` crashes. Detailed logs attached to this issue. + +``` +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x00000040126f9980, pid=8425, tid=8430 +# +# JRE version: OpenJDK Runtime Environment (11.0.10+9) (build 11.0.10+9-Ubuntu-0ubuntu1.20.04) +# Java VM: OpenJDK 64-Bit Server VM (11.0.10+9-Ubuntu-0ubuntu1.20.04, mixed mode, tiered, compressed oops, g1 gc, linux-s390x) +# Problematic frame: +# J 4 c1 java.lang.StringLatin1.hashCode([B)I java.base@11.0.10 (42 bytes) @ 0x00000040126f9980 [0x00000040126f9980+0x0000000000000000] +# +# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to //core.8425) +# +# An error report file with more information is saved as: +# //hs_err_pid8425.log +sed with "/usr/share/apport/apport %p %s %c %d %P %E" (or dumping to /root/core.10740) +# +# An error report file with more information is saved as: +# /root/hs_err_pid10740.log +``` + +Observed this on s390x/ubuntu as well as alpine when run on amd64. +Please note, on native s390x, the installation is successful. Also this crash is not observed while installing openjdk-8-jdk. + +Qemu version: 5.2.0 + +Please let me know if any more details are needed. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1921138 b/results/classifier/deepseek-2-tmp/output/mistranslation/1921138 new file mode 100644 index 000000000..51c6a1f38 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1921138 @@ -0,0 +1,14 @@ + +tcg.c:3329: tcg fatal error + +I am currently building my own kernel with bootloader and qemu crashed after I have set an IDT in protected mode and then create a invalid opcode exception with the opcode 0xff. + +My code is here: https://github.com/Luis-Hebendanz/svm_kernel/blob/qemu_crash/svm_kernel/external/bootloader/src/main.rs#L80 + +Build instructions are here: https://github.com/Luis-Hebendanz/svm_kernel/tree/qemu_crash + +A precompiled binary is here: https://cloud.gchq.icu/s/LcjoDWRW2CbxJ5i + +I executed the following command: qemu-system-x86_64 -smp cores=4 -cdrom target/x86_64-os/debug/bootimage-svm_kernel.iso -serial stdio -display none -m 4G + +I am running QEMU emulator version 5.1.0 \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1921664 b/results/classifier/deepseek-2-tmp/output/mistranslation/1921664 new file mode 100644 index 000000000..3794916d1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1921664 @@ -0,0 +1,93 @@ + +QEMU coroutines fail with LTO on non-x86_64 architectures + +I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion: + + +OpenSBI v0.6 + ____ _____ ____ _____ + / __ \ / ____| _ \_ _| + | | | |_ __ ___ _ __ | (___ | |_) || | + | | | | '_ \ / _ \ '_ \ \___ \| _ < | | + | |__| | |_) | __/ | | |____) | |_) || |_ + \____/| .__/ \___|_| |_|_____/|____/_____| + | | + |_| + +... +Found /boot/extlinux/extlinux.conf +Retrieving file: /boot/extlinux/extlinux.conf +618 bytes read in 2 ms (301.8 KiB/s) +RISC-V Qemu Boot Options +1: Linux kernel-5.5.0-dirty +2: Linux kernel-5.5.0-dirty (recovery mode) +Enter choice: 1: Linux kernel-5.5.0-dirty +Retrieving file: /boot/initrd.img-5.5.0-dirty +qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed. +./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi +ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi +ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports + +Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated). + + +Think you have everything already, but just in case: + +$ lsb_release -rd +Description: Ubuntu Hirsute Hippo (development branch) +Release: 21.04 + +$ uname -a +Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux +(note this is a VM running on macOS/M1) + +$ apt-cache policy qemu +qemu: + Installed: 1:5.2+dfsg-9ubuntu1 + Candidate: 1:5.2+dfsg-9ubuntu1 + Version table: + *** 1:5.2+dfsg-9ubuntu1 500 + 500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages + 100 /var/lib/dpkg/status + +ProblemType: Bug +DistroRelease: Ubuntu 21.04 +Package: qemu 1:5.2+dfsg-9ubuntu1 +ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0 +Uname: Linux 5.11.0-11-generic aarch64 +ApportVersion: 2.20.11-0ubuntu61 +Architecture: arm64 +CasperMD5CheckResult: unknown +CurrentDmesg: + Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie + Error executing command as another user: Not authorized + + This incident has been reported. +Date: Mon Mar 29 02:33:25 2021 +Dependencies: + +KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND +Lspci-vt: + -[0000:00]-+-00.0 Apple Inc. Device f020 + +-01.0 Red Hat, Inc. Virtio network device + +-05.0 Red Hat, Inc. Virtio console + +-06.0 Red Hat, Inc. Virtio block device + \-07.0 Red Hat, Inc. Virtio RNG +Lsusb: Error: command ['lsusb'] failed with exit code 1: +Lsusb-t: + +Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: +ProcEnviron: + TERM=screen + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=C.UTF-8 + SHELL=/bin/bash +ProcKernelCmdLine: console=hvc0 root=/dev/vda +SourcePackage: qemu +UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago) +acpidump: + Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie + Error executing command as another user: Not authorized + + This incident has been reported. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1922617 b/results/classifier/deepseek-2-tmp/output/mistranslation/1922617 new file mode 100644 index 000000000..c3236f36b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1922617 @@ -0,0 +1,121 @@ + +qemu-aarch64-static "Illegal instruction" with debootstrap + +This is reproducible against QEMU master. I apologize for the long reproduction steps, I tried to distill it down as much as possible. + +System info: + +# qemu-aarch64-static --version +qemu-aarch64 version 5.2.91 (v6.0.0-rc1-68-gee82c086ba) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +# cat /etc/os-release +PRETTY_NAME="Debian GNU/Linux 10 (buster)" +NAME="Debian GNU/Linux" +VERSION_ID="10" +VERSION="10 (buster)" +VERSION_CODENAME=buster +ID=debian +HOME_URL="https://www.debian.org/" +SUPPORT_URL="https://www.debian.org/support" +BUG_REPORT_URL="https://bugs.debian.org/" + +# head -n 26 /proc/cpuinfo +processor : 0 +vendor_id : GenuineIntel +cpu family : 6 +model : 85 +model name : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz +stepping : 7 +microcode : 0x5002f01 +cpu MHz : 1000.716 +cache size : 22528 KB +physical id : 0 +siblings : 32 +core id : 0 +cpu cores : 16 +apicid : 0 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 22 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities +bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs taa itlb_multihit +bogomips : 4600.00 +clflush size : 64 +cache_alignment : 64 +address sizes : 46 bits physical, 48 bits virtual +power management: + +My reproduction steps: + +# apt-get install --no-install-recommends -y \ + build-essential \ + ca-certificates \ + debootstrap \ + git \ + libglib2.0-dev \ + libpixman-1-dev \ + ninja-build \ + pkg-config \ + python3 \ + zstd + +# git clone https://github.com/qemu/qemu + +# mkdir qemu/build + +# cd qemu/build + +# ../configure \ + --enable-debug \ + --enable-linux-user \ + --disable-bsd-user \ + --disable-werror \ + --disable-system \ + --disable-tools \ + --disable-docs \ + --disable-gtk \ + --disable-gnutls \ + --disable-nettle \ + --disable-gcrypt \ + --disable-glusterfs \ + --disable-libnfs \ + --disable-libiscsi \ + --disable-vnc \ + --disable-kvm \ + --disable-libssh \ + --disable-libxml2 \ + --disable-vde \ + --disable-sdl \ + --disable-opengl \ + --disable-xen \ + --disable-fdt \ + --disable-vhost-net \ + --disable-vhost-crypto \ + --disable-vhost-user \ + --disable-vhost-vsock \ + --disable-vhost-scsi \ + --disable-tpm \ + --disable-qom-cast-debug \ + --disable-capstone \ + --disable-zstd \ + --disable-linux-io-uring \ + --static \ + --target-list-exclude=hexagon-linux-user + +# ninja qemu-aarch64 + +# install -Dm755 qemu-aarch64 /usr/local/bin/qemu-aarch64-static + +# cat <<'EOF' >/proc/sys/fs/binfmt_misc/register +:qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-aarch64-static:CF +EOF + +# debootstrap --arch arm64 --foreign buster debian-rootfs + +# chroot debian-rootfs /debootstrap/debootstrap --second-stage +Illegal instruction + +This prevents me from building an arm64 Debian image on x86_64. If I am doing something wrong, please let me know. The binary has been uploaded for your convenience. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1922887 b/results/classifier/deepseek-2-tmp/output/mistranslation/1922887 new file mode 100644 index 000000000..d459d45c2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1922887 @@ -0,0 +1,31 @@ + +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/deepseek-2-tmp/output/mistranslation/1923197 b/results/classifier/deepseek-2-tmp/output/mistranslation/1923197 new file mode 100644 index 000000000..fe17cbdf1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1923197 @@ -0,0 +1,38 @@ + +RISC-V priviledged instruction error + +Hello when performing an MRET with MPP set to something else than 0b11 in MSTATUS, 'Invalid Instruction' exception will be triggered. The problem appeared in code after version 5.2.0. + +<pre> + # setup interrupt handling for monitor mode + la t0, entry_loop + la t1, entry_trap + li t2, 0x888 + li t3, 0x1880 # MPP in MSTATUS selects to which mode to return & MPIE selects if to enable interrupts after MRET + csrw mepc, t0 + csrw mtvec, t1 + csrs mie, t2 + csrs mstatus, t3 + + # if supervisor mode not supported, then loop forever + csrr t0, misa + li t1, 0x40000 + and t2, t1, t0 + beqz t2, 1f + + # setup interrupt i& exception delegation for supervisor mode + li t0, 0xc0000000 # 3 GiB (entry address of supervisor) + li t1, 0x1000 + #li t2, 0x300 # bit 8 & 9 is for ecall from user & supervisor mode + #li t3, 0x222 + csrw mepc, t0 + csrc mstatus, t1 + #csrs medeleg, t2 + #csrs mideleg, t3 + + # pass mhartid as first parameter to supervisor + csrr a0, mhartid + +1: + mret +</pre> \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1923861 b/results/classifier/deepseek-2-tmp/output/mistranslation/1923861 new file mode 100644 index 000000000..7e79c8ed9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1923861 @@ -0,0 +1,22 @@ + +Hardfault when accessing FPSCR register + +QEMU release version: v6.0.0-rc2 + +command line: +qemu-system-arm -machine mps3-an547 -nographic -kernel <my_project>.elf -semihosting -semihosting-config enable=on,target=native + +host operating system: Linux ISCNR90TMR1S 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux + +guest operating system: none (bare metal) + +Observation: +I am simulating embedded firmware for a Cortex-M55 device, using MPS3-AN547 machine. In the startup code I am accessing the FPSCR core register: + + unsigned int fpscr =__get_FPSCR(); + fpscr = fpscr & (~FPU_FPDSCR_AHP_Msk); + __set_FPSCR(fpscr); + +where the register access functions __get_FPSCR() and __set_FPSCR(fpscr) are taken from CMSIS_5 at ./CMSIS/Core/include/cmsis_gcc.h + +I observe hardfaults upon __get_FPSCR() and __set_FPSCR(fpscr). The same startup code works fine on the Arm Corstone-300 FVP. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1924231 b/results/classifier/deepseek-2-tmp/output/mistranslation/1924231 new file mode 100644 index 000000000..ed4a5331d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1924231 @@ -0,0 +1,102 @@ + +Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on. + +the QEMU release version where the bug was found. + +apt list --installed | grep qemu +qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.14 amd64 [installed] + + +The installing "libc-bin" which "wget" depends on crashes as below when we execute docker image of Debian GNU/Linux bullseye for ARM64 on Ubuntu 20.04 for AMD64. +This problem also occurs on CI(GitHub Actions)(https://github.com/groonga/groonga/runs/2338497272?check_suite_focus=true#step:11:127). +Probably, The cause of this crash is https://bugs.launchpad.net/qemu/+bug/1749393. +This bug has already been fixed in qemu-user-static pacakge for Ubuntu 20.10. + +However, this fix is not included in qemu-user-static pacakge for Ubuntu 20.04. +Currently, GitHub Actions does not support Ubuntu 20.10. +Therefore, this problem is still happening in CI. + +Would it be possible for you to backport this fix into Ubuntu 20.04? + + +How to reproduce: + +sudo apt install -y qemu-user-static docker.io +sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] +Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] +Get:3 http://deb.debian.org/debian bullseye-updates InRelease [40.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8084 kB] +Get:5 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [808 B] +Fetched 8311 kB in 4s (2001 kB/s) +Reading package lists... +Building dependency tree... +Reading state information... +2 packages can be upgraded. Run 'apt list --upgradable' to see them. + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Reading package lists... +Building dependency tree... +Reading state information... +The following additional packages will be installed: + ca-certificates libpsl5 openssl publicsuffix +The following NEW packages will be installed: + ca-certificates libpsl5 openssl publicsuffix wget +0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded. +Need to get 2111 kB of archives. +After this operation, 5844 kB of additional disk space will be used. +Get:1 http://deb.debian.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1 [829 kB] +Get:2 http://deb.debian.org/debian bullseye/main arm64 ca-certificates all 20210119 [158 kB] +Get:3 http://deb.debian.org/debian bullseye/main arm64 libpsl5 arm64 0.21.0-1.2 [57.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 wget arm64 1.21-1 [946 kB] +Get:5 http://deb.debian.org/debian bullseye/main arm64 publicsuffix all 20210108.1309-1 [121 kB] +debconf: delaying package configuration, since apt-utils is not installed +Fetched 2111 kB in 0s (12.9 MB/s) +Selecting previously unselected package openssl. +(Reading database ... 6640 files and directories currently installed.) +Preparing to unpack .../openssl_1.1.1k-1_arm64.deb ... +Unpacking openssl (1.1.1k-1) ... +Selecting previously unselected package ca-certificates. +Preparing to unpack .../ca-certificates_20210119_all.deb ... +Unpacking ca-certificates (20210119) ... +Selecting previously unselected package libpsl5:arm64. +Preparing to unpack .../libpsl5_0.21.0-1.2_arm64.deb ... +Unpacking libpsl5:arm64 (0.21.0-1.2) ... +Selecting previously unselected package wget. +Preparing to unpack .../archives/wget_1.21-1_arm64.deb ... +Unpacking wget (1.21-1) ... +Selecting previously unselected package publicsuffix. +Preparing to unpack .../publicsuffix_20210108.1309-1_all.deb ... +Unpacking publicsuffix (20210108.1309-1) ... +Setting up libpsl5:arm64 (0.21.0-1.2) ... +Setting up wget (1.21-1) ... +Setting up openssl (1.1.1k-1) ... +Setting up publicsuffix (20210108.1309-1) ... +Setting up ca-certificates (20210119) ... +debconf: unable to initialize frontend: Dialog +debconf: (TERM is not set, so the dialog frontend is not usable.) +debconf: falling back to frontend: Readline +debconf: unable to initialize frontend: Readline +debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) +debconf: falling back to frontend: Teletype +Updating certificates in /etc/ssl/certs... +129 added, 0 removed; done. +Processing triggers for libc-bin (2.31-11) ... +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +dpkg: error processing package libc-bin (--configure): + installed libc-bin package post-installation script subprocess returned error exit status 139 +Processing triggers for ca-certificates (20210119) ... +Updating certificates in /etc/ssl/certs... +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +done. +Errors were encountered while processing: + libc-bin +E: Sub-process /usr/bin/dpkg returned an error code (1) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1924669 b/results/classifier/deepseek-2-tmp/output/mistranslation/1924669 new file mode 100644 index 000000000..d5f3a535b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1924669 @@ -0,0 +1,11 @@ + +VFP code cannot see CPACR write in the same TB + +If FPU is enabled by writing to CPACR, and the code is in the same translation block as the following VFP code, qemu generates "v7M NOCP UsageFault". + +This can be reproduced with git HEAD (commit 8fe9f1f891eff4e37f82622b7480ee748bf4af74). + +The target binary is attached. The qemu command is: +qemu-system-arm -nographic -monitor null -serial null -semihosting -machine mps2-an505 -cpu cortex-m33 -kernel cpacr_vfp.elf -d in_asm,int,exec,cpu,cpu_reset,unimp,guest_errors,nochain -D log + +If the code is changed a little, so that they are not in the same block, VFP code can see the effect of CPACR, or -singlestep of qemu has the same result. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1925512 b/results/classifier/deepseek-2-tmp/output/mistranslation/1925512 new file mode 100644 index 000000000..2415ad2b5 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1925512 @@ -0,0 +1,19 @@ + +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/deepseek-2-tmp/output/mistranslation/1926044 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926044 new file mode 100644 index 000000000..3797c8ac4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926044 @@ -0,0 +1,31 @@ + +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/deepseek-2-tmp/output/mistranslation/1926202 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926202 new file mode 100644 index 000000000..fb45856fd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926202 @@ -0,0 +1,19 @@ + +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/deepseek-2-tmp/output/mistranslation/1926246 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926246 new file mode 100644 index 000000000..0edb5e96e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926246 @@ -0,0 +1,51 @@ + +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/deepseek-2-tmp/output/mistranslation/1926277 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926277 new file mode 100644 index 000000000..348343693 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926277 @@ -0,0 +1,38 @@ + +MIPS MT dvpe does not regard VPEConf0.MVP + +Hi, + +According to MIPS32® Architecture for Programmers VolumeIV-f: The MIPS® MT Application-Specific Extension to the MIPS32® Architecture, for instruction: dvpe, evpe: + +If the VPE executing the instruction is not a Master VPE, with the MVP bit of the VPEConf0 register set, the EVP bit is unchanged by the instruction. + +The pseudo code is: + +data ← MVPControl +GPR[rt] ← data +if(VPEConf0.MVP = 1) then + MVPControl.EVP ← sc +endif + +However the helper functions of dvpe, evpe does not regard the VPEConf0.MVP bit, namely, it does not check if the VPE is a master VPE. Code is copied below as: + +target_ulong helper_dvpe(CPUMIPSState *env) +{ + CPUState *other_cs = first_cpu; + target_ulong prev = env->mvp->CP0_MVPControl; + + CPU_FOREACH(other_cs) { + MIPSCPU *other_cpu = MIPS_CPU(other_cs); + /* Turn off all VPEs except the one executing the dvpe. */ + if (&other_cpu->env != env) { + other_cpu->env.mvp->CP0_MVPControl &= ~(1 << CP0MVPCo_EVP); + mips_vpe_sleep(other_cpu); + } + } + return prev; +} + +Is this a bug? + +QEMU head commit: 0cef06d18762374c94eb4d511717a4735d668a24 is checked. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1926521 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926521 new file mode 100644 index 000000000..460550985 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926521 @@ -0,0 +1,63 @@ + +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/deepseek-2-tmp/output/mistranslation/1926996 b/results/classifier/deepseek-2-tmp/output/mistranslation/1926996 new file mode 100644 index 000000000..bd28b3232 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1926996 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/1927530 b/results/classifier/deepseek-2-tmp/output/mistranslation/1927530 new file mode 100644 index 000000000..57f1fcad3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1927530 @@ -0,0 +1,40 @@ + +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/deepseek-2-tmp/output/mistranslation/1929 b/results/classifier/deepseek-2-tmp/output/mistranslation/1929 new file mode 100644 index 000000000..5632fc42a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1929 @@ -0,0 +1,22 @@ + +regression: 7.0.0 breaks registering process subreaper on Apple silicon +Description of problem: +When running any container on the QEMU virtual guest that is using a utility like `tini` which is trying to register itself as a process subreaper I get an error message like this: + +``` +[FATAL tini (1)] PR_SET_CHILD_SUBREAPER is unavailable on this platform. Are you using Linux >= 3.4? +``` + +The issue has been observed by multiple people on Apple silicon Macs, e.g. in these issues: +https://github.com/docker/for-mac/issues/6620#issuecomment-1694380189 +https://github.com/GoogleCloudPlatform/spark-on-k8s-operator/issues/1735 +Steps to reproduce: +1. Install QEMU 7.0.0+ on an Apple silicon MAC +2. Run a virtual guest +3. Try to register a process subreaper, e.g. like `tini -s` does +Additional information: +the issue was introduced in QEMU 7.0.0 with this commit: +https://gitlab.com/qemu-project/qemu/-/commit/220717a6f46a99031a5b1af964bbf4dec1310440 + +tini readme talking about process subreaping: +https://github.com/krallin/tini#subreaping diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1930 b/results/classifier/deepseek-2-tmp/output/mistranslation/1930 new file mode 100644 index 000000000..34e8dd842 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1930 @@ -0,0 +1,47 @@ + +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/deepseek-2-tmp/output/mistranslation/1936977 b/results/classifier/deepseek-2-tmp/output/mistranslation/1936977 new file mode 100644 index 000000000..9fb8f2fe6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1936977 @@ -0,0 +1,8 @@ + + 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/deepseek-2-tmp/output/mistranslation/1945540 b/results/classifier/deepseek-2-tmp/output/mistranslation/1945540 new file mode 100644 index 000000000..f4b788fde --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1945540 @@ -0,0 +1,64 @@ + +Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8' + +Host environment + +- Operating system: Ubuntu 20.04.3 LTS Desktop +- OS/kernel version: Linux tower 5.11.0-37-generic #41~20.04.2-Ubuntu + SMP Fri Sep 24 09:06:38 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux +- Architecture: amd64 +- QEMU flavor: qemu-system-s390x +- QEMU version: QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.17) +- QEMU command line: See attached file 'command-line.txt' + +Emulated/Virtualized environment + +- Operating system: Ubuntu 20.04.3 LTS Server +- OS/kernel version: Linux s390x-focal 5.4.0-88-generic #99-Ubuntu + SMP Thu Sep 23 17:27:44 UTC 2021 s390x s390x s390x GNU/Linux +- Architecture: s390x + +Description of problem + +Java crashes as shown below: + +$ java --version +# +# A fatal error has been detected by the Java Runtime Environment: +# +# SIGILL (0x4) at pc=0x000003ff9f5fe6f4, pid=6789, tid=6818 +# +# JRE version: (17.0+35) (build ) +# Java VM: OpenJDK 64-Bit Server VM (17+35-snap, mixed mode, sharing, +# tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) +# Problematic frame: +# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8 +# +# Core dump will be written. Default location: core.6789 (may not +# exist) +# +# An error report file with more information is saved as: +# /home/ubuntu/src/hs_err_pid6789.log +# +# +Aborted (core dumped) + +Steps to reproduce + +Run any Java program to reproduce the problem. + +Because the 'openjdk' packages in Ubuntu run the 'java' command during installation, they hit the same error and fail to install. As an alternative, you can install the OpenJDK Snap package for the 's390x' architecture as follows: + + $ sudo snap install openjdk + +The OpenJDK Snap package has been tested to work on a real IBM/S390 8561 system, namely the IBM LinuxONE III LT1 at Marist College: + + Marist College Installs World’s First IBM LinuxONE III™ + https://www.marist.edu/-/marist-first-linuxone-iii + +Additional information + +See the following attached files: + +command-line.txt - the command-line used to start the virtual machine +hs_err_pid6789.log - the log file resulting from 'java --version' \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/1967248 b/results/classifier/deepseek-2-tmp/output/mistranslation/1967248 new file mode 100644 index 000000000..d9e7789f0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/1967248 @@ -0,0 +1,39 @@ + +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/deepseek-2-tmp/output/mistranslation/2011 b/results/classifier/deepseek-2-tmp/output/mistranslation/2011 new file mode 100644 index 000000000..9ddabc4a9 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2011 @@ -0,0 +1,2 @@ + +ARM emulation layer for Windows x86_64 OS request diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2024 b/results/classifier/deepseek-2-tmp/output/mistranslation/2024 new file mode 100644 index 000000000..86bcbe6ff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2024 @@ -0,0 +1,31 @@ + +IPv6 DHCPv6 DUID-UUID Generation Issue with iPXE on QEMU 8.1.2 and SMBIOS 3.0 +Description of problem: +I'm creating this ticket in both projects affected as I'm unsure which side needs to resolve it. I discovered this bug after upgrading Proxmox to version 8.1. I use iPXE to boot in IPv6 and retrieve the configuration from a web server. I have a DHCPv6 and SLAAC server configured. + +In this configuration, iPXE is unable to generate the necessary DUID-UUID for IPv6. If I revert to the previous QEMU version (using the machine: pc-i440fx-8.0 option in Proxmox), I have no issues. The only difference I notice and understand is the switch to SMBIOS 3.0, which is 64 bits, compared to SMBIOS 2.8, which is 32 bits. It appears to be the same issue with Libvirt. By default, it uses pc-q35-8.1, and I encounter the bug. However, if I switch to pc-q35-8.0, the problem is resolved. + +I've included two sets of information in the first part. The first one is from my local computer using libvirt, making it easier to reproduce the bug. The second set is from my production environment. + +Here's the iPXE trace: + +```plaintext +iPXE> ifconf --configurator ipv6 +Configuring [ipv6] (net0 66:b5:3e:97:7d:4e)... +DHCPv6 net0 could not create DUID-UUID: No such file or directory (https://ipxe.org/2d0c203b) +No such file or directory (https://ipxe.org/2d0c203b) +``` +Steps to reproduce: +1. Create a PXE ISO with IPv6 debug options: + 1. Clone the iPXE repository with the following command: + * `git clone https://github.com/ipxe/ipxe` + 2. Navigate to the src directory: + * `cd ipxe/src` + 3. Build the iPXE ISO with IPv6 debug options using the following command: + * `DEBUG='dhcpv6,neighbour' make bin/ipxe.iso` +2. Set up a Libvirt network with DHCPv6 enabled (example configuration provided in the next section). +3. Create a virtual machine with the generated iPXE ISO and the network configured for IPv6. +4. Press `Ctrl+B` to access the iPXE shell. +5. Execute the command `ifconf --configurator ipv6` in the iPXE shell. +Additional information: +# diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2072564 b/results/classifier/deepseek-2-tmp/output/mistranslation/2072564 new file mode 100644 index 000000000..80539baae --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2072564 @@ -0,0 +1,46 @@ + +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/deepseek-2-tmp/output/mistranslation/2076 b/results/classifier/deepseek-2-tmp/output/mistranslation/2076 new file mode 100644 index 000000000..96aa84e7d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2076 @@ -0,0 +1,2 @@ + +stringop-overread warning in tests/tcg/multiarch/sha1.c diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2082 b/results/classifier/deepseek-2-tmp/output/mistranslation/2082 new file mode 100644 index 000000000..395d10247 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2082 @@ -0,0 +1,45 @@ + +"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/deepseek-2-tmp/output/mistranslation/2112 b/results/classifier/deepseek-2-tmp/output/mistranslation/2112 new file mode 100644 index 000000000..86d2d9eb2 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2112 @@ -0,0 +1,27 @@ + +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/deepseek-2-tmp/output/mistranslation/2122 b/results/classifier/deepseek-2-tmp/output/mistranslation/2122 new file mode 100644 index 000000000..306af058a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2122 @@ -0,0 +1,8 @@ + +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/deepseek-2-tmp/output/mistranslation/2123 b/results/classifier/deepseek-2-tmp/output/mistranslation/2123 new file mode 100644 index 000000000..64c913204 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2123 @@ -0,0 +1,32 @@ + +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/deepseek-2-tmp/output/mistranslation/2131 b/results/classifier/deepseek-2-tmp/output/mistranslation/2131 new file mode 100644 index 000000000..f7819bfba --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2131 @@ -0,0 +1,2 @@ + +tcg mem plugin, udata always zero diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2134 b/results/classifier/deepseek-2-tmp/output/mistranslation/2134 new file mode 100644 index 000000000..a763cbd5e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2134 @@ -0,0 +1,2 @@ + +[Tricore Board]How to map LOCAL. DSPR/LOCAL.PSPR to other CPU globle_DSPR/globle_PSPR diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2154 b/results/classifier/deepseek-2-tmp/output/mistranslation/2154 new file mode 100644 index 000000000..34273bdcf --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2154 @@ -0,0 +1,8 @@ + +ID_AA64MMFR2_EL1 is all zeros +Description of problem: +When the `ID_AA64MMFR2_EL1` register is read via `mrs x[n], ID_AA64MMFR2_EL1`, it is read as all zeros. This is at the very least not correct for `ID_AA64MMFR2_EL1.ST`, which describes support for small translation tables (FEAT_TTST). +Steps to reproduce: +1. Run `mrs x[n], ID_AA64MMFR2_EL1` within qemu-system-aarch64 +Additional information: +FEAT_TTST is a relatively new aarch64 feature that appears to have caused many problems basically everywhere. However, [qemu has reportedly implemented it](https://www.qemu.org/2021/04/30/qemu-6-0-0/). diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2157 b/results/classifier/deepseek-2-tmp/output/mistranslation/2157 new file mode 100644 index 000000000..7f6e2bf0f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2157 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/2238 b/results/classifier/deepseek-2-tmp/output/mistranslation/2238 new file mode 100644 index 000000000..74454581c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2238 @@ -0,0 +1,48 @@ + +The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored +Description of problem: +The `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` is not properly honored. +Steps to reproduce: +1. Register a callback with `qemu_plugin_register_vcpu_mem_cb()` +2. In the callback, print the return of `qemu_plugin_mem_is_store()` (either `true` or `false`) +3. Change the value of `rw` parameter of `qemu_plugin_register_vcpu_mem_cb()` and look whether the callback prints `true` and/or `false` to determine if this is inline with `rw`. + +In the callback, we don't we get what we asked for. + +| Requested with rw | Observed in the callback | +|---------------------|----------------------------| +| QEMU_PLUGIN_MEM_R | Only writes | +| QEMU_PLUGIN_MEM_W | Both reads and writes | +| QEMU_PLUGIN_MEM_RW | Both reads and writes | +Additional information: +In `plugin-gen.c`, line 497, there is the following function: + +```cpp +static bool op_rw(const TCGOp *op, const struct qemu_plugin_dyn_cb *cb) +{ + int w; + + w = op->args[2]; + return !!(cb->rw & (w + 1)); +} +``` + +The issue described above seems to be caused by the `+ 1`. I removed it and got the expected results. + +This function is used in the same file, line 526, like this: + +```cpp + if (!ok(begin_op, cb)) { + continue; + } +``` + +This isn't consistent with `core.c`, line 509, where the same flag is checked like this: + +```cpp + if (!(rw & cb->rw)) { + break; + } +``` + +Inconsistent because of the `+1` and also because of `break`/`continue`. diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2353 b/results/classifier/deepseek-2-tmp/output/mistranslation/2353 new file mode 100644 index 000000000..9b1473052 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2353 @@ -0,0 +1,57 @@ + +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/deepseek-2-tmp/output/mistranslation/2386 b/results/classifier/deepseek-2-tmp/output/mistranslation/2386 new file mode 100644 index 000000000..baab48726 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2386 @@ -0,0 +1,44 @@ + +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/deepseek-2-tmp/output/mistranslation/2435 b/results/classifier/deepseek-2-tmp/output/mistranslation/2435 new file mode 100644 index 000000000..ecdc61a3c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2435 @@ -0,0 +1,21 @@ + +CPU halted during fuzzing OHCI +Description of problem: +Is there a limit on the number of CPU cores that QEMU can use? I am running multiple sets of parallel fuzzing tests on a host machine. To prevent CPU contention, I have divided the running environments by using docker. The docker startup command is as follows: +`docker run --cpuset-cpus=8-15 --privileged --name qemu-container-ohci -it qemu-container bash` + +I found that the CPU is in a halted state and encountered the following error: +``` +#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=126899170563648) at ./nptl/pthread_kill.c:44 +#1 __pthread_kill_internal (signo=6, threadid=126899170563648) at ./nptl/pthread_kill.c:78 +#2 __GI___pthread_kill (threadid=126899170563648, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 +#3 0x0000736a904a3476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#4 0x0000736a904897f3 in __GI_abort () at ./stdlib/abort.c:79 +#5 0x0000736a90dcbb57 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#6 0x0000736a90e2570f in g_assertion_message_expr () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 +#7 0x00005eca4aff5bad in mttcg_cpu_thread_fn (arg=0x62b000000200) at ../accel/tcg/tcg-accel-ops-mttcg.c:110 +#8 0x00005eca4b89d658 in qemu_thread_start (args=0x60300008b030) at ../util/qemu-thread-posix.c:541 +#9 0x0000736a904f5ac3 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442 +#10 0x0000736a90587850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +``` +Can someone help analyze the reason? diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2446 b/results/classifier/deepseek-2-tmp/output/mistranslation/2446 new file mode 100644 index 000000000..fa64bd694 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2446 @@ -0,0 +1,61 @@ + +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/deepseek-2-tmp/output/mistranslation/2510 b/results/classifier/deepseek-2-tmp/output/mistranslation/2510 new file mode 100644 index 000000000..64ac6aab0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2510 @@ -0,0 +1,46 @@ + +Cross compiling tools / qemu-img results in "ninja: no work to do" +Description of problem: +I have the following Dockerfile setting up a cross-compile environment for QEMU. +I am trying to build qemu-img.exe only at the moment + + +``` +FROM fedora as builder +RUN --mount=type=cache,target=/var/cache \ + dnf -v install --assumeyes strace gcc make mingw64-gcc mingw64-binutils python-setuptools meson mingw64-glib2-static mingw64-glib2 diffutils + +FROM builder as qemu-builder +WORKDIR /src/qemu #assuming qemu source tree is already available at /src/qemu +RUN +RUN ./configure --cross-prefix=x86_64-w64-mingw32- --target-list='' --static +RUN make V=1 tools +``` +With either `make tools` or `make qemu-img.exe` I get + +``` +#10 0.265 changing dir to build for make "tools"... +#10 0.267 make[1]: Entering directory '/src/qemu/build' +#10 0.330 ninja: no work to do. +#10 0.331 { \ +#10 0.331 echo 'ninja-targets = \'; \ +#10 0.331 /usr/bin/ninja -t targets all | sed 's/:.*//; $!s/$/ \\/'; \ +#10 0.331 echo 'build-files = \'; \ +#10 0.331 /usr/bin/ninja -t query build.ninja | sed -n '1,/^ input:/d; /^ outputs:/q; s/$/ \\/p'; \ +#10 0.331 } > Makefile.ninja.tmp && mv Makefile.ninja.tmp Makefile.ninja +#10 0.363 /src/qemu/build/pyvenv/bin/meson introspect --targets --tests --benchmarks | /src/qemu/build/pyvenv/bin/python3 -B scripts/mtest2make.py > Makefile.mtest +#10 0.634 make[1]: Nothing to be done for 'tools'. +#10 0.634 make[1]: Leaving directory '/src/qemu/build' +#10 DONE 0.6s +``` + +Following the info in `make help`, I tried `make qemu-img.o` which resulted in + +``` +cc -c -o qemu-img.o qemu-img.c +qemu-img.c:25:10: fatal error: qemu/osdep.h: No such file or directory + 25 | #include "qemu/osdep.h" + | ^~~~~~~~~~~~~~ +``` +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2570 b/results/classifier/deepseek-2-tmp/output/mistranslation/2570 new file mode 100644 index 000000000..000d9c501 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2570 @@ -0,0 +1,56 @@ + +TCG Plugins: "Code should not be reached" error after resetting plugin from vcpu_tb_trans callback +Description of problem: +In a TCG plugin, using the `qemu_plugin_reset` method from within a `vcpu_tb_trans` callback produces the following error. If this isn't a supported use case, it should probably be described in the documentation. If this is supposed to work, it doesn't seem to. + +``` +** +ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached +Bail out! ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached +Aborted (core dumped) +``` +Steps to reproduce: +1. Build the current head of master (4b7ea33074450bc6148c8e1545d78f179e64adb4) with the below `min` plugin (i.e., add to contrib/plugins and update contrib/plugins/Makefile so it is built) +2. `../configure --enable-plugins --target-list=x86_64-softmmu --disable-docs` +3. `make && make plugins` +4. Get a qcow, e.g., the Ubuntu Bionic qcow from [here](https://panda.re/qcows/linux/ubuntu/1804/x86_64/bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2). +5. `./qemu-system-x86_64 -plugin contrib/plugins/libmin.so bionic-server-cloudimg-amd64-noaslr-nokaslr.qcow2 -nographic` + +The first three lines are output by the plugin as expected, the error after that and the abort are unexpected: +``` +Translating basic block +Reset request issued +Reset finished +** +ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached +Bail out! ERROR:/home/user/git/qemu/tcg/i386/tcg-target.c.inc:3018:tcg_out_op: code should not be reached +Aborted (core dumped) +``` +Additional information: +contrib/plugins/min.c +```c +#include <stdio.h> +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +qemu_plugin_id_t plugin_id = {0}; + +static void post_reset(qemu_plugin_id_t id) { + printf("Reset finished\n"); +} + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) { + printf("Translating basic block\n"); + qemu_plugin_reset(plugin_id, post_reset); + printf("Reset request issued\n"); +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, int argc, char **argv) { + + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + plugin_id = id; + return 0; +} +``` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2592 b/results/classifier/deepseek-2-tmp/output/mistranslation/2592 new file mode 100644 index 000000000..ed59686ed --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2592 @@ -0,0 +1,38 @@ + +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/deepseek-2-tmp/output/mistranslation/2598 b/results/classifier/deepseek-2-tmp/output/mistranslation/2598 new file mode 100644 index 000000000..f6875487a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2598 @@ -0,0 +1,2 @@ + +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/deepseek-2-tmp/output/mistranslation/2628 b/results/classifier/deepseek-2-tmp/output/mistranslation/2628 new file mode 100644 index 000000000..9e481fa64 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2628 @@ -0,0 +1,21 @@ + +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/deepseek-2-tmp/output/mistranslation/2629 b/results/classifier/deepseek-2-tmp/output/mistranslation/2629 new file mode 100644 index 000000000..1467f66c7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2629 @@ -0,0 +1,2 @@ + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2647 b/results/classifier/deepseek-2-tmp/output/mistranslation/2647 new file mode 100644 index 000000000..f9785c005 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2647 @@ -0,0 +1,48 @@ + +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/deepseek-2-tmp/output/mistranslation/2685 b/results/classifier/deepseek-2-tmp/output/mistranslation/2685 new file mode 100644 index 000000000..877b95f61 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2685 @@ -0,0 +1,2 @@ + +Netbsd 10.0 AMD64 as host fails in tcg? diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2694 b/results/classifier/deepseek-2-tmp/output/mistranslation/2694 new file mode 100644 index 000000000..caefde121 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2694 @@ -0,0 +1,25 @@ + +error: implicit declaration of function 'IOMainPort' is invalid in C99 +Description of problem: +Build in MacOS + Hardware Overview: + + Model Name: MacBook Air + Chip: Apple M1 + Total Number of Cores: 8 (4 performance and 4 efficiency) + Memory: 16 GB +Steps to reproduce: +1. ./configure --cpu=aarch64 --target-list=aarch64-softmmu --enable-slirp +2. make -j +Additional information: +``` +FAILED: libblock.a.p/block_file-posix.c.o +cc -Ilibblock.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -Iblock -I/opt/homebrew/opt/zstd/include -I/opt/homebrew/Cellar/glib/2.82.2/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.82.2/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre2/10.44/include -I/opt/homebrew/Cellar/glib/2.82.2/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k -Wignored-qualifiers -Winit-self -Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wredundant-decls -Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings -Wno-gnu-variable-sized-type-not-at-end -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -Wno-string-plus-int -Wno-tautological-type-limit-compare -Wno-typedef-redefinition -iquote . -iquote /Users/august/qemu/src -iquote /Users/august/qemu/src/include -iquote /Users/august/qemu/src/host/include/aarch64 -iquote /Users/august/qemu/src/host/include/generic -iquote /Users/august/qemu/src/tcg/aarch64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv -fno-pie -MD -MQ libblock.a.p/block_file-posix.c.o -MF libblock.a.p/block_file-posix.c.o.d -o libblock.a.p/block_file-posix.c.o -c ../block/file-posix.c +../block/file-posix.c:3940:18: error: implicit declaration of function 'IOMainPort' is invalid in C99 [-Werror,-Wimplicit-function-declaration] + kernResult = IOMainPort(MACH_PORT_NULL, &mainPort); + ^ +1 error generated. +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [build] Error 2 +``` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2711 b/results/classifier/deepseek-2-tmp/output/mistranslation/2711 new file mode 100644 index 000000000..e893132b1 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2711 @@ -0,0 +1,2 @@ + +TSTEQ lowering and optimization bug diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2737 b/results/classifier/deepseek-2-tmp/output/mistranslation/2737 new file mode 100644 index 000000000..e19f1ad68 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2737 @@ -0,0 +1,2 @@ + +Plans for Adding RISC-V Vector (RVV) Backend Support? diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/276 b/results/classifier/deepseek-2-tmp/output/mistranslation/276 new file mode 100644 index 000000000..669b58726 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/276 @@ -0,0 +1,2 @@ + +Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2815 b/results/classifier/deepseek-2-tmp/output/mistranslation/2815 new file mode 100644 index 000000000..816c45584 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2815 @@ -0,0 +1,2 @@ + +clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2906 b/results/classifier/deepseek-2-tmp/output/mistranslation/2906 new file mode 100644 index 000000000..106ff63f8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2906 @@ -0,0 +1,14 @@ + +x86 (32-bit) multicore very slow, but x86-64 is fast (on macOS arm64 host) +Description of problem: +More cores doesn't slow down a x86-32 guest on an x86-64 host, nor does it slow down an x86-64 guest on an arm64 host. However, adding extra cores massively slows down an x86-32 guest on an arm64 host. +Steps to reproduce: +1. Run 32-bit guest or 32-bit installer +2. +3. + +I have replicated this over several OSes using homebrew qemu, source-built qemu and UTM. This is not to be confused with a different bug in UTM that caused its version of QEMU to be slow. + +This also seems to apply to 32-bit processes in an x86-64 guest. +Additional information: +https://github.com/utmapp/UTM/issues/5468 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2914 b/results/classifier/deepseek-2-tmp/output/mistranslation/2914 new file mode 100644 index 000000000..2e488d971 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2914 @@ -0,0 +1,16 @@ + +JRE fails (SIGSEGV) on x86 Ubuntu 24.04 LTS emulated on Apple Silicon M2 ARM +Description of problem: +JRE (HotSpot Runtime) errors with SIGSEGV on x86 Linux Ubuntu 24.04.2 LTS when it is emulated on Apple Silicon M2. In this case, JRE is being triggered by SBT that is running Scala source code. + +This could be a Qemu issue, an OpenJDK issue, an Apple issue, etc. - Let me know if this is the wrong place/not under the purview of Qemu and I'll post it somewhere else. +Steps to reproduce: +I am attempting to run a Scala project (https://github.com/ucb-bar/chipyard) on a x86 machine emulated on an Apple Silicon device. The project build flow fails on step 5 when Scala sources are compiled and run. You can reproduce the issue by running Chipyard's recommended setup flow here: + +https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#default-requirements-installation + +Then instead of running the given build-setup command in the tutorial, run `./build-setup.sh riscv-tools -s 3 -s 8 -s 7 -s 8 -s 9 -s 10 --use-lean-conda` in order to skip the irrelevant setup steps. + +The SBT build config is in the project's base directory under build.sbt. There is a commonSettings sequence that is inherited by each subsequent project. The flow: line 409 of common.mk is triggered by line 257 & 258 of build-setup.sh, which then triggers SBT with some arguments passed into the SBT executable. +Additional information: +Extensive crash logs and attempts to solve the issue has been documented at this issue on UTM's GitHub: https://github.com/utmapp/UTM/issues/7070 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2935 b/results/classifier/deepseek-2-tmp/output/mistranslation/2935 new file mode 100644 index 000000000..2b253343b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2935 @@ -0,0 +1,25 @@ + +strchrnul detection not suitable for macOS +Description of problem: +When qemu is compiled on macOS 15.4, targeting an earlier macOS version (e.g., 15.1), and then run on this earlier macOS version (15.1), it segfaults. This is because: + +- the meson test for strchrnul succeeds (the function is present in the library) +- the strchrnul function is therefore used +- but that function was introduced in the system's libc in 15.4 only + +The root cause for the bug is that the meson test for strchrnul does not include the appropriate header. Indeed, see the documentation for meson on compiler.has_function (https://mesonbuild.com/Compiler-properties.html#does-a-function-exist) + +> Note that, on macOS programs can be compiled targeting older macOS versions than the one that the program is compiled on. It can't be assumed that the OS version that is compiled on matches the OS version that the binary will run on. +> +> Therefore when detecting function availability with compiler.has_function(), it is important to specify the correct header in the prefix argument. + +The correct fix would be, in qemu's meson.build, to change: + +`cc.has_function('strchrnul')` + +into `cc.has_function('strchrnul', prefix : '#include <string>')` + +This is the recommended best practice and would allow correct detection on all platforms, including macOS. +Steps to reproduce: +1. Install qemu from Homebrew, which is built on macOS 15.4 +2. Run it on a machine with macOS < 15.4 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/2971 b/results/classifier/deepseek-2-tmp/output/mistranslation/2971 new file mode 100644 index 000000000..c82b5cefa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/2971 @@ -0,0 +1,45 @@ + +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/deepseek-2-tmp/output/mistranslation/345 b/results/classifier/deepseek-2-tmp/output/mistranslation/345 new file mode 100644 index 000000000..fb872b710 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/345 @@ -0,0 +1,2 @@ + +Sector translation bug in scsi_unmap_complete_noio diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/372 b/results/classifier/deepseek-2-tmp/output/mistranslation/372 new file mode 100644 index 000000000..e1fc27269 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/372 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the TCG / CPU subsystem diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/415 b/results/classifier/deepseek-2-tmp/output/mistranslation/415 new file mode 100644 index 000000000..956e46ba3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/415 @@ -0,0 +1,2 @@ + +Error handling: Use TFR() macro where applicable diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/419 b/results/classifier/deepseek-2-tmp/output/mistranslation/419 new file mode 100644 index 000000000..59cd74aa4 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/419 @@ -0,0 +1,2 @@ + +bsd-user dumps core for all binaries emulated diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/456 b/results/classifier/deepseek-2-tmp/output/mistranslation/456 new file mode 100644 index 000000000..3e30dd07f --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/456 @@ -0,0 +1,30 @@ + +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/deepseek-2-tmp/output/mistranslation/480 b/results/classifier/deepseek-2-tmp/output/mistranslation/480 new file mode 100644 index 000000000..751a7d5cf --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/480 @@ -0,0 +1,2 @@ + +Supported ARMv8.? Opcodes diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/578 b/results/classifier/deepseek-2-tmp/output/mistranslation/578 new file mode 100644 index 000000000..e82ed3f7c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/578 @@ -0,0 +1,31 @@ + +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/deepseek-2-tmp/output/mistranslation/579 b/results/classifier/deepseek-2-tmp/output/mistranslation/579 new file mode 100644 index 000000000..b18fa5bb7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/579 @@ -0,0 +1,51 @@ + +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/deepseek-2-tmp/output/mistranslation/629791 b/results/classifier/deepseek-2-tmp/output/mistranslation/629791 new file mode 100644 index 000000000..84b16fcaa --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/629791 @@ -0,0 +1,6 @@ + +sysret sets invalid ss + +I'm developing an OS. I use only sysret to enter user space. When an interrupt occurred, it would GPF on iretq'ing from it. On investigating, the cs on the stack is 0x2b (valid and correct). The ss on the stack is 0x20, which has a rpl of 0 which is incorrect. iretq checks that and gpf's. Making the irq handler manually modify it to 0x23 fixes it locally. + +This happens on the non-kvm'ed qemu. I haven't tried the kvm'ed one. Qemu version 0.12.5. I haven't tried with the current development version either. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/640 b/results/classifier/deepseek-2-tmp/output/mistranslation/640 new file mode 100644 index 000000000..2229a8c20 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/640 @@ -0,0 +1,7 @@ + +qemu-system-x86_64 behaving as 32 bits +Description of problem: +Qemu is throwing the error ```file '/grub/i386-pc/normal.mod' not found.``` and going into rescue mode while booting my pendrive with a dual boot installation from scratch from [link](https://wiki.archlinux.org/title/Multiboot_USB_drive). +The files like normal.mod aren't in the i386-pc folder because it's a x86 architecture install. The path it was supposed to see it is ```/grub/x86_64-efi/normal.mod``` +Additional information: + diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/661696 b/results/classifier/deepseek-2-tmp/output/mistranslation/661696 new file mode 100644 index 000000000..65663387d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/661696 @@ -0,0 +1,29 @@ + +incomplete emulation of fstenv under TCG + +Steps to reproduce: + +1) Install Windows (tried XP and 7) in qemu (tried qemu without kvm and qemu-kvm). + +2) Get OllyDbg ( http://ollydbg.de/odbg200.zip ). + +3) Use some Metasploit-encoded file, example included. + +It is not a virus! + +File was generated with Metasploit, command (if i remember it right): `msfpayload windows/exec cmd=notepad R | msfencode -e x86/shikata_ga_nai -t exe -o cmd_exec_notepad.shikata_ga_nai.exe`. + +4) Launch the file under Windows in qemu, make sure it opens a notepad. + +5) Open file under OllyDbg, run (F9) it there. It opens a notpad. Close OllyDbg. + +6) Open file under OllyDbg, trace over (Ctrl+F12) it there. It fails with `Access violation when writing to [some address]`. +Command: 316A 13, XOR DWORD PTR DS:[EDX+13],EBP + +Under native Windows, the trace over command works fine. + +Under VMware the trace works fine. +Under VirtualBox it also fails (checked in the spring). + +$ qemu-kvm --version +QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/672934 b/results/classifier/deepseek-2-tmp/output/mistranslation/672934 new file mode 100644 index 000000000..1cb3904dd --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/672934 @@ -0,0 +1,8 @@ + +FPU incorrect on Mac OS X + +I am using the 0.13.0 release version of QEMU on Mac OS X 10.6.4. I work for a university and the affected guest OS is our own research OS. I believe I found a bug in QEMU's FPU emulation, which only triggers on the Mac. You can reproduce the problem by booting the attached ISO image. + +Investigating the problem, I found that the lua interpreter in our loader component (called "ned") internally uses doubles to represent all lua-numbers. These doubles are showing completely wrong values on QEMU/Mac, resulting in the lua code not processing properly. + +I also attached a patch which fixes the problem for me. The attached ZIP-file also contains "before" and "after" screenshots. Note that booting the ISO on a real machine or on a Linux-QEMU always shows the correct "after" behavior. Only QEMU on the Mac exhibits the wrong "before" behavior without my patch. The patch might break other systems setting the CONFIG_BSD flag, so maybe the preprocessor should check for __APPLE__ instead to make the fix Mac-only. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/678363 b/results/classifier/deepseek-2-tmp/output/mistranslation/678363 new file mode 100644 index 000000000..41c95999c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/678363 @@ -0,0 +1,12 @@ + +Swapping caps lock and control causes qemu confusion + +Running Fedora14 [host], I have caps-lock and control swapped over in my keyboard preferences. + +Qemu doesn't cope very well with this; running an OS inside Qemu (again fedora, suspect that it doesn't matter): + +The physical caps-lock key [which the host uses as control] toggles caps-lock on both press and release. + +The physical control key [which the host uses as caps-lock], acts as both a caps-lock and control key. + +Qemu should either respect my keyboard layout or else ignore it completely. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/713 b/results/classifier/deepseek-2-tmp/output/mistranslation/713 new file mode 100644 index 000000000..dd9a62496 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/713 @@ -0,0 +1,2 @@ + +Missing safe-syscall.inc.S for mips diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/732 b/results/classifier/deepseek-2-tmp/output/mistranslation/732 new file mode 100644 index 000000000..ddaad066a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/732 @@ -0,0 +1,2 @@ + +Can not use --enable-fuzzing on Ubuntu 20.04 Aarch64 diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/74 b/results/classifier/deepseek-2-tmp/output/mistranslation/74 new file mode 100644 index 000000000..c608b62b7 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/74 @@ -0,0 +1,2 @@ + +AUD_set_volume_out takes SWVoiceOut as parameter, but controls HWVoiceOut diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/757702 b/results/classifier/deepseek-2-tmp/output/mistranslation/757702 new file mode 100644 index 000000000..fd92daf85 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/757702 @@ -0,0 +1,4 @@ + +ARM: singlestepping insn which UNDEFs should stop at UNDEF vector insn, not after it + +ARMv7a has lot of undefined instruction from its instruction opcode space. This undefined instructions are very useful for replacing sensitive non-priviledged instructions of guest operating systems (virtualization). The undefined instruction exception executes at <exception_base> + 0x4, where <exception_base> can be 0x0 or 0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at 0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0, seems like this is a new bug. As as example, if we try to execute value "0xec019800" in qemu 0.14.0 then it should cause undefined exception at <exception_base>+0x4 since "0xec019800" is an undefined instruction. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/760976 b/results/classifier/deepseek-2-tmp/output/mistranslation/760976 new file mode 100644 index 000000000..61ab8595d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/760976 @@ -0,0 +1,15 @@ + +Nexenta 3.0.1 fails to install + +The latest git version of qemu (commit 420b6c317de87890e06225de6e2f8af7bf714df0) fails to boot Nexenta3.0.1. I don't know if this is a bug in nextenta, or in QEMU or both. + +You can obtain a bootable image of Nextenta from http://www.nexenta.org/releases/nexenta-core-platform_3.0.1-b134_x86.iso.zip + +Host: Linux/x86_64 gcc4.5 ./configure --enable-linux-aio --enable-io-thread --enable-kvm + +qemu-img create nexenta3.0.1 3G +qemu -hda nexenta3.0.1 -cdrom nexenta-core-platform3.0.1-b134x86.iso -boot d -k en-us -m 256 + +Boots to grub OK, but when you hit install you get panic[cpu0]/thread=fec226c0: vmem_hash_delete(d4404690, d445abc0, 0): bad free. + +You get the same error with or without -enable-kvm \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/786442 b/results/classifier/deepseek-2-tmp/output/mistranslation/786442 new file mode 100644 index 000000000..50de560ba --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/786442 @@ -0,0 +1,8 @@ + +GCC -O2 causes segfaults + +unless compiled without optimizations, no system may be ran except the default with -kvm-enabled +I had to modify config-host.mak and remove -O2 from CFLAGS to be able to work without kvm. + +GCC 4.4.4 qemu-0.14.1 +***NOTE: this has been an issue for several versions. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/788701 b/results/classifier/deepseek-2-tmp/output/mistranslation/788701 new file mode 100644 index 000000000..c0742a3dc --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/788701 @@ -0,0 +1,11 @@ + +qemu-user fails to run rpcgen (i386, x86_64) + +Confirmed on qemu current development tree (git commit aa29141). While trying to run eglibc's rpcgen from native system by qemu-user, I get an error: + +qemu-x86_64 /usr/bin/rpcgen -c /dev/null +fork: Invalid argument + +I am running a Debian Wheezy system and rpcgen comes from libc-dev-bin. Just in case I am attaching my rpcgen binaries from i386 and x86_64 systems. + +Very similar problem was mentioned on the QEMU forum on February 2007, so I guess it might be a known issue. Nevertheless, I was unable to find any information about bug reports, fixes nor workarounds for it so I'm reporting it here. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/796202 b/results/classifier/deepseek-2-tmp/output/mistranslation/796202 new file mode 100644 index 000000000..440c56c1e --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/796202 @@ -0,0 +1,33 @@ + +Doing a 64 bit load from a 32 bit local APIC register is allowed + +Doing + +u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20; + +and later in an interrupt handler + +movq (lapic_idregister), %rcx +movq (%rcx), %rcx + +in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots). +On real hardware only + +movl (%rcx), %ecx + +works (also in qemu). + +Commandline: +qemu-system-x86_64 \ + -kernel $LINUXDIR/arch/x86_64/boot/bzImage \ + -hda $BUILDROOTDIR/output/images/rootfs.ext2 \ + -append "root=/dev/sda rw rootfstype=ext2 maxcpus=4" \ + -cpu phenom \ + -smp 4 \ + -gdb tcp::1234 \ + -net nic -net user + +Guest: +Vanilla Linux Kernel 2.6.37.6 64-bit with buildroot + +Mikael Pettersson from the linux kernel mailinglist told me it's an accepts-invalid bug in qemu. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/796480 b/results/classifier/deepseek-2-tmp/output/mistranslation/796480 new file mode 100644 index 000000000..7a9b7d7e8 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/796480 @@ -0,0 +1,46 @@ + +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/deepseek-2-tmp/output/mistranslation/823 b/results/classifier/deepseek-2-tmp/output/mistranslation/823 new file mode 100644 index 000000000..3962ea19b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/823 @@ -0,0 +1,22 @@ + +rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed. +Description of problem: +qemu rcutorture tests are failing when building qemu for Rawhide. See the scratch build I did here and the follow log files: + +https://koji.fedoraproject.org/koji/taskinfo?taskID=81316487 +https://kojipkgs.fedoraproject.org//work/tasks/6509/81316509/build.log +https://kojipkgs.fedoraproject.org//work/tasks/6508/81316508/build.log +https://kojipkgs.fedoraproject.org//work/tasks/6510/81316510/build.log + +The full error is: + +``` +MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))} G_TEST_SRCDIR=/builddir/build/BUILD/qemu-6.2.0/tests/unit G_TEST_BUILDDIR=/builddir/build/BUILD/qemu-6.2.0/qemu_kvm_build/tests/unit tests/unit/rcutorture --tap -k +ERROR rcutorture - too few tests run (expected 2, got 0) +rcutorture: ../tests/unit/rcutorture.c:321: rcu_update_stress_test: Assertion `p != cp' failed. +make: *** [Makefile.mtest:1208: run-test-149] Error 1 +``` +Steps to reproduce: +1. Compile qemu and run the test suite. +Additional information: +The only significant recent change since it was built successfully is adoption of GCC 12. Could it be a change in compiler that causes this? diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/834 b/results/classifier/deepseek-2-tmp/output/mistranslation/834 new file mode 100644 index 000000000..e612e98c6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/834 @@ -0,0 +1,60 @@ + +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/deepseek-2-tmp/output/mistranslation/842290 b/results/classifier/deepseek-2-tmp/output/mistranslation/842290 new file mode 100644 index 000000000..50fcdbb59 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/842290 @@ -0,0 +1,12 @@ + +MIPS Malta mini-bootloader print function has bad jump instruction + +One of the hardcoded bootloader library instructions in the MIPS Malta mini-bootloader's print function is: + +stl_raw(p++, 0x08000205); /* j 814 */ + +Since this function is loaded at 0xbfc00808, this jump jumps to the middle of nowhere. The properly-encoded instruction is: + +stl_raw(p++, 0x0bf00205); /* j 814 */ + +With this patch, the print function behaves as expected. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/885 b/results/classifier/deepseek-2-tmp/output/mistranslation/885 new file mode 100644 index 000000000..8c92b741b --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/885 @@ -0,0 +1,2 @@ + +linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/889053 b/results/classifier/deepseek-2-tmp/output/mistranslation/889053 new file mode 100644 index 000000000..04b81298a --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/889053 @@ -0,0 +1,16 @@ + +x86: FPU_MAX, FPU_MIN incorrect + +Dear All, + +Bug was found in qemu.git. +Now (0.15, 1.0) all fpu is softfpu. +See target-i386/ops_sse.h: +#define FPU_MIN(size, a, b) (a) < (b) ? (a) : (b) +#define FPU_MAX(size, a, b) (a) > (b) ? (a) : (b) +It is incorrect now, becouse float64 (or 32) is (typedef) uint64_t (or 32). +And if we have signed operands we get error... + +There is a test with this error (spec shinx3 test data, results diffs on machine and qemu (linux)) and fixed patch. See attach. + +Daniil. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/893068 b/results/classifier/deepseek-2-tmp/output/mistranslation/893068 new file mode 100644 index 000000000..3e9bd2b27 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/893068 @@ -0,0 +1,12 @@ + +Spanish keys { and [ did not work + +The keys { and [ did not work inside the virtualized enviorment (widnows 7). The problems happens ussing aqemu as a front end as well as invoking qemu-kvm from command line: + +qemu-kvm -m 8096 eclipse.img -smp cores=4,threads=2 -hdb ander.img -k es + +We have also notices this warning in the console: + +Warning: no scancode found for keysym 314 + +The host system is gentoo stable with some exceptions (mainly qemu-kvm-0.15.1-r1, gcc-4.6.2 and kernel-3.2_rc2) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/896 b/results/classifier/deepseek-2-tmp/output/mistranslation/896 new file mode 100644 index 000000000..6516a6f72 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/896 @@ -0,0 +1,2 @@ + +tcg/arm emits UNPREDICTABLE LDRD insn diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/898 b/results/classifier/deepseek-2-tmp/output/mistranslation/898 new file mode 100644 index 000000000..605a18ab6 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/898 @@ -0,0 +1,2 @@ + +check-tcg sha512-mvx test is failing on s390x hosts diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/904308 b/results/classifier/deepseek-2-tmp/output/mistranslation/904308 new file mode 100644 index 000000000..65277a4b3 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/904308 @@ -0,0 +1,99 @@ + +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/deepseek-2-tmp/output/mistranslation/907063 b/results/classifier/deepseek-2-tmp/output/mistranslation/907063 new file mode 100644 index 000000000..2d005bd23 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/907063 @@ -0,0 +1,11 @@ + +Error reading VMDK4 with footer instead of header + +VMDK4 files can have a footer in the last block, which is the same datastructure as the header but must be used instead if present. In this case, the gd_offset in the usual header at the beginning of the file is the special flag -1 (VMDK 1.1 spec, page 17, "GD_AT_END +"). qemu-img doesn't know about this flag so it goes on to try to read extents with a bogus l1_table from the wrong location in the file. + +I have regression-tested this with various OVAs exported from VSphere/ESXi 3 and 4. Current master and all previous QEMU versions were unable to import any compressed VMDKs with a footer. It now works on all the ones I have. + +bb45ded93115ad4303471c9a492579dc36716547 changed the order of gd_offset and rgd_offset in the VMDK4Header struct. Page 8 of the VMDK 1.1 spec from VMWare shows the structure as rgd_ then gd_, while QEMU now has gd_ *before* rgd_offset. I was only able to get VMDK conversion to work by switching the order back to that specified by VMWare and previously used by QEMU. I don't know what VMDK this commit is referring to, so I can't test to see if I've broken it. :( + +I will submit this patch to the mailing list if I get a chance, but I'm also uploading it here so I don't lose it. \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/911 b/results/classifier/deepseek-2-tmp/output/mistranslation/911 new file mode 100644 index 000000000..4abbf928c --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/911 @@ -0,0 +1,18 @@ + +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/deepseek-2-tmp/output/mistranslation/929 b/results/classifier/deepseek-2-tmp/output/mistranslation/929 new file mode 100644 index 000000000..f085f5295 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/929 @@ -0,0 +1,34 @@ + +qemu-user syscall clone fails +Description of problem: +This seems very similar to the issue reported here (https://bugs.launchpad.net/qemu/+bug/1926996). When attempting to perform the clone syscall, an error of -1 is returned where I would expect it to succeed. Running the same executable outside of qemu works as expected. +Steps to reproduce: +1. gcc clone.c +2. qemu-x86_64 a.out +Additional information: +I've tried building with gcc, zig cc, and clang and the output of each works fine when running natively, but running under qemu fails. I originally discovered it when cross compiling to riscv64 but it doesn't seem to be limited to that architecture. + +``` +// clone.c + +#include <linux/sched.h> +#include <sched.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <stdio.h> + +int main(void) { + + long pid = syscall( SYS_clone, 0, 0, 0, 0, 0 ); + + if (pid < 0) { + printf( "error %ld\n", pid ); + } else if (pid == 0) { + printf( "child %ld\n", pid ); + } else { + printf( "parent %ld\n", pid ); + } + + return 0; +} +``` diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/947 b/results/classifier/deepseek-2-tmp/output/mistranslation/947 new file mode 100644 index 000000000..5bfad3a1d --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/947 @@ -0,0 +1,14 @@ + +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/deepseek-2-tmp/output/mistranslation/965133 b/results/classifier/deepseek-2-tmp/output/mistranslation/965133 new file mode 100644 index 000000000..45d3757ff --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/965133 @@ -0,0 +1,38 @@ + +Sparc64 crash on start + +qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64 architecture. + +With more than 4G of memory sparc64 machine crash on start. + +command line: qemu-system-sparc64 -m 4G + +output: +VNC server running on `127.0.0.1:5900' +qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state +pc: 00000000ffd04c80 npc: 00000000ffd04c84 +General Registers: +%g0-3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%g4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 + +Current Register Window: +%o0-3: 00000000ffd00000 0000000000080000 0000000000080000 0000000000000000 +%o4-7: 0000000000000000 0000000000000000 00000000fff754e1 00000000ffd144d4 +%l0-3: 0000000100000000 00000000fff75c4d 0000000000000000 0000000000000000 +%l4-7: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%i0-3: 0000000000000000 0000000000000000 0000000100000000 0000000000000036 +%i4-7: 00000000ffe87418 00000000ffe87648 00000000fff75591 00000000ffd0bf54 + +Floating Point Registers: +%f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f32: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f40: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f48: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +%f56: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 +pstate: 00000414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0 +cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3 +fsr: 0000000000000000 y: 0000000000000000 fprs: 0000000000000000 +Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/969 b/results/classifier/deepseek-2-tmp/output/mistranslation/969 new file mode 100644 index 000000000..3afe482df --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/969 @@ -0,0 +1,2 @@ + +qemu: Georgian translation diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/980 b/results/classifier/deepseek-2-tmp/output/mistranslation/980 new file mode 100644 index 000000000..f1a51cd05 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/980 @@ -0,0 +1,17 @@ + +Binary emulation of a Solaris-8-compiled dynamically linked C program gives a bus error immediately on startup when running with qemu-sparc +Description of problem: +I am currently trying to use binary emulation to run a dynamically-linked executable C program that was written and compiled on a Solaris 8 VM. However, when I do so, I immediately get a bus error, and I'm not sure what the cause is. Below I'll delineate all of the steps I took to recreate this. +Steps to reproduce: +1. Start Solaris 8 VM (this was done via QEMU, actually, and there are no issues here) +2. Write a simple `.c` program. +3. Compile that program with `/usr/local/bin/gcc`. The name of the program is `binary_emulation`. +4. Test program on the VM to ensure functionality. +5. Stop VM. +6. Mount `.qcow2` on the Linux host so I can easily extract files from it. +7. Copy the entire `/` directory off to `~/binary_emulation/target` +8. Copy `binary_emulation` to a separate directory. +9. `cd` to `.../qemu/build` +10. Run `./qemu-sparc -L ~/binary_emulation/target ~/binary_emulation/binary_emulation` +Additional information: +# diff --git a/results/classifier/deepseek-2-tmp/output/mistranslation/982 b/results/classifier/deepseek-2-tmp/output/mistranslation/982 new file mode 100644 index 000000000..e06cb2e73 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/982 @@ -0,0 +1,38 @@ + +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/deepseek-2-tmp/output/mistranslation/996798 b/results/classifier/deepseek-2-tmp/output/mistranslation/996798 new file mode 100644 index 000000000..ced953bb0 --- /dev/null +++ b/results/classifier/deepseek-2-tmp/output/mistranslation/996798 @@ -0,0 +1,12 @@ + +Incorrect order of task switching + +In Intel specifications (http://download.intel.com/design/processor/manuals/253668.pdf 7.3), we can see: + + 8. Saves the state of the current (old) task in the current task’s TSS. + +… + + 11. Loads the task register with the segment selector and descriptor for the new task's TSS. + +But, in QEMU code (https://raw.github.com/qemu/QEMU/v1.0/target-i386/op_helper.c :375), the order is reversed: TSS registers & segments loads BEFORE save old task state. \ No newline at end of file |