diff options
Diffstat (limited to 'results/classifier/no-thinking-deepseek-r1:32b/output/syscall')
76 files changed, 3008 insertions, 0 deletions
diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 new file mode 100644 index 000000000..d2ad3ea54 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1007 @@ -0,0 +1,4 @@ + + + +qemu-user: add execveat syscall support diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 new file mode 100644 index 000000000..6c3c897d5 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1012 @@ -0,0 +1,44 @@ + + + +9p: newfstatat behaves differently than fstat causing ENOENT for here-documents +Description of problem: +After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error. +Steps to reproduce: +1. I have file `a` with: +``` +cat <<EOF +x +EOF +``` +2. User visible error inside VM: +``` +root@x86_64:~# grep 9p /proc/mounts +/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0 +root@x86_64:~# bash a +cat: -: No such file or directory +``` +3. `strace -fyv bash a` shows: +``` + [pid 291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, +st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0 + [pid 291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory) + [pid 291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5 + [pid 291] write(2</dev/ttyS0>, "-", 1-) = 1 + [pid 291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27 + [pid 291] write(2</dev/ttyS0>, "\n", 1 +``` +Additional information: +In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows: +``` + [pid 283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204, +st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0 + [pid 283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */, +st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0 + [pid 283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 + [pid 283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000 + [pid 283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2 + [pid 283] write(1</dev/ttyS0>, "x\n", 2x +``` + +So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 new file mode 100644 index 000000000..6db76014b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1033 @@ -0,0 +1,30 @@ + + + +fakeroot under qemu fails with 'semop(1): encountered an error: Function not implemented' +Description of problem: +Appears to be the same issue as that discussed and reportedly fixed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965109 + +Running raspberry pi os in a chroot (using schroot). Execution of fakeroot as part of dpkg-buildpackage results in: + +``` +dpkg-buildpackage: info: source package clementine +dpkg-buildpackage: info: source version 1.4.0rc1-836-g4665916ba~bullseye +dpkg-buildpackage: info: source distribution bullseye +dpkg-buildpackage: info: source changed by David Sansome <me@davidsansome.com> +dpkg-buildpackage: info: host architecture armhf + dpkg-source --before-build . + fakeroot debian/rules clean +semop(1): encountered an error: Function not implemented +dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 1 +``` + +This is the same error as reported in bug 965109, but I'm running the most recent version of qemu - I built it from the git repo, so it should include the fix for 965109. +Steps to reproduce: +1. Setup (s)chroot with arm architecture (although the architecture may not matter) +2. Run fakeroot in the chroot +3. Observe the failure related to the semop syscall +Additional information: +- Not sure what other information I can provide to be helpful. +- The command line listed above is what I gather from ps; it's how qemu-arm-static is called by schroot. I've not been able to figure out _how_ schroot calls qemu-arm-static, I only know it does. +- I compiled qemu from source using my own user id, and ran into an issue with make install, so I manually used install to deploy the executable to /usr/local/bin... And then had to symlink that to /usr/bin as schroot apparently hardcodes the location of qemu-arm-static (at least it did not pick up the version I'd placed in /usr/local/bin). diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1052857 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1052857 new file mode 100644 index 000000000..6cf3a4398 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1052857 @@ -0,0 +1,18 @@ + + + +qemu-user compiled static for ppc fails on 64bit hosts + +On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce: + +host$ mkdir powerpc +host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian +host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/ +host$ LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash +I have no name!@guest:/# pwd +/ +I have no name!@guest:/# cd home/ +I have no name!@guest:/home# ls +qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed. + +I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1054831 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1054831 new file mode 100644 index 000000000..96c71a31a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1054831 @@ -0,0 +1,20 @@ + + + +qemu-user-static for sparc32plus : bash: fork: Invalid argument + +On Debian x86-64 host system I setup a sparc chroot using: + +host $ mkdir sparc +host $ sudo debootstrap --arch=sparc --foreign wheezy sparc http://ftp.au.debian.org/debian +host $ sudo cp ~/Git/qemu/sparc32plus-linux-user/qemu-sparc32plus sparc/usr/bin/qemu-sparc32plus-static +host $ LANG=C sudo chroot sparc/ /usr/bin/qemu-sparc32plus-static /bin/bash + +When I then run the second stage of debootstrap I get: + +target $ /debootstrap/debootstrap --second-stage +bash: fork: Invalid argument + +The above procedures works perfectly for armhf. + +This is with current git HEAD (commit 93b6599734f81328ee3d608f57667742cafeea72). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 new file mode 100644 index 000000000..56fc7d509 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075272 @@ -0,0 +1,16 @@ + + + +socket type mapping wrong for mips app-level emulation + +linux-user/syscall.c's do_socket function contains socket type remapping to work around the nonsensically-permuted MIPS socket types. However, it fails to account for the SOCK_NONBLOCK and SOCK_CLOEXEC flags that may be or'd onto the type. Thus, a call from the application such as: + +socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) + +will fail to have the type permutation performed, and will be passed to the system as: + +socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP) + +resulting in EPROTONOSUPPORT. + +To fix this, the flag bits should be masked off of the type before the permutation. They also need remapping themselves (since MIPS uses different values for these flags bits). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 new file mode 100644 index 000000000..7cdd34fbc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1075339 @@ -0,0 +1,6 @@ + + + +linux-user emulation of setsockopt ignores optlen + +setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 new file mode 100644 index 000000000..39d32b76e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1076445 @@ -0,0 +1,48 @@ + + + +qemu-i386 fails on system(3) with a cross-toolchain from Buildroot + +qemu-i386 fails with small C program containing a system(). +The C program is cross-compiled with a toolchain created by buildroot (http://buildroot.net/), gcc version 4.6.3, uClibc version 0.9.33.2 . +qemu version 1.2.0 (built with http://git.buildroot.net/buildroot/tree/package/qemu/qemu.mk) +host machine : Ubuntu 12.04 LTS on x86_64. + + $ cat sys.c + #include <stdio.h> + #include <stdlib.h> + + int main() + { + int ret = system("echo hello"); + printf("%d\n", ret); + } + + $ ../../host/usr/bin/i686-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-i386 ./sys + -1 + +same problem with x86_64 : + $ ../../host/usr/bin/x86_64-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-x86_64 sys + -1 + +works fine with arm : + $ ../../host/usr/bin/arm-buildroot-linux-uclibcgnueabi-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped + $ ../../host/usr/bin/qemu-arm ./sys + hello + 0 + +works fine with mips : + $ ../../host/usr/bin/mips-buildroot-linux-uclibc-gcc -o sys sys.c + $ file sys + sys: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked (uses shared libs), with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70403, not stripped + $ ../../host/usr/bin/qemu-mips sys + hello + 0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 new file mode 100644 index 000000000..b0fbfb334 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1111 @@ -0,0 +1,21 @@ + + + +Calling FUTEX_LOCK_PI with qemu-x86_64-static caused ENOSYS error. +Description of problem: +When I executed the command "perf bench futex lock-pi" in amd64 docker image on s390x, I got the following error. +``` +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +perf: thread 2: Could not lock pi-lock for 0x40006c4480 (-1): Function not implemented +``` + +I searched for this error message in the source code of perf-bench. I think that the following system call caused ENOSYS error. +` syscall(SYS_futex, uaddr, FUTEX_LOCK_PI | opflags, val, timeout, uaddr2, val3)` +Steps to reproduce: +1. Execute the command "perf bench futex lock-pi" in amd64 docker image on s390x +2. +3. +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 new file mode 100644 index 000000000..cd164940b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1238 @@ -0,0 +1,122 @@ + + + +qemu-mipsn32el and qemu-mipsn32 problems with coreutils-9*, fadvise64 or fallocate related? +Description of problem: +- Recently about 15 of the ca. 250 packages in our system set fail during `make install`. A typical error is +> `/usr/bin/install: error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff': Invalid argument` +- Given the timing and the involved binaries (most of the times `install`, but also `cp`), I suspect this was triggered by coreutils-9 +- The problem seems to only occur on ext4 (our release engineering box), but not on btrfs (my home development box) +- The problem seems to be limited to n32 (both big and little endian) + +Here's a run with strace functionality enabled: + +``` +dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # /usr/bin/qemu-mipsn32el -strace /usr/bin/install troff '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin' +3216 brk(NULL) = 0x40032000 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f7ba000 +3216 uname(0x3fffebb0) = 0 +3216 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/etc/ld.so.cache",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe280) = 0 +3216 mmap(NULL,11294,PROT_READ,MAP_PRIVATE,3,0) = 0x3f7b7000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libacl.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4c4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe220) = 0 +3216 mmap(NULL,197008,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f786000 +3216 mmap(0x3f790000,131472,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f790000 +3216 munmap(0x3f786000,40960) = 0 +3216 munmap(0x3f7b1000,20880) = 0 +3216 mprotect(0x3f797000,98304,PROT_NONE) = 0 +3216 mmap(0x3f7af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f7af000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libattr.so.1",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4b4,512) = 512 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe210) = 0 +3216 mmap(NULL,196864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f75f000 +3216 mmap(0x3f760000,131328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f760000 +3216 munmap(0x3f75f000,4096) = 0 +3216 munmap(0x3f781000,57600) = 0 +3216 mprotect(0x3f764000,110592,PROT_NONE) = 0 +3216 mmap(0x3f77f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xf000) = 0x3f77f000 +3216 close(3) = 0 +3216 openat(AT_FDCWD,"/lib32/libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 read(3,0x3fffe4a4,512) = 512 +3216 pread64(3,1073734640,32,34504,1065377824,0) = 32 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe200) = 0 +3216 mmap(NULL,2056864,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 mmap(0x3f570000,1991328,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0) = 0x3f570000 +3216 munmap(0x3f569000,28672) = 0 +3216 munmap(0x3f757000,33440) = 0 +3216 mprotect(0x3f73c000,61440,PROT_NONE) = 0 +3216 mmap(0x3f74b000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x1cb000) = 0x3f74b000 +3216 mmap(0x3f752000,17056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x3f752000 +3216 close(3) = 0 +3216 mmap(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f569000 +3216 set_thread_area(0x3f570580) = 0 +3216 set_tid_address(1062637704,1065348616,1065377824,0,-1,0) = 3216 +3216 set_robust_list(1062637712,12,1065377824,0,-1,0) = -1 errno=89 (Function not implemented) +3216 Unknown syscall 6331 +3216 mprotect(0x3f74b000,16384,PROT_READ) = 0 +3216 mprotect(0x3f77f000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7af000,4096,PROT_READ) = 0 +3216 mprotect(0x4002e000,4096,PROT_READ) = 0 +3216 mprotect(0x3f7fc000,8192,PROT_READ) = 0 +3216 getrlimit(3,1073737152,1064664656,1062638996,1064337736,1064664656) = 0 +3216 munmap(0x3f7b7000,11294) = 0 +3216 getrandom(1064649956,4,1,1064337736,2130640639,1077952576) = 4 +3216 brk(NULL) = 0x40032000 +3216 brk(0x40053000) = 0x40053000 +3216 brk(0x40054000) = 0x40054000 +3216 openat(AT_FDCWD,"/usr/lib/locale/locale-archive",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +3216 statx(3,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffed58) = 0 +3216 mmap(NULL,2097152,PROT_READ,MAP_PRIVATE,3,0) = 0x3f369000 +3216 close(3) = 0 +3216 geteuid() = 0 +3216 umask(0) = 18 +3216 openat(AT_FDCWD,"/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin",O_RDONLY|O_DIRECTORY|O_LARGEFILE|O_PATH) = 3 +3216 statx(AT_FDCWD,"troff",AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 statx(3,"troff",AT_NO_AUTOMOUNT|AT_SYMLINK_NOFOLLOW,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 unlinkat(3,"troff",0) = 0 +3216 openat(AT_FDCWD,"troff",O_RDONLY|O_LARGEFILE) = 4 +3216 statx(4,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 openat(3,"troff",O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE,0600) = 5 +3216 ioctl(5,FICLONE,4) = -1 errno=122 (Operation not supported) +3216 statx(5,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe998) = 0 +3216 lseek(4,0,SEEK_DATA) = 0 +3216 fadvise64(4,0,0,2,1664557525,0) = -1 errno=22 (Invalid argument) +3216 lseek(4,0,SEEK_HOLE) = 716800 +3216 lseek(4,0,SEEK_SET) = 0 +3216 mmap(NULL,139264,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x3f347000 +3216 read(4,0x3f348000,131072) = 131072 +3216 write(5,0x3f348000,122880) = 122880 +3216 read(4,0x3f348000,131072) = 131072 +3216 lseek(5,12288,SEEK_CUR) = 135168 +3216 fallocate(5,FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE,122880,4290510848) = -1 errno=22 (Invalid argument) +3216 openat(AT_FDCWD,"/usr/share/locale/locale.alias",O_RDONLY|O_CLOEXEC) = 6 +3216 statx(6,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x3fffe2c8) = 0 +3216 read(6,0x400333a0,4096) = 2998 +3216 read(6,0x400333a0,4096) = 0 +3216 close(6) = 0 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/coreutils.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc888,18)/usr/bin/install: = 18 +3216 write(2,0x3fffc8b8,79)error deallocating '/var/tmp/portage/sys-apps/groff-1.22.4/image/usr/bin/troff' = 79 +3216 openat(AT_FDCWD,"/usr/share/locale/C.UTF-8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C.utf8/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 openat(AT_FDCWD,"/usr/share/locale/C/LC_MESSAGES/libc.mo",O_RDONLY) = -1 errno=2 (No such file or directory) +3216 write(2,0x3fffc428,18): Invalid argument = 18 +3216 write(2,0x3fffc858,1) + = 1 +3216 close(5) = 0 +3216 close(4) = 0 +3216 munmap(0x3f347000,139264) = 0 +3216 lseek(0,0,SEEK_CUR) = -1 errno=29 (Illegal seek) +3216 close(0) = 0 +3216 close(1) = 0 +3216 close(2)dilfridge-mips64el-n32 /var/tmp/portage/sys-apps/groff-1.22.4/work/groff-1.22.4 # +``` + +More information and debugging on request. Any advice is appreciated. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 new file mode 100644 index 000000000..a19a401fc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1261 @@ -0,0 +1,28 @@ + + + +qemu-user syscall 439 (faccessat2) not implemented - loongarch64 +Description of problem: +On LoongArch64 architecture faccessat syscall is missing and only faccessat2 is present, but it is not handled in linux-user/syscall +Steps to reproduce: +1. Launch a simple bash test script (call it test.sh): if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi +2. The result is "ERROR" even if the file "test.sh" exists and it is readeable +3. The correct result should be "OK" +Additional information: +test.sh: + ``` + if [[ -r test.sh ]] ; then echo OK ; else echo ERROR ; fi + ``` +qemu-loongarch -strace log: + ``` +[...] +12579 statx(255,"",AT_EMPTY_PATH|AT_NO_AUTOMOUNT,STATX_BASIC_STATS,0x0000004000802a50) = 0 +12579 lseek(255,0,SEEK_CUR) = 0 +12579 read(255,0x2016d490,56) = 56 +12579 Unknown syscall 439 +12579 write(1,0x20172010,6) = 6 +12579 read(255,0x2016d490,56) = 0 +12579 rt_sigprocmask(SIG_BLOCK,0x0000004000802b60,0x0000004000802be0) = 0 +12579 rt_sigprocmask(SIG_SETMASK,0x0000004000802be0,NULL) = 0 +12579 exit_group(0) + ``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 new file mode 100644 index 000000000..96b55b038 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1394 @@ -0,0 +1,64 @@ + + + +Byte-swapping issue in getresuid on qemu-user-sparc64 +Description of problem: +When calling getresuid() in the big-endian sparc64 guest, the uid_t values are written with their 16-bit halves reversed. + +For example, the UID 0x000003e8 (1000) becomes 0x03e80000. +Steps to reproduce: +A minimal test case looks like this: +```c +#define _GNU_SOURCE +#include <stdio.h> +#include <sys/types.h> +#include <pwd.h> +#include <unistd.h> + +int main(int argc, char **argv) { + struct passwd *pw = getpwuid(geteuid()); + if (pw == NULL) { + perror("getpwuid failure"); + return 1; + } + printf("getpwuid()->pw_uid=0x%08x\n", pw->pw_uid); + + uid_t ruid = 0, euid = 0, suid = 0; + if (getresuid(&ruid, &euid, &suid) != 0) { + perror("getresuid failure"); + return 1; + } + printf("getresuid()->suid=0x%08x\n", suid); + + return 0; +} +``` + +Compile and run with: +``` +$ sparc64-linux-gnu-gcc -Wall -O0 -g -o sid-sparc64/test test.c +$ sudo chroot sid-sparc64 +[chroot] $ qemu-sparc64-static ./test +``` + +Alternatively, static compilation without a chroot is also possible (despite a warning about `getpwuid()`): +``` +$ sparc64-linux-gnu-gcc -static -Wall -O0 -g -o test test.c +$ qemu-sparc64-static ./test +``` + +Expected output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x000003e8 +``` + +Actual output: +``` +$ ./test +getpwuid()->pw_uid=0x000003e8 +getresuid()->suid=0x03e80000 +``` +Additional information: +I'm not sure if this is a glibc, qemu or kernel issue, but it doesn't occur outside qemu. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 new file mode 100644 index 000000000..c4c233a02 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1457275 @@ -0,0 +1,108 @@ + + + +qemu-user hangs in m{,un}map loop + +Gentoo amd64 there, tried both 2.3.0 and eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces with qemu-x86_64 as well. + +∞ strace qemu-arm bin/true 2>&1| head -n 100 +execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0 +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +brk(0) = 0x62a4d070 +brk(0x62a4e2b0) = 0x62a4e2b0 +arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0 +set_tid_address(0x62a4dc50) = 7841 +set_robust_list(0x62a4dc60, 24) = 0 +rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17 +brk(0x62a6f2b0) = 0x62a6f2b0 +brk(0x62a70000) = 0x62a70000 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 +mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000 +mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0 +clone(child_stack=0x2c9527f8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 7842 +rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +gettimeofday({1432174351, 569148}, NULL) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +time(NULL) = 1432174351 +openat(AT_FDCWD, "/usr/gnemul/qemu-arm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument) +mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c94eff9000 +brk(0x62a91000) = 0x62a91000 +mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x8000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x9000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xa000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xb000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xc000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xd000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xe000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xf000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x10000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x11000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 new file mode 100644 index 000000000..4204668d8 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1470170 @@ -0,0 +1,43 @@ + + + +Unsupported syscalls 370 and 355 + +Qemu seems to be missing syscalls 370 and 355 when running qemu usermode arm. These are used by systemd or some similar new package. This can be detected by creating an debian sid armhf with qemu debootstrap. When the system is launched with "systemd-nspawn -bD sid-arm" this happens (newest git as of today): + +pawning container sid-arm on /home/jpakkane/qemutest/sid-arm. +Press ^] three times within 1s to kill container. +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +Failed to create directory /home/jpakkane/qemutest/sid-arm//sys/fs/selinux: Read-only file system +/etc/localtime is not a symlink, not updating container timezone. +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 384 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +qemu: Unsupported syscall: 370 +systemd 221 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN) +Detected virtualization systemd-nspawn. +Detected architecture arm. + +Welcome to Debian GNU/Linux stretch/sid! + +Set hostname to <manos>. +qemu: Unsupported syscall: 355 +Failed to allocate manager object: Function not implemented +[!!!!!!] Failed to allocate manager object, freezing. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 new file mode 100644 index 000000000..30acd8686 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1516408 @@ -0,0 +1,34 @@ + + + +sh4: Unsupported syscall: 186 + +Hello! + +I'm currently testing qemu as a possibility to set up a buildd for the Debian sh4 port. + +I set up qemu and an sh4 chroot as described in the Debian Wiki [1]. This seems to be working mostly fine (besides the fact that qemu segfaults on an amd64 host while it runs fine on an i386 host, I'll file a separate bug report). However, when installing python3.4 in the sh4 chroot, qemu repeatedly printed an error message about an unimplemented syscall: 186: + +qemu: Unsupported syscall: 186 + +From the source code in linux-user/sh4/syscall_nr.h it's apparent that 186 is defined as + +#define TARGET_NR_sigaltstack 186 + +Looking at the implementation part, it becomes obvious that this syscall is not enabled for sh4: + +#if defined(TARGET_I386) || defined(TARGET_ARM) || defined(TARGET_MIPS) || \ + defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_ALPHA) || \ + defined(TARGET_M68K) || defined(TARGET_S390X) || defined(TARGET_OPENRISC) + ret = do_sigaltstack(arg1, arg2, get_sp_from_cpustate((CPUArchState *)cpu_env)); + break; +#else + goto unimplemented; +#endif + +Is there any particular reason why TARGET_NR_sigaltstack is not enabled on sh4? If not, could you enable it? + +Thanks, +Adrian + +> [1] https://wiki.debian.org/QemuUserEmulation \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 new file mode 100644 index 000000000..957d6dfd0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1617929 @@ -0,0 +1,53 @@ + + + +qemu hangs in pselect syscall + +I'm using git commit d75aa4372f0414c9960534026a562b0302fcff29 (v2.7.0-rc4) configured with; + --enable-linux-user \ + --disable-system \ + --disable-tools \ + --disable-guest-agent \ + --static --disable-linux-aio \ + --disable-fdt \ + --without-pixman \ + --disable-blobs \ +Stable version (v2.6.0) also have the same problem. + +In a chroot environment I ran below command-line to compile some things, different sources each time. + /usr/bin/qemu-arm -0 /usr/bin/edje_cc /usr/bin/edje_cc -id /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/images_mob/ -DBROWSER_RESOLUTION_720x1280=1 -DPROFILE_MOBILE=1 /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/services/SimpleUI/edc/TextPopup_mob.edc /home/abuild/rpmbuild/BUILD/org.tizen.browser-1.6.2/build-tizen/services/SimpleUI/720x1280_TextPopup.edj + +Here is back trace with gdb; +#0 safe_syscall_end () at /usr/src/debug/qemu-2.6.94/linux-user/host/i386/safe-syscall.inc.S:78 +#1 0x60049370 in safe_pselect6 (nfds=10, readfds=0xffa31b5c, writefds=0xffa31bdc, exceptfds=0xffa31c5c, timeout=0x0, sig=0x0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:855 +#2 0x6004b2fe in do_select (n=10, rfd_addr=1082122232, wfd_addr=1082122360, efd_addr=1082122488, target_tv_addr=0) + at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:1386 +#3 0x6005e5ba in do_syscall (cpu_env=0x640d0454, num=142, arg1=10, arg2=1082122232, arg3=1082122360, arg4=1082122488, arg5=0, arg6=1087473216, arg7=0, + arg8=0) at /usr/src/debug/qemu-2.6.94/linux-user/syscall.c:9690 +#4 0x60045def in cpu_loop (env=0x640d0454) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:876 +#5 0x60047640 in main (argc=10, argv=0xffa33c84, envp=0xffa33cb0) at /usr/src/debug/qemu-2.6.94/linux-user/main.c:4817 + +Attached core file taken from gdb. To see the stack frame, you could try; +$ tar -xf reproduced_118_04.tar.bz2; gdb --core core.1823 qemu-arm + +And recent strace log for PID 1823(stucked one); +79965 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79966 [ 313s] ==>[pselect6(0xa)=] +79967 [ 313s] [pselect6=0x1]<== +79968 [ 313s] 1823 :0x8e _newselect(10,[9,],[],[],NULL) +79969 [ 313s] 1823 :0x8e => = 0x00000001 ([9,],[],[],NULL) +79970 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79971 [ 313s] 1823 :0xfc epoll_wait(3,1082121456,32,0,1082121456,3) +79972 [ 313s] 1823 :0xfc => = 0 +79973 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79974 [ 313s] 1823 :0x3 read(9,0x407fdeec,16) +79975 [ 313s] 1823 :0x3 => = 8 +79976 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79977 [ 313s] 1823 :0x107 clock_gettime(1,1082122120,0,1082829144,1082827588,0) +79978 [ 313s] 1823 :0x107 => = 0 +79979 [ 313s] 1823 :0x8e _newselect(10,[9,3,],[],[],NULL) +79980 [ 313s] ==>[pselect6(0xa)=] + +I'm using 64-bit Ubuntu with kernel release Linux 3.19.0-25-generic #26~14.04.1-Ubuntu. +Reproducibility is low. One occurrence out of 50+ trials. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 new file mode 100644 index 000000000..65fb39f5e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1619896 @@ -0,0 +1,53 @@ + + + +linux-user missing cmsg IP_PKTINFO support ("Unsupported ancillary data: 0/8") + +Hello, + +I have the following issue when launching the Teamspeak Server x86 binary on an arm host. + +Host: + Linux 4.6.2 (vanilla) + Ubuntu 14.04.5 LTS + HW: Cubietruck board, armv7l + + +Used SW: Release archive qemu-2.7.0.tar.bz2 and git commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a +Configure options: + ../configure --target-list=i386-linux-user +I attached the output of the configure script as configure.log + +Testcase: + +1. Download and extract TeamSpeak 3 Server 3.0.13.3 (x86) + Souce: http://dl.4players.de/ts/releases/3.0.13.3/teamspeak3-server_linux_x86-3.0.13.3.tar.bz2 + +2. Modifiy ts3server_minimal_runscript.sh for ease of use + - ./ts3server $@ + + /usr/local/bin/qemu-i386 ./ts3server $@ + +3. Execute ./ts3server_minimal_runscript.sh + +Wait for 6 Minutes until teamspeak server started. QEMU saturates the cpu while Teamspeak is precomputing a puzzle. (Whatever that means) + +After that Teamspeak settles with the following output: + 2016-09-03 10:50:59.555582|INFO |Query | |listening on 0.0.0.0:10011, :::10011 + +The Qemu process is now idling with ~2% cpu load. This is actually the first time for me that QEMU is able to successfully launch the Teamspeak server. Kudos! + +4. Connect client 1 + +TS Clients can connect, but the following line is printed pretty often: + Unsupported ancillary data: 0/8 + +The line seems to come from qemu (linux-user/syscall.c) + + +5. Connect client 2 +When a second client is connected the audio transmission is successful for a few seconds, but the server drops the connection after that and refuses to take new connections. + +Please let me know, if you need more information. I'll gladly provide strace or valgrind logs. + +Best regards, +Tobias \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 new file mode 100644 index 000000000..459b87752 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1643619 @@ -0,0 +1,35 @@ + + + +netlink broken on big-endian mips + +Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159) + +As the summary says, netlink is completely broken on big-endian mips running qemu-user. + +Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes. + +[...] +[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0 +[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0 +[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0 +[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0 +[pid 11249] time([1479745823]) = 1479745823 +[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40 +[pid 11249] recvmsg(3, + +Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped. + +Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason. + +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1, + #ifdef TARGET_NR_socket + case TARGET_NR_socket: + ret = do_socket(arg1, arg2, arg3); +- fd_trans_unregister(ret); + break; + #endif + #ifdef TARGET_NR_socketpair \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 new file mode 100644 index 000000000..f6d257a86 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1689367 @@ -0,0 +1,29 @@ + + + +In qemu chroot, repeating "qemu: Unsupported syscall: 384" messages. sys_getrandom ? + +On exec of an armv7 qemu chroot on my local x86_64 desktop, launched via + + /usr/sbin/qemu-binfmt-conf.sh + +from + + qemu-linux-user-2.9.0-374.1.x86_64 + +on the host, inside the chroot any compile activity is laced with repetitions of + + qemu: Unsupported syscall: 384 + +messages. + +This wasn't always the case -- but, TBH, it's been ~ 6 months since I used this env, and there have been scads of usual pkg updates in the interim. These messages appear to be non-fatal, with no particular effect at all; at least not so far ... + +From a chat in #IRC, + + [10:05] davidgiluk clever/pgnd: I see it as getrandom + [10:05] davidgiluk pgnd: https://fedora.juszkiewicz.com.pl/syscalls.html sort it on the ARM table and you can easily see it + [10:05] clever arch/arm/tools/syscall.tbl:384 common getrandom sys_getrandom + [10:06] davidgiluk pgnd: my *guess* is that something is calling getrandom, getting told it's not implemented and then falling back to using /dev/urandom + [10:10] pgnd davidgiluk: If that *is* the case, is it to be considered a problem, or just informational? + [10:12] davidgiluk pgnd: As long as it's falling back probably informational; but someone should probably go and wire up sys_getrandom at some point \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 new file mode 100644 index 000000000..9eea4be1a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1696773 @@ -0,0 +1,10 @@ + + + +golang calls to exec crash user emulation + +An example program can be found here: + +https://github.com/willnewton/qemucrash + +This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures). \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 new file mode 100644 index 000000000..1ee2c3ed6 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701808 @@ -0,0 +1,19 @@ + + + +stack smashing in or after recvmsg system call in aarch64 user mode + +A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware. + +How to reproduce: +$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0 +$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out +*** stack smashing detected ***: ./a.out terminated +qemu: uncaught target signal 6 (Aborted) - core dumped + +On native aarch64 hardware: +$ ./a.out +$ echo $? +0 + +The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 new file mode 100644 index 000000000..34a76741a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701971 @@ -0,0 +1,48 @@ + + + +multithreading not working right under qemu user mode for sh4 + +In a multithreaded program running under qemu-sh4 (version 2.9.0), thread termination and/or pthread_join is not working right. + +The attached program works natively on all kinds of platforms, and under qemu user mode emulation for at least alpha, armelhf, aarch64, powerpc64le. + +How to reproduce: +- Compile the program: sh4-linux-gnu-gcc-5 -O -Wall -lpthread -o test-tls test-tls.c +- Set environment variables for running qemu-sh4. +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-tls + +Expected behaviour: After the "Worker xxxxx dying" line, the main() function prints "OK", and the program terminates. + +Actual behaviour (only on sh4): After the "Worker xxxxx dying" line, it hangs. Attaching gdb to qemu shows 15 threads with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=128, val=val@entry=2, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161181992) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161181992, uaddr2=4134624624, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-160342672, + arg6=-161181992, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=env@entry=0x5584fb3d04f8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86f5dd5 in clone_func (arg=0x7fff4d485c20) at /build/qemu-2.9.0/linux-user/syscall.c:6234 +#6 0x00007f08f05a46ba in start_thread (arg=0x7f08f1368700) at pthread_create.c:333 +#7 0x00007f08f02da3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 + +and 1 thread with a stack trace like +#0 safe_syscall_base () at /build/qemu-2.9.0/linux-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005584f86f4c48 in safe_futex (uaddr=<optimized out>, op=op@entry=0, val=val@entry=18875, timeout=<optimized out>, uaddr2=uaddr2@entry=0x0, + val3=val3@entry=-161180376) at /build/qemu-2.9.0/linux-user/syscall.c:921 +#2 0x00005584f870353b in do_futex (val3=-161180376, uaddr2=4135101768, timeout=0, val=<optimized out>, op=<optimized out>, uaddr=<optimized out>) + at /build/qemu-2.9.0/linux-user/syscall.c:7147 +#3 do_syscall (cpu_env=<optimized out>, num=240, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=0, arg5=-159865528, + arg6=-161180376, arg7=0, arg8=0) at /build/qemu-2.9.0/linux-user/syscall.c:11692 +#4 0x00005584f86f454a in cpu_loop (env=0x5584fb3b99a8) at /build/qemu-2.9.0/linux-user/main.c:2676 +#5 0x00005584f86c12d3 in main (argc=<optimized out>, argv=0x7fff4d4878b8, envp=<optimized out>) + at /build/qemu-2.9.0/linux-user/main.c:4860 + +and 1 thread with a stack trace like +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x00005584f876eab5 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x5584faa43d84 <rcu_call_ready_event>) at /build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x00005584f87748ce in call_rcu_thread (opaque=<optimized out>) at /build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f08f05a46ba in start_thread (arg=0x7f08eff62700) at pthread_create.c:333 +#5 0x00007f08f02da3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701973 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701973 new file mode 100644 index 000000000..1b13a29b0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701973 @@ -0,0 +1,20 @@ + + + +pread does not work right under qemu-sh4 + +The pread system call returns a wrong value in some case, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pread test-pread.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pread + +Expected output: +ret=1 errno=0 + +Actual output: +ret=0 errno=2 +test-pread.c:44: assertion 'ret == 1' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 new file mode 100644 index 000000000..ea81509d9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1701974 @@ -0,0 +1,20 @@ + + + +pwrite does not work right under qemu-sh4 + +The pwrite system call has no effect when writing to a non-zero file position, in a program running under qemu-sh4 (version 2.9.0). + +How to reproduce: +- Compile the program: + sh4-linux-gnu-gcc-5 -O -Wall -static -o test-pwrite test-pwrite.c +- Set environment variable for using qemu-sh4 (actually not needed, since the program is statically linked here). +- ~/inst-qemu/2.9.0/bin/qemu-sh4 test-pwrite + +Expected output: +buf = 01W3456789 + +Actual output: +buf = 0123456789 +test-pwrite.c:56: assertion 'strcmp ("01W3456789",buf) == 0' failed +qemu: uncaught target signal 6 (Aborted) - core dumped \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 new file mode 100644 index 000000000..e0209f879 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1716292 @@ -0,0 +1,33 @@ + + + +User mode emulation returns wrong value for write(fd, NULL, 0) + +QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c) +OS version: Ubuntu 14.04.3 +Configured with: ../configure --target-list=x86_64-linux-user + +QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1. + +I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case: + +zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c +#include <stdio.h> +#include <unistd.h> +#include <fcntl.h> + +int main() { + ssize_t ret = write(STDOUT_FILENO, NULL, 0); + fprintf(stderr, "write returned %ld\n", ret); + return 0; +} +zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c +zhuowei@zhuowei-tablet:/tmp$ uname -a +Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes +write returned 0 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes +write returned -1 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version +qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 new file mode 100644 index 000000000..13658861b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1726394 @@ -0,0 +1,8 @@ + + + +Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) + +qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address) unmodified, but the third argument is an address to a BPF filter, causing an EFAULT. Now, the filter is architecture-specifc, so you can't just rewrite the addresses, so the safest bet is to just return an error here. + +I guess you should just return EINVAL, but not sure. I'd really like something that can be identified, so seccomp errors can be ignored when it's not supported. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 new file mode 100644 index 000000000..b161a72f3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1728116 @@ -0,0 +1,50 @@ + + + +Empty /proc/self/auxv (linux-user) + +The userspace Linux API virtualization used to fake access to /proc/self/auxv, to provide meaningful data for the guest process. + +For newer qemu versions, this fails: The openat() is intercepted, but there's no content: /proc/self/auxv has length zero (i.e. reading from it returns 0 bytes). + +Good: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +256 /proc/self/auxv + +Bad: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +0 /proc/self/auxv + +This worked in 2.7.1, and fails in 2.10.1. + +This causes e.g. any procps-ng-based tool to segfault while reading from /proc/self/auxv in an endless loop (probably worth another bug report...) + +Doing a "git bisect" shows that this commit: https://github.com/qemu/qemu/commit/7c4ee5bcc introduced the problem. + +It might be a simple logic (subtraction in the wrong direction?) or sign-ness error: Adding some logging (to v2.10.1) + +diff --git a/linux-user/syscall.c b/linux-user/syscall.c +index 9b6364a..49285f9 100644 +--- a/linux-user/syscall.c ++++ b/linux-user/syscall.c +@@ -7469,6 +7469,9 @@ static int open_self_auxv(void *cpu_env, int fd) + abi_ulong len = ts->info->auxv_len; + char *ptr; + ++ gemu_log(TARGET_ABI_FMT_lu"\n", len); ++ gemu_log(TARGET_ABI_FMT_ld"\n", len); ++ + /* + * Auxiliary vector is stored in target process stack. + * read in whole auxv vector and copy it to file + +shows this output: + +$ x86_64-linux-user/qemu-x86_64 /usr/bin/cat /proc/self/auxv | wc -c +18446744073709551264 +-352 +0 + +And 352 could be the expected length. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 new file mode 100644 index 000000000..fc8e0fa87 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1729 @@ -0,0 +1,50 @@ + + + +mremap fails with EFAULT if address range overlaps with stack guard +Description of problem: +When running 32-bit user-static on 64-bit host, `mremap` behave differently from the kernel. This difference let programs that call `pthread_getattr_np` on musl-libc to run into a loop on repeated calling `mremap`. + +https://git.musl-libc.org/cgit/musl/plain/src/thread/pthread_getattr_np.c + +``` c + while (mremap(p-l-PAGE_SIZE, PAGE_SIZE, 2*PAGE_SIZE, 0)==MAP_FAILED && errno==ENOMEM) + l += PAGE_SIZE; +``` +Steps to reproduce: +Compile the following program against musl-libc arm 32-bit, and run it in qemu-user-static on x86_64 host. + +``` c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} +``` + +For example, on x86_64 fedora 38 with podman and qemu-user-static installed, we can reproduce this with alpine container: + +``` +$ podman run --rm -it --arch arm/v7 docker.io/library/alpine:latest + +/ # apk add alpine-sdk + +...... + +/ # cat test.c +#define _GNU_SOURCE +#include <pthread.h> + +int main(int argc, char *argv[]) { + pthread_attr_t attr; + return pthread_getattr_np(pthread_self(), &attr); +} + +/ # gcc test.c + +/ # ./a.out +``` +Additional information: +Original thread on musl mail list where this was initially reported: https://www.openwall.com/lists/musl/2017/06/15/9 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 new file mode 100644 index 000000000..2ec071756 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1734792 @@ -0,0 +1,10 @@ + + + +linux-user mode does not support memfd_create syscall + +qemu-x86_66 GIT HEAD fails on a userspace application that requires memfd_create with: + +"qemu: Unsupported syscall: 319". + +memfd_create support needs to be implemented in QEMU. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 new file mode 100644 index 000000000..10955285a --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1738545 @@ -0,0 +1,34 @@ + + + +Go binaries panic with "mmap errno 9" on qemu-user + +Go binaries panic with "mmap errno 9" on qemu-user. + +root@nofan:/# cat hello.go +package main + +import "fmt" + +func main() { + fmt.Println("hello world") +} +root@nofan:/# gccgo-7 hello.go -o hello +root@nofan:/# ./hello +mmap errno 9 +fatal error: mmap + +runtime stack: +mmap errno 9 +fatal error: mmap +panic during panic + +runtime stack: +mmap errno 9 +fatal error: mmap +stack trace unavailable +root@nofan:/# + +Tested with qemu from git master with Debian unstable for armel. + +Same binaries work fine on real hardware. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 new file mode 100644 index 000000000..a2237f14e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1749393 @@ -0,0 +1,29 @@ + + + +sbrk() not working under qemu-user with a PIE-compiled binary? + +In Debian unstable, we recently switched bash to be a PIE-compiled binary (for hardening). Unfortunately this resulted in bash being broken when run under qemu-user (for all target architectures, host being amd64 for me). + +$ sudo chroot /srv/chroots/sid-i386/ qemu-i386-static /bin/bash +bash: xmalloc: .././shell.c:1709: cannot allocate 10 bytes (0 bytes allocated) + +bash has its own malloc implementation based on sbrk(): +https://git.savannah.gnu.org/cgit/bash.git/tree/lib/malloc/malloc.c + +When we disable this internal implementation and rely on glibc's malloc, then everything is fine. But it might be that glibc has a fallback when sbrk() is not working properly and it might hide the underlying problem in qemu-user. + +This issue has also been reported to the bash upstream author and he suggested that the issue might be in qemu-user so I'm opening a ticket here. Here's the discussion with the bash upstream author: +https://lists.gnu.org/archive/html/bug-bash/2018-02/threads.html#00080 + +You can find the problematic bash binary in that .deb file: +http://snapshot.debian.org/archive/debian/20180206T154716Z/pool/main/b/bash/bash_4.4.18-1_i386.deb + +The version of qemu I have been using is 2.11 (Debian package qemu-user-static version 1:2.11+dfsg-1) but I have had reports that the problem is reproducible with older versions (back to 2.8 at least). + +Here are the related Debian bug reports: +https://bugs.debian.org/889869 +https://bugs.debian.org/865599 + +It's worth noting that bash used to have this problem (when compiled as a PIE binary) even when run directly but then something got fixed in the kernel and now the problem only appears when run under qemu-user: +https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1518483 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 new file mode 100644 index 000000000..cfe5b3d57 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756 @@ -0,0 +1,46 @@ + + + +qemu8-user on Linux: SIGSEGV because brk(NULL) does not exist +Description of problem: +On Linux, the return value of the system call brk(NULL) need not point to a page that exists. +If so, then qemu8-user will generate SIGSEGV at the next call to brk() with a higher value, +because qemu8 believes that it should maintain contiguous .bss with bytes of value 0. +Thus qemu8-user so calls `memset(g2h_untagged(target_brk), 0, brk_page - target_brk); +in do_brk() at ../linux-user/syscall.c:867, and this generates SIGSEGV at +the non-existent page that covers brk(NULL). + +Instead, the safest thing to do is nothing at all. +Linux deliberately returns a random value for brk(NULL), subject to the conditions +that the value be at least as large as the maximum over all PT_LOAD of (.p_vaddr + .p_memsz), +and "somewhat near" that maximum. The purpose of randomness is to use variability +to interfere with effectiveness of malware, and to expose application coding errors +regarding brk() and sbrk(). If qemu-user wants to preserve contiguous .bss, +then qemu-user should call memset() only if the first page of the range exists. +(As explained in the next paragraph, "contiguous .bss" is a murky concept.) + +Linux itself is partly to blame, because it computes the maximum (.p_vaddr + .p_memsz) +over all the PT_LOAD of the most recent execve(). The most recent execve() seen by +Linux might have no relationship to the state of the address space at the time of +_either_ call to brk(). The app can do arbitrary mmap, munmap, mprotect at any time. +In particular, the run-time de-compressor of UPX does exactly that for a compressed +main program. The maximum computed by Linux is for the compressed program, +which has a different layout than the de-compressed program. + +There is a Linux system call prctl(PR_SET_MM_BRK, new_value) which sets a value +for "the brk", but that syscall tries to validate the new_value based on +the most recent execve(). Once again, that has no relationship to the current +layout of the address space produced by the UPX de-compressor. +Steps to reproduce: +1. build qemu8-x86_64 from +``` +commit fcb237e64f9d026c03d635579c7b288d0008a6e5 (HEAD -> master, origin/master, origin/HEAD) +Merge: 2ff49e96ac c00aac6f14 +Date: Mon Jul 10 09:17:06 2023 +0100 +``` +2. run `build/qemu-x86_64 -strace upx-4.0.2-amd64_linux/upx --version` where the upx +is from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-amd64_linux.tar.xz +3. output ends with +``` +372621 close(3) = 0 +372621 munmap(0x0000004000803000,3055) = 0 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756807 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756807 new file mode 100644 index 000000000..3ab520168 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1756807 @@ -0,0 +1,70 @@ + + + +performance regression in qemu-user + proot + +To reproduce: + +1. Install qemu-user-static and proot +2. Enter some arm chroot using them: + + proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash + +3. Run a command which normally takes a short but measurable amount of time: + + cd /usr/share/doc && time grep -R hello + +Result: + +This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. + +Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. + +If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. + +Logs: + + + +System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 +qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) +proot 5.1.0 + +al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-desktop:/# cd /usr/share/doc +root@al-desktop:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m0.066s +user 0m0.040s +sys 0m0.008s + + + + + +System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) +proot 5.1.0 + +al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-thinkpad:/# cd /usr/share/doc +root@al-thinkpad:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m24.176s +user 0m0.366s +sys 0m11.352s + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu (not installed) +ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 +Uname: Linux 4.15.0-12-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +Date: Mon Mar 19 07:13:25 2018 +InstallationDate: Installed on 2018-03-18 (0 days ago) +InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1760 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1760 new file mode 100644 index 000000000..336c62075 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1760 @@ -0,0 +1,56 @@ + + + +qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90) +Description of problem: +qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386. +``` +$ strace ./oldmmap +execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0 +[ Process PID=405233 runs in 32 bit mode. ] +mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000 +exit(5) = ? ++++ exited with 5 +++ + +$ build/qemu-i386 -strace ./oldmmap +405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000 +405254 exit(5) +``` +Steps to reproduce: +1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S # build 32-bit executable +2. strace ./oldmmap # run under strace +3. build/qemu-i386 -strace ./oldmmap # run under "qemu-i386 -strace" +4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did. +Additional information: +``` +$ cat oldmmap.S +MAP_FIXED= 0x10 +MAP_PRIVATE= 0x02 +MAP_ANONYMOUS= 0x20 + +PROT_READ= 1 +PROT_WRITE= 2 +PROT_EXEC= 4 + +_NR_exit = 1 +_NR_mmap = 90 // oldmmap: %ebx -> array of 6 arguments + + .globl _start +_start: + push $0 // offset + push $-1 // fd + push $MAP_PRIVATE|MAP_ANONYMOUS // flags + push $PROT_READ|PROT_WRITE // protection + push $2<<12 // length + push $0 // addr (kernel chooses) + mov %esp,%ebx + mov $_NR_mmap,%eax + int $0x80 + nop + + mov $5,%ebx + mov $_NR_exit,%eax + int $0x80 + hlt +$ +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 new file mode 100644 index 000000000..245df7766 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1791796 @@ -0,0 +1,126 @@ + + + +unimplemented thread syscalls in nios2 user-mode emulation + +This bug is reported against the 3.0 release. + +I noticed that the GCC test gcc.dg/torture/tls/tls-test.c is failing when run in user-mode qemu for nios2 target. The problem appears to be that the thread-related syscalls are unimplemented in qemu. Here is output from running with -strace: + +22484 brk(NULL) = 0x00005000 +22484 uname(0x7fffef5a) = 0 +22484 faccessat(AT_FDCWD,"/etc/ld.so.preload",R_OK,0x5) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls/libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 errno=2 (No such file or directory) +22484 fstatat64(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./tls",0x7fffe870,0) = -1 errno=2 (No such file or directory) +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libm.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe954,512) = 512 +22484 fstat64(3,0x7fffe870) = 0 +22484 mmap2(NULL,803596,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f716000 +22484 mmap2(0x7f7d8000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0xc1) = 0x7f7d8000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libpthread.so.0",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe948,512) = 512 +22484 mmap2(NULL,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x7f714000 +22484 fstat64(3,0x7fffe864) = 0 +22484 mmap2(NULL,120700,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f6f6000 +22484 mprotect(0x7f70e000,4096,PROT_NONE) = 0 +22484 mmap2(0x7f70f000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x18) = 0x7f70f000 +22484 mmap2(0x7f712000,6012,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f712000 +22484 close(3) = 0 +22484 openat(AT_FDCWD,"/scratch/sandra/nios2-linux-trunk3/obj/test-2018.11-999999-nios2-linux-gnu/host-x86_64-linux-gnu/sourceryg++-2018.11/nios2-linux-gnu/libc/./lib/./libc.so.6",O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 +22484 read(3,0x7fffe93c,512) = 512 +22484 fstat64(3,0x7fffe858) = 0 +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) +sandra@build2-trusty-cs:/scratch/sandra/nios2-linux-trunk3$ +22484 mmap2(NULL,1491048,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 0x7f589000 +22484 mmap2(0x7f6de000,86016,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x154) = 0x7f6de000 +22484 mmap2(0x7f6f3000,8296,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0) = 0x7f6f3000 +22484 close(3) = 0 +22484 mprotect(0x7f6de000,65536,PROT_READ) = 0 +22484 mprotect(0x7f70f000,8192,PROT_READ) = 0 +22484 mprotect(0x7f7d8000,4096,PROT_READ) = 0 +22484 mprotect(0x00003000,4096,PROT_READ) = 0 +22484 mprotect(0x7f7fc000,4096,PROT_READ) = 0 +22484 set_tid_address(2138131700,2147480980,2147480988,2147480988,87148,47) = 22484 +22484 set_robust_list(2138131708,12,2147480988,0,87148,47) = -1 errno=38 (Function not implemented) +22484 rt_sigaction(32,0x7ffff36c,NULL) = 0 +22484 rt_sigaction(33,0x7ffff36c,NULL) = -1 errno=22 (Invalid argument) +22484 rt_sigprocmask(SIG_UNBLOCK,0x7ffff4a8,NULL) = 0 +22484 getrlimit(3,2147480732,3,0,62512,47) = 0 +22484 mmap2(NULL,8392704,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|0x20000,-1,0) = 0x7ed88000 +22484 mprotect(0x7ed89000,8388608,PROT_READ|PROT_WRITE) = 0 +22484 brk(NULL) = 0x00005000 +22484 brk(0x00026000) = 0x00026000 +22484 clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,child_stack=0x7f588018,parent_tidptr=0x7f5884fc,tls=0x7f58f928,child_tidptr=0x7f5884fc) = 22503 +22484 io_setup(4001536,2136506392,2136507644,2136507644,2136537384,4100) = -1 errno=38 (Function not implemented) +22484 futex(0x7f5884fc,FUTEX_WAIT,22503,NULL,NULL,0)22484 set_robust_list(2136507652,12,0,4100,2136508076,4100) = -1 errno=38 (Function not implemented) +22484 madvise(2128117760,8372224,4,2136507672,528660,4100) = 0 +22484 exit(0) + = 0 +22484 fstat64(1,0x7fffef48) = 0 +22484 write(1,0x51e8,42)FAIL: a= 10, thr_a = 10 Addr = 0x7f715120 + = 42 +22484 exit_group(1) + +Note that set_robust_list and clone are reported as unimplemented. + +I've reported the problems with the signal syscalls separately here. +https://bugs.launchpad.net/qemu/+bug/1791763 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 new file mode 100644 index 000000000..fbb73f826 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1805913 @@ -0,0 +1,24 @@ + + + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host + +This can be simply reproduced by compiling and running the attached C code (readdir-bug.c) under 32-bit user-static qemu, such as qemu-arm-static: + +# Setup docker for user-static binfmt +docker run --rm --privileged multiarch/qemu-user-static:register --reset +# Compile the code and run (readdir for / is fine, so create a new directory /test). +docker run -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static -v /path/to/readdir-bug.c:/tmp/readdir-bug.c -it --rm arm32v7/ubuntu:18.10 bash -c '{ apt update && apt install -y gcc; } >&/dev/null && mkdir -p /test && cd /test && gcc /tmp/readdir-bug.c && ./a.out' +dir=0xff5b4150 +readdir(dir)=(nil) +errno=75: Value too large for defined data type + +Do remember to replace the /path/to/qemu-arm-static and /path/to/readdir-bug.c to the actual paths of the files. + +The root cause is in glibc: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getdents.c;h=6d09a5be7057e2792be9150d3a2c7b293cf6fc34;hb=a5275ba5378c9256d18e582572b4315e8edfcbfb#l87 + +By C standard, the return type of readdir() is DIR*, in which the inode number and offset are 32-bit integers, therefore, glibc calls getdents64() and check if the inode number and offset fits the 32-bit range, and reports EOVERFLOW if not. + +The problem here is for 32-bit user-static qemu running on 64-bit host, getdents64 simply passing through the inode number and offset from underlying getdents64 syscall (from 64-bit kernel), which is very likely to not fit into 32-bit range. On real hardware, the 32-bit kernel creates 32-bit inode numbers, therefore works properly. + +The glibc code makes sense to do the check to be conformant with C standard, therefore ideally it should be a fix on qemu side. I admit this is difficult because qemu has to maintain a mapping between underlying 64-bit inode numbers and 32-bit inode numbers, which would severely hurt the performance. I don't expect this could be fix anytime soon (or even there would be a fix), but it would be worthwhile to surface this issue. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 new file mode 100644 index 000000000..d91c43bdf --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1810433 @@ -0,0 +1,50 @@ + + + +aarch64-linux-user master: inconsistent pwrite behaviour + +Hello, + +I am running aarch64-linux-user from master, commit 20d6c7312f1b812bb9c750f4087f69ac8485cc90 + +And I've found the following inconsistent emulation of pwrite() call when buf==NULL and len=0. +Minimal reproducible sample is the following: + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <string.h> + +/* + System | Result +-------------------------+---------------- + Native x86_64 4.12.14 | pwrite ret = 0 + Native aarch64 4.4.159 | pwrite ret = 0 + qemu-aarch64 at x86_64 | pwrite ret = -1 + ( 20d6c7312f1b8 ) | +*/ + +int main(int argc, char** argv) { + int fd = open("test.dat", O_CREAT | O_RDWR, 0644); + if (fd < 0) { + perror("open"); + return 1; + } + + int ret = fallocate(fd, 0, 0, 1000); + if (ret < 0) { + perror("fallocate"); + return 1; + } + + ssize_t ret_pwrite = pwrite(fd, NULL, 0, 0); + printf("pwrite ret = %ld\n", ret_pwrite); + + close(fd); + + return 0; +} \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 new file mode 100644 index 000000000..f2902e8bd --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1813307 @@ -0,0 +1,24 @@ + + + +util/path.c/follow_path() does not handle "/" well + +Hello, + +I noticed that qemu does not handle "/" very well in follow_path(). + +Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd. + +Indeed it does something like + if (__lstat ("/", &st) < 0) +..... +and then loops from current dir toward the top using lstat("..") + +On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot). +OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails. + +I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so? + +If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ? + +Thanks \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 new file mode 100644 index 000000000..40f085527 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1821006 @@ -0,0 +1,38 @@ + + + +qemu: Unsupported syscall: 382 + +I used + +qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] + +When I try to build an image of a docker for an arm, an error occurs. + +This affects the operation of applications. + + +Dockerfile + +ARG ARCH +FROM ${ARCH}/debian:buster-slim + +RUN \ + printf "Install dependencies...\n" && \ + apt-get update && \ + apt-get install -y --no-install-recommends ca-certificates curl + +RUN curl https://google.com + +EOF + +The command that I run + +docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . + + +root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf +:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F + +Here is a related discussion. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 new file mode 100644 index 000000000..7cda11ff7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1837 @@ -0,0 +1,38 @@ + + + +Support IP_MULTICAST_IF socket option in linux-user +Additional information: +I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet. + +Here's some source code that demonstrates the failure: +``` +#include <sys/socket.h> +#include <arpa/inet.h> +#include <netinet/ip.h> +#include <unistd.h> +#include <assert.h> +#include <stdio.h> + +int main() +{ + int fd, ret; + struct in_addr addr = {htonl(INADDR_LOOPBACK)}; + + fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); + assert(fd >= 0); + ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr)); + if (ret < 0) + { + perror("setsockopt failed"); + return 1; + } + close(fd); + printf("Success!\n"); + return 0; +} +``` + +When run under qemu, it gives the error `setsockopt failed: Protocol not available`. + +It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 new file mode 100644 index 000000000..f7ec248b3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1860053 @@ -0,0 +1,23 @@ + + + +Possible lack of precision when calling clock_gettime via vDSO on user mode ppc64le + +Occurs on QEMU v4.2.0 run on docker (via the qemu-user-static:v4.2.0-2 image) on an AMD64 Ubuntu 18.04.3 LTS machine provided by travis-ci.org. + +From golang's https://github.com/golang/go/issues/36592: + +It was discovered that golang's time.NewTicker() and time.Sleep() malfunction when a compiled application was run via QEMU's ppc64le emulator in user mode. + +The methods did not malfunction on actual PowerPC hardware or when the same golang application was compiled for golang's arm, arm64 or 386 targets and was run via user mode QEMU on the same system. + +Curiously, the methods also worked when the program was compiled under go 1.11, but do malfunction in go 1.12 and 1.13. + +It was identified the change in behaviour was most likely attributable to golang switching to using vSDO for calling clock_gettime() on PowerPC 64 architectures in 1.12. I.E: +https://github.com/golang/go/commit/dbd8af74723d2c98cbdcc70f7e2801f69b57ac5b + +We therefore suspect there may be a bug in QEMU's user-mode emulation of ppc64le as relates to vDSO calls to clock_gettime(). + +The nature of the malfunction of time.NewTicker() and time.Sleep() is such that sleeps or ticks with a granularity of less than one second do not appear to be possible (they all revert to 1 second sleeps/ticks). Could it be that the nanoseconds field of clock_gettime() is getting lost in the vDSO version but not in the syscall? Or some other issue calling these methods via vDSO? + +Thanks in advance. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 new file mode 100644 index 000000000..d39d7f69d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1861341 @@ -0,0 +1,33 @@ + + + +ARM QEMU: Unknown syscall 397 + +QEMU is reporting + +``` +Unknown syscall 397 +``` + +(statx if I read tables right) when used via flatpak for ARM images on x86_64. This has been reproduced on Fedora and Gentoo. + +To reproduce: + +- get flatpak KDE 5.12 for arm: + +flatpak install --user org.kde.Sdk/arm/5.12 org.kde.Platform/arm/5.12 + + +- run qmake inside Sdk: + +QEMU_STRACE=1 flatpak run --filesystem=host --command=qmake org.kde.Sdk/arm/5.12 . + + +You will get a host of messages with unknown syscall. In practice, qmake will fail to find .pro files if you have them in that folder and libraries in the system. + +As far as I understand, Flatpak images are built on AARCH64 hardware. + +My config on Gentoo: + +kernel: 4.19.86-gentoo x86_64 +app-emulation/qemu: ~4.2.0-r1 , same with 4.0.0 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 new file mode 100644 index 000000000..97bedb20d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1876373 @@ -0,0 +1,51 @@ + + + +segfault mremap 4096 + +a qemu-hosted process segfaults when the program calls mremap to shrink the size of a buffer to 4096 that was allocated with mmap. See below for a C program to reproduce this issue. I was able to compile this program for both i386 and 32-bit arm, and use qemu-i386 and qemu-arm to reproduce the segfault. If I run the i386 program natively on my x86_64 system, no segfault occurs. Also note that if I change the mremap size to something else such as 12288, no segfault occurs. I also confirmed using qemu's -singlestep debug option that the segfault occurs during the mremap syscall. + +If you save the source below to mremapbug.c, the following should reproduce the issue given you have gcc-multilib: + +gcc -m32 mremapbug.c +# works +./a.out +# segfault +qemu-i386 a.out + +If you can also compile to arm, the same thing happens when running "qemu-arm a.out". I also tried compiling natively and running "qemu-x86_64 a.out" but no segfault in that case, not sure if it's because it is 64-bits or if it was because it was my native target. + + +#define _GNU_SOURCE +#include <stdlib.h> +#include <stdio.h> +#include <sys/mman.h> + +int main(int argc, char *argv[]) +{ + const size_t initial_size = 8192; + + printf("calling mmap, size=%llu\n", (unsigned long long)initial_size); + void *mmap_ptr = mmap(NULL, initial_size, + PROT_READ | PROT_WRITE , + MAP_PRIVATE | MAP_ANONYMOUS, + -1, 0); + printf("mmap returned : %p\n", mmap_ptr); + if (mmap_ptr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + const size_t new_size = 4096; + printf("calling mremap, size=%llu\n", (unsigned long long)new_size); + void *remap_ptr = mremap(mmap_ptr, initial_size, new_size, 0); + printf("mremap returned: %p\n", remap_ptr); + if (remap_ptr != mmap_ptr) { + perror("mreamap"); + exit(1); + } + printf("Success: pointers match\n"); +} + + +This issue was found while I was pushing code that calls "mremap" to the Zig compiler repository, it's CI testing uses qemu-i386 and qemu-arm to run tests for non-native hosts. I've filed an issue in that repository as well with details on how to reproduce this issue with the Zig compiler as well: https://github.com/ziglang/zig/issues/5245 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 new file mode 100644 index 000000000..c7204a9fc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1893010 @@ -0,0 +1,8 @@ + + + +qemu linux-user doesn't support OFD fcntl locks + +"Open file description locks (non-POSIX)", as they are described in fcntl(2) man page, aren't supported by qemu-user and attempting to use those results in EINVAL. I'm on Gentoo with latest QEMU version currently available (5.0.0-r2), and trying to emulate ppc64 and s390x on x86_64. + +Looking at linux-user/syscall.c, I'm guessing the issue is in (at least) `target_to_host_fcntl_cmd` where switch reaches the default clause as there're no cases for F_OFD_SETLK / F_OFD_SETLKW / F_OFD_GETLK. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 new file mode 100644 index 000000000..2f0619424 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1894361 @@ -0,0 +1,8 @@ + + + +linux-user: syscall.c lacks pselect6_time64 + +in commit 50efc69586388a975c1ebd90cb8cc8e4a7328bc4 legacy pselect6 definition +for riscv32 was removed in favour of pselect6_time64, but pselect6_time64 is +not available in syscall.c, thus leaving riscv32 without pselect syscall. \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 new file mode 100644 index 000000000..d4b24928f --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926246 @@ -0,0 +1,53 @@ + + + +chrome based apps can not be run under qemu user mode + +chrome uses /proc/self/exe to fork render process. +Here a simple code to reproduce the issue. It's output parent then child but failed with qemu: unknown option 'type=renderer'. + +Maybe we can modify exec syscall to replace /proc/self/exe to the real path. + +//gcc -o self self.c +#include <stdio.h> +#include <sys/types.h> +#include <unistd.h> +int main(int argc, char** argv) { + if(argc==1){ + printf ("parent\n"); + if ( fork() == 0 ) + { + return execl("/proc/self/exe","/proc/self/exe", "--type=renderer",NULL); + } + } else { + printf ("child\n"); + } + return 0; +} + +similar reports: +https://github.com/AppImage/AppImageKit/issues/965 +https://github.com/golang/go/issues/42080 + +Workardound: +compile chrome or your chrome based app with a patch to content/common/child_process_host_impl.cc:GetChildPath, get the realpath of /proc/self/exe: + +diff --git a/content/common/child_process_host_impl.cc b/content/common/child_process_host_impl.cc +index bc78aba80ac8..9fab74d3bae8 100644 +--- a/content/common/child_process_host_impl.cc ++++ b/content/common/child_process_host_impl.cc +@@ -60,8 +60,12 @@ base::FilePath ChildProcessHost::GetChildPath(int flags) { + #if defined(OS_LINUX) + // Use /proc/self/exe rather than our known binary path so updates + // can't swap out the binary from underneath us. +- if (child_path.empty() && flags & CHILD_ALLOW_SELF) +- child_path = base::FilePath(base::kProcSelfExe); ++ if (child_path.empty() && flags & CHILD_ALLOW_SELF) { ++ if (!ReadSymbolicLink(base::FilePath(base::kProcSelfExe), &child_path)) { ++ NOTREACHED() << "Unable to resolve " << base::kProcSelfExe << "."; ++ child_path = base::FilePath(base::kProcSelfExe); ++ } ++ } + #endif + + // On most platforms, the child executable is the same as the current \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 new file mode 100644 index 000000000..84aee5b60 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926521 @@ -0,0 +1,65 @@ + + + +QEMU-user ignores MADV_DONTNEED + +There is comment int the code "This is a hint, so ignoring and returning success is ok" +https://github.com/qemu/qemu/blob/b1cffefa1b163bce9aebc3416f562c1d3886eeaa/linux-user/syscall.c#L11941 + +But it seems incorrect with the current state of Linux + +"man madvise" or https://man7.org/linux/man-pages/man2/madvise.2.html +says the following: +>> These advice values do not influence the semantics +>> of the application (except in the case of MADV_DONTNEED) + +>> After a successful MADV_DONTNEED operation, the semantics +>> of memory access in the specified region are changed: +>> subsequent accesses of pages in the range will succeed, +>> but will result in either repopulating the memory contents +>> from the up-to-date contents of the underlying mapped file +>> (for shared file mappings, shared anonymous mappings, and +>> shmem-based techniques such as System V shared memory +>> segments) or zero-fill-on-demand pages for anonymous +>> private mappings. + +Some applications use this behavior clear memory and it +would be nice to be able to run them on QEMU without +workarounds. + +Reproducer on "Debian 5.10.24 x86_64 GNU/Linux" as a host. + + +``` +#include "assert.h" +#include "stdio.h" +#include <sys/mman.h> +#include <errno.h> + +int main() { + char *P = (char *)mmap(0, 4096, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + assert(P); + *P = 'A'; + while (madvise(P, 4096, MADV_DONTNEED) == -1 && errno == EAGAIN) { + } + assert(*P == 0); + + printf("OK\n"); +} + +/* +gcc /tmp/madvice.c -o /tmp/madvice + +qemu-x86_64 /tmp/madvice +madvice: /tmp/madvice.c:13: main: Assertion `*P == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted + +/tmp/madvice +OK + + +*/ + +``` \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 new file mode 100644 index 000000000..677818f55 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/1926996 @@ -0,0 +1,23 @@ + + + +qemu-user clone syscall fails + +qemu-user fails to emulate clone() (https://linux.die.net/man/2/clone). The architecture doesn't seem to matter, tho I've mostly been testing aarch64. + +Attached is clone_test.c that demonstrates the problem. Running it natively looks like this: +$ bin/clone_test +The variable was 9 +clone returned 4177: 0 Success +The variable is now 42 + + +However, running it via qemu looks like: +$ qemu-aarch64-static --version +qemu-aarch64 version 5.2.0 (v5.2.0) +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers + +$ qemu-aarch64-static ./clone_test +The variable was 9 +clone returned -1: 22 Invalid argument +The variable is now 9 \ No newline at end of file diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2101 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2101 new file mode 100644 index 000000000..eefe48057 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2101 @@ -0,0 +1,20 @@ + + + +[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result +Description of problem: +``` + qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls /tmp/ls-x86_64/root-x86_64-ls/bin/ls -l / + ``` +get wrong result +Steps to reproduce: +1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform +2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir /path/to/ls / -l +Additional information: +Actual test script: +``` +# host +curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls +scp ls.x86_64.ash root@jiyin-fedora-39_aarch64: +ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l / +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2112 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2112 new file mode 100644 index 000000000..bc4154860 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2112 @@ -0,0 +1,29 @@ + + + +Limited Support for MIPS clone syscall in QEMU User Mode +Description of problem: +Hello, + +I have been working with QEMU user mode to run programs based on the MIPS architecture and have encountered a limitation regarding the support for the MIPS clone syscall in the current implementation of QEMU user mode. Specifically, when invoking the clone syscall with certain flags, it results in the error "errno=22 (Invalid argument)" due to the absence of corresponding handling code in QEMU. + +Upon further investigation, I pinpointed the probable cause. QEMU user mode appears to check if the flags for the clone syscall include all the flags defined in CLONE_THREAD_FLAGS. If there is a mismatch, it returns "-TARGET_EINVAL". + +[source code](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c?ref_type=heads#L6564) + +The current CLONE_THREAD_FLAGS in QEMU are set to include: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM). + +However, in my MIPS program, the flags are only: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). + +Aligning my MIPS program to include all the flags as per CLONE_THREAD_FLAGS alters the clone syscall's behavior, deviating from the original semantics required by my MIPS program. + +I am seeking guidance on whether there is a way in QEMU user mode's MIPS syscall handling to exclusively use the flags (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). Alternatively, I am interested in any possible approach to enable support for the MIPS architecture's clone syscall in QEMU user mode. + +Thank you for your time and assistance. +Steps to reproduce: +1. Write a C program that utilizes the clone function, specifying the flags as: CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND. + +strace output: +``` +clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND,child_stack=0x009359a8,parent_tidptr=0x00000f00,tls=0x00000003,child_tidptr=0x2b36d510) = -1 errno=22 (Invalid argument) +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 new file mode 100644 index 000000000..ec7f9aaa9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2123 @@ -0,0 +1,34 @@ + + + +Invalid subprocess commands spawns successfully when running under QEMU +Description of problem: +When executing a subprocess from with a non-existing command EQMU still spawns a process. + +Consider this small rust program for instance: +```rust +use std::process::Command; + +fn main() { + match Command::new("thisdoesnotexist").spawn() { + Ok(child) => { + println!("Child process id is {}", child.id()); + } + Err(_) => { + println!("This should happen"); + } + } +} +``` + +**Executing with `qemu-aarch64`:** +```shell +qemu-aarch64 ./rust-app +Child process id is 20182 +``` + +**Executing regularly:** +```shell +./rust-app +This should happen +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 new file mode 100644 index 000000000..374e0a3b0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2168 @@ -0,0 +1,35 @@ + + + +qemu-x86_64: segfault when running grep on arm64 host +Description of problem: +An internal segmentation fault occurs when attempting to run `grep` in a Gentoo stage3 chroot +Steps to reproduce: +1. Unpack an x86_64 chroot environment (easiest way is using one of Gentoo's stage3s from https://get.gentoo.org) +2. Run `qemu-x86_64 -L /path/to/x86_64/chroot /path/to/x86_64/chroot/bin/grep` +Additional information: +It seems this only occurs in 8.x.x, 7.x.x does not have this segfault. + +Output: +``` +# qemu-x86_64 -L /bugs/grep-sandbox /bugs/grep-sandbox/bin/grep +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +``` + +GDB bt: +``` +(gdb) bt +#0 open_self_maps_2 (opaque=0xffffffffd0b0, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000000000048539c in walk_memory_regions (priv=priv@entry=0xffffffffd0b0, fn=fn@entry=0x4a13e4 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x00000000004a20bc in open_self_maps_1 (smaps=false, fd=3, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x00000000004aaa00 in do_guest_openat (cpu_env=cpu_env@entry=0x862050, dirfd=dirfd@entry=-100, fname=fname@entry=0x5555555776f1 "/proc/self/maps", flags=0, mode=mode@entry=0, safe=safe@entry=true) + at ../linux-user/syscall.c:8381 +#5 0x00000000004b0cc4 in do_syscall1 (cpu_env=cpu_env@entry=0x862050, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=93824992376561, arg3=arg3@entry=0, arg4=arg4@entry=0, + arg5=arg5@entry=93824992373306, arg6=arg6@entry=0, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x00000000004b2770 in do_syscall (cpu_env=cpu_env@entry=0x862050, num=257, arg1=4294967196, arg2=93824992376561, arg3=0, arg4=0, arg5=93824992373306, arg6=0, arg7=arg7@entry=0, arg8=arg8@entry=0) + at ../linux-user/syscall.c:13658 +#7 0x0000000000404fdc in cpu_loop (env=env@entry=0x862050) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x0000000000400d7c in main (argc=4, argv=0xffffffffed48, envp=<optimized out>) at ../linux-user/main.c:1014 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 new file mode 100644 index 000000000..08119aaf3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2197 @@ -0,0 +1,61 @@ + + + +qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly +Description of problem: +Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**. + +When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero. +Steps to reproduce: +1. compile this code to binary executable: +```c +#include <unistd.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/if_alg.h> + +int create_alg(const char *alg) +{ + struct sockaddr_alg salg; + int sk; + + sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0); + if (sk < 0) + return -1; + + memset(&salg, 0, sizeof(salg)); + salg.salg_family = AF_ALG; + strcpy((char *) salg.salg_type, "hash"); + strcpy((char *) salg.salg_name, alg); + + if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) { + close(sk); + return -1; + } + + return sk; +} + +int main() { + int fd = create_alg("hmac(sha1)"); + char buf[10]; + int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0); + if(ret < 0){ + perror("err"); + } + else{ + puts("SUCCESS!"); + } + return 0; +} +``` +2. run it in any qemu user space emulator + +On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`. + +The error is neither informative nor intuitive and could be misleading for user programs. +Additional information: +I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 new file mode 100644 index 000000000..103adf3c7 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2333 @@ -0,0 +1,48 @@ + + + +VDSO on armeb seems broken +Description of problem: +I'm seeing the VDSO method for `__clock_gettime64()` crashing under `qemu-armeb` (stack trace under Additional information, below). + +I rebuilt glibc with VDSO globally kludged off, and all was well. +Steps to reproduce: +``` +#include <time.h> +#include <stdlib.h> +#include <stdio.h> + +int main(int argc, char **argv) { + time_t ts; + printf("%ld\n", time(&ts)); + exit(0); +} +``` + +Results, first with VDSO active via a system snapshot, second with the patched glibc: +``` +$ armeb-linux-gnueabihf-gcc -o /tmp/time /tmp/time.c +$ qemu-armeb -L /.mirrorsnaps/.rootsnap.prev/usr/armeb-linux-gnueabihf /tmp/time +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ qemu-armeb -L /usr/armeb-linux-gnueabihf /tmp/time +1715123280 +``` +Additional information: +``` +Program received signal SIGSEGV, Segmentation fault. +0x4082b462 in ?? () +(gdb) bt +#0 0x4082b462 in ?? () +#1 0x40bf64a4 in __GI___clock_gettime64 (clock_id=clock_id@entry=5, tp=tp@entry=0x407fe9c0) + at ../sysdeps/unix/sysv/linux/clock_gettime.c:42 +#2 0x40be9f58 in __GI___time64 (timer=0x0) at ../sysdeps/unix/sysv/linux/time.c:60 +#3 __time (timer=0x407fea04) at ../sysdeps/unix/sysv/linux/time.c:73 +``` + +`clock_gettime.c:42` is +``` + r = INTERNAL_VSYSCALL_CALL (vdso_time64, 2, clock_id, tp); +``` + +Interestingly, the problem doesn't occur on qemu-arm (little endian), all else equal. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 new file mode 100644 index 000000000..31e35832e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2390 @@ -0,0 +1,66 @@ + + + +linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly +Description of problem: +In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`. +Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html): + +> For getsockopt(), optlen is a value-result argument, initially + containing the size of the buffer pointed to by optval, and + modified on return to indicate the actual size of the value + returned. **If no option value is to be supplied** or returned, + **optval may be NULL.**" + +For me it sounds like accepting NULL without error (and x64 confirms that interpretation). +Steps to reproduce: +1. Use below toy program `getsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -std=gnu11 -pedantic getsockopt.c -o getsockopt +``` + +``` +#include <stdlib.h> +#include <unistd.h> +#include <errno.h> +#include <stdio.h> +#include <netinet/in.h> +#include <sys/socket.h> +#include <netinet/tcp.h> + +static void fail_on_error(int error, const char *msg) { + if (error < 0) { + perror(msg); + exit(errno); + } +} + +int main(int argc, char **argv) { + int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP); + fail_on_error(socketfd, "socket error"); + uint8_t *option_value = NULL; + int32_t len = 0; + int32_t *option_len = &len; + socklen_t opt_len = (socklen_t)*option_len; + int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len); + fail_on_error(status, "getsockopt error"); + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@57646f544f3a:/runtime/programs# ./getsockopt-x64 +root@57646f544f3a:/runtime/programs# ./getsockopt-riscv +getsockopt error: Bad address +``` +Additional information: +I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here: +[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522) + +Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space +instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) + +Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 new file mode 100644 index 000000000..ec48cb93e --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2410 @@ -0,0 +1,95 @@ + + + +linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error +Description of problem: +It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. +On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`. +According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work". +Steps to reproduce: +1. Use below toy program `setsockopt.c` and compile it without optimizations like: +``` + gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt +``` + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <arpa/inet.h> +#include <netinet/in.h> +#include <unistd.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> + +int main() { + { + int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); + if(sd < 0) { + perror("Opening stream socket error"); + exit(1); + } + else + printf("Opening stream socket....OK.\n"); + + struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; + int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); + + if (err < 0) { + perror("Connect error"); + close(sd); + } + else + printf("Connect...OK.\n"); + } + { + int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); + if(sd < 0) { + perror("Opening stream socket error"); + exit(1); + } + else + printf("Opening stream socket....OK.\n"); + + char option[4] = {0}; + if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) { + perror("setsockopt error"); + close(sd); + exit(1); + } + else + printf("setsockopt...OK.\n"); + + struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}}; + int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16); + + if (err < 0) { + perror("Connect error"); + close(sd); + } + else + printf("Connect...OK.\n"); + } + return 0; +} +``` + + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@AMDC4705:~/runtime/connect$ ./setsockopt-x64 +Opening stream socket....OK. +Connect error: Network is unreachable +Opening stream socket....OK. +setsockopt...OK. +Connect error: Network is unreachable + +root@AMDC4705:/runtime/connect# ./setsockopt-riscv +Opening stream socket....OK. +Connect error: Network is unreachable +Opening stream socket....OK. +setsockopt error: Protocol not available +``` +Additional information: +In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. +From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 new file mode 100644 index 000000000..13ff21166 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2446 @@ -0,0 +1,63 @@ + + + +linux-user: Qemu doesn't support `set_robust_list` used by glibc robust mutex implementation +Description of problem: +It seems that syscall set_robust_list is not implemented on Qemu for any Linux platform: [link]( https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L12811) +Steps to reproduce: +1. Use below toy program `set_robust_list.c` and compile it without optimizations like: +``` + gcc -Wall -W -Wextra -std=gnu17 -pedantic set_robust_list.c -o set_robust_list +``` + +``` +#include <stdio.h> +#include <stdlib.h> +#include <errno.h> +#include <sys/syscall.h> +#include <sys/types.h> +#include <unistd.h> +#include <linux/futex.h> +#include <syscall.h> + +int main(void) +{ +#ifdef __NR_set_robust_list + struct robust_list_head head; + size_t len = sizeof(struct robust_list_head); + + // This call to set_robust_list function should fail + int err = syscall(__NR_set_robust_list, &head, -1); + if (err < 0) + perror("1st set_robust_list error"); + else + puts("1st set_robust_list OK"); + + // This call to set_robust_list function should be sucessful + err = syscall(__NR_set_robust_list, &head, len); + if (err < 0) + perror("2nd set_robust_list error"); + else + puts("2nd set_robust_list OK"); +#else + puts("No set_robust_list support"); +#endif + exit(0); +} +``` + +2. Run program on Qemu and compare output with output from x64 build. In my case it looks like: +``` +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list +1st set_robust_list error: Invalid argument +2nd set_robust_list OK +root@AMDC4705:/runtime/set_robust_list# ./set_robust_list-riscv +1st set_robust_list error: Function not implemented +2nd set_robust_list error: Function not implemented +``` +Additional information: +Working `set_robust_list` on Linux is quite important in context of named robust mutexes. In NPTL `set_robust_list` is used internally at ld.so initialization time to perform following check: [link](https://github.com/bminor/glibc/blob/master/sysdeps/nptl/dl-tls_init_tp.c#L96) + +When syscall fails, later `pthread_mutex_init` (with `PTHREAD_MUTEX_ROBUST` + `PTHREAD_PROCESS_SHARED` attributes) end up with `ENOTSUP` error [link](https://github.com/bminor/glibc/blob/master/nptl/pthread_mutex_init.c#L99). + +In dotnet we use robust mutexes for process synchronization purpose. Although there are other available techniques like named semaphores or file locks, robust mutexes are better locking option in case of unexpected process death. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2485 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2485 new file mode 100644 index 000000000..31508fdf4 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2485 @@ -0,0 +1,50 @@ + + + +getifaddrs linked with musl libc hangs on big-endian targets +Description of problem: +When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success. + +```c +#include <stdlib.h> +#include <ifaddrs.h> + +int +main (void) +{ + + struct ifaddrs *ifa = 0; + int error; + + error = getifaddrs(&ifa); + if (error || !ifa) + exit(1); + else + exit(0); + + return 0; +} +``` +Steps to reproduce: +1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/)) +2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`) +3. Observe that the process hangs. +Additional information: +This has come up elsewhere: + +* https://bugs.gentoo.org/914256 +* https://www.openwall.com/lists/musl/2018/05/30/4 +* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain) +* Likely affects sparc but that port/toolchain is also a WIP + +Here are some static sample binaries for the above program: + +* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later) + +GitLab labels seem to be missing: + +* ~"kind::Bug" +* ~"linux-user" +* ~"target: ppc" +* ~"target: m68k" +* ~"target: s390x" diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2553 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2553 new file mode 100644 index 000000000..f6a16c6da --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2553 @@ -0,0 +1,85 @@ + + + +Joining IP multicast fails when emulating 64-bit Linux +Description of problem: +I have some code that joins IP multicast groups and I'd like to use QEMU to test it on big-endian and/or 32-bit platforms. But when I compile it for 64-bit big-endian platforms (e.g. PowerPC64) and run it under QEMU user-mode emulation, the setsockopt(IP_ADD_MEMBERSHIP) call fails with ENODEV. + +This appears to refer to the imr_ifindex ("interface index") field in struct ip_mreqn not being valid, which in turn appears to be because it's not being correctly marshalled from the binary under emulation, to the host's *actual* setsockopt system call. + +I *think* this may be because linux-user/syscall_defs.h (https://github.com/qemu/qemu/blob/master/linux-user/syscall_defs.h) contains the following at line 210: + +``` +struct target_ip_mreqn { + struct target_in_addr imr_multiaddr; + struct target_in_addr imr_address; + abi_long imr_ifindex; +}; +``` + +but the actual Linux ip_mreqn has imr_ifindex as an int (32-bit everywhere) not a long (64-bit on PPC64); the size of this structure is 12 on all Linux platforms. + +I opted to submit an issue instead of just patching it, in case there was some wider context I hadn't seen? +Steps to reproduce: +1. take the following C program (distilled from a larger program): + +``` +#include <sys/types.h> +#include <sys/socket.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <stdio.h> +#include <stdlib.h> + +int main(int argc, char *argv[]) +{ + int fd = socket(AF_INET, SOCK_DGRAM, 0); + if (fd < 0) { + perror("socket"); + return 1; + } + + struct ip_mreqn mreq; + mreq.imr_multiaddr.s_addr = inet_addr("239.255.255.250"); + mreq.imr_address.s_addr = htonl(INADDR_ANY); + mreq.imr_ifindex = 1; + int size = sizeof(mreq); + printf("size=%u\n", size); + if (setsockopt(fd, IPPROTO_IP, IP_ADD_MEMBERSHIP, + (char*) &mreq, sizeof(mreq)) < 0) { + perror("setsockopt"); + return 1; + } + printf("OK\n"); + return 0; +} +``` + +2. confirm it works compiled native on amd64/x86_64: + +``` +[peter@amd64 misc]$ gcc mcast.c -o mcast +[peter@amd64 misc]$ ./mcast +size=12 +OK +``` + +3. watch it *not* work emulated: + +``` +[peter@amd64 misc]$ powerpc64-linux-gnu-gcc mcast.c -o mcast.ppc64 +[peter@amd64 misc]$ QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 ./mcast.ppc64 +size=12 +setsockopt: No such device +``` +Additional information: +If the target_ip_mreqn issue is real, the following code in syscall.c helped conceal it: + + if (optlen < sizeof (struct target_ip_mreq) || + optlen > sizeof (struct target_ip_mreqn)) { + return -TARGET_EINVAL; + } + +Should this instead be testing for size equal to target_ip_mreq or equal to target_ip_mreqn, not anywhere in between? in this case target_ip_mreq is 8 bytes, target_ip_mreqn is 16 bytes, but optlen is 12. The end result is that QEMU passes 4 bytes of uninitialised stack memory as imr_ifindex! + +The actual kernel behaviour appears to be: smaller than ip_mreq, EINVAL; between ip_mreq and ip_mreqn, silently treat as ip_mreq; larger or equal to ip_mreqn, silently treat as ip_mreqn. see https://github.com/torvalds/linux/blob/b31c4492884252a8360f312a0ac2049349ddf603/net/ipv4/ip_sockglue.c#L1234 diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 new file mode 100644 index 000000000..6f7daacfc --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2592 @@ -0,0 +1,40 @@ + + + +qemu-aarch64 cannot properly support some python functions from the `time` module +Description of problem: +When a function is run in python (for example, `time.time()`), python returns the following error: +``` +Traceback (most recent call last): + File "<string>", line 1, in <module> +OSError: [Errno 0] Error +``` +I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem. +Steps to reproduce: +Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts. +1. Create a simple codespace environment. +2. Run the following commands through the terminal: +``` +git clone https://github.com/termux-pacman/glibc-packages +cd glibc-packages +./get-build-package.sh +sudo mkdir /data +sudo chown codespace /data +sudo chgrp codespace /data +sudo apt update +sudo apt install patchelf +./scripts/setup-cgct.sh +``` +3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete. +``` +./build-package.sh -I -w --library glibc gpkg/gobject-introspection +``` +4. Install standard qemu via apt. +5. Run the following command: +``` +qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()" +``` +Additional information: +- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur. + - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502. +For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 new file mode 100644 index 000000000..f3908b636 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/263 @@ -0,0 +1,4 @@ + + + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 new file mode 100644 index 000000000..0af803764 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/2738 @@ -0,0 +1,13 @@ + + + +golang 1.23 build hangs when running under qemu-user on x86_64 host +Description of problem: +Forwarded from https://github.com/golang/go/issues/70329. + +# +Steps to reproduce: +1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora. +2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 new file mode 100644 index 000000000..3b9132949 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/470 @@ -0,0 +1,4 @@ + + + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 new file mode 100644 index 000000000..367666b81 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/577 @@ -0,0 +1,28 @@ + + + +getdtablesize() returns wrong value in qemu user mode on Linux/alpha +Description of problem: +The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. +Steps to reproduce: +[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) + +1. +``` +# apt install g++-10-alpha-linux-gnu +``` +2. +``` +$ alpha-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) + +3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. +4. +``` +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? +``` +Expected: `0` +Actual: `1` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 new file mode 100644 index 000000000..044d207a9 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/578 @@ -0,0 +1,33 @@ + + + +getdomainname() is not implemented in QEMU user mode on Linux/sparc64 +Description of problem: +The `getdomainname()` function fails, instead of succeeding. +Steps to reproduce: +[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints +``` +result: (none) +``` +4. +``` +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out +``` +Expected: `result: (none)` +Actual: `getdomainname: Function not implemented` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 new file mode 100644 index 000000000..205f8cfbe --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/579 @@ -0,0 +1,53 @@ + + + +chown() fails when it should succeed in QEMU user mode on Linux/sparc64 +Description of problem: +The `chown()` function fails, instead of succeeding, in a particular situation. +Steps to reproduce: +[foo.c](/uploads/630d9b83671a071f4ded4da43b6c1b9b/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/bbab43a1b78e6d16ee13e0eff5e963a5/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute these commands there: +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ ./a.out; echo $? +``` +It prints `0`. + +4. +``` +$ id +``` +Verify that you are in 2 or more groups. +``` +$ touch file +$ ln -s file link +$ ln -s link link2 +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out; echo $? +``` +Expected: `0` +Actual: +``` +chown: Operation not permitted +1 +``` +Additional information: + diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 new file mode 100644 index 000000000..3314ee07b --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/829 @@ -0,0 +1,17 @@ + + + +user space emulation: openat() seems to defeat sysroot path translation +Description of problem: +It appears that the user space emulation code is doing some path manipulation of some syscalls to sometimes prefix them with the sysroot. This seems to be interacting badly sometimes with certain usage patterns. This was noticed because a test suite of various libc calls was failing under `qemu-arm`, and a `strace` of the qemu-arm process revealed that the translated paths were being inconsistently applied. + +In particular, the sequence which fails is: +* create a file in `/tmp/`. +* open `/tmp` itself. This succeeds, but `strace` reveals that it actually opened `SYSROOT/tmp/`. +* `openat(tmpfd, tmpfile_name)` then fails, as the fd provided to openat is actually inside the sysroot, not at `/tmp` as expected. +Steps to reproduce: +1. Get toolchain https://toolchains.bootlin.com/downloads/releases/toolchains/armv7-eabihf/tarballs/armv7-eabihf--uclibc--bleeding-edge-2021.11-1.tar.bz2 +2. Compile attached test program [test_openat.c](/uploads/69eb997256ff29d2178be85531c6b3c6/test_openat.c) +3. Try to run under `qemu-arm`. + +This code passes in non-emulated situations, but fails under user-space emulation. Presumably it would also pass under full system emulation. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 new file mode 100644 index 000000000..a3ce6e4f0 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/833 @@ -0,0 +1,45 @@ + + + +linux-user: sendmsg fails to send messages without iov +Description of problem: +When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux. + +A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526 + +A message without data but only ancillary data is used to set the IV. +Steps to reproduce: +See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`). + +(Test case is to be considered GPL, as I've copied bits from `ell`) + +Native: +``` +$ strace -esendmsg ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0 +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + + +Qemu (observe missing sendmsg call): +``` +$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + +For a practical reproducer: + +1. Compile and run `ell`'s `test-cipher` test case: + +``` +$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher +TEST: unsupported +TEST: aes +TEST: aes_ctr +test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed. +Aborted (core dumped) +``` + +A strace will look similar. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 new file mode 100644 index 000000000..5979c6a19 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/836 @@ -0,0 +1,88 @@ + + + +qemu-riscv32: Syscall LSEEK returns -14 (EFAULT) +Description of problem: +The lseek() system call returns -14 (EFAULT) if the file descriptor is correct, +which it should never do (According to the lseek(2) man page). + +Here is some demonstrative code: +``` +/* System Call numbers, according to https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h */ +.set SYS_OPENAT, 0x38 +.set SYS_CLOSE, 0x39 +.set SYS_LSEEK, 0x3e +.set SYS_READ, 0x3f +.set SYS_WRITE, 0x40 +.set SYS_EXIT, 0x5d + +.set SEEK_CUR, 1 + +/* According to https://elixir.bootlin.com/linux/v5.16.2/C/ident/AT_FDCWD */ +.set AT_FDCWD, (-100) + +.section .text +.global _start +_start: + +/* Open the file with SYS_OPENAT, because SYS_OPEN does not exist on riscv32 for some reason. + Effectively: + s0 = open(argv[1], 0, 0644); */ +li a7, SYS_OPENAT +li a0, AT_FDCWD +lw a1, 8(sp) +li a2, 0 +li a3, 0644 +ecall + +/* Error checking. This succeeds. */ +blt a0, zero, unrelated_error + +mv s0, a0 + +/* The broken lseek() call. + Same also happens no matter the position in the file. + Effectively: + lseek(s0, 0, SEEK_CUR); */ +li a7, SYS_LSEEK +mv a0, s0 +li a1, 0 +li a2, SEEK_CUR +ecall + +/* XXX: lseek() returns -14 */ +blt a0, zero, lseek_error + +/* Close the file. */ +li a7, SYS_CLOSE +mv a0, s0 +ecall + +/* Error checking. This also succeeds. */ +blt a0, zero, unrelated_error + +/* exit(0); */ +li a7, SYS_EXIT +li a0, 0 +ecall + +/* exit(-return_value); */ +lseek_error: +li a7, SYS_EXIT +sub a0, zero, a0 +ecall + +unrelated_error: +li a7, SYS_EXIT +li a0, 128 +ecall +``` +Steps to reproduce: +1. riscv32-unknown-linux-gnu-as test.s -o test.o +2. riscv32-unknown-linux-gnu-ld test.o +3. qemu-riscv32 ./a.out test +4. echo $? # This returns 14 +Additional information: +Complete test setup: + +[test.tgz](/uploads/af68c9a5236628a9c6f31f2ce94e2f04/test.tgz) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 new file mode 100644 index 000000000..1805ec8de --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/856 @@ -0,0 +1,64 @@ + + + +Occasional deadlock in linux-user (sh4) when running threadcount test +Description of problem: + +Steps to reproduce: +1. docker run --rm -it -u (id -u) -v $HOME:$HOME -w (pwd) qemu/debian-all-test-cross /bin/bash +2. '../../configure' '--cc=clang' '--cxx=clang++' '--disable-system' '--target-list-exclude=microblazeel-linux-user,aarch64_be-linux-user,i386-linux-user,m68k-linux-user,mipsn32el-linux-user,xtensaeb-linux-user' '--extra-cflags=-fsanitize=undefined' '--extra-cflags=-fno-sanitize-recover=undefined' +3. make; make build-tcg +4. retry.py -n 400 -c -- timeout --foreground 90 ./qemu-sh4 -plugin ./tests/plugin/libinsn.so -d plugin ./tests/tcg/sh4-linux-user/threadcount + +Failure rate on hackbox: + +``` +Results summary: +0: 397 times (99.25%), avg time 0.686 (0.00 varience/0.01 deviation) +124: 3 times (0.75%), avg time 90.559 (0.00 varience/0.01 deviation) +``` + +It seems to fail more frequently on Gitlabs CI +Additional information: +Without the timeout you end up with a deadlock. The following backtrace was found, stepping in gdb unwedges the hang: + +``` +(gdb) info threads + Id Target Id Frame +* 1 LWP 15894 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 + 2 LWP 15994 "qemu-sh4" 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 + 3 LWP 15997 "qemu-sh4" safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x58e8, op=-513652411, val=<optimized out>, timeout=0xf0, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=22760, arg4=<optimized out>, arg5=<optimized out>, arg6=240, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee294b028) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee16ee37d in main (argc=-493657104, argv=0x7ffdcaf52028, envp=<optimized out>) at ../../linux-user/main.c:883 +(gdb) thread 2 +[Switching to thread 2 (LWP 15994)] +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) bt +#0 0x00007f956b800f59 in syscall () from target:/lib/x86_64-linux-gnu/libc.so.6 +#1 0x0000560ee1847bd6 in qemu_futex_wait (f=<optimized out>, val=<optimized out>) at /home/alex.bennee/lsrc/qemu.git/include/qemu/futex.h:29 +#2 qemu_event_wait (ev=0x560ee2738974 <rcu_call_ready_event>) at ../../util/qemu-thread-posix.c:481 +#3 0x0000560ee18539a2 in call_rcu_thread (opaque=<optimized out>) at ../../util/rcu.c:261 +#4 0x0000560ee1847f17 in qemu_thread_start (args=0x560ee2933eb0) at ../../util/qemu-thread-posix.c:556 +#5 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#6 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +(gdb) thread 3 +[Switching to thread 3 (LWP 15997)] +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +75 cmp $-4095, %rax +(gdb) bt +#0 safe_syscall_base () at ../../common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x0000560ee17196e4 in safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:681 +#2 do_safe_futex (uaddr=0x2, op=-513652411, val=<optimized out>, timeout=0x3f7fcdc4, uaddr2=<optimized out>, val3=582) at ../../linux-user/syscall.c:7757 +#3 0x0000560ee170c8d9 in do_syscall1 (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=2, arg4=<optimized out>, arg5=<optimized out>, arg6=1065340356, arg7=0, arg8=0) at /home/alex.bennee/lsrc/qemu.git/include/exec/cpu_ldst.h:90 +#4 0x0000560ee170220c in do_syscall (cpu_env=<optimized out>, num=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>, arg7=<optimized out>, arg8=<optimized out>) at ../../linux-user/syscall.c:13239 +#5 0x0000560ee1626111 in cpu_loop (env=0x560ee2a2c2d8) at ../../linux-user/sh4/cpu_loop.c:43 +#6 0x0000560ee171728f in clone_func (arg=<optimized out>) at ../../linux-user/syscall.c:6608 +#7 0x00007f956b8f6fa3 in start_thread () from target:/lib/x86_64-linux-gnu/libpthread.so.0 +#8 0x00007f956b8064cf in clone () from target:/lib/x86_64-linux-gnu/libc.so.6 +``` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 new file mode 100644 index 000000000..e60fa91d2 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/871 @@ -0,0 +1,17 @@ + + + +qemu-x86_64 don't support unshare(CLONE_NEWUSER) +Description of problem: +Why qemu-x86_64 call unshare(CLONE_NEWUSER) fail? +``` + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ qemu-x86_64 /bin/unshare --user /bin/bash + unshare: unshare failed: Invalid argument + fuzzing@ubuntu:~/Desktop/afl/AFLplusplus$ /bin/unshare --user /bin/bash + nobody@ubuntu:~/Desktop/afl/AFLplusplus$ +``` +Steps to reproduce: +1.execute `qemu-x86_64 /bin/unshare --user /bin/bash` ,it will fail <br/> +2.execute `/bin/unshare --user /bin/bash` ,it will ok + +How i fix that? diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 new file mode 100644 index 000000000..97df04d6d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/885 @@ -0,0 +1,4 @@ + + + +linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 new file mode 100644 index 000000000..f54a96ae3 --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/911 @@ -0,0 +1,20 @@ + + + +Unable to strace execve calls in mipsel user mode +Description of problem: +Used 6.2.0 ZIP and git to build, configured with +``` +./configure --target-list=mipsel-linux-user --static --disable-system --enable-linux-user +``` + +When trying to strace a mipsel-arch application, I cannot see traces for the `execve` syscall. It looks like the call to `safe_execve` is not returning, so the strace printout is never completed. I'm assuming this has to do with `execve` syscall not returning on success, but older versions appeared to be able to do it. I tried it with QEMU 4.2.1 from the package manager on Ubuntu and I saw the `execve` syscall (see qemu-4.2.1.log). +Steps to reproduce: +1. Build mipsel app: ` mipsel-linux-gnu-gcc -o test.mipsel test.c` (Test code is attached as `test.c`) +2. Run qemu-mipsel: `./build/qemu-mipsel -L /usr/mipsel-linux-gnu/ -strace ../test.mipsel` +3. Note that even though the app uses both `system` and `popen` to create subprocesses, no `execve` syscall is shown in the strace output. +Additional information: +[qemu-6.2.90.log](/uploads/ca03e6f40b3b0ea79a042786a123760a/qemu-6.2.90.log) +[qemu-6.2.0.log](/uploads/ca15057398377d49b396e9e77a5cb639/qemu-6.2.0.log) +[qemu-4.2.1.log](/uploads/1087250dd9fc4d8d106d2cbc58c2b14a/qemu-4.2.1.log) +[test.c](/uploads/9d242a724b10b296cfd7a945ae4d6c4d/test.c) diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 new file mode 100644 index 000000000..7a39f030c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/927 @@ -0,0 +1,35 @@ + + + +linux-user: openat on /proc/self/exe can return a closed file descriptor +Description of problem: +`open("/proc/self/exe", ...)` returns a closed file descriptor if qemu-user was executed as an interpreter, passing a file descriptor in the `AT_EXECFD` auxval. + +When the `AT_EXECFD` auxval is nonzero the user program is loaded through `load_elf_binary()` (in `linux-user/elfload.c`) which ultimately calls `load_elf_image()` with that same file descriptor, and `load_elf_image()` closes the file descriptor before returning. + +`do_openat` in `linux-user/syscall.c` will return that file descriptor to the user if the opened path satisfies `is_proc_myself(pathname, "exe")`, which is obviously wrong both in that the file descriptor is closed as part of the initialization process of qemu itself, and that the user program would then close that file descriptor and thus the next invocation of `open` would have the same problem. +Steps to reproduce: +This program prints `3 3` in a x86_64 docker container on my machine (arm64 macos, which docker desktop handles by running containers in a native linux VM under qemu-user). + +```c +#include <fcntl.h> +#include <stdio.h> + +int main(int argc, char **argv) { + int selfexe = open("/proc/self/exe", O_RDONLY | O_CLOEXEC); + if (selfexe < 0) { + perror("open self"); + return 1; + } + + int devnull = open("/dev/null", O_WRONLY | O_CLOEXEC); + if (devnull < 0) { + perror("open devnull"); + return 1; + } + + printf("%d %d\n", selfexe, devnull); +} +``` +Additional information: +Thanks to @pm215 for helping me pinpoint the exact issue I was encountering. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 new file mode 100644 index 000000000..e5e185f1c --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/957 @@ -0,0 +1,74 @@ + + + +qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code." +Description of problem: +The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is +``` +The futex facility returned an unexpected error code. +``` + +Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``. + +Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument". + + +``` +116876 get_thread_area(0x00000001) = 989882672 +116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672 + = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744 +futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000) + = 1065219744 +0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744 +116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument) + = 0 + = 116876 get_thread_area(0x3f7d4c34)1 = +116876 get_thread_area(0x00000000) = 1065219744 +926968112 +116876 get_thread_area(0x00000016) = 926968112 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000000) = 1065219744 +116876 get_thread_area(0x00000001)116876 = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112 +116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE +,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112 +1065219744 +116876 get_thread_area(0x00000001)116876 = 1065219744 +1073732112) = 116876 -1 errno=22 (Invalid argument) +futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112) +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0 +116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 + = 0 +116876 get_thread_area(0x40053a8c) = 885025072 +116876 get_thread_area(0x00000001) = 885025072 +116876 get_thread_area(0x00b4b456) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00000000) = 885025072 +116876 Unknown syscall 403 +116876 get_thread_area(0x00000000) = 885025072 +116876 get_thread_area(0x00003baa) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 get_thread_area(0x00003b01) = 885025072 +116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112 +116876 get_thread_area(0x00000018) = 926968112 +116876 get_thread_area(0x3ed5b9c8) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000000) = 926968112 +116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1 +116876 get_thread_area(0x00000000) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x0000000f) = 926968112116876 = 0 + +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001) = 926968112 +116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112 +The futex facility returned an unexpected error code. +116876 get_thread_area(0x3f7d4c30) = 885025072 +``` + +Advice on how to do further debuggging is appreciated. diff --git a/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 new file mode 100644 index 000000000..7302cb49d --- /dev/null +++ b/results/classifier/no-thinking-deepseek-r1:32b/output/syscall/982 @@ -0,0 +1,40 @@ + + + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` |