diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-04 17:16:22 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-04 17:16:22 +0000 |
| commit | 4c7f62574f2e257741bc05bd3d7e5ec460ecf316 (patch) | |
| tree | 70ee187c55940185b28ee6b7fd5cd00eae3f900e /results/classifier/mode-gemma3:12b/user | |
| parent | d9b111b78db74f5603bc7b65702cb3afea37bdf8 (diff) | |
| download | emulator-bug-study-4c7f62574f2e257741bc05bd3d7e5ec460ecf316.tar.gz emulator-bug-study-4c7f62574f2e257741bc05bd3d7e5ec460ecf316.zip | |
add user/system-mode classification with gemma3:12b
Diffstat (limited to 'results/classifier/mode-gemma3:12b/user')
691 files changed, 24390 insertions, 0 deletions
diff --git a/results/classifier/mode-gemma3:12b/user/1007 b/results/classifier/mode-gemma3:12b/user/1007 new file mode 100644 index 00000000..7afa91ba --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1007 @@ -0,0 +1,3 @@ + + +qemu-user: add execveat syscall support diff --git a/results/classifier/mode-gemma3:12b/user/1012 b/results/classifier/mode-gemma3:12b/user/1012 new file mode 100644 index 00000000..54286479 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1012 @@ -0,0 +1,43 @@ + + +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/mode-gemma3:12b/user/1020 b/results/classifier/mode-gemma3:12b/user/1020 new file mode 100644 index 00000000..e3ff45b8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1020 @@ -0,0 +1,18 @@ + + +Display mode 0x6 doubles lines +Description of problem: +When developing https://github.com/korneliuszo/ne2000xt I've occured problem with double lines in mode 0x06 of VGA display, problem doesn't exist in mode 0x05 +Steps to reproduce: +1. Call int 0x10, to setup video mode +2. put data into video ram (./cga.py -i 192.168.1.102 -I ~/a.png) +3. bad display +Additional information: +Bad display: + + +Same data, but in mode 0x05 + + +Same script as in bad display but run under 86Box + diff --git a/results/classifier/mode-gemma3:12b/user/1024 b/results/classifier/mode-gemma3:12b/user/1024 new file mode 100644 index 00000000..c10dd15d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1024 @@ -0,0 +1,12 @@ + + +Unable to build QEMU with dbus display support on Windows +Description of problem: +When building QEMU on Windows with `./configure --enable-dbus-display --enable-modules`, the following error appears: + +`ERROR: Modules are not available for Windows` +Steps to reproduce: +1. Attempt to build QEMU on Windows (MSYS2 MinGW) with dbus display support +Additional information: +Attempting to build with only `--enable-dbus-display` does not work either, as it requires `--enable-modules`, which does not work on Windows: +`../meson.build:1598:0: ERROR: Feature dbus_display cannot be enabled: -display dbus requires --enable-modules` diff --git a/results/classifier/mode-gemma3:12b/user/1027 b/results/classifier/mode-gemma3:12b/user/1027 new file mode 100644 index 00000000..91aa42c7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1027 @@ -0,0 +1,17 @@ + + +Executables should have embedded plist on macOS +Description of problem: +QEMU binaries on macOS should have an embedded property list (`plist`). + +The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). + +When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier). + +All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary: + +``` +-sectcreate __TEXT __info_plist YourPlistFile.plist +``` + +This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code. diff --git a/results/classifier/mode-gemma3:12b/user/1031920 b/results/classifier/mode-gemma3:12b/user/1031920 new file mode 100644 index 00000000..e3fc5697 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1031920 @@ -0,0 +1,39 @@ + + +Linux user gdbserver does not respond to remote `Ctrl-C' interrupts + +The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver: + +$ qemu-arm -g 1234 a.out + +and then connecting from gdb: + +(gdb) target remote :1234 +Remote debugging using :1234 +[New Remote target] +[Switching to Remote target] +0x00008ba8 in _start () +(gdb) b main +Breakpoint 1 at 0x8cb0: file hello.c, line 5. +(gdb) cont +Continuing. + +Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5 +5 int n = 0; +(gdb) l +1 #include <stdio.h> +2 +3 int main (int argc, char **argv) +4 { +5 int n = 0; +6 +7 for (;;) { +8 printf ("Hello, World!\n"); +9 sleep (5); +10 } +(gdb) cont +Continuing. +^C^CInterrupted while waiting for the program. +Give up (and stop debugging it)? (y or n) y + +Notice that the `Ctrl-C' interrupts are ignored.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1034 b/results/classifier/mode-gemma3:12b/user/1034 new file mode 100644 index 00000000..9d4a7ce7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1034 @@ -0,0 +1,19 @@ + + +Erlang/OTP 25 JIT on AArch64 fails in user mode emulation +Description of problem: +Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation: + +> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is: +> +> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed. +> +> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one. +> +> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code. +> +> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region. +> +> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated. + +There doesn't seem to a open or closed QEMU bug that actually describes this problem. diff --git a/results/classifier/mode-gemma3:12b/user/1041 b/results/classifier/mode-gemma3:12b/user/1041 new file mode 100644 index 00000000..ef0d5f92 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1041 @@ -0,0 +1,33 @@ + + +x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel +Description of problem: +Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`. + +This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless +Steps to reproduce: +1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c) + +``` +#include <stdio.h> +#include <elf.h> + +int main(int argc, char** argv, char* envp[]) { + Elf64_auxv_t *auxv; + while(*envp++ != NULL); + + /*from stack diagram above: *envp = NULL marks end of envp*/ + int i = 0 ; + for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++) + /* auxv->a_type = AT_NULL marks the end of auxv */ + { + if( auxv->a_type == AT_PLATFORM) + printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val)); + } +} +``` +2. Run with `qemu-x86_64-static` +3. See `AT_PLATFORM is: i686` +4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64` +Additional information: +I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case. diff --git a/results/classifier/mode-gemma3:12b/user/1042388 b/results/classifier/mode-gemma3:12b/user/1042388 new file mode 100644 index 00000000..75c82ecd --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1042388 @@ -0,0 +1,16 @@ + + +qemu: Unsupported syscall: 257 (timer_create) + +Running qemu-arm-static for git HEAD. When I try to install ghc from debian into my arm chroot I get: + +Setting up ghc (7.4.1-4) ... +qemu: Unsupported syscall: 257 +ghc: timer_create: Function not implemented +qemu: Unsupported syscall: 257 +ghc-pkg: timer_create: Function not implemented +dpkg: error processing ghc (--configure): + subprocess installed post-installation script returned error exit status 1 +Errors were encountered while processing: + ghc +E: Sub-process /usr/bin/dpkg returned an error code (1)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1052857 b/results/classifier/mode-gemma3:12b/user/1052857 new file mode 100644 index 00000000..8413a1d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1052857 @@ -0,0 +1,17 @@ + + +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/mode-gemma3:12b/user/1054831 b/results/classifier/mode-gemma3:12b/user/1054831 new file mode 100644 index 00000000..e6df2c6f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1054831 @@ -0,0 +1,19 @@ + + +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/mode-gemma3:12b/user/1059 b/results/classifier/mode-gemma3:12b/user/1059 new file mode 100644 index 00000000..6d5235ef --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1059 @@ -0,0 +1,12 @@ + + +qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Description of problem: +When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue +Steps to reproduce: +1. https://botfront.io/docs/installation/local-machine install in local machine +2. run bot front run +3. Go to the docker dashboard and open the botfront-rasa. +4.  +Additional information: +Looking forward to get some updates regarding how we can solve this or any hack we can apply here. Thanks in advance. diff --git a/results/classifier/mode-gemma3:12b/user/1066909 b/results/classifier/mode-gemma3:12b/user/1066909 new file mode 100644 index 00000000..9feac3f5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1066909 @@ -0,0 +1,9 @@ + + +App-level clone emulation for microblaze is broken + +When CLONE_THREAD is used, the new process starts with the program counter pointing to the system call instruction, rather than the instruction immediately following it. This causes an infinite cascade (linear growth, not exponential) of thread creation, which quickly crashes when the threads start running and they're all using the same stack. + +I'm using qemu 1.1.2 packaged with Debian, but I'm not aware of any fixes since then that would address the problem. + +I can provide a test program if needed; a short C program using syscall() directly or an even-shorter asm program can demonstrate the issue without need for debugging around pthread library routines.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1067 b/results/classifier/mode-gemma3:12b/user/1067 new file mode 100644 index 00000000..71eeb92b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1067 @@ -0,0 +1,86 @@ + + +SSH QEMU ISSUE by using with MacOs +Description of problem: +ssh connection between Qemu Image and Guest Host (MacOS) broken down after few minutes +Steps to reproduce: +1. Take the Qemu window and external ssh connection to backround, \ + wait until few minutes and the connection are frozen. \ + If we clicking to qemu window again, the ssh connection are available +Additional information: +The ssh connection settings by Macos: \ +Host * \ +AddKeysToAgent yes \ +IdentityFile ~/.ssh/id_rsa \ +IdentitiesOnly yes \ +ServerAliveInterval 3600 \ +TCPKeepAlive yes \ +ServerAliveCountMax 2 \ +\ +\ +SSH connection settings by Ubuntu Server: + +Include /etc/ssh/sshd_config.d/*.conf \ +\ +#Port 22 \ +#AddressFamily any \ +#ListenAddress 0.0.0.0 \ +#ListenAddress :: \ +#HostKey /etc/ssh/ssh_host_rsa_key \ +#HostKey /etc/ssh/ssh_host_ecdsa_key \ +#HostKey /etc/ssh/ssh_host_ed25519_key \ +#RekeyLimit default none \ +#SyslogFacility AUTH \ +#LogLevel INFO \ +#LoginGraceTime 2m \ +#PermitRootLogin prohibit-password \ +#StrictModes yes \ +#MaxAuthTries 6 \ +#MaxSessions 10 \ +#PubkeyAuthentication yes \ +#Expect .ssh/authorized_keys2 to be disregarded by default in future. \ +#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 \ +#AuthorizedPrincipalsFile none \ +#AuthorizedKeysCommand none \ +#AuthorizedKeysCommandUser nobody \ +#HostbasedAuthentication no \ +#IgnoreUserKnownHosts no \ +#IgnoreRhosts yes \ +#PasswordAuthentication yes \ +#PermitEmptyPasswords no \ +ChallengeResponseAuthentication no \ +#KerberosAuthentication no \ +#KerberosOrLocalPasswd yes \ +#KerberosTicketCleanup yes \ +#KerberosGetAFSToken no \ +#GSSAPIAuthentication no \ +#GSSAPICleanupCredentials yes \ +#GSSAPIStrictAcceptorCheck yes \ +#GSSAPIKeyExchange no \ +UsePAM yes \ +#AllowAgentForwarding yes \ +#AllowTcpForwarding yes \ +#GatewayPorts no \ +X11Forwarding yes \ +#X11DisplayOffset 10 \ +#X11UseLocalhost yes \ +#PermitTTY yes \ +PrintMotd no \ +#PrintLastLog yes \ +#TCPKeepAlive yes \ +#PermitUserEnvironment no \ +#Compression delayed \ +#ClientAliveInterval 0 \ +#ClientAliveCountMax 3 \ +#UseDNS no \ +#PidFile /var/run/sshd.pid \ +#MaxStartups 10:30:100 \ +#PermitTunnel no \ +#ChrootDirectory none \ +#VersionAddendum none \ +#Banner none \ +AcceptEnv LANG LC_* \ +PasswordAuthentication yes \ +ClientAliveInterval 600 \ +TCPKeepAlive yes \ +ClientAliveCountMax 10 \ diff --git a/results/classifier/mode-gemma3:12b/user/1068900 b/results/classifier/mode-gemma3:12b/user/1068900 new file mode 100644 index 00000000..0da3058b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1068900 @@ -0,0 +1,7 @@ + + +Thread cancellation broken in app-level emulation + +Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash. + +The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1072 b/results/classifier/mode-gemma3:12b/user/1072 new file mode 100644 index 00000000..ffc1bb3e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1072 @@ -0,0 +1,26 @@ + + +different behavior when remote debugger is used +Description of problem: +I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: + +1. Is this intended behavior? +1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below) +1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference. + +The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR) +The preprocessed code is as follows: + if (((((st.st_mode)) & 0170000) == (0020000))) + +I then compared two different approaches to run Qemu: + +1. I used the following command line to collect the trace: qemu_aarch64 -strace -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR +1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). + +Thanks! +Steps to reproduce: +1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64) +2. +3. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1075272 b/results/classifier/mode-gemma3:12b/user/1075272 new file mode 100644 index 00000000..9cc0e2bd --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1075272 @@ -0,0 +1,15 @@ + + +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/mode-gemma3:12b/user/1075339 b/results/classifier/mode-gemma3:12b/user/1075339 new file mode 100644 index 00000000..9622308e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1075339 @@ -0,0 +1,5 @@ + + +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/mode-gemma3:12b/user/1076445 b/results/classifier/mode-gemma3:12b/user/1076445 new file mode 100644 index 00000000..3e73e5d5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1076445 @@ -0,0 +1,47 @@ + + +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/mode-gemma3:12b/user/1077116 b/results/classifier/mode-gemma3:12b/user/1077116 new file mode 100644 index 00000000..d4210141 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1077116 @@ -0,0 +1,55 @@ + + +automoc4 segfaults when building in an armhf pbuilder on an amd64 host + +When trying to build kde4libs in an armhf pbuilder created with the pbuilder-scripts running on an amd64 host automoc4 recieves a segmentation fault and I can't get any useful information out of it: + +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# /usr/bin/automoc4 kdeui_automoc.cpp ../../kdeui/ . moc-qt4 cmake +unable to dump 00102c00 +Segmentation fault (core dumped) +root@yofel-thinkpad:/tmp/kde4libs-4.9.3/build/kdeui# gdb /usr/bin/automoc4 qemu_automoc4_20121108-211818_15839.core +GNU gdb (GDB) 7.5-ubuntu +Copyright (C) 2012 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "arm-linux-gnueabihf". +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>... +Reading symbols from /usr/bin/automoc4...done. +BFD: Warning: /tmp/kde4libs-4.9.3/build/kdeui/qemu_automoc4_20121108-211818_15839.core is truncated: expected core file size >= 5150720, found: 974848. +[New LWP 15839] +[New LWP 15866] +Cannot access memory at address 0xf67fe954 +Cannot access memory at address 0xf67fe950 +(gdb) bt +#0 0xf6630306 in ?? () +#1 0xf6415ff8 in ?? () +#2 0xf6415ff8 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) + +automoc4 runs fine when building on a nexus7 so this sounds like an issue in qemu. +Tested in quantal and raring. + +ProblemType: Bug +DistroRelease: Ubuntu 13.04 +Package: qemu-user-static 1.2.0-2012.09-0ubuntu1 +Uname: Linux 3.6.2-030602-generic x86_64 +NonfreeKernelModules: nvidia +ApportVersion: 2.6.2-0ubuntu3 +Architecture: amd64 +Date: Fri Nov 9 19:29:28 2012 +EcryptfsInUse: Yes +InstallationDate: Installed on 2011-10-08 (398 days ago) +InstallationMedia: Kubuntu 11.10 "Oneiric Ocelot" - Beta amd64 (20111007) +MarkForUpload: True +ProcEnviron: + SHELL=/bin/bash + TERM=xterm + PATH=(custom, user) + LANG=en_US.UTF-8 + LANGUAGE=en_US.UTF-8 +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1079 b/results/classifier/mode-gemma3:12b/user/1079 new file mode 100644 index 00000000..55fbbb81 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1079 @@ -0,0 +1,34 @@ + + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Description of problem: +I am trying to build `arm64` image on my `x86_64` machine using `buildx` and I have encountered `qemu: uncaught target signal 11 (Segmentation fault) - core dumped` Error. <br> +# +Steps to reproduce: +1. Create a Dockerfile +``` +FROM python:3.8-slim + +ENV PYTHONDONTWRITEBYTECODE=1 + +# Install packages +RUN apt update +RUN apt-get install -y python3-pip +``` +2. Run binfmt container +``` +docker run --privileged --rm tonistiigi/binfmt --install all +``` +3. Setup new builder +``` +$ docker buildx create --name mybuilder +$ docker buildx use mybuilder +$ docker buildx inspect --bootstrap +``` +4. Build Image +``` +$ docker buildx build --platform linux/amd64,linux/arm64 --push -t user/failure-case . +``` +# +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1084148 b/results/classifier/mode-gemma3:12b/user/1084148 new file mode 100644 index 00000000..35463d21 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1084148 @@ -0,0 +1,45 @@ + + +Qt5 Beta 1 QProcess start and execute causes segmentation fault on armhf + +Steps +1) pbuilder-dist quantal armhf create +2) add ppa from https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta1 to the pbuilder +2.0) pbuilder-dist quantal armhf login +2.1) apt-get install software-properties-common +2.2) apt-add-repository ppa:canonical-qt5-edgers/qt5-beta1 +2.3) apt-get update +3) apt-get install qtbase qtdeclarative qttools bzr +4) bzr branch lp:~juhapekka-piiroinen/+junk/qemu-crash +5) cd qemu-crash; /opt/qt5/bin/qmake; make; ./untitled + +Expected Result: +Would execute 'ls' + +Actual result: +# ./untitled +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Note: this code works on i386, amd64 and armel. + +Packages: +$ apt-cache policy qemu-user-static +qemu-user-static: + Installed: 1.2.0-2012.09-0ubuntu1 + Candidate: 1.2.0-2012.09-0ubuntu1 + Version table: + *** 1.2.0-2012.09-0ubuntu1 0 + 500 http://fi.archive.ubuntu.com/ubuntu/ quantal/universe amd64 Packages + 100 /var/lib/dpkg/status + 1.2.0-2012.09-0ubuntu1~linaro1 0 + 500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ quantal/main amd64 Packages + +# apt-cache policy qtbase +qtbase: + Installed: 5.0-release~beta+20120831-1ubuntu54 + Candidate: 5.0-release~beta+20120831-1ubuntu54 + Version table: + *** 5.0-release~beta+20120831-1ubuntu54 0 + 500 http://ppa.launchpad.net/canonical-qt5-edgers/qt5-beta1/ubuntu/ quantal/main armhf Packages + 100 /var/lib/dpkg/status
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1085 b/results/classifier/mode-gemma3:12b/user/1085 new file mode 100644 index 00000000..db6521bf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1085 @@ -0,0 +1,42 @@ + + +QEMU 7.0.0 - NSIS installer issue +Description of problem: +Misisng info in QEMU.nsi file +Steps to reproduce: +The exe installer exe file properties has a lot of porpeties missing + + + +This is casued by mssing instruction like + +VIAddVersionKey "ProductName" "" +VIAddVersionKey "ProductVersion" "" +VIAddVersionKey "Comments" "" +VIAddVersionKey "CompanyName" "" +VIAddVersionKey "LegalTrademarks" "" +VIAddVersionKey "LegalCopyright" "" +VIAddVersionKey "FileVersion" "" +VIAddVersionKey "FileDescription" "" + +VIAddVersionKey "InternalName" "" +VIAddVersionKey "OriginalFilename" "" + +In Windows program òlist about uninstalle + +the QEMU icon is not right (generic icon) +The Is missing teh publisg + + + +This si due error on + +!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico" + +that probably point to an icon file not available + +and an misisng line that set Publisher info for uninstalelr + +WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "" + +Thanks. KR. diff --git a/results/classifier/mode-gemma3:12b/user/1090615 b/results/classifier/mode-gemma3:12b/user/1090615 new file mode 100644 index 00000000..a715838f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1090615 @@ -0,0 +1,29 @@ + + + RFE: More info in qemu-img info/check + +Originally filed in Fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=861375 + +""" +qemu-img info currently give me info like this: + +image: /home/alex/.local/share/gnome-boxes/images/Fedora 16 +file format: qcow2 +virtual size: 11G (11794287616 bytes) +disk size: 4.5G +cluster_size: 65536 + +In order to figure out the "health" of an image there is some more information I would like: + +in-use disk size - I.e the subset of disk size that is not marked as unused due to e.g. TRIM operations + +amount of compressed clusters. I.e. "is it useful to re-compress the image". + +Fragmentation estimation. + +This would be useful to both sysadmins in general and for automated things like +what we want to do in gnome-boxes: +https://bugzilla.gnome.org/show_bug.cgi?id=685032 +""" + +As mentioned in the original report, qemu-img check currently has fragmentation stats, but only for QED.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1093 b/results/classifier/mode-gemma3:12b/user/1093 new file mode 100644 index 00000000..1edebb93 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1093 @@ -0,0 +1,35 @@ + + +RISC-V: signal frame is misaligned in signal handlers +Description of problem: +`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan. +Steps to reproduce: +1. Create a C file with the following contents: +```c +#include <signal.h> +#include <stdio.h> + +void handler(int sig, siginfo_t *info, void *context) { + printf("signal occurred, info: %p, context: %p\n", info, context); +} + +int main() { + struct sigaction act; + act.sa_flags = SA_SIGINFO; + act.sa_sigaction = handler; + sigaction(SIGINT, &act, NULL); + + // Deliberately misalign the stack + asm volatile ("addi sp, sp, -4"); + + while(1); + // Unreachable +} +``` +2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`. +3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned: +``` +signal occurred, info: 0x400080025c, context: 0x40008002dc +``` +Additional information: +This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15. diff --git a/results/classifier/mode-gemma3:12b/user/1097 b/results/classifier/mode-gemma3:12b/user/1097 new file mode 100644 index 00000000..20c17d43 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1097 @@ -0,0 +1,3 @@ + + +linux-user build broken on 32-bit ppc diff --git a/results/classifier/mode-gemma3:12b/user/1098729 b/results/classifier/mode-gemma3:12b/user/1098729 new file mode 100644 index 00000000..8838b5be --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1098729 @@ -0,0 +1,45 @@ + + +qemu-user-static for armhf: segfault in threaded code + + +Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian. + +The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot. + +Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs. + +As an example, I've grabbed the threads demo program here: + + https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c + +and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest): + + gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex + +When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever. + +However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output: + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + Thread 0 did 0 to 100000: mysum=100000.000000 global sum=200000.000000 + TCG temporary leak before f6731ca0 + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371: + tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed. + + + (armhf) $ ./dotprod_mutex + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault + + (armhf) $ ./dotprod_mutex + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519: + tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed. + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1100 b/results/classifier/mode-gemma3:12b/user/1100 new file mode 100644 index 00000000..da2f29a3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1100 @@ -0,0 +1,3 @@ + + +It riscv64 platform support user model?? diff --git a/results/classifier/mode-gemma3:12b/user/1102 b/results/classifier/mode-gemma3:12b/user/1102 new file mode 100644 index 00000000..16703b3e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1102 @@ -0,0 +1,40 @@ + + +qemu-user: zero_bss might raise segfault when segment is not writable +Description of problem: +When a PT_LOAD segment with the following attributes presented in the user program, +* MemSiz > FileSiz +* NOT Writable + +qemu-aarch64 will crash with segment fault running it. + + + + +in [linux-user/elfload.c: bss_zero](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2097), the exceeded part is zero'ed without checking if it is writable +``` + if (host_start < host_map_start) { + memset((void *)host_start, 0, host_map_start - host_start); + } +``` +Steps to reproduce: +1. ./qemu-aarch64 ./X.so +Additional information: +readelf output of X.so +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x0000000000000230 0x0000000000000230 R E 0x8 + LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000110270 0x00000000001c94e0 R E 0x10000 + LOAD 0x0000000000129bd0 0x00000000001d9bd0 0x00000000001d9bd0 0x0000000000000438 0x00000000000004c0 RW 0x10000 + LOAD 0x000000000013a008 0x00000000001ea008 0x00000000001ea008 0x0000000000017bd0 0x0000000000017bd0 RW 0x10000 + LOAD 0x0000000000161bd8 0x0000000000211bd8 0x0000000000211bd8 0x000000000000f740 0x000000000000f740 RW 0x10000 + DYNAMIC 0x0000000000161e60 0x0000000000211e60 0x0000000000211e60 0x00000000000001e0 0x00000000000001e0 RW 0x8 + INTERP 0x0000000000089410 0x0000000000089410 0x0000000000089410 0x0000000000000015 0x0000000000000015 R 0x1 + [Requesting program interpreter: /system/bin/linker64] + NOTE 0x000000000013dbc8 0x00000000001edbc8 0x00000000001edbc8 0x0000000000000011 0x0000000000000011 R 0x1 + GNU_EH_FRAME 0x00000000001c86a4 0x00000000001c86a4 0x00000000001c86a4 0x00000000000002dc 0x00000000000002dc R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 +``` + +X.so: https://drive.google.com/file/d/1A7mkWRcK2BKkpeevt8T6FVLg-t6mWdgi/view?usp=sharing diff --git a/results/classifier/mode-gemma3:12b/user/1110 b/results/classifier/mode-gemma3:12b/user/1110 new file mode 100644 index 00000000..59a47640 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1110 @@ -0,0 +1,5 @@ + + +Add vhost-user-gpu support for cross architecture emulation +Additional information: +host:Android 12 with Linux kernel 4.14.186+ diff --git a/results/classifier/mode-gemma3:12b/user/1119686 b/results/classifier/mode-gemma3:12b/user/1119686 new file mode 100644 index 00000000..42f75ccf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1119686 @@ -0,0 +1,17 @@ + + +Incorrect handling of icebp + +Wine conformance suite tests the behavior of various low-level Windows API functions. One of the tests involves checking the interaction of breakpoints and exceptions, and in particular the 'icebp' breakpoint. This test works on a Windows XP machine running either on the metal or in VMware ESX but fails when run in QEmu. + +To reproduce the issue grab the attached 'exception.exe' file and run it. If you get 'Test failed' lines like below then it means the problem is still present: + + exception.c:202: exception 0: 80000004 flags:0 addr:003F0000 + exception.c:208: Test failed: 0: Wrong exception address 003F0000/003F0001 + exception.c:214: this is the last test seen before the exception + exception: unhandled exception 80000004 at 003F0000 + exception.c:202: exception 0: c0000027 flags:2 addr:7C80E0B9 + exception.c:205: Test failed: 0: Wrong exception code c0000027/80000004 + exception.c:208: Test failed: 0: Wrong exception address 7C80E0B9/003F0001 + +Note that this bug was not present in QEmu 1.1.2+dfsg-5 (Debian Testing) but is now present in 1.4.0~rc0+dfsg-1exp (Debian Experimental).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1129571 b/results/classifier/mode-gemma3:12b/user/1129571 new file mode 100644 index 00000000..0b2983ec --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1129571 @@ -0,0 +1,16 @@ + + +libreoffice armhf FTBFS + +We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. + +While we do not have a small test case yet, we do have a build log (attaching here). + +The relevant snippet from the build log is: + +3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro +dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' + +We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. + +Any help in tracking this down would be appreciated.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1143 b/results/classifier/mode-gemma3:12b/user/1143 new file mode 100644 index 00000000..8d43e950 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1143 @@ -0,0 +1,80 @@ + + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/mode-gemma3:12b/user/1147 b/results/classifier/mode-gemma3:12b/user/1147 new file mode 100644 index 00000000..41d88bd6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1147 @@ -0,0 +1,11 @@ + + +x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu) +Description of problem: +Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.` + +No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above. + +Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi. + +These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit). diff --git a/results/classifier/mode-gemma3:12b/user/1165383 b/results/classifier/mode-gemma3:12b/user/1165383 new file mode 100644 index 00000000..f2a83f7d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1165383 @@ -0,0 +1,5 @@ + + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault + +executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1178101 b/results/classifier/mode-gemma3:12b/user/1178101 new file mode 100644 index 00000000..41f6135d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1178101 @@ -0,0 +1,47 @@ + + +Could not enable gtk UI on build for Windows target + +$ ${QEMU_SRC_DIR}/configure --prefix=${BIN_ROOT} --cross-prefix=${HOST_TRIPLET}- --extra-cflags="-I${BIN_ROOT}/include" --extra-ldflags="-L${BIN_ROOT}/lib" --enable-gtk --disable-xen + +ERROR: User requested feature gtk + configure was not able to find it + + +$ cat config.log +# QEMU configure log Thu May 9 13:50:40 CST 2013 +# Configured with: '/home/cauchy/vcs/git/qemu/configure' '--prefix=/home/cauchy/w32' '--cross-prefix=i686-w64-mingw32-' '--extra-cflags=-I/home/cauchy/w32/include' '--extra-ldflags=-L/home/cauchy/w32/lib' '--enable-gtk' '--disable-xen' +# +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:2:2: error: #error __linux__ not defined + #error __linux__ not defined + ^ +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -g -L/home/cauchy/w32/lib -liberty +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Winitializer-overrides -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc: error: unrecognized command line option ‘-Winitializer-overrides’ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Werror -Wendif-labels -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Werror -Wmissing-include-dirs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Werror -Wempty-body -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Werror -Wnested-externs -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Werror -Wformat-security -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Werror -Wformat-y2k -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Werror -Winit-self -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Werror -Wignored-qualifiers -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Werror -Wold-style-declaration -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Werror -Wold-style-definition -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Werror -Wtype-limits -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -Werror -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -Werror -fno-gcse -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +/tmp/qemu-conf--18025-.c:4:2: error: #error No bug in this compiler. + #error No bug in this compiler. + ^ +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -c -o /tmp/qemu-conf--18025-.o /tmp/qemu-conf--18025-.c +/tmp/qemu-conf--18025-.c:1:19: fatal error: sched.h: No such file or directory + #include <sched.h> + ^ +compilation terminated. +i686-w64-mingw32-gcc -m32 -D__USE_MINGW_ANSI_STDIO=1 -DWIN32_LEAN_AND_MEAN -DWINVER=0x501 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -I/home/cauchy/w32/include -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -o /tmp/qemu-conf--18025-.exe /tmp/qemu-conf--18025-.c -m32 -g -L/home/cauchy/w32/lib -lz
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1187319 b/results/classifier/mode-gemma3:12b/user/1187319 new file mode 100644 index 00000000..43e35e67 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1187319 @@ -0,0 +1,10 @@ + + +Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL + +The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect. + +I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either. + +Keyboard layout: US int with AltGr dead keys +version: 1.5.0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1207896 b/results/classifier/mode-gemma3:12b/user/1207896 new file mode 100644 index 00000000..1afbe1cc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1207896 @@ -0,0 +1,5 @@ + + +binfmt wrapper for argv[0] handling + +Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/121 b/results/classifier/mode-gemma3:12b/user/121 new file mode 100644 index 00000000..441c151f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/121 @@ -0,0 +1,3 @@ + + +multiprocess program gets incorrect results with qemu arm-linux-user diff --git a/results/classifier/mode-gemma3:12b/user/1211 b/results/classifier/mode-gemma3:12b/user/1211 new file mode 100644 index 00000000..3132820f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1211 @@ -0,0 +1,9 @@ + + +Bad fonts in "cirrus" VGA card. +Description of problem: +Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file. +Steps to reproduce: +Similar to #988. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1211943 b/results/classifier/mode-gemma3:12b/user/1211943 new file mode 100644 index 00000000..cca96650 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1211943 @@ -0,0 +1,5 @@ + + +#GP and aligned move instruction + +When the operand of movaps, movapd or movdqa instruction isn't aligned, general-protection exception should be generated.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1213 b/results/classifier/mode-gemma3:12b/user/1213 new file mode 100644 index 00000000..8be8510f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1213 @@ -0,0 +1,45 @@ + + +7.1.0 - NSIS Installer file issues +Description of problem: + + +Please check the screenshot relative to Window program list + +**Problem n. 1 (standard icon)** + +The icon rlative to QEMU is not graphic icon but starndrd udenfiend icon + +**Problem n. 2 (author missing)** + +Author info is missing + +**Problem n. 3 (installer date is not updated)** + +When you upgrade QEM the installation date not reflect last update but first installation (ex. version 7.1.0 with date of 2021). + +Note: all issues are relative to NSIS installer script. + +**Uninstaller icon** + +It seems that + +**!define MUI_UNICON "${SRCDIR}\pc-bios\qemu-nsis.ico"**__ + +didn't work. + +Please check here + +https://nsis.sourceforge.io/Add_uninstall_information_to_Add/Remove_Programs + +Please try to add in uninsaller section + + WriteRegStr HKLM "${UNINST_KEY}" "DisplayIcon" "${SRCDIR}\pc-bios\qemu-nsis.ico" + +**Missing author info in uninstall view** + + ; Write the uninstall keys for Windows + WriteRegStr HKLM "${UNINST_KEY}" "DisplayName" "QEMU" + WriteRegStr HKLM "${UNINST_KEY}" "Publisher" "QEMU crew" + +Replace "QEMU crew" with text that you like. diff --git a/results/classifier/mode-gemma3:12b/user/1216845 b/results/classifier/mode-gemma3:12b/user/1216845 new file mode 100644 index 00000000..3d9f4f59 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1216845 @@ -0,0 +1,47 @@ + + +qemu-system-arm semihosting always calls exit(0) + +In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error. + +Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API. + +Up to now everything is fine with the emulation. + +However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework. + +I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0): + + case SYS_EXIT: + gdb_exit(env, 0); + exit(0); + +To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system. + + qemu: Unsupported SemiHosting SWI 0xf1 + +This kludge is more or less functional, but is quite inconvenient. + +After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose. + +Now the question: + +Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value? + +The suggested rule would be: + +if (code ==0 || code == 0x20026) + exit(0); +elif (code < 256) + exit(code); +else + exit(1); + +The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement. + +What do you think? Can this be added to arm-semi.c? + + +Regards, + +Liviu
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/122 b/results/classifier/mode-gemma3:12b/user/122 new file mode 100644 index 00000000..426ec8cf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/122 @@ -0,0 +1,3 @@ + + +linux-user does not check PROT_EXEC diff --git a/results/classifier/mode-gemma3:12b/user/1222 b/results/classifier/mode-gemma3:12b/user/1222 new file mode 100644 index 00000000..f1d8409e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1222 @@ -0,0 +1,23 @@ + + +/proc/self/exe not handled in execve +Description of problem: +I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this. + +My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with `execve /proc/self/exe`. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use... + +> Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary +> emulated, as opposed to qemu-system which runs an entire system but is harder to automate in +> toolchains) we need these patches because of a peculiar thing many golang applications do. They +> re-execute themselves using the execve syscall using /proc/self/exe as the executable. In +> non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the +> top-level emulator process and _not_ podman/buildah/skopeo. This causes all container storage +> operations to mysteriously fail, because the wrong binary is being executed. This issue was quite +> difficult to root cause. +Additional information: +Old patchsets that seem to be trying to fix this: +- http://next.patchew.org/QEMU/20210531055019.10149-1-yamamoto@midokura.com/20210531055019.10149-2-yamamoto@midokura.com/ +- https://patchew.org/QEMU/20190916155545.29928-1-olivier.dion@polymtl.ca/ +- https://patchew.org/QEMU/20190807135458.32440-1-dion@linutronix.de/ + +It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue. diff --git a/results/classifier/mode-gemma3:12b/user/1224414 b/results/classifier/mode-gemma3:12b/user/1224414 new file mode 100644 index 00000000..7b2d2d6d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1224414 @@ -0,0 +1,20 @@ + + +dtc/.git file included in release tarball + +The release tarballs include the dtc/.git submodule file, causing when working git in some circumstances (e.g. doing git clean -fxd in a parent git repository): + +$ mkdir foo && cd foo +$ git init +$ echo yo >bar +$ curl http://wiki.qemu-project.org/download/qemu-1.6.0.tar.bz2 +$ tar xjf qemu-1.6.0.tar.bz2 +$ git clean -fxd +Removing bar +Removing qemu-1.6.0.tar.bz2 +Removing qemu-1.6.0/ +fatal: Not a git repository: qemu-1.6.0/pixman/../.git/modules/pixman + +Leaving the qemu-1.6.0 directory intact. + +So, my suggestion is, would it be possible to filter out the .git file from the release tarball when building a release? Thanks.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1228 b/results/classifier/mode-gemma3:12b/user/1228 new file mode 100644 index 00000000..a0e2a8d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1228 @@ -0,0 +1,45 @@ + + +-display curses only recognizes escape characters if pressed very quickly +Description of problem: +The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work. + +I have tried all the ones from here: +https://www.qemu.org/docs/master/system/keys.html +https://www.qemu.org/docs/master/system/mux-chardev.html + +When using the graphical display, the escape characters works as expected but when using -display curses, they do not. +Steps to reproduce: +1. Start qemu with the command provided +2. Try to exit using ctrl + x a - Not working +3. Try to exit using alt + 2 - Not working + +The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. + +I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE). +Additional information: +Linux 0.01 build: +https://github.com/mariuz/linux-0.01 + +**Tests using showkey** + +Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine +``` +^[2 27 0033 0x1b + 50 0062 0x32 +``` + +Option + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +@ 64 0100 0x40 +``` + +Esc + 2 from macOS Terminal + ssh -> Ubuntu machine +``` +^[ 27 0033 0x1b +2 50 0062 0x32 +``` + +**Update** + +It seems to work if I press ESC + 2 at exactly the same time. diff --git a/results/classifier/mode-gemma3:12b/user/1233225 b/results/classifier/mode-gemma3:12b/user/1233225 new file mode 100644 index 00000000..da87b869 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1233225 @@ -0,0 +1,26 @@ + + +mips/mipsel linux user float division problem + +Hi, + +I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program: + +#include <stdio.h> +int main(int argc, char **argv) +{ + int a = 1; + double d = a/2.0; + printf("%f\n", d); + return 0; +} + +Instead of printing 0.5, it will print 2.0 if executed in qemu user mode. + +$ mipsel-linux-gnu-gcc mipstest.c +$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out +2.0 + +Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode. + +Can anybody else reproduce this problem?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1238 b/results/classifier/mode-gemma3:12b/user/1238 new file mode 100644 index 00000000..00b9d58f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1238 @@ -0,0 +1,121 @@ + + +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/mode-gemma3:12b/user/1239 b/results/classifier/mode-gemma3:12b/user/1239 new file mode 100644 index 00000000..bc210795 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1239 @@ -0,0 +1,38 @@ + + +The help document of qemu-img misses some options +Description of problem: +The "--help" option of qemu-img misses the option "skip-broken-bitmaps" for convert , "image-opts" for bench, "object" for dd and "force-share" for measure. +Steps to reproduce: +1. For the option "skip-broken-bitmaps", the following code appears during option parsing for convert and modifies the skip_broken in qemu-img.c:2377-2379. + +``` + case OPTION_SKIP_BROKEN: + skip_broken = true; + break; +``` + +2. For the option "image-opts", the following code appears during option parsing for bench and modifies the image_opts in qemu-img.c:4511-4513. + +``` + case OPTION_IMAGE_OPTS: + image_opts = true; + break; +``` +3. For the option "object", the following code appears during option parsing for dd and calls the user_creatable_process_cmdline in qemu-img.c:4980-4982. + +``` + case OPTION_OBJECT: + user_creatable_process_cmdline(optarg); + break; +``` +4. For the option "force-share", the following code appears during option parsing for measure and modifies the force_share in qemu-img.c:5237-5239. +``` + case 'U': + force_share = true; + break; +``` +Additional information: +But they do not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/mode-gemma3:12b/user/1240 b/results/classifier/mode-gemma3:12b/user/1240 new file mode 100644 index 00000000..df36d21c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1240 @@ -0,0 +1,17 @@ + + +The help document of qemu-nbd misses an option +Description of problem: +The "--help" option of qemu-nbd misses the option "tls-hostname". +Steps to reproduce: +1. For the option "tls-hostname", the following code appears during option parsing and modifies the tlshostname in qemu-nbd.c:760-762. + +``` + case QEMU_NBD_OPT_TLSHOSTNAME: + tlshostname = optarg; + break; +``` +Additional information: +But it does not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/mode-gemma3:12b/user/1244 b/results/classifier/mode-gemma3:12b/user/1244 new file mode 100644 index 00000000..6b9fa156 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1244 @@ -0,0 +1,47 @@ + + +macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups +Description of problem: +Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway: + +``` +$ ld -v +@(#)PROGRAM:ld PROJECT:ld64-819.6 +BUILD 14:58:44 Aug 5 2022 +configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em +LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29) +TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) + +$ ninja -C build +ninja: Entering directory `build' +[314/2946] Linking static target libevent-loop-base.a +warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols) +[2044/2946] Generating qemu-system-aarch64 with a custom command +qemu-system-aarch64.tmp: replacing existing signature +[2584/2946] Linking target tests/plugin/libempty.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2585/2946] Linking target tests/plugin/libbb.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2588/2946] Linking target tests/plugin/libinsn.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2589/2946] Linking target tests/plugin/libmem.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2592/2946] Linking target tests/plugin/libsyscall.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2946/2946] Linking target tests/qtest/test-arm-mptimer +``` + +I saw a similar discussions in Bazel building system, CPython, and Ruby: +- https://github.com/bazelbuild/bazel/issues/16413 +- https://github.com/python/cpython/issues/97524 +- https://github.com/ruby/ruby/pull/6193 +- https://issues.guix.gnu.org/issue/57849 +Steps to reproduce: +1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though) +2. `ninja -C build` +3. Observe the warnings +Additional information: +See "New Features" subsection under "Linking" section for chained fixup +https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information: + +> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380) diff --git a/results/classifier/mode-gemma3:12b/user/1245703 b/results/classifier/mode-gemma3:12b/user/1245703 new file mode 100644 index 00000000..888e579e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1245703 @@ -0,0 +1,11 @@ + + +LD_PREFIX option reads directories recursively in an endless loop + +If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel. + +According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop. + +The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. + +Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1246990 b/results/classifier/mode-gemma3:12b/user/1246990 new file mode 100644 index 00000000..28a74119 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1246990 @@ -0,0 +1,40 @@ + + +[qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version. + +On linux: + +./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) + +$ sudo ./qemu-x86_64 ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +$ sudo gdb ./qemu-x86_64 +(gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet +(gdb) where +#0 0x00005555559c21bd in static_code_gen_buffer () +#1 0x00005555555b74d5 in cpu_tb_exec (cpu=0x555557972580, tb_ptr=0x5555559c2190 <static_code_gen_buffer+819792> "A\213n\250\205\355\017\205\257") + at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56 +#2 0x00005555555b817d in cpu_x86_exec (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631 +#3 0x00005555555d997a in cpu_loop (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283 +#4 0x00005555555eca6b in clone_func (arg=0x7fffffffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266 +#5 0x00007ffff71bfe0e in start_thread (arg=0x7ffff7f04700) at pthread_create.c:311 +#6 0x00007ffff6ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 + +$ file rjsupplicant +rjsupplicant: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped + +$ uname -r +3.10-2-amd64 + + +And it can be run on Linux amd64 successfully. + +Though I don't have the source code of rjsupplicant, so I don't have further information. + +`qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log + + +The binary is available to download at http://ge.tt/6pgG1tw/v/0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1248 b/results/classifier/mode-gemma3:12b/user/1248 new file mode 100644 index 00000000..39898840 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1248 @@ -0,0 +1,13 @@ + + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/mode-gemma3:12b/user/1251 b/results/classifier/mode-gemma3:12b/user/1251 new file mode 100644 index 00000000..d4f5a9a7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1251 @@ -0,0 +1,17 @@ + + +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/mode-gemma3:12b/user/1254672 b/results/classifier/mode-gemma3:12b/user/1254672 new file mode 100644 index 00000000..dd333665 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1254672 @@ -0,0 +1,43 @@ + + +ps segfaults with qemu-{arm,armel,mips,powerpc}-static + +Host: Ubuntu Precise AMD64 +Guest: Debian Testing armhf + +After running a debootstrap for Debian testing/armhf and entering the chroot, simply running "ps" causes a segmentation fault. + +$ sudo qemu-debootstrap --arch=armhf testing armhf http://ftp.uk.debian.org/debian/ +[...] +$ sudo chroot armhf +# ps +Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4). +/bin/ps:display.c:59: please report this bug + +I couldn't find a bug report for procps, which would be unusual if such a bug existed, so I'm assuming the bug is in qemu. + +Unfortunately trying to run debootstrap for an Ubuntu variant fails to find the release file. + +ps is used a lot, as you can imagine, but specifically it fails when trying to install some packages via "apt-get install" and no attempt is made to recover. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 10:43:12 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1254828 b/results/classifier/mode-gemma3:12b/user/1254828 new file mode 100644 index 00000000..a960a1f3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1254828 @@ -0,0 +1,39 @@ + + +qemu-sparc64-static: Segmentation Fault during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian Sid (ports) sparc64 + +When attempting the second stage of a debootstrap for a sparc64 Debian Sid guest, a segmentation fault occurs. + +$ sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch sparc64 --foreign --no-check-gpg sid sparc64 http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage +/debootstrap/debootstrap: 22: .: Can't open /usr/share/debootstrap/functions +Segmentation fault (core dumped) + +Running a simple "sudo chroot sparc64" exits silently on amd64, and reports a segfault on i386. + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 17:49:34 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1256 b/results/classifier/mode-gemma3:12b/user/1256 new file mode 100644 index 00000000..5760c429 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1256 @@ -0,0 +1,24 @@ + + +Building installer fails on Windows 10 Msys2 +Description of problem: +build fails with: +``` +make[2]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +Traceback (most recent call last): + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 89, in <module> + main() + File "C:\Users\sxlga\source\repos\qemu\scripts\nsis.py", line 34, in main + with open( +OSError: [Errno 22] Invalid argument: 'C:/Users/sxlga/AppData/Local/Temp/tmpinyvlwkoC:/msys64/qemu/system-emulations.nsh' +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:165: run-ninja] Error 1 +make[1]: Leaving directory '/c/Users/sxlga/source/repos/qemu/build' +make: *** [GNUmakefile:11: installer] Error 2 +``` +Steps to reproduce: +1. ./configure --target-list=arm-softmmu,aarch64-softmmu +2. make all +3. make installer +Additional information: +following https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2 to set up toolchain diff --git a/results/classifier/mode-gemma3:12b/user/1258626 b/results/classifier/mode-gemma3:12b/user/1258626 new file mode 100644 index 00000000..4fd607a9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1258626 @@ -0,0 +1,11 @@ + + +Curses Keyboard Broken On OS X + +Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k en-gb'') on OS X 10.9, the keyboard does not work properly. For example, when attempting to switch to the QEMU console with Alt+2, I get: + +``Warning: no scancode found for keysym 226 +Warning: no scancode found for keysym 130 +Warning: no scancode found for keysym 172'' + +I have checked and these scancodes are not mentioned in ``share/qemu/keymaps/''.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1261 b/results/classifier/mode-gemma3:12b/user/1261 new file mode 100644 index 00000000..cea36ed5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1261 @@ -0,0 +1,27 @@ + + +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/mode-gemma3:12b/user/1263747 b/results/classifier/mode-gemma3:12b/user/1263747 new file mode 100644 index 00000000..1b71d402 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1263747 @@ -0,0 +1,31 @@ + + +Arm64 fails to run a binary which runs OK on real hardware + +This binary: + +http://oirase.annexia.org/tmp/test.gz + +runs OK on real aarch64 hardware. It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly. + +On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU. + +---- +The following section is only if you wish to compile this binary from source, otherwise you can ignore it. + +First compile OCaml from: + +https://github.com/ocaml/ocaml + +(note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile). You will have to apply the one-line patch from: + +https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html + + ./configure + make -j1 world.opt + +Then do: + + echo 'print_endline "hello, world"' > test.ml + ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test + ./test
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1267 b/results/classifier/mode-gemma3:12b/user/1267 new file mode 100644 index 00000000..a79cab43 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1267 @@ -0,0 +1,95 @@ + + +qemu-i386 missing VDSO +Description of problem: +Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue. +I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping` + +Interestingly, qemu-x86_64 and qemu-arm appear to work just fine. + +Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct: + +``` +~/src/qemu/build$ /bin/lldb ./qemu-i386 +(lldb) target create "./qemu-i386" +Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64). +(lldb) run /home/ayke/src/tinygo/tinygo/test +Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64) +Process 97986 stopped +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 +libc.so.6`__sigsuspend: +-> 0xfffff78fb9fc <+92>: svc #0 + 0xfffff78fba00 <+96>: cmn x0, #0x1, lsl #12 ; =0x1000 + 0xfffff78fba04 <+100>: b.hi 0xfffff78fba3c ; <+156> + 0xfffff78fba08 <+104>: mov w19, w0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 + frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5 + frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13 + frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13 + frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9 + frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5 + frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160 + frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81 +(lldb) ^D +``` + +I got a better (but still not great) backtrace in Qemu 7.0.0: + +``` +~/src/tinygo/tinygo$ /bin/lldb qemu-i386 +(lldb) target create "qemu-i386" +Current executable set to 'qemu-i386' (aarch64). +(lldb) run test +Process 98106 launched: '/usr/bin/qemu-i386' (aarch64) +Process 98106 stopped +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 +qemu-i386`cpu_ldub_code: +-> 0xaaaaaac4b564 <+32>: ldrb w0, [x0, w1, uxtw] + 0xaaaaaac4b568 <+36>: str xzr, [x2] + 0xaaaaaac4b56c <+40>: ret + +qemu-i386`cpu_lduw_code: + 0xaaaaaac4b570 <+0>: mrs x2, TPIDR_EL0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 + frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72 + frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144 + frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24 + frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400 + frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72 + frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364 + frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480 + frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208 + frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020 + frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160 + frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48 +(lldb) ^D +``` + +And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable: + +``` +#0 0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170 +#1 0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#2 translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#3 x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916 +#4 0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506 +#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569 +#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>) + at ../../accel/tcg/translator.c:103 +#7 0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512) + at ../../target/i386/translate.c:8631 +#8 0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, + cflags@entry=0) at ../../accel/tcg/translate-all.c:1744 +#9 0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414 +#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770 +#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207 +#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882 +``` diff --git a/results/classifier/mode-gemma3:12b/user/1267955 b/results/classifier/mode-gemma3:12b/user/1267955 new file mode 100644 index 00000000..e9cb6da8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1267955 @@ -0,0 +1,44 @@ + + +[i386] Parity Flag Not Set On xor %eax,%eax + +Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid + +Steps To Reproduce + +$ cat > prog.hex << EOF + +7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 +02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 +00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 +00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 +00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 +00 10 00 00 + +31 c0 +9c + +b8 04 00 00 00 +bb 01 00 00 00 +89 e1 +ba 04 00 00 00 +cd 80 + +b8 01 00 00 00 +bb 00 00 00 00 +cd 80 + +EOF + +$ xxd -p -r prog.hex > prog +$ chmod 700 prog + +$ ./prog | hexdump -vC +00000000 46 02 00 00 |F...| +00000004 + +$ qemu-i386 ./prog | hexdump -vC +00000000 42 02 00 00 |B...| +00000004 + +On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1274170 b/results/classifier/mode-gemma3:12b/user/1274170 new file mode 100644 index 00000000..b4500387 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1274170 @@ -0,0 +1,5 @@ + + +qemu window hides in the background on osx + +When launching qemu on OSX (10.8.5), the window comes up in the background. A bit of googling shows that the addition of [NSApp activateIgnoringOtherApps:YES]; before the [NSApp run]; in main fixes this.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1276 b/results/classifier/mode-gemma3:12b/user/1276 new file mode 100644 index 00000000..246ca0eb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1276 @@ -0,0 +1,17 @@ + + +[SDL] Fractional scaling is blurry +Description of problem: +The display looks blurry +Steps to reproduce: +1. Use a Wayland compositor (eg. Sway) with scale set to `1.25` +2. Launch an Ubuntu guest with the SDL display +3. Notice blurryness +Additional information: +https://github.com/libsdl-org/SDL/issues/6438 + +Blurry display https://user-images.githubusercontent.com/67585967/197484538-fde750aa-8982-4ac2-9d83-3861f6411a31.png + +Display with 1.00 scale https://user-images.githubusercontent.com/67585967/197484417-afd1d1c5-5ea1-46ce-82c5-fa8d9b2df459.png + +It was suggested in the SDL issue (https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1289513402) that it's caused by the `SDL_WINDOW_ALLOW_HIGHDPI` not being set. However, after setting that flag, the display is sharp again but it's not scaled properly (boxed) https://github.com/libsdl-org/SDL/issues/6438#issuecomment-1291663284, no idea what other changes need to be made. diff --git a/results/classifier/mode-gemma3:12b/user/1278 b/results/classifier/mode-gemma3:12b/user/1278 new file mode 100644 index 00000000..f395abe2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1278 @@ -0,0 +1,8 @@ + + +Error creating encrypted qcow2 disk using qemu-img +Description of problem: +Error creating encrypted qcow2 disk using qemu-img:No crypto library supporting PBKDF in this build: Function not implemented + +Steps to reproduce: +1.qemu-img create --object secret,id=sec0,data=123456 -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 base.qcow2 1G diff --git a/results/classifier/mode-gemma3:12b/user/1283519 b/results/classifier/mode-gemma3:12b/user/1283519 new file mode 100644 index 00000000..34d05437 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1283519 @@ -0,0 +1,12 @@ + + +PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped + +When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions: + +If the binary contains vrfim QEMU sees vrfiz +If the binary contains vrfin QEMU sees vrfim +If the binary contains vrfiz QEMU sees vrfin +The vrfip instruction is correctly recognized. + +Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1285363 b/results/classifier/mode-gemma3:12b/user/1285363 new file mode 100644 index 00000000..3aaa7b71 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1285363 @@ -0,0 +1,47 @@ + + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1287195 b/results/classifier/mode-gemma3:12b/user/1287195 new file mode 100644 index 00000000..c9149b5f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1287195 @@ -0,0 +1,5 @@ + + +validate_guest_space incorrectly enabled on AArch64 + +When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1294898 b/results/classifier/mode-gemma3:12b/user/1294898 new file mode 100644 index 00000000..015a4cb3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1294898 @@ -0,0 +1,80 @@ + + +gtk: menubar visible in fullscreen mode with gtk3 + +Using the gtk UI, compiled with gtk3, the menu bar is fully visible in full screen mode. On gtk2 it's hidden. The set_size_request call isn't abided on gtk3 it seems. + +Simple fix is: + +diff --git a/ui/gtk.c b/ui/gtk.c +index 66e886f..7b3bd3d 100644 +--- a/ui/gtk.c ++++ b/ui/gtk.c +@@ -805,7 +805,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + + if (!s->full_screen) { + gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE); +- gtk_widget_set_size_request(s->menu_bar, 0, 0); ++ gtk_widget_hide(s->menu_bar); + gtk_widget_set_size_request(s->drawing_area, -1, -1); + gtk_window_fullscreen(GTK_WINDOW(s->window)); + if (gd_on_vga(s)) { +@@ -815,7 +815,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + } else { + gtk_window_unfullscreen(GTK_WINDOW(s->window)); + gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s); +- gtk_widget_set_size_request(s->menu_bar, -1, -1); ++ gtk_widget_show(s->menu_bar); + gtk_widget_set_size_request(s->drawing_area, + surface_width(s->ds), + surface_height(s->ds)); + + +The problem with that is that hiding the menu bar means all its associated accelerators are no longer usable, so there's way to exit fullscreen mode. That's kind of a problem :) + +We can install the accelerators on the window, but make sure the menu item still shows the accelerator short cut. Example with the fullscreen accelerator: + +diff --git a/ui/gtk.c b/ui/gtk.c +index 66e886f..fbce2b0 100644 +--- a/ui/gtk.c ++++ b/ui/gtk.c +@@ -799,7 +799,7 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque) + } + } + +-static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) ++static void gd_do_full_screen(void *opaque) + { + GtkDisplayState *s = opaque; + +@@ -828,6 +828,11 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) + gd_update_cursor(s, FALSE); + } + ++static void gd_menu_full_screen(GtkMenuItem *item, void *opaque) ++{ ++ gd_do_full_screen(opaque); ++} ++ + static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque) + { + GtkDisplayState *s = opaque; +@@ -1304,10 +1309,11 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s, GtkAccelGroup *accel_g + gtk_menu_set_accel_group(GTK_MENU(view_menu), accel_group); + + s->full_screen_item = gtk_menu_item_new_with_mnemonic(_("_Fullscreen")); +- gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->full_screen_item), +- "<QEMU>/View/Full Screen"); +- gtk_accel_map_add_entry("<QEMU>/View/Full Screen", GDK_KEY_f, +- HOTKEY_MODIFIERS); ++ gtk_accel_group_connect(accel_group, GDK_KEY_f, HOTKEY_MODIFIERS, 0, ++ g_cclosure_new_swap(G_CALLBACK(gd_do_full_screen), s, NULL)); ++ gtk_accel_label_set_accel( ++ GTK_ACCEL_LABEL(gtk_bin_get_child(GTK_BIN(s->full_screen_item))), ++ GDK_KEY_f, HOTKEY_MODIFIERS); + gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->full_screen_item); + + separator = gtk_separator_menu_item_new(); + + +However gtk_accel_label_set_accel, which shows the accel key sequence in the menu, is gtk 3.8+ :/ So older versions wouldn't have any visual indication of the shortcuts. Maybe that's not a problem, SDL didn't have any indication of shortcuts either.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1295 b/results/classifier/mode-gemma3:12b/user/1295 new file mode 100644 index 00000000..d730d0ce --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1295 @@ -0,0 +1,29 @@ + + +configure script can fail if compiler flag `-Wunused-parameter` is enabled +Description of problem: +`configure` fails with an error message: + +``` +ERROR: SafeStack is only supported by the coroutine backend ucontext +``` +Steps to reproduce: +1. Run `./configure --cross-prefix=x86_64-w64-mingw32- --disable-werror --extra-cflags=-Wunused-parameter` +Additional information: +Last part of `config.log`: + +``` +x86_64-w64-mingw32-gcc -m64 -mcx16 -I/mingw64/include -Wunused-parameter -fno-pie -mthreads -std=gnu11 -Wall -fno-pie -no-pie -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -Werror -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -L/mingw64/lib -no-pie +config-temp/qemu-conf.c: In function ‘main’: +config-temp/qemu-conf.c:1:14: error: unused parameter ‘argc’ [-Werror=unused-parameter] + 1 | int main(int argc, char *argv[]) + | ~~~~^~~~ +config-temp/qemu-conf.c:1:26: error: unused parameter ‘argv’ [-Werror=unused-parameter] + 1 | int main(int argc, char *argv[]) + | ~~~~~~^~~~~~ +cc1: all warnings being treated as errors +``` + +The configure script fails because it tries to compile small C programs with a main function which is declared with arguments `argc` and `argv` although those arguments are unused. + +Using the same compiler flag for a native build (`./configure --disable-werror --extra-cflags=-Wunused-parameter`) shows the same errors in `config.log`, but surprisingly does not fail. diff --git a/results/classifier/mode-gemma3:12b/user/1308381 b/results/classifier/mode-gemma3:12b/user/1308381 new file mode 100644 index 00000000..df1cb782 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1308381 @@ -0,0 +1,16 @@ + + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1310 b/results/classifier/mode-gemma3:12b/user/1310 new file mode 100644 index 00000000..fa00532e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1310 @@ -0,0 +1,192 @@ + + +qemu-nbd export img and detect block if is zero with libnbd +Description of problem: +In our project,we use qemu-nbd to export a img,and use libnbd to read/write data.if the img is preallocated,we wonder the data block if is zero,we use api nbd_block_status in libnbd to get the block status,but it shows server does not support structured replies: Operation not supported.I know our qemu is too old.so,i want to know how can i know if the block in preallocated is zero or not in nbd client. +Steps to reproduce: +1.qemu-nbd -p 8889 -f raw a.img + +2.the nbd client use libnbd,code is: +```c +#include <config.h> + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <assert.h> +#include <stdbool.h> +#include <errno.h> + +#include <libnbd.h> + +static const char *bitmap; + +struct data { + bool req_one; /* input: true if req_one was passed to request */ + int count; /* input: count of expected remaining calls */ + bool fail; /* input: true to return failure */ + bool seen_base; /* output: true if base:allocation encountered */ + bool seen_dirty; /* output: true if qemu:dirty-bitmap encountered */ +}; + +static int +cb (void *opaque, const char *metacontext, uint64_t offset, + uint32_t *entries, size_t len, int *error) +{ + struct data *data = opaque; + + /* libnbd does not actually verify that a server is fully compliant + * to the spec; the asserts marked [qemu-nbd] are thus dependent on + * the fact that qemu-nbd is compliant. Furthermore, qemu 5.2 and + * 6.0 disagree on whether base:allocation includes the hole bit for + * the zeroes at 512k (both answers are compliant); but we care more + * that the zeroes show up in the dirty bitmap + */ + assert (offset == 0); + assert (!*error || (data->fail && data->count == 1 && *error == EPROTO)); + assert (data->count-- > 0); /* [qemu-nbd] */ + + if (strcmp (metacontext, LIBNBD_CONTEXT_BASE_ALLOCATION) == 0) { + assert (!data->seen_base); /* [qemu-nbd] */ + data->seen_base = true; + if (data->req_one) + assert (len == 2); /* [qemu-nbd] */ + else + assert ((len & 1) == 0 && len > 2); /* [qemu-nbd] */ + + /* Data block offset 0 size 128k */ + assert (entries[0] == 131072); assert (entries[1] == 0); + if (!data->req_one) { + if (len == 4) { + /* hole|zero offset 128k size 896k */ + assert (entries[2] == 917504); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + else { + assert (len == 8); + /* hole|zero offset 128k size 384k */ + assert (entries[2] == 393216); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + /* allocated zero offset 512k size 64k */ + assert (entries[4] == 65536); + assert (entries[5] == LIBNBD_STATE_ZERO); + /* hole|zero offset 576k size 448k */ + assert (entries[6] == 458752); + assert (entries[7] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + } + } + else if (strcmp (metacontext, bitmap) == 0) { + assert (!data->seen_dirty); /* [qemu-nbd] */ + data->seen_dirty = true; + assert (len == (data->req_one ? 2 : 10)); /* [qemu-nbd] */ + + assert (entries[0] == 65536); assert (entries[1] == 0); + if (!data->req_one) { + /* dirty block offset 64K size 64K */ + assert (entries[2] == 65536); assert (entries[3] == 1); + assert (entries[4] == 393216); assert (entries[5] == 0); + /* dirty block offset 512K size 64K */ + assert (entries[6] == 65536); assert (entries[7] == 1); + assert (entries[8] == 458752); assert (entries[9] == 0); + } + } + else { + fprintf (stderr, "unexpected context %s\n", metacontext); + exit (EXIT_FAILURE); + } + + if (data->fail) { + /* Something NBD servers can't send */ + *error = data->count == 1 ? EPROTO : ECONNREFUSED; + return -1; + } + return 0; +} + +int +main (int argc, char *argv[]) +{ + struct nbd_handle *nbd; + int64_t exportsize; + struct data data; + char c; + + if (argc < 3) { + fprintf (stderr, "%s bitmap qemu-nbd [args ...]\n", argv[0]); + exit (EXIT_FAILURE); + } + bitmap = argv[1]; + + nbd = nbd_create (); + if (nbd == NULL) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION); + nbd_add_meta_context (nbd, bitmap); + + if (nbd_connect_tcp (nbd, argv[2],argv[3]) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + exportsize = nbd_get_size (nbd); + if (exportsize == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + data = (struct data) { .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + data = (struct data) { .req_one = true, .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + LIBNBD_CMD_FLAG_REQ_ONE) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + /* Trigger a failed callback, to prove connection stays up. */ + data = (struct data) { .count = 2, .fail = true, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) != -1) { + fprintf (stderr, "unexpected block status success\n"); + exit (EXIT_FAILURE); + } + assert (nbd_get_errno () == EPROTO && nbd_aio_is_ready (nbd)); + assert (data.seen_base && data.seen_dirty); + + if (nbd_pread (nbd, &c, 1, 0, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + if (nbd_shutdown (nbd, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_close (nbd); + + exit (EXIT_SUCCESS); +} + +``` +3. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1311614 b/results/classifier/mode-gemma3:12b/user/1311614 new file mode 100644 index 00000000..36d096a7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1311614 @@ -0,0 +1,49 @@ + + +qemu-arm segfaults with gcc 4.9.0 + +I have an ARM chroot that working with qemu-arm emulation + +[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm +enabled +interpreter /usr/bin/qemu-arm-binfmt +flags: P +offset 0 +magic 7f454c4601010100000000000000000002002800 +mask ffffffffffffff00fffffffffffffffffeffffff + + +In chroot installed gcc dependencies with 4.9.0 version + +sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0 + +libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl +libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl +libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl +gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl + + +When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message + + +example: + +[root@filzbach /]# uname -a +Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux + +[root@filzbach /]# rpm +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + + +Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0. + +When i downgrade it to 4.8.3 all working fine again. +It looks like a qemu bug with gcc. + + +P.S. +I tried to rebuild qemu with gcc 4.9.0 +I tried to build qemu from git sources, from fedora sources, from suse sources etc.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1312561 b/results/classifier/mode-gemma3:12b/user/1312561 new file mode 100644 index 00000000..ef0d5ef4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1312561 @@ -0,0 +1,17 @@ + + +libstdc++-6.dll is missing from your computer + +qemu-w64-setup-20140418.exe + +Windows 7 64 bit PC. + +qemu-system-armw -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda c:\11\rasimg\test.vhd + + +qemu-system-armw.exe - System Error +The program can't start because libstdc++-6.dll is missing from your computer. + +Try reinstalling the program to fix this problem. + +I tried reinstalling, but no change.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1314667 b/results/classifier/mode-gemma3:12b/user/1314667 new file mode 100644 index 00000000..02fef521 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1314667 @@ -0,0 +1,46 @@ + + +PMPrebUSB - appcrash of qemu in Win-7-64bit + +I am not sure if this issue is a bug of qemu or by Win-7. +I want to test in advance with QEMU the ability if my USB-Rescue-Drive is +booting correctly. I have Win-7-64 and run qemu v.o.15.1.0 out of the installed RMPrepUSB v.2.1.719 +program. The settings for the preparation of my USB drive were FAT32 boot as +HD, bootloader WinPE/Win-7/Vista, set for running iso-files directly in %_ISO +\MAINMENU\Hiren’sBootCD.iso. When I run Qemu I get the messages in the cmd starting window it says: + +Administrator: RMPrepUSB QEMU Launcher +************************************** +EXECUTING "C:\Program Files (x86)\RMPrepUSB\qemu\STARTFROMUSB.cmd" +DRIVE NUMBER=3 +MEMORY SIZE=1000 +HARD DISK IMAGE=harddisk.img +NOWRITE= +Found OS=VISTA_OR_LATER +Sending command Start_VM.exe 3 500 qemu.exe -L . -name "RMPrepUSB Emulation +Session RAM=1000MB VirtualHDD=harddisk.i +lt+LCtrl)" -boot c -m 1000 -drive file=\\. +\PhysicalDrive3,if=ide,index=0,media=disk -hdb harddisk.img to shell... + +Win-7: in the second window appears: +*********************************** +-->qemu funktioniert nicht mehr +Problemsignatur: + Problemereignisname: APPCRASH + Anwendungsname: qemu.exe + Anwendungsversion: 0.15.1.0 + Anwendungszeitstempel: 4f478c16 + Fehlermodulname: qemu.exe + Fehlermodulversion: 0.15.1.0 + Fehlermodulzeitstempel: 4f478c16 + Ausnahmecode: 40000015 + Ausnahmeoffset: 00053b06 + Betriebsystemversion: 6.1.7601.2.1.0.256.48 + Gebietsschema-ID: 1031 + Zusatzinformation 1: bf8d + Zusatzinformation 2: bf8d49108a2e5a0707fc48438e01652a + Zusatzinformation 3: b0f1 + Zusatzinformation 4: b0f155b0f1de9c5eb22bd6d100737cbe + +If somebody can understand that behaviour I appreciate everybodies help. Thank you with regards +H.O.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1318281 b/results/classifier/mode-gemma3:12b/user/1318281 new file mode 100644 index 00000000..2c5e988e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1318281 @@ -0,0 +1,36 @@ + + +linux-user: x86_64 target fails to call sys_futex() + +I'm building the latest QEMU (06b4f00d53637f2c16a62c2cbaa30bffb045cf88) on ARM to run some x86_64 executables in user mode. This is my configuration: + +./configure \ + --prefix=/root/qemu-x86_64 \ + --target-list=x86_64-linux-user \ + --disable-system \ + --disable-tools + +The following program is used for testing: + +https://gist.github.com/hujiajie/e8cff43b574b399c8f59#file-test-c + +I compile the test program in Debian-7.5-amd64 like this: + +gcc -o test `pkg-config --cflags glib-2.0` test.c `pkg-config --static --libs glib-2.0` -static + +and launch the program on ARM with + +qemu-x86_64 test + +The test crashes with the following message: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +The output of `strace qemu-x86_64 test` is here: + +https://gist.github.com/hujiajie/88d1d5e580d432d11b2d#file-test-strace-log + +It seems that the error is caused by the failure of the futex syscall. + +qemu-i386 could launch the 32-bit test perfectly, the problem only happens on a x86_64 target.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1319100 b/results/classifier/mode-gemma3:12b/user/1319100 new file mode 100644 index 00000000..13bc34c6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1319100 @@ -0,0 +1,71 @@ + + +qemu-arm-static bug in signal handling causes mono and java to hang + +Note, this bug is already reported to debian, but it seems to also affect the upstream code. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748043 + +running mono in a chroot environment with qemu-user-static is not posible +because at least one signal used during termination of mono is routed to the +host. + +This can be reproduced by: +debootstrap --include=mono-runtime --foreign --arch=armel "wheezy" "mono-test" "http://ftp.de.debian.org//debian" +cp /usr/bin/qemu-arm-static mono-test/usr/bin +mount -t proc none mono-test/proc +mount -o bind /dev mono-test/dev +mount -o bind /sys mono-test/sys +chroot mono-test +../debootstrap/debootstrap --second-stage +exit +mount -t proc none mono-test/proc +mount -o bind /sys mono-test/sys +chroot mono-test +QEMU_STRACE=1 /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +This will block on a futex: + +--8<-- +18663 sched_yield(0,0,2582980,0,0,2582928) = 0 +18663 clock_gettime(1,-150996384,2,1,2585016,2585600) = 0 +18663 tgkill(18663,18664,30,18664,30,-161951744) = 0 +18663 futex(0x00293774,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,0,NULL,NULL,0) +--8<-- + +If you use mono within strace on a native x86 box you can see, that signals +between threads are used during termination: + +strace -f -o log.txt /usr/bin/mono /usr/lib/mono/4.0/gacutil.exe + +--8<-- +14075 sched_yield() = 0 +14075 tgkill(14075, 14083, SIGPWR) = 0 +14075 futex(0x983f00, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...> +14083 <... futex resumed> ) = ? ERESTARTSYS (To be restarted) +14083 --- SIGPWR (Power failure) @ 0 (0) --- +14083 futex(0x983f00, FUTEX_WAKE_PRIVATE, 1) = 1 +14075 <... futex resumed> ) = 0 +14083 rt_sigsuspend(~[INT QUIT ABRT TERM XCPU RTMIN RT_1] <unfinished ...> +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 24) = 3 +14078 <... futex resumed> ) = 0 +14078 futex(0x94da20, FUTEX_WAKE_PRIVATE, 1) = 1 +14077 <... futex resumed> ) = 0 +14075 futex(0x94d9a4, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x94da20, 26 <unfinished ...> +--8<-- + +This also blocks the installation of libnunit2.6-cil within a armel chroot, +because it uses mono in its postinst script. +E.g. (/usr/bin/mono /usr/share/mono/MonoGetAssemblyName.exe /usr/lib/cli/nunit.core-2.6/nunit.core.dll) + +Obviously the same as described in: +http://lists.opensuse.org/opensuse-arm/2011-12/msg00000.html +is happening here. + +There is an openSuSE patch against qemu: +https://build.opensuse.org/package/view_file/Virtualization:Qemu/qemu/0002-XXX-work-around-SA_RESTART-race-wit.patch?expand=1 + +This patch also applies against qemu from backports-wheezy and resolves this +issue. + +As it seems, that this issue is not Debian specific i will also report it to +the qemu project and reference this bug report.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1325 b/results/classifier/mode-gemma3:12b/user/1325 new file mode 100644 index 00000000..9c37e9ce --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1325 @@ -0,0 +1,83 @@ + + +c++: internal compiler error: Segmentation fault signal terminated program cc1plus when running in qemu-aarch64-static chroot on x86_64 +Description of problem: +After a moment of compiling the `src/emoji/Provider.cpp` file, `cc1plus` (I assume the compiler program itself) throws a segfault when running in the emulated chroot environment. The error is shown below. +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +c++: internal compiler error: Segmentation fault signal terminated program cc1plus +Please submit a full bug report, with preprocessed source (by using -freport-bug). +See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions. +``` + +This does not happen if you enter the chroot environment on a real ARM device (like a Raspberry PI 3 or 4 or PinePhone). The ARM device does not need to have `qemu-user-static`, nor `qemu-user-static-binfmt` installed because it does not need to emulate an aarch64 CPU. +Steps to reproduce: +There are two ways to replicate this. Either use (1) my preconfigured ARM chroot or (2) setup the chroot environment yourself. These instructions assume you are running on Arch Linux (x86_64). +1. You can use my aarch64 chroot environment provided. (This is the easy way) + - 1) Clone the repo I provided and then change into that directory. +```bash +git clone https://github.com/i3Craig/Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu.git +cd Temp-aarch64-chroot-for-nheko-compile-issues-in-qemu +``` + - 2) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (technically `chroot` will work since we don't need to use `pacman` for anything with this method, so you could skip `arch-install-scripts` if you prefer). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 3) I put the chroot environment in a state where you can simply run the following command to build the one file that fails. Run the following command. + ```bash +sudo chroot chroot/ /usr/bin/c++ -DFMT_SHARED -DGSTREAMER_AVAILABLE -DNHEKO_DBUS_SYS -DQAPPLICATION_CLASS=QApplication -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_QMLMODELS_LIB -DQT_QML_LIB -DQT_QUICKCONTROLS2_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SVG_LIB -DQT_WIDGETS_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DXCB_AVAILABLE -Dnheko_EXPORTS -I/home/builder/packages/nheko/src/build -I/home/builder/packages/nheko/src/nheko-0.10.2 -I/home/builder/packages/nheko/src/build/nheko_autogen/include -I/home/builder/packages/nheko/src/nheko-0.10.2/src -I/home/builder/packages/nheko/src/nheko-0.10.2/includes -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/blurhash -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/cpp-httplib-0.5.12 -I/home/builder/packages/nheko/src/nheko-0.10.2/third_party/SingleApplication-3.3.2 -isystem /usr/include/qt -isystem /usr/include/qt/QtDBus -isystem /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /usr/include/qt/QtSvg -isystem /usr/include/qt/QtConcurrent -isystem /usr/include/qt/QtMultimedia -isystem /usr/include/qt/QtNetwork -isystem /usr/include/qt/QtQml -isystem /usr/include/qt/QtQuickControls2 -isystem /usr/include/qt/QtQuick -isystem /usr/include/qt/QtQmlModels -isystem /usr/include/qt/QtQuickWidgets -isystem /usr/include/gstreamer-1.0 -isystem /usr/include/glib-2.0 -isystem /usr/lib/glib-2.0/include -isystem /usr/include/sysprof-4 -isystem /usr/include/orc-0.4 -isystem /usr/include/libmount -isystem /usr/include/blkid -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wp,-D_GLIBCXX_ASSERTIONS -Wall -Wextra -pedantic -fsized-deallocation -fdiagnostics-color=always -Wunreachable-code -Wno-attributes -fPIE -fPIC -DSPDLOG_SHARED_LIB -DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL -pthread -std=gnu++17 -Winvalid-pch -include /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/cmake_pch.hxx -MD -MT /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -MF /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o.d -o /home/builder/packages/nheko/src/build/CMakeFiles/nheko.dir/src/emoji/Provider.cpp.o -c /home/builder/packages/nheko/src/nheko-0.10.2/src/emoji/Provider.cpp + ``` +- 4) The above command will fail with a segfault error. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and run the compile command from step (3), it will be successful. This suggests that everything is setup correctly, but there is a bug in QEMU that causes the c++ compiler to fail. + +2. You can download an Arch Linux ARM image from archlinuxarm.org and chroot into that. Then attempt to build the `nheko` AUR package. (This way requires extra work, but you can use this if you don't trust my chroot archive). + - 1) Download Arch Linux ARM to your X86_64 PC. The Raspberry PI 3/4 image should work. `http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-aarch64-latest.tar.gz`. Signatures are available on archlinuxarm.org. + - 2) Extract the tar archive: `mkdir chroot; sudo tar -xf ArchLinuxARM-rpi-aarch64-latest.tar.gz -C chroot` (this will extract to the `chroot` folder in your current working directory. + - 3) On your PC, install `qemu-user-static` and `qemu-user-static-binfmt` and `arch-install-scripts`. This will allow us to `chroot` into the Arch Linux ARM image (using the `arch-chroot` because we will need to install packages with pacman in the chroot environment). `sudo pacman -S qemu-user-static qemu-user-static-binfmt arch-install-scripts`. + - 4) Now, we can bindmount the `chroot` directory to itself so `arch-chroot` is happy. `sudo mount --bind chroot/ chroot/` + - 5) Enter the chroot: `sudo arch-chroot chroot/` + - 6) At this point, we need to get our build environment setup. Let's start by installing `git`, `base-devel`, `screen` and `vim`. `pacman -S git base-devel screen vim`. I use screen to have one terminal for the root user to install stuff and one for the `builder` user that we will create for building packages as `makepkg` does not particularly like to run as root. + - 7) Add the builder user and create its home folder: `useradd builder; mkdir /home/builder; chown builder:builder /home/builder`. + - 8) You could maybe use an AUR helper to build the following packages, but they don't have the 'aarch64' flag, so they will throw an error when you try to compile them. Thus, I use `makepkg` manually with the `--ignorearch` flag to ignore the architecture of the chroot environment (they are fully compatible with aarch64, just not marked as such). Thus, run `su -l builder` to switch to the builder user, `mkdir packages` to create the packages folder, and then clone the following AUR packages into this folder and build them: `coeurl lmdbxx mtxclient nheko tweeny`. These are dependencies for `nheko`. The process is `git clone https://aur.archlinux.org/<PACKAGENAME>.git`, then `cd PACKAGENAME`, then `makepkg --ignorearch`, then (as the root user in the chroot environment - can use sudo if you set it up) `pacman -U PACKAGENAME.PACKAGEVERSION.pkg.tar.xz` (you can type the package name and then use tab to autocomplete the exact package name). They will all compile just fine and install correctly. + - 9) Now, do the same for the AUR package `nheko`. Notice that it will start to compile, but the error shown above will be printed on the screen after a while. If you copy your `chroot` over to a real ARM device (like an Raspberry PI 3 or 4 or PinePhone) and `arch-chroot` into it and attempt the compile again, it will be successful. This suggests that everything is setup correctly, but there is a bug in qemu that causes the c++ compiler to fail. This is known to break in nheko version `0.10.2-1`. You can get to this by running `git checkout d83124fbffe86d7f875bf8e56834ae98cc21160c` after you clone the `nheko` AUR build script. This is the current latest version as of writing this, but this may change in the future and the bug may no longer show up. If it doesn't, run that `git checkout` command. +Additional information: +After using the `-strace` option in `qemu-aarch64-static` (which has to be copied from the host system to the chroot for this to work: `sudo cp /usr/bin/qemu-aarch64-static chroot/usr/bin/qemu-aarch64-static`), I determined that `c++` was running `/usr/lib/gcc/aarch64-unknown-linux-gnu/12.1.0/cc1plus`, which segfaulted. Note: have to run `sudo arch-chroot chroot/ /usr/bin/qemu-aarch64-static -strace <PUT LONG C++ COMPILE COMMAND HERE>`. +After manually running the `cc1plus` command with the `-strace` option outlined above, I get the following strace, which doesn't seem particularly interesting. +``` +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520bc3000 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 mmap(NULL,4198400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520be3000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 munmap(0x0000005520be3000,4198400) = 0 +1 brk(0x000000000320a000) = 0x000000000320a000 +1 brk(0x000000000324a000) = 0x000000000324a000 +1 brk(0x00000000032ca000) = 0x00000000032ca000 +1 brk(0x00000000033ca000) = 0x00000000033ca000 +1 brk(0x00000000035ca000) = 0x00000000035ca000 +1 brk(0x00000000039ca000) = 0x00000000039ca000 +1 brk(0x00000000031ca000) = 0x00000000031ca000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x0000005520fe4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055211e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055213e4000 +1 mmap(NULL,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055215e4000 +1 brk(0x00000000031eb000) = 0x00000000031eb000 +1 mmap(NULL,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 0x00000055217e4000 +1 brk(0x0000000003214000) = 0x0000000003214000 +1 brk(0x0000000003274000) = 0x0000000003274000 +1 brk(0x0000000003295000) = 0x0000000003295000 +1 brk(0x0000000003318000) = 0x0000000003318000 +1 brk(0x0000000003339000) = 0x0000000003339000 +1 brk(0x000000000335a000) = 0x000000000335a000 +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +--- SIGSEGV {si_signo=SIGSEGV, si_code=2, si_addr=0x0000005500000ff0} --- +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +``` + + +I haven't encountered this bug when compiling any other programs, which is good. However, it mea diff --git a/results/classifier/mode-gemma3:12b/user/1326533 b/results/classifier/mode-gemma3:12b/user/1326533 new file mode 100644 index 00000000..0118e6be --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1326533 @@ -0,0 +1,21 @@ + + +SDL2 UI sends a NULL to sdl_grab_start if fullscreen, which crashes + +in ui/sdl2.c: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(0); + } + +Is sent, but no null checks are made in sdl_grab_start (its assumed to be an allocated pointer). So a crash happens if you start qemu -full-screen. + +It should at lease send the first [0] of the newly allocated sdl2_console through. + +Quickly looking around should look something like: + + if (full_screen) { + gui_fullscreen = 1; + sdl_grab_start(&sdl2_console[0]); + }
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1327 b/results/classifier/mode-gemma3:12b/user/1327 new file mode 100644 index 00000000..200c1e41 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1327 @@ -0,0 +1,92 @@ + + +vhost-user-test outputs scary messages +Description of problem: +The qos-test seems to output failure messages when run in verbose mode, see e.g.: + +https://gitlab.com/qemu-project/qemu/-/jobs/3340919275#L5615 + +``` +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-reconnect,path=/tmp/vhost-test-9B51V1/reconnect.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-9B51V1/reconnect.sock,server=on +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-connect-fail,path=/tmp/vhost-test-49UUV1/connect-fail.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: Failed to read msg header. Read 0 instead of 12. Original request 1. +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: vhost_backend_init failed: Protocol error +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: failed to init vhost_net for queue 0 +qemu-system-aarch64: -netdev vhost-user,id=hs0,chardev=chr-connect-fail,vhostforce=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-49UUV1/connect-fail.sock,server=on +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: -chardev socket,id=chr-flags-mismatch,path=/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on: info: QEMU waiting for connection on: disconnected:unix:/tmp/vhost-test-LTKOV1/flags-mismatch.sock,server=on +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 52. +qemu-system-aarch64: vhost_set_mem_table failed: Invalid argument (22) +qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio +vhost lacks feature mask 0x40000000 for backend +qemu-system-aarch64: failed to init vhost_net for queue 0 +qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 20. +qemu-system-aarch64: vhost_set_vring_num failed: Invalid argument (22) +qemu-system-aarch64: unable to start vhost net: 22: falling back on userspace virtio +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 2 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 3 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_endian failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22) +qemu-system-aarch64: Failed to set msg fds. +qemu-system-aarch64: vhost_set_vring_call failed: Invalid argument (22) +―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― +``` diff --git a/results/classifier/mode-gemma3:12b/user/1328996 b/results/classifier/mode-gemma3:12b/user/1328996 new file mode 100644 index 00000000..7580ee16 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1328996 @@ -0,0 +1,5 @@ + + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/134 b/results/classifier/mode-gemma3:12b/user/134 new file mode 100644 index 00000000..b6f7fb36 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/134 @@ -0,0 +1,3 @@ + + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions diff --git a/results/classifier/mode-gemma3:12b/user/1346769 b/results/classifier/mode-gemma3:12b/user/1346769 new file mode 100644 index 00000000..9f137c47 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1346769 @@ -0,0 +1,38 @@ + + +/proc/self/maps content returned to 32-bits guest under 64-bits qemu + +Reading /proc/self/maps a user doesn't get a stack record. Not all programs relies on the maps file but some do. + +The bug found by running 32-bits binaries with address sanitizer (Asan) instrumentations under 64-bit qemu. + +$ echo "int main() { return 0; }" > /tmp/test.c +$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c +$ qemu-i386-static /tmp/test +==4092==AddressSanitizer CHECK failed: /home/michail/Downloads/gcc-4.9.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:63 "(((uptr)&rl >= start && (uptr)&rl < end)) != (0)" (0x0, 0x0) + #0 0xf632ff01 (/home/michail/build/lib32/libasan.so.1+0x53f01) + #1 0xf6333f49 (/home/michail/build/lib32/libasan.so.1+0x57f49) + #2 0xf6338785 (/home/michail/build/lib32/libasan.so.1+0x5c785) + #3 0xf6338bd1 (/home/michail/build/lib32/libasan.so.1+0x5cbd1) + #4 0xf6331baf (/home/michail/build/lib32/libasan.so.1+0x55baf) + #5 0xf6331dca (/home/michail/build/lib32/libasan.so.1+0x55dca) + #6 0xf6331f5a (/home/michail/build/lib32/libasan.so.1+0x55f5a) + #7 0xf6330bd4 (/home/michail/build/lib32/libasan.so.1+0x54bd4) + #8 0xf67ebeec (/lib/ld-linux.so.2+0xeeec) + #9 0xf67de10e (/lib/ld-linux.so.2+0x110e) + +This happened because during initialization Asan can't find stack boundaries. + +For some reasons Qemu wants to report stack boundaries just for several arch targets skipping other ones. This is from linux-user/syscall.c open_self_maps() + +#if defined(TARGET_ARM) || defined(TARGET_M68K) || defined(TARGET_UNICORE32) + dprintf(fd, "%08llx-%08llx rw-p %08llx 00:00 0 [stack]\n", + (unsigned long long)ts->info->stack_limit, + (unsigned long long)(ts->info->start_stack + + (TARGET_PAGE_SIZE - 1)) & TARGET_PAGE_MASK, + (unsigned long long)0); +#endif + +Not very clear why the case covers just specific targets. + +This bug continues the previously reported issue with not hiden system map http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1349722 b/results/classifier/mode-gemma3:12b/user/1349722 new file mode 100644 index 00000000..e207e7b6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1349722 @@ -0,0 +1,17 @@ + + +qemu-io: Exit code is always zero + +The qemu-io always returns zero on exit independently on errors occurred during the command execution. + +Example, + +$ qemu-io -c 'write 128 234' /tmp/run1/test-1/test.img + +offset 128 is not sector aligned + +$ echo $? +0 + + +qemu.git HEAD: 41a1a9c42c4e
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1356916 b/results/classifier/mode-gemma3:12b/user/1356916 new file mode 100644 index 00000000..7bcb2390 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1356916 @@ -0,0 +1,8 @@ + + +Too small argv limit + +Current kernels don't have a fixed argv/environ limit any more, but the user-space emulation of qemu is still using a fixed limit. This can cause execve to fail when it wouldn't on a real system. For example, the follwing command should not fail in the emulated environment: + +$ /bin/true $(yes | head -n 100000) +-bash: /bin/true: Argument list too long
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1357206 b/results/classifier/mode-gemma3:12b/user/1357206 new file mode 100644 index 00000000..32b80cd3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1357206 @@ -0,0 +1,61 @@ + + +QEMU user mode still crashes in multi-thread code. + +I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode. + +I did a little search and found LP:668799 but it is far from now and it is probably not the problem here. + +I used program below as the test program: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> + +void *print_message_function( void *ptr ); + +main() +{ + pthread_t thread1, thread2; + const char *message1 = "Thread 1"; + const char *message2 = "Thread 2"; + int iret1, iret2; + + /* Create independent threads each of which will execute function */ + + iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1); + if(iret1) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1); + exit(EXIT_FAILURE); + } + + iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2); + if(iret2) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2); + exit(EXIT_FAILURE); + } + + printf("pthread_create() for thread 1 returns: %d\n",iret1); + printf("pthread_create() for thread 2 returns: %d\n",iret2); + + /* Wait till threads are complete before main continues. Unless we */ + /* wait we run the risk of executing an exit which will terminate */ + /* the process and all threads before the threads have completed. */ + + pthread_join( thread1, NULL); + pthread_join( thread2, NULL); + + exit(EXIT_SUCCESS); +} + +void *print_message_function( void *ptr ) +{ + char *message; + message = (char *) ptr; + printf("%s \n", message); +} + +Compiled to i386 and aarch64 object, +and both qemu-i386 and qemu-aarch64 had segmentation faults.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1357226 b/results/classifier/mode-gemma3:12b/user/1357226 new file mode 100644 index 00000000..b9ec9d8b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1357226 @@ -0,0 +1,13 @@ + + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +steps to reproduce: +pbuilder-dist utopic armhf create +pbuilder-dist utopic armhf login +apt-get install imagemagick +convert foo.xpm foo.png +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +(doesn't matter if images are actually there or not)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1361 b/results/classifier/mode-gemma3:12b/user/1361 new file mode 100644 index 00000000..c4da99cf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1361 @@ -0,0 +1,22 @@ + + +ppc64le linux user emulation w/ 64KiB pages seems broken since v5.0.0 +Description of problem: +[Our (snmalloc's)](https://github.com/microsoft/snmalloc) CI includes running a PowerPC64 little-endian Linux build inside qemu, running with 64KiB pages as, at least, Debian runs them by default. As reported [over there](https://github.com/microsoft/snmalloc/issues/576), this broke when GitHub's CI runners moved from Ubuntu Focal (20.04) to Jammy (22.04), bringing qemu from v4.2 to v6.2. + +The failing test case appears to die of an erroneous `SIGSEGV` `SEGV_MAPERR`: +``` +--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0x0000004001be5000} --- +``` +despite that address nominally being mapped by the last memory syscall to touch that area +``` +openat(AT_FDCWD,"/usr/powerpc64le-linux-gnu/lib/libstdc++.so.6",O_RDONLY|O_CLOEXEC) = 4 +[...] +mmap(0x0000004001bd0000,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,4,0x2f0000) = 0x4001bd0000 +``` + +Bisection reveals that the breakage first occurred with 4dcf078f094d436866ef793aa25c96fba85ac8d0, though I suspect this is merely the commit that exposes some underlying bug rather than being the actual root cause. +Steps to reproduce: +Run a ppc64el Linux executable under `qemu-user` with `-p 65536`. +Additional information: +Please advise what more would be useful. diff --git a/results/classifier/mode-gemma3:12b/user/1361912 b/results/classifier/mode-gemma3:12b/user/1361912 new file mode 100644 index 00000000..bf2c9bcb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1361912 @@ -0,0 +1,11 @@ + + +qemu-mips64 Segmentation fault + +When I ran qemu-mips64 for any mips 64 executable , I got this error: + +$ ./qemu-mips64 ../lang +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) + +Is this a known issue?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1368815 b/results/classifier/mode-gemma3:12b/user/1368815 new file mode 100644 index 00000000..e9f7f670 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1368815 @@ -0,0 +1,39 @@ + + +qemu-img convert intermittently corrupts output images + +-- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on Ubuntu 14.04 using Ext4 filesystems. + +The command + + qemu-img convert -O raw inputimage.qcow2 outputimage.raw + +intermittently creates corrupted output images, when the input image is not yet fully synchronized to disk. While the issue has actually been discovered in operation of of OpenStack nova, it can be reproduced "easily" on command line using + + cat $SRC_PATH > $TMP_PATH && $QEMU_IMG_PATH convert -O raw $TMP_PATH $DST_PATH && cksum $DST_PATH + +on filesystems exposing this behavior. (The difficult part of this exercise is to prepare a filesystem to reliably trigger this race. On my test machine some filesystems are affected while other aren't, and unfortunately I haven't found the relevant difference between them, yet. Possible it's timing issues completely out of userspace control ...) + +The root cause, however, is the same as in + + http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html + +and it can be solved the same way as suggested in + + http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html + +In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change + + f.fm.fm_flags = 0; + +to + + f.fm.fm_flags = FIEMAP_FLAG_SYNC; + +As discussed in the thread mentioned above, retrieving a page cache coherent map of file extents is possible only after fsync on that file. + +See also + + https://bugs.launchpad.net/nova/+bug/1350766 + +In that bug report filed against nova, fsync had been suggested to be performed by the framework invoking qemu-img. However, as the choice of fiemap -- implying this otherwise unneeded fsync of a temporary file -- is not made by the caller but by qemu-img, I agree with the nova bug reviewer's objection to put it into nova. The fsync should instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC, specifically intended for that purpose.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1388 b/results/classifier/mode-gemma3:12b/user/1388 new file mode 100644 index 00000000..95aee3ea --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1388 @@ -0,0 +1,16 @@ + + +QEMU 7.2.0 - Update file repository with x86/x64 Windows installer +Description of problem: +In file repository + +https://qemu.weilnetz.de/w32/ +https://qemu.weilnetz.de/w64/ + +are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0. + +The latest version is 7.2.0.RC4 (08.12.2022). + +Thanks. +Steps to reproduce: + diff --git a/results/classifier/mode-gemma3:12b/user/1394 b/results/classifier/mode-gemma3:12b/user/1394 new file mode 100644 index 00000000..db30c77f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1394 @@ -0,0 +1,63 @@ + + +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/mode-gemma3:12b/user/1395958 b/results/classifier/mode-gemma3:12b/user/1395958 new file mode 100644 index 00000000..3f297327 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1395958 @@ -0,0 +1,27 @@ + + +boost managed_shared_memory segment on arm emulator crashes + +The following code segment crashes when run: + +#include <boost/interprocess/managed_shared_memory.hpp> +#include <boost/interprocess/allocators/allocator.hpp> +#include <boost/interprocess/containers/map.hpp> +#include <boost/interprocess/containers/vector.hpp> +#include <boost/interprocess/containers/string.hpp> + +using namespace boost::interprocess; + +int main(int argc, char** argv) +{ + namespace bi = boost::interprocess; + const char* name = "foobar"; + bi::shared_memory_object::remove(name); + bi::managed_shared_memory segment(bi::create_only, name, 10 * 1024); +} + +using qemu-arm-static +qemu-arm version 1.5.0 (Debian 1.5.0-2013.06+git74+20130802+ef1b0ae-3linaroprecise1), Copyright (c) 2003-2008 Fabrice Bellard + + +Any idea?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1396497 b/results/classifier/mode-gemma3:12b/user/1396497 new file mode 100644 index 00000000..cfcf4584 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1396497 @@ -0,0 +1,77 @@ + + +'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot + +qemu-img _may_ be working as designed, but it feels like this could be a bug. I'd certainly prefer to only allow unique snapshot names (unless maybe something like a "--force-non-unique-snapshot-names" was also specified). + +If this really is correct behaviour, it should be documented as qemu-img(1) currently specifies no details whatsoever regarding expected behaviour or valid snapshot names. + +$ qemu-img snapshot -l image.cow +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +$ + +Note also how snapshot deletion works in reverse order - the oldest snapshot with a given name is deleted first. + +ProblemType: Bug +DistroRelease: Ubuntu 15.04 +Package: qemu-utils 2.1+dfsg-4ubuntu9 +ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7 +Uname: Linux 3.16.0-25-generic x86_64 +ApportVersion: 2.14.7-0ubuntu10 +Architecture: amd64 +CurrentDesktop: Unity +Date: Wed Nov 26 08:28:16 2014 +InstallationDate: Installed on 2014-04-11 (228 days ago) +InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 719 2 0.0 [kvm-irqfd-clean] +MachineType: LENOVO 20AQCTO1WW +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago) +dmi.bios.date: 02/10/2014 +dmi.bios.vendor: LENOVO +dmi.bios.version: GJET71WW (2.21 ) +dmi.board.asset.tag: Not Available +dmi.board.name: 20AQCTO1WW +dmi.board.vendor: LENOVO +dmi.board.version: 0B98405 STD +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.name: 20AQCTO1WW +dmi.product.version: ThinkPad T440s +dmi.sys.vendor: LENOVO
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/140 b/results/classifier/mode-gemma3:12b/user/140 new file mode 100644 index 00000000..e98a5519 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/140 @@ -0,0 +1,3 @@ + + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) diff --git a/results/classifier/mode-gemma3:12b/user/1404690 b/results/classifier/mode-gemma3:12b/user/1404690 new file mode 100644 index 00000000..b4ecb65d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1404690 @@ -0,0 +1,40 @@ + + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1407808 b/results/classifier/mode-gemma3:12b/user/1407808 new file mode 100644 index 00000000..120dd12a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1407808 @@ -0,0 +1,11 @@ + + +virtual console gives strange response to ANSI DSR + +With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. + +Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. + +Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. + +This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius-systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1407813 b/results/classifier/mode-gemma3:12b/user/1407813 new file mode 100644 index 00000000..370c0507 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1407813 @@ -0,0 +1,11 @@ + + +QEMU wrongly translates newlines on serial output + +When using "-serial stdio", QEMU shows the guest serial port's output on the tty running qemu. As it should, QEMU sets the tty to raw mode. Or almost... Strangely, it neglects to remove one output-translation bit, ONLCR (see termios(3)) enabled on the tty. And it should have removed this output translation! + +The problem is that with this ONLCR, the guest has no way of outputting a bare linefeed ('\n') - every time the guest tries to output a bare linefeed to the serial port, the host tty will translate it to \r\n which will be sent to the underlying terminal (e.g., xterm). + +In most cases, this issue doesn't cause a problem: When the guest is running a Unix-like operating system which is itself in cooked mode, the guest itself will always output \r\n, and the hosts second translation (to \r\r\n) does no harm. But in certain cases, the guest can *really* want to output just \n, and have this \n reach the terminal emulator and do what a linefeed is supposed to do without a carriage-return - namely - just go one line down in the same column. + +As an illustration of this bug, consider a guest running a Unix-like operating system running a curses-based application (e.g., "vi"). If you look at the output of "infocmp xterm", you'll notice that cud1=^J. This means that if the curses library decides to move one line down (it can happen in some cursor movement situations) it might decide to print a linefeed (\n) to move one line down. The guest's operating system will not mess with this linefeed (because the guest is in raw mode), but then qemu's tty, because it was wrongly left in ONLCR mode, will change this \n to \r\n before it reaches the terminal - causing wrong cursor movement (instead the cursor going straight down, it moves to the first column of the next line).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1413 b/results/classifier/mode-gemma3:12b/user/1413 new file mode 100644 index 00000000..1472a20f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1413 @@ -0,0 +1,24 @@ + + +I tried to use qemu-nbd in the shell script, but it seems that qemu-nbd has some delay. +Description of problem: + +Steps to reproduce: +1. +``` +cat ~/test.sh +#!/bin/bash +qemu-nbd -c /dev/nbd0 $1 +mount -t ntfs3 -o uid=1000,gid=1000 /dev/disk/by-label/OS /mnt/OS +``` +2. +``` +sudo ~/test.sh ~/VM/win7_i386.qcow2 +mount: /mnt/OS: special device /dev/disk/by-label/OS does not exist. + dmesg(1) may have more information after failed mount system call. + +``` +Additional information: +But when I added a one-second delay between qemu-nbd and mount commands, the problem was solved. + +The qemu-img convert command also has a similar problem. It seems that these commands have a certain delay. Is this in line with expectations? diff --git a/results/classifier/mode-gemma3:12b/user/1416988 b/results/classifier/mode-gemma3:12b/user/1416988 new file mode 100644 index 00000000..c84a3131 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1416988 @@ -0,0 +1,34 @@ + + +Wrong signal handling in qemu-aarch64. + +Running GCC 5.0 testsuite under qemu-aarch64, I noticed that tests connected with stack unwinding fail with: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +or run into infinite loop. + +Here is one example: + +$ /home/max/build/gcc-aarch64/gcc/xgcc -B/home/max/build/gcc-aarch64/gcc/ /home/max/src/toolchain/gcc/gcc/testsuite/gcc.dg/cleanup-11.c -fexceptions -fnon-call-exceptions -O2 -lm -o ./cleanup-11.exe + +$ qemu-aarch64 -L /home/max/install/aarch64/aarch64-linux/sys-root/ -R 0 -/cleanup-11.exe +qemu: uncaught target signal 11 (Segmentation fault) - core dumped. + +Actually, this caused by ABI incompatibility between Linux Kernel (trunk) and qemu-aarch64. In fact, size of siginfo structure in Linux and target_siginfo structure in qemu-aarch64 differ: + +sizeof (struct target_siginfo) = 136 // QEMU +sizeof (struct siginfo) = 128 // Linux Kernel + + +This caused by wrong TARGET_SI_PAD_SIZE defined in linux-user/syscall_defs.h: + +#define TARGET_SI_PAD_SIZE ((TARGET_SI_MAX_SIZE/sizeof(int)) - 3) + +In Kernel respective value is: + +#define SI_PAD_SIZE ((SI_MAX_SIZE - __ARCH_SI_PREAMBLE_SIZE) / sizeof(int)) +............................................. +#define __ARCH_SI_PREAMBLE_SIZE (4 * sizeof(int)) // for Aarch64 + +Trivial fix, changing TARGET_SI_PAD_SIZE to right value, is attached.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1422307 b/results/classifier/mode-gemma3:12b/user/1422307 new file mode 100644 index 00000000..eed3bf4c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1422307 @@ -0,0 +1,41 @@ + + +qemu-nbd corrupts files + +Dear all, + +On Trusty, in certain situations, try to copy files over a qemu-nbd mounted file system leads to write errors (and thus, file corruption). + +Here is the last example I tried: +-> virtual disk is a VDI disk +-> It has only one partition, in FAT + +Here is my mount process: +# modprobe nbd max_part=63 +# qemu-nbd -c /dev/nbd0 "virtual_disk.vdi" +# partprobe /dev/nbd0 +# mount /dev/nbd0p1 /tmp/mnt/ + +Partition is properly mounted at that point: +/dev/nbd0p1 on /tmp/mnt type vfat (rw) + +Now, when I copy a file (rather big, ~28MB): +# cp file_to_copy /tmp/mnt/ ; sync +# md5sum /tmp/mnt/file_to_copy +2efc9f32e4267782b11d63d2f128a363 /tmp/mnt/file_to_copy +# umount /tmp/mnt +# mount /dev/nbd0p1 /tmp/mnt/ +# md5sum /tmp/mnt/file_to_copy +42b0a3bf73f704d03ce301716d7654de /tmp/mnt/file_to_copy + +The first hash was obviously the right one. + +On a previous attempt I did, I spotted thanks to vbindiff that parts of the file were just filed with 0s instead of actual data. +It will randomly work after several attempts to write. + +Version information: +# qemu-nbd --version +qemu-nbd version 0.0.1 +Written by Anthony Liguori. + +Cheers,
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1426 b/results/classifier/mode-gemma3:12b/user/1426 new file mode 100644 index 00000000..bfdc2356 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1426 @@ -0,0 +1,40 @@ + + +On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client +Description of problem: +I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client. +Windows spice client virtviewer won't start like it does under Linux. +The error message indicaes that the spice-server itself failed to open spice sockets +The registry to handle ```spice://``` URI handler is configured. +Steps to reproduce: +1. just run command +Additional information: +URI handler in registry is configure using a regestry import file ```spiceproto.reg``` +``` +Windows Registry Editor Version 5.00 + +[HKEY_CLASSES_ROOT\spice] +"URL Protocol"="" + +[HKEY_CLASSES_ROOT\spice\DefaultIcon] +@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1" + +[HKEY_CLASSES_ROOT\spice\Extensions] +[HKEY_CLASSES_ROOT\spice\shell] +[HKEY_CLASSES_ROOT\spice\shell\open] +[HKEY_CLASSES_ROOT\spice\shell\open\command] +@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\"" + +[HKEY_CLASSES_ROOT\spice+unix] +"URL Protocol"="" + +[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon] +@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1" + +[HKEY_CLASSES_ROOT\spice+unix\Extensions] +[HKEY_CLASSES_ROOT\spice+unix\shell] +[HKEY_CLASSES_ROOT\spice+unix\shell\open] +[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] +@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\"" +``` +This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox. diff --git a/results/classifier/mode-gemma3:12b/user/1426593 b/results/classifier/mode-gemma3:12b/user/1426593 new file mode 100644 index 00000000..ac1462fb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1426593 @@ -0,0 +1,10 @@ + + +linux-user: doesn't handle guest setting its memory ulimit very small + +using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested. +i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it + +building coreutils hangs on "checking whether printf survives out-of-memory conditions" + +i have not had time to dig into the build system to isolate the test yet, there were old reports of this bug but i can no longer find them on google.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1428352 b/results/classifier/mode-gemma3:12b/user/1428352 new file mode 100644 index 00000000..a722410c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1428352 @@ -0,0 +1,46 @@ + + +SYSRET instruction incorrectly implemented + +The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic: + +SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *) + +Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here: + +http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html + +[...] + SS(SEL) = IA32_STAR[63:48] + 8; + SS(PL) = 0x3; +[...] + +In other words, the value of the %ss register is supposed to be loaded from bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call. + +However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this: + + cpu_x86_load_seg_cache(env, R_SS, selector + 8, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +It should look like this: + + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss). + +The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.) + +This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :) + +Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM. + +The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware. + +- Bill (<email address hidden>)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1429313 b/results/classifier/mode-gemma3:12b/user/1429313 new file mode 100644 index 00000000..b7a167b3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1429313 @@ -0,0 +1,11 @@ + + +qemu-user doesn't block target signals on entry to signal hanlder. + +Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler. + +The attached test case my be run as: + +$ (sleep 2 ; echo) | qemu-i386 ./a.out +.................. Recursion in signal handler! +qemu: uncaught target signal 6 (Aborted) - core dumped
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1441 b/results/classifier/mode-gemma3:12b/user/1441 new file mode 100644 index 00000000..8a63089d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1441 @@ -0,0 +1,36 @@ + + +Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction +Description of problem: +When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.``` + +It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848 +Steps to reproduce: +The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6): +``` +/* test.c */ +#include <riscv_vector.h> + +#define LEN 4 + +int main(int argc, char *argv[]) { + double in[LEN]; + int out[LEN]; + + vfloat64m1_t vf = vle64_v_f64m1(in, LEN); + vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN); + vse32_v_i32mf2(out, vi, LEN); + + return 0; +} +``` + +The above `test.c` can be compiled and run as follows: +``` +clang -O3 -march=rv64gcv -static test.c +qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out +qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed. +Segmentation fault (core dumped) +``` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1455 b/results/classifier/mode-gemma3:12b/user/1455 new file mode 100644 index 00000000..4d52ef62 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1455 @@ -0,0 +1,5 @@ + + +copy-paste not working +Description of problem: +copy-paste not working under Sway (wayland - wlroots) when I use `-display gtk`. This was broken recently. I have `spice-vdagent` as well as `spice-vdagentd` running properly in the guest, still copy-paste not working. diff --git a/results/classifier/mode-gemma3:12b/user/1462640 b/results/classifier/mode-gemma3:12b/user/1462640 new file mode 100644 index 00000000..afca522c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1462640 @@ -0,0 +1,37 @@ + + +shmat fails on 32-to-64 setup + + +I am trying to run a guest mips32 program (user mode) on a x86_64 host. The program fails on a call to shmat() reproducibly. when digging into this problem, I could make a small guest POC that fails when compiled as i386 (-m32) running on a x86_64 host, but pass when compiled as 64bit. The problem has to do with mmap flags. + +From what I can understand, when running 32bits guests programs, qemu reserve the whole guest virtual space with an mmap call. That mmap call specifys MAP:PRIVATE flag. When shmat is called, it tries to make part of that region MAP_SHARED and that fails. + +As a possible fix, it looks like it is possible to first unmap the shm region before calling shmat. + +steps to reproduce: +1 - create a file shm.c with content below +2 - compile with: gcc -m32 shm.c -o shm32 +3 - run on a x86_64 host: qemu-i386 ./shm32 +4 - observe shmat fails, by returning ptr -1 + +5- compile without -m32: : gcc shm.c -o shm64 +6 - observe it pass: qemu-x84_64 ./shm64 + + + +#include <sys/ipc.h> +#include <sys/shm.h> +#include <sys/mman.h> +#include <stdio.h> + +int main() +{ + struct shmid_ds shm_desc; + int err = 0; + int id = shmget(IPC_PRIVATE, 688128, IPC_CREAT|IPC_EXCL|0666); + err = shmctl(id, IPC_STAT, &shm_desc); + const void *at = 0x7f7df38ea000; + void* ptr = shmat(id, at, 0); + printf( "got err %d, ptr %p\n", err, ptr ); +}
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1462944 b/results/classifier/mode-gemma3:12b/user/1462944 new file mode 100644 index 00000000..75e7e0d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1462944 @@ -0,0 +1,13 @@ + + +vpc file causes qemu-img to consume lots of time and memory + +The attached vpc file causes 'qemu-img info' to consume 3 or 4 seconds of CPU time and 1.3 GB of heap, causing a minor denial of service. + +$ /usr/bin/time ~/d/qemu/qemu-img info afl12.img +block-vpc: The header checksum of 'afl12.img' is incorrect. +qemu-img: Could not open 'afl12.img': block-vpc: free_data_block_offset points after the end of file. The image has been truncated. +1.19user 3.15system 0:04.35elapsed 99%CPU (0avgtext+0avgdata 1324504maxresident)k +0inputs+0outputs (0major+327314minor)pagefaults 0swaps + +The file was found using american-fuzzy-lop.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1462949 b/results/classifier/mode-gemma3:12b/user/1462949 new file mode 100644 index 00000000..32ad7001 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1462949 @@ -0,0 +1,29 @@ + + +vmdk files cause qemu-img to consume lots of time and memory + +The two attached files cause 'qemu-img info' to consume lots of time and memory. Around 10-12 seconds of CPU time, and around 3-4 GB of heap. + +$ /usr/bin/time ~/d/qemu/qemu-img info afl10.img +qemu-img: Can't get size of device 'image': File too large +0.40user 11.57system 0:12.03elapsed 99%CPU (0avgtext+0avgdata 4197804maxresident)k +56inputs+0outputs (0major+1045672minor)pagefaults 0swaps + +$ /usr/bin/time ~/d/qemu/qemu-img info afl11.img +image: afl11.img +file format: vmdk +virtual size: 12802T (14075741666803712 bytes) +disk size: 4.0K +cluster_size: 65536 +Format specific information: + cid: 4294967295 + parent cid: 4294967295 + create type: monolithicSparse + extents: + [0]: + virtual size: 14075741666803712 + filename: afl11.img + cluster size: 65536 + format: +0.29user 9.10system 0:09.43elapsed 99%CPU (0avgtext+0avgdata 3297360maxresident)k +8inputs+0outputs (0major+820507minor)pagefaults 0swaps
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1463338 b/results/classifier/mode-gemma3:12b/user/1463338 new file mode 100644 index 00000000..e4a468df --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1463338 @@ -0,0 +1,16 @@ + + +qemu-system-arm injects #UND exception with wrong PC + +Usually all accesses to coprocessor registers are only possible in PL1 or higher. When accessing a coprocessor register in user mode, QEMU generates a trap and the PC of the trapping instruction is passed to the OS with an offset of+ 4. Some coprocessor registers can be configured to allow access to them in usermode (PL0). The latest qemu-git (ee09f84e6bf5383a23c9624115c26b72aa1e076c) seems to add an offest of 8 instead of four if such a register is accessed from user mode. This happens only if the coprocessors register that is accessed might also be accessed from PL0. In case all accesses to the coprocessor register from PL0 cause a trap, qemu injects the #UND trap with the correct PC value. + +Attached is a small test program that installs a signal handler for "SIGILL". On a pandaboard the progam prints "Val=0x2 Val2=0x2" whereas on the latest "qemu-system-arm" the output is : "Val=0x1 Val2=0x2" + +Qemu was configured with: "./configure --python=`which python2.7` --target-list=arm-softmmu" +The test can be compiled with: "gcc -g -static test2.c -o test2" + +If further information is needed, feel free to ask. + +Regards, + +Robert
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1469 b/results/classifier/mode-gemma3:12b/user/1469 new file mode 100644 index 00000000..b7635410 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1469 @@ -0,0 +1,50 @@ + + +QEMU 7.2.0 - make install fail +Description of problem: +`[10055/10057] Generating docs/QEMU manual with a custom command +[10056/10057] Generating docs/QEMU man pages with a custom command +[10056/10057] Installing files. +Traceback (most recent call last): + File "/home/clive/.local/bin/meson", line 5, in <module> + from mesonbuild.mesonmain import main +ModuleNotFoundError: No module named 'mesonbuild' +FAILED: meson-internal__install +/home/clive/.local/bin/meson install --no-rebuild +ninja: build stopped: subcommand failed. +make: *** [Makefile:165: run-ninja] Error 1 +[clive@localhost build]$ +` +Steps to reproduce: +1. as user in shell +2. `wget https://download.qemu.org/qemu-7.2.0.tar.xz` +2. `tar xvJf qemu-7.2.0.tar.xz` +3. `cd qemu-7.2.0` +4. `./configure` +5. `make install` +Additional information: +installed meson via `pip3 --user` + +`pip3 --list` **Output** `meson version 1.0.0` + +**Using** - python version 3.11.1 + +`ninja-build` installed via package manager `dnf` + +**Using** - ninja-build version 1.8.2 + +Used `dnf builddep` on `ninja-build`, `meson`, and `qemu-kvm` before and after installation confirming I have dependencies. + + File "/home/clive/.local/bin/meson" contains +``` +#!/usr/local/bin/python3.11 +# -*- coding: utf-8 -*- +import re +import sys +from mesonbuild.mesonmain import main +if __name__ == '__main__': + sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0]) + sys.exit(main()) + + +``` diff --git a/results/classifier/mode-gemma3:12b/user/1470170 b/results/classifier/mode-gemma3:12b/user/1470170 new file mode 100644 index 00000000..cc554fcd --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1470170 @@ -0,0 +1,42 @@ + + +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/mode-gemma3:12b/user/1471 b/results/classifier/mode-gemma3:12b/user/1471 new file mode 100644 index 00000000..8a6d52a1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1471 @@ -0,0 +1,18 @@ + + +16fc5726a6 breaks curl SSL connections +Description of problem: +`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`). +Steps to reproduce: +1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 +2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0 +3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` +4. Observe the following error message: + +``` +curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature +``` + +Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. + +Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a). diff --git a/results/classifier/mode-gemma3:12b/user/1475 b/results/classifier/mode-gemma3:12b/user/1475 new file mode 100644 index 00000000..e3413a57 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1475 @@ -0,0 +1,16 @@ + + +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +Description of problem: +Mixing driver=https with an http URL gives this assert fail in glib2: + +``` +$ ~/d/qemu/build/qemu-img convert -p -W -f qcow2 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }' -O raw jammy-server-cloudimg-amd64.img.raw +qemu-img: GLib: g_hash_table_foreach_remove: assertion 'hash_table != NULL' failed +qemu-img: GLib: g_hash_table_destroy: assertion 'hash_table != NULL' failed +qemu-img: Could not open 'json:{ "file.readahead": 67108864, "file.driver": "https", "file.url": "http://web/tmp/jammy-server-cloudimg-amd64.qcow2", "file.timeout":2000 }': https curl driver cannot handle the URL 'http://oirase.annexia.org/tmp/jammy-server-cloudimg-amd64.qcow2' (does not start with 'https://') +``` + +(It seems to be a warning rather than a crash) +Steps to reproduce: +1. Run the command above. diff --git a/results/classifier/mode-gemma3:12b/user/1490611 b/results/classifier/mode-gemma3:12b/user/1490611 new file mode 100644 index 00000000..b8934cff --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1490611 @@ -0,0 +1,50 @@ + + +Using qemu >=2.2.1 to convert raw->VHD (fixed) adds extra padding to the result file, which Microsoft Azure rejects as invalid + +Starting with a raw disk image, using "qemu-img convert" to convert from raw to VHD results in the output VHD file's virtual size being aligned to the nearest 516096 bytes (16 heads x 63 sectors per head x 512 bytes per sector), instead of preserving the input file's size as the output VHD's virtual disk size. + +Microsoft Azure requires that disk images (VHDs) submitted for upload have virtual sizes aligned to a megabyte boundary. (Ex. 4096MB, 4097MB, 4098MB, etc. are OK, 4096.5MB is rejected with an error.) This is reflected in Microsoft's documentation: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-create-upload-vhd-generic/ + +This is reproducible with the following set of commands (including the Azure command line tools from https://github.com/Azure/azure-xplat-cli). For the following example, I used qemu version 2.2.1: + +$ dd if=/dev/zero of=source-disk.img bs=1M count=4096 + +$ stat source-disk.img + File: ‘source-disk.img’ + Size: 4294967296 Blocks: 798656 IO Block: 4096 regular file +Device: fc01h/64513d Inode: 13247963 Links: 1 +Access: (0644/-rw-r--r--) Uid: ( 1000/ smkent) Gid: ( 1000/ smkent) +Access: 2015-08-18 09:48:02.613988480 -0700 +Modify: 2015-08-18 09:48:02.825985646 -0700 +Change: 2015-08-18 09:48:02.825985646 -0700 + Birth: - + +$ qemu-img convert -f raw -o subformat=fixed -O vpc source-disk.img dest-disk.vhd + +$ stat dest-disk.vhd + File: ‘dest-disk.vhd’ + Size: 4296499712 Blocks: 535216 IO Block: 4096 regular file +Device: fc01h/64513d Inode: 13247964 Links: 1 +Access: (0644/-rw-r--r--) Uid: ( 1000/ smkent) Gid: ( 1000/ smkent) +Access: 2015-08-18 09:50:22.252077624 -0700 +Modify: 2015-08-18 09:49:24.424868868 -0700 +Change: 2015-08-18 09:49:24.424868868 -0700 + Birth: - + +$ azure vm image create testimage1 dest-disk.vhd -o linux -l "West US" +info: Executing command vm image create ++ Retrieving storage accounts +info: VHD size : 4097 MB +info: Uploading 4195800.5 KB +Requested:100.0% Completed:100.0% Running: 0 Time: 1m 0s Speed: 6744 KB/s +info: https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd was uploaded successfully +error: The VHD https://[redacted].blob.core.windows.net/vm-images/dest-disk.vhd has an unsupported virtual size of 4296499200 bytes. The size must be a whole number (in MBs). +info: Error information has been recorded to /home/smkent/.azure/azure.err +error: vm image create command failed + +I also ran the above commands using qemu 2.4.0, which resulted in the same error as the conversion behavior is the same. + +However, qemu 2.1.1 and earlier (including qemu 2.0.0 installed by Ubuntu 14.04) does not pad the virtual disk size during conversion. Using qemu-img convert from qemu versions <=2.1.1 results in a VHD that is exactly the size of the raw input file plus 512 bytes (for the VHD footer). Those qemu versions do not attempt to realign the disk. As a result, Azure accepts VHD files created using those versions of qemu-img convert for upload. + +Is there a reason why newer qemu realigns the converted VHD file? It would be useful if an option were added to disable this feature, as current versions of qemu cannot be used to create VHD files for Azure using Microsoft's official instructions.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1506 b/results/classifier/mode-gemma3:12b/user/1506 new file mode 100644 index 00000000..a0ddd9c7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1506 @@ -0,0 +1,3 @@ + + +QEMU not support 32-bit stack in unreal/flat/big 32-bit mode diff --git a/results/classifier/mode-gemma3:12b/user/1511 b/results/classifier/mode-gemma3:12b/user/1511 new file mode 100644 index 00000000..99fe7f1a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1511 @@ -0,0 +1,3 @@ + + +Please a CPU model for ABI version for x86_64 i386 according to x86-64 psABI diff --git a/results/classifier/mode-gemma3:12b/user/1512 b/results/classifier/mode-gemma3:12b/user/1512 new file mode 100644 index 00000000..cf987a82 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1512 @@ -0,0 +1,3 @@ + + +AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/mode-gemma3:12b/user/1516408 b/results/classifier/mode-gemma3:12b/user/1516408 new file mode 100644 index 00000000..9c600a16 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1516408 @@ -0,0 +1,33 @@ + + +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/mode-gemma3:12b/user/1519037 b/results/classifier/mode-gemma3:12b/user/1519037 new file mode 100644 index 00000000..107c1c18 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1519037 @@ -0,0 +1,9 @@ + + +qemu-i386 32-bit segfault + +I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow? + +In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? + +Thanks!
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1525676 b/results/classifier/mode-gemma3:12b/user/1525676 new file mode 100644 index 00000000..457d661c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1525676 @@ -0,0 +1,37 @@ + + +qemu runas and sandbox option incompatible, process will hang in futex after setgid + +With -runas [user] and -sandbox on, qemu process will fail in the process of dropping privileges. While setgid() is done (see below), setuid() is not attempted. Instead process blocks waiting for a futex never to come. + +[pid 21769] +++ killed by SIGSYS +++ +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] tgkill(21767, 21768, SIGRT_1 <unfinished ...> +[pid 21768] <... nanosleep resumed> {0, 7284187}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) +[pid 21768] --- SIGRT_1 {si_signo=SIGRT_1, si_code=SI_TKILL, si_pid=21767, si_uid=0} --- +[pid 21768] setgid(100) = 0 +[pid 21768] futex(0x7f7f0f53fd1c, FUTEX_WAKE_PRIVATE, 1) = 0 +[pid 21768] rt_sigreturn() = -1 EINTR (Interrupted system call) +[pid 21768] nanosleep({0, 7284187}, <unfinished ...> +[pid 21767] <... tgkill resumed> ) = 0 +[pid 21767] futex(0x7ffd5a9b6890, FUTEX_WAIT_PRIVATE, 3, NULL <unfinished ...> +[pid 21768] <... nanosleep resumed> 0x7f7f0f53eb00) = 0 +[pid 21768] futex(0x55f52acd1f44, FUTEX_WAIT, 4294967295, NULL + +This bug might be addresses in the discussion/patchset http://qemu.11.n7.nabble.com/PATCH-Add-syscalls-for-runas-and-chroot-to-the-seccomp-sandbox-td359588.html + +# lsb_release -rd +Description: Ubuntu 15.10 +Release: 15.10 + +# apt-cache policy qemu-system-x86 +qemu-system-x86: + Installed: 1:2.3+dfsg-5ubuntu9.1 + Candidate: 1:2.3+dfsg-5ubuntu9.1 + Version table: + *** 1:2.3+dfsg-5ubuntu9.1 0 + 500 http://archive.ubuntu.com/ubuntu/ wily-updates/main amd64 Packages + 500 http://archive.ubuntu.com/ubuntu/ wily-security/main amd64 Packages + 100 /var/lib/dpkg/status + 1:2.3+dfsg-5ubuntu9 0 + 500 http://archive.ubuntu.com/ubuntu/ wily/main amd64 Packages
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1527300 b/results/classifier/mode-gemma3:12b/user/1527300 new file mode 100644 index 00000000..546c9a9e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1527300 @@ -0,0 +1,11 @@ + + +linux-user/elfload.c: byteswap function is not working when ELF is big endian + +I run qemu-mipsel for ELF with mips MSB(big endian), it always outputs error message: Invalid ELF image for this architecture. For the ELF I run: + +$file busybox + +ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped + +The section header is not corrupted(MSB, corrputed section header table also outputs same error as above), when I run ELF with LSB, it works perfectly. I debugged with /linux-user/elfload.c, I am sure that the problem comes from byteswap function. But I don't know how to handle it. I really hope this can be fixed ASAP. Really appreciate your help.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1527765 b/results/classifier/mode-gemma3:12b/user/1527765 new file mode 100644 index 00000000..ee04a055 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1527765 @@ -0,0 +1,74 @@ + + +sh4: ghc randomly segfaults on qemu-sh4-static + +Hello! + +I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source: + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls +Main.hi Main.hs Setup.hs ghc-pwd.cabal ghc.mk +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi + ghc: panic! (the 'impossible' happened) + (GHC version 7.10.3 for sh4-unknown-linux): + getSymtabName:unknown known-key unique +<<details unavailable>> + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs +/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +[1 of 1] Compiling Main ( Main.hs, Main.o ) +Linking Main ... +root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# + +As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs. + +I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help). + +> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz + +In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc: + +> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz + +Just extract in the chroot of the sh4 chroot. + +Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186: + +> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824 +> https://bugs.launchpad.net/qemu/+bug/1516408 + +The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test. + +Cheers, +Adrian
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1528 b/results/classifier/mode-gemma3:12b/user/1528 new file mode 100644 index 00000000..ccad0eb3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1528 @@ -0,0 +1,11 @@ + + +ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed." +Description of problem: +Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware. +Steps to reproduce: +1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello) +2. Build latest qemu-arm from master +3. Run qemu-arm against hello world binary +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1528239 b/results/classifier/mode-gemma3:12b/user/1528239 new file mode 100644 index 00000000..19c0140b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1528239 @@ -0,0 +1,47 @@ + + +Unable to debug PIE binaries with QEMU gdb stub. + +The issue occurs on current trunk: + +max@max:~/build/qemu$ cat test.c +#include <stdio.h> + +int main() { + printf("Hello, world!\n"); + return 0; +} + +max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x +max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x +............................. + + +max@max:~/build/qemu$ gdb +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 +........................................................................................ +(gdb) file bad.x +Reading symbols from bad.x...(no debugging symbols found)...done. +(gdb) b main +Breakpoint 1 at 0x779 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). + +Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. +done. +Loaded symbols for /lib64/ld-linux-x86-64.so.2 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 +(gdb) c +Continuing. +[Inferior 1 (Remote target) exited normally] +(gdb) + + +max@max:~/build/qemu$ cat config.log +# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' + + +W/O QEMU or -pie flag breakpoint on main works fine.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/153 b/results/classifier/mode-gemma3:12b/user/153 new file mode 100644 index 00000000..7cdd7662 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/153 @@ -0,0 +1,3 @@ + + +SLIRP SMB silently fails with MacOS smbd diff --git a/results/classifier/mode-gemma3:12b/user/1530 b/results/classifier/mode-gemma3:12b/user/1530 new file mode 100644 index 00000000..981ad689 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1530 @@ -0,0 +1,13 @@ + + +Problem with sdl,gl=on windows 10 +Description of problem: +sdl window opens with black screen, freezes, then crashes +Steps to reproduce: +1. run the command +Additional information: +- Works fine with just `sdl`, running `gtk,gl=on` outputs `opengl is not supported by the display` +- tried with both `-vga virtio` and `vga std`, same result +- tried with SVM turned on and off (AMD cpu, ryzen 2600x), same result +- built the project `./configure --enable-gtk --enable-sdl --enable-opengl, saw the `OK` for all 3 +- have opengl ver 4.6 diff --git a/results/classifier/mode-gemma3:12b/user/1531 b/results/classifier/mode-gemma3:12b/user/1531 new file mode 100644 index 00000000..6be72b13 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1531 @@ -0,0 +1,17 @@ + + +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/mode-gemma3:12b/user/1534 b/results/classifier/mode-gemma3:12b/user/1534 new file mode 100644 index 00000000..bd7b0b20 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1534 @@ -0,0 +1,3 @@ + + +usermode emulation warns about features that are system-only (x2apic, tsc-deadline, pcid, invpcid) diff --git a/results/classifier/mode-gemma3:12b/user/1536 b/results/classifier/mode-gemma3:12b/user/1536 new file mode 100644 index 00000000..c6685bb0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1536 @@ -0,0 +1,18 @@ + + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/mode-gemma3:12b/user/1547 b/results/classifier/mode-gemma3:12b/user/1547 new file mode 100644 index 00000000..f9f8da6a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1547 @@ -0,0 +1,14 @@ + + +POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later) +Description of problem: +Comparing two floating point memory operands produces incorrect result +Steps to reproduce: +1. Unpack attached archive and change to test_p64 directory +2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64 +3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt +4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts +Additional information: +The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz) + +The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531 diff --git a/results/classifier/mode-gemma3:12b/user/1550503 b/results/classifier/mode-gemma3:12b/user/1550503 new file mode 100644 index 00000000..a217bdfa --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1550503 @@ -0,0 +1,15 @@ + + +target-arm/helper.c:5493: bad test ? + +[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true. + +Source code is + + (env->uncached_cpsr & CPSR_M) != CPSR_USER && + +but + +./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU) + +./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1553 b/results/classifier/mode-gemma3:12b/user/1553 new file mode 100644 index 00000000..0736d6aa --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1553 @@ -0,0 +1,14 @@ + + +Build error: implicit declaration of function 'qemu_close_to_socket' +Description of problem: +When build the latest master code with MSYS2 on Windows 10, GCC reports: +../ui/spice-core.c: In function 'watch_remove': +../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration] + 152 | qemu_close_to_socket(watch->fd); + | ^~~~~~~~~~~~~~~~~~~~ +../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs] +Steps to reproduce: +1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu +2. cd build +3. make diff --git a/results/classifier/mode-gemma3:12b/user/1556044 b/results/classifier/mode-gemma3:12b/user/1556044 new file mode 100644 index 00000000..0dc9ad6b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1556044 @@ -0,0 +1,10 @@ + + +Redox GUI hangs with 100% CPU on ARM + +Booting into Redox OS cli on ARM with qemu-system-i386 works fine. However, starting the Redox GUI (orbital) brings up the graphical interface and then starts using 100% CPU. I'd guess it's related to mouse detection and handling. + +The OS image is fully usable on x86. + + +https://www.dropbox.com/s/u6v2k9wzcuiycfo/redox-disk.img.xz?dl=0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1557 b/results/classifier/mode-gemma3:12b/user/1557 new file mode 100644 index 00000000..c6a32a4a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1557 @@ -0,0 +1,13 @@ + + +qemu-binfmt-conf.sh handles errors inconsistently +Description of problem: +We are installing qemu via multiarch/qemu-user-static docker image. https://github.com/multiarch/qemu-user-static + +What we have noticed is that because qemu-binfmt-conf.sh does not use `set -e`, its behavior with regards to failures is inconsistent. In short, registering the same thing into binfmt twice is an error (you get EEXIST). However, the exit code of qemu-binfmt-conf.sh itself seems to depend only on whether the last interpreter succeeded, leading to confusing and inconsistent results. +Steps to reproduce: +1. Register only qemu-arm-static interpreter with binfmt. +2. Run qemu-binfmt-conf.sh. Observe that the exit code is zero, and logs show the duplicate interpreter was rejected. +3. Remove all qemu interpreters. +3. Register only qemu-loongarch64-static interpreter (currently last in qemu_target_list) with binfmt. +3. Run qemu-binfmt-conf.sh. Observe that the exit code is non-zero, and logs show the duplicate interpreter was rejected. diff --git a/results/classifier/mode-gemma3:12b/user/1563612 b/results/classifier/mode-gemma3:12b/user/1563612 new file mode 100644 index 00000000..932084f2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1563612 @@ -0,0 +1,52 @@ + + +pulseaudio applications crash under linux-user-x86_64 + +Running a simple application that uses pulseaudio under qemu-i386 or qemu-x86_64 makes it crash (tested on Debian 8.0): + +# apt-get install build-essential qemu-user libpulse-dev pulseaudio +$ cat > test.c << __EOF +#include <pulse/simple.h> + +int main(void) { + pa_simple *s; + pa_sample_spec ss; + ss.format = PA_SAMPLE_S16NE; + ss.channels = 2; + ss.rate = 44100; + s = pa_simple_new(NULL, // Use the default server. + "Fooapp", // Our application's name. + PA_STREAM_PLAYBACK, + NULL, // Use the default device. + "Music", // Description of our stream. + &ss, // Our sample format. + NULL, // Use default channel map + NULL, // Use default buffering + // attributes. + NULL // Ignore error code. + ); + + int16_t buf[2 * 1000]; + int i; + memset(buf, 0, sizeof buf); + for (i = 0; i < 44; i++) { + pa_simple_write(s, buf, sizeof buf, NULL); + } + + pa_simple_free(s); + + return 0; +} +__EOF +$ gcc test.c -o test -lpulse -lpulse-simple +$ ./test +<no output, no error> +$ qemu-x86_64 ./test +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +$ + + +I think this is related to the futex system call. In an attempt to debug the problem, I compiled pulseaudio in debug mode and it hit an assertion failure in pa_mutex_unlock. + +Thank you for developing QEMU. :-)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1564 b/results/classifier/mode-gemma3:12b/user/1564 new file mode 100644 index 00000000..fbebfff2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1564 @@ -0,0 +1,72 @@ + + +stat64 on sparc64 failed to get correct major/minor dev +Description of problem: +The reported device major/minor is not correct, e.g: stat /dev/zero: +Reported: Device type: 0,10500000 +Correct : Device type: 1,5 +Steps to reproduce: +1. "stat /dev/zero" or "ls -l /dev/zero" +Additional information: +The problem is a missing padding into target_stat64 struct related to sparc64. Here patch to solve the issue (it also fixes some incorrect variables size): + +``` +--- qemu-20230327/linux-user/syscall_defs.h 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/linux-user/syscall_defs.h.new 2023-03-27 21:43:25.615115126 +0200 +@@ -1450,7 +1450,7 @@ struct target_stat { + unsigned int st_dev; + abi_ulong st_ino; + unsigned int st_mode; +- unsigned int st_nlink; ++ short int st_nlink; + unsigned int st_uid; + unsigned int st_gid; + unsigned int st_rdev; +@@ -1465,8 +1465,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + uint64_t st_nlink; +@@ -1476,14 +1475,13 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ unsigned int __pad0; ++ uint64_t st_rdev; + + int64_t st_size; + int64_t st_blksize; + +- unsigned char __pad4[4]; +- unsigned int st_blocks; ++ int64_t st_blocks; + + abi_ulong target_st_atime; + abi_ulong target_st_atime_nsec; +@@ -1522,8 +1520,7 @@ struct target_stat { + + #define TARGET_HAS_STRUCT_STAT64 + struct target_stat64 { +- unsigned char __pad0[6]; +- unsigned short st_dev; ++ uint64_t st_dev; + + uint64_t st_ino; + +@@ -1533,8 +1530,7 @@ struct target_stat64 { + unsigned int st_uid; + unsigned int st_gid; + +- unsigned char __pad2[6]; +- unsigned short st_rdev; ++ uint64_t st_rdev; + + unsigned char __pad3[8]; +``` diff --git a/results/classifier/mode-gemma3:12b/user/1568107 b/results/classifier/mode-gemma3:12b/user/1568107 new file mode 100644 index 00000000..11819561 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1568107 @@ -0,0 +1,11 @@ + + +x86_64 linux-user: setup_rt_frame: not implemented + +Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this: + +$ qemu-x86_64 parity --pruning fast + +setup_rt_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1569988 b/results/classifier/mode-gemma3:12b/user/1569988 new file mode 100644 index 00000000..e3507613 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1569988 @@ -0,0 +1,9 @@ + + +[2.6] user network broken reaching foreign servers on Win64 + +Both on master and, starting with 2016-03-22 builds from http://qemu.weilnetz.de/w64/, user mode network can't reach foreign servers. For example, wget http://mifritscher resolves the DNS, but then the message "network target couldn't be reached" occures. 2016-03-03 works fine. I suspect the IPv6 changes. My connection is IPv4 only. + +I tested via knoppix 7.6. The command line is + +qemu-system-x86_64.exe -m 512 -k de --cdrom c:\Users\michaelfritscher\Downloads\linux\KNOPPIX_V7.4.2DVD-2014-09-28-DE.iso -netdev user,id=mynet0,restrict=n -device e1000,netdev=mynet0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1574246 b/results/classifier/mode-gemma3:12b/user/1574246 new file mode 100644 index 00000000..0ca4b0f5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1574246 @@ -0,0 +1,23 @@ + + +Drunken keyboard in go32v2 programs + +QEMU 2.5.0, SeaBIOS 1.9.1; I've been noticing this bug for quite a while, though. + +Steps to reproduce: + +# Create a VM image, install DOS in it (doesn't matter which) and launch it. +# Launch a "bare DOS" DPMI host (not an operating system) in it; I tested with CWSDPMI and HDPMI32. +# Run a go32v2 program which reads keyboard input (say, the Lua interpreter: <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/devel/lua.zip>; the Free Pascal IDE will also do; on the other hand, DOS/4GW programs seem unaffected). +# Quickly type in something random (e.g. alternate between hitting "p" and "q"), then optionally move the cursor left and right. +# Observe how some keystrokes are missed, and some are caught twice. + +The issue does NOT arise: +* on bare metal DOS, +* in VirtualBox, +* in Bochs with stock Plex86 BIOS, +* in Bochs with SeaBIOS, +* in DOSEMU, +* in DOSBox, +* in QEMU when the DPMI host is Windows 3.11/9x +so at this point I'm reasonably sure that it's the fault of either QEMU or SeaBIOS, and probably the former. The issue arises regardless of whether KVM is enabled.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1578192 b/results/classifier/mode-gemma3:12b/user/1578192 new file mode 100644 index 00000000..cf39f3ca --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1578192 @@ -0,0 +1,58 @@ + + +GTK+ interface doesn't translate keycodes properly with Wayland backend + +I already posted this on the mailing list (https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00119.html) but I decided to do a formal bug report so it can be tracked and doesn't get lost. + +... I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.c:gd_key_event callback function, which calls ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the Qemu keycode before sending it on using qemu_input_event_send_key_number. The problem is that gd_map_keycode is incomplete when GTK+ is running on a backend other than X11. + +static int gd_map_keycode(GtkDisplayState *s, GdkDisplay *dpy, int gdk_keycode) +{ + int qemu_keycode; + +#ifdef GDK_WINDOWING_WIN32 + if (GDK_IS_WIN32_DISPLAY(dpy)) { + qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC); + switch (qemu_keycode) { + case 103: /* alt gr */ + qemu_keycode = 56 | SCANCODE_GREY; + break; + } + return qemu_keycode; + } +#endif + + if (gdk_keycode < 9) { + qemu_keycode = 0; + } else if (gdk_keycode < 97) { + qemu_keycode = gdk_keycode - 8; +#ifdef GDK_WINDOWING_X11 + } else if (GDK_IS_X11_DISPLAY(dpy) && gdk_keycode < 158) { + if (s->has_evdev) { + qemu_keycode = translate_evdev_keycode(gdk_keycode - 97); + } else { + qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97); + } +#endif + } else if (gdk_keycode == 208) { /* Hiragana_Katakana */ + qemu_keycode = 0x70; + } else if (gdk_keycode == 211) { /* backslash */ + qemu_keycode = 0x73; + } else { + qemu_keycode = 0; + } + + return qemu_keycode; +} + +In my case, I'm using GTK+'s Wayland backend, so keycodes 97 through 157 (this includes KEY_HOME(102), KEY_PAGEUP(104), KEY_PAGEDOWN(109), KEY_END(107), etc.) are never translated into a qemu_keycode, and the final 'else' block is hit, causing gd_map_keycode to return 0, which is an invalid keycode and thus cannot be handled by xen-kbdfront. At least that's my best guess as to what is happening. + +The solution that comes to mind is provide an alternative to translate_{evdev,xfree86}_keycode that is compatable with Wayland/libinput, but I don't know exactly which API would provide this functionality, much less do I have a patch. Intuition tells me that translate_evdev_keycode would probably work under Wayland because Weston uses libinput which uses evdev as its backend, but I don't know this for a fact, and I don't know if it would be the Right Way (i.e. Wayland or libinput might provide an API for this purpose, but I don't know). + +I may try to do some testing with translate_evdev_keycode on Wayland and also look into any possible APIs for keycode translation, but I just wanted to put it out there and get some feedback awhile. + +Qemu 2.2.1 from Xen 4.6.1 (relevant code appears unchanged in Qemu master) +GTK+ 3.18.7 +Wayland 1.9.0 +Weston 1.9.0 +libinput 1.2.3
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1585840 b/results/classifier/mode-gemma3:12b/user/1585840 new file mode 100644 index 00000000..fa9c859f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1585840 @@ -0,0 +1,11 @@ + + +multiprocess program gets incorrect results with qemu arm-linux-user + +The attached program can run either in a threaded mode or a multiprocess mode. It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process". "success" of the test is defined as the final count being seen as 2000000 by both tasks. + +In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes. But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode. + +The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes. I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware) + +I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1588473 b/results/classifier/mode-gemma3:12b/user/1588473 new file mode 100644 index 00000000..bfff07ed --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1588473 @@ -0,0 +1,21 @@ + + +Qemu Mate 16.10 and Gtk dont build + +when i try to build last qemu 2.6 on 16.10 of ubuntu mate i have this. +note on 16.04 was building without problem + +LINK i386-softmmu/qemu-system-i386 +../ui/gtk.o: In function `gd_get_pointer': +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +../ui/gtk.o: In function `gd_grab_update': +/home/amigaone/src/qemu/ui/gtk.c:1339: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:1353: undefined reference to `gdk_seat_grab' +/home/amigaone/src/qemu/ui/gtk.c:1356: undefined reference to `gdk_seat_ungrab' +../ui/gtk.o: In function `gd_get_pointer': +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_display_get_default_seat' +/home/amigaone/src/qemu/ui/gtk.c:486: undefined reference to `gdk_seat_get_pointer' +collect2: error: ld returned 1 exit status
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1591611 b/results/classifier/mode-gemma3:12b/user/1591611 new file mode 100644 index 00000000..3623cb59 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1591611 @@ -0,0 +1,25 @@ + + +chroot using qemu-x86_64-static fails on ppc64el + +When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error. /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel. + +Sample output illustrating the problem, as well as bash builtins working: + +# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash +# ls +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +setup_frame: not implemented +setup_frame: not implemented +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +setup_frame: not implemented +setup_frame: not implemented +# echo TEST +TEST +# cat test +bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed. +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +It is currently unknown if other host architectures (e.g. aarch64) are also affected.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1593 b/results/classifier/mode-gemma3:12b/user/1593 new file mode 100644 index 00000000..f2fbebd0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1593 @@ -0,0 +1,9 @@ + + +SLIRP hostfwd ignores bind address and uses `INADDR_ANY` +Description of problem: +When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic). +Additional information: +The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777 + +Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address. diff --git a/results/classifier/mode-gemma3:12b/user/1594394 b/results/classifier/mode-gemma3:12b/user/1594394 new file mode 100644 index 00000000..53c675bc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1594394 @@ -0,0 +1,43 @@ + + +Using setreuid / setegid crashes x86_64 user-mode target + +When setreuid() or setegid() are called from x86_64 target code in user mode, qemu crashes inside the NPTL signal handlers. x86 targets do not directly use a syscall to handle setreuid() / setegid(); instead the x86 NPTL implementation sets up a temporary data region in memory (__xidcmd) and issues a signal (SIGRT1) to all threads, allowing the handler for that signal to issue the syscall. Under qemu, __xidcmd remains null (see variable display below backtrace). + +Backtrace: +Program received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x3fff85c74fc0 (LWP 74517)] +0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +263 nptl-init.c: No such file or directory. +(gdb) thread apply all bt + +Thread 3 (Thread 0x3fff87e8efc0 (LWP 74515)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060109080 in futex_wait (val=<optimized out>, ev=<optimized out>) at /build/qemu/util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=0x62367bb0 <rcu_call_ready_event>) at /build/qemu/util/qemu-thread-posix.c:399 +#3 0x000000006010f73c in call_rcu_thread (opaque=<optimized out>) at /build/qemu/util/rcu.c:250 +#4 0x0000000060176f8c in start_thread (arg=0x3fff87e8efc0) at pthread_create.c:336 +#5 0x00000000601cebf4 in clone () + +Thread 2 (Thread 0x3fff85c74fc0 (LWP 74517)): +#0 0x000000006017491c in sighandler_setxid (sig=33, si=0x3fff85c72d08, ctx=0x3fff85c71f90) at nptl-init.c:263 +#1 <signal handler called> +#2 0x00000000601cc42c in syscall () +#3 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#4 do_futex (val3=<optimized out>, uaddr2=275186650880, timeout=0, val=1129, op=128, uaddr=275186651116) at /build/qemu/linux-user/syscall.c:6201 +#5 do_syscall (cpu_env=0x1000abfd350, num=<optimized out>, arg1=275186651116, arg2=<optimized out>, arg3=1129, arg4=0, arg5=275186650880, arg6=<optimized out>, arg7=0, arg8=0) + at /build/qemu/linux-user/syscall.c:10651 +#6 0x00000000600347b8 in cpu_loop (env=0x1000abfd350) at /build/qemu/linux-user/main.c:317 +#7 0x0000000060036ae0 in clone_func (arg=0x3fffc4c2ca38) at /build/qemu/linux-user/syscall.c:5445 +#8 0x0000000060176f8c in start_thread (arg=0x3fff85c74fc0) at pthread_create.c:336 +#9 0x00000000601cebf4 in clone () + +Thread 1 (Thread 0x1000aa05000 (LWP 74511)): +#0 0x00000000601cc430 in syscall () +#1 0x0000000060044b08 in safe_futex (val3=<optimized out>, uaddr2=0x0, timeout=<optimized out>, val=<optimized out>, op=128, uaddr=<optimized out>) at /build/qemu/linux-user/syscall.c:748 +#2 do_futex (val3=<optimized out>, uaddr2=1, timeout=0, val=1, op=128, uaddr=275078324992) at /build/qemu/linux-user/syscall.c:6201 +#3 do_syscall (cpu_env=0x1000aa23890, num=<optimized out>, arg1=275078324992, arg2=<optimized out>, arg3=1, arg4=0, arg5=1, arg6=<optimized out>, arg7=0, arg8=0) at /build/qemu/linux-user/syscall.c:10651 +#4 0x00000000600347b8 in cpu_loop (env=0x1000aa23890) at /build/qemu/linux-user/main.c:317 +#5 0x00000000600020e4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /build/qemu/linux-user/main.c:4779 +(gdb) p __xidcmd +$1 = (struct xid_command *) 0x0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1596009 b/results/classifier/mode-gemma3:12b/user/1596009 new file mode 100644 index 00000000..f6c6aa4c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1596009 @@ -0,0 +1,23 @@ + + +config/build problem due to libncursesw on Xenial + +it happened to me during a build of yocto/bitbake related cross tools. the auto-configuration part titled "SDL probe" for qemu-2.2.0 i found the configuration step failing for the compile_prog routine. actually those test compile went fine but only the test linking failed. + +this was due a reference of the sub-sub-...-included libcaca referenced an initially not installed (hint: check for and report such pre-requisites upfront - might be yocto related) and later on installed by me component of name libncursesw seemingly in its dev variant (i was installing libncursesw5-dev_6.0+20160213-1ubuntu1_amd64.deb). tests on the command line showed that adding the required paths and resources made the test application link nicely. + +a quick hack attempt for the config script resulted in those line: + sdl_libs="$sdl_libs -L/lib/x86_64-linux-gnu -lncursesw" +this allowed me to pass the configuration check nicely. +i am just seeing my full scale compile fail for the same reason multiple times for linking. that all should be fixable the same way. + +you might or might not have addressed this in newer versions of your package. but you probably know that setups for embedded targets will sometimes lack behind in their evolution until a sudden (well prepared) some big jump in versions does happen. so i leave the hint here for your reference - for the main reason of this very often spotted message - raised by several main reasons according to public web reports, but not this one until right here and now: + +| ERROR: User requested feature sdl +| configure was not able to find it. +| Install SDL devel + +By the way these lines already have to locations in the configure script +where the first indicates that pkg/sdl/sdl2-config application is not there (=no SDL devel there) +whilst the second indicates that *-config is there but the test compile failed (=devel is broken for some other reason). +This could/should see some improvement as well as this is the first hint on what went wrong - and in the second case you definitely can give the user the quite valueable hint for the log file with the results of the test compile.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1596870 b/results/classifier/mode-gemma3:12b/user/1596870 new file mode 100644 index 00000000..31c998ae --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1596870 @@ -0,0 +1,9 @@ + + +qemu-img backed over https fails on zero-length file + +When creating new disk with qemu-img backed by file accessed over HTTPS and the backing file has zero length, qemu-img fails with uninformative error: + + qemu-img: disk.qcow2: CURL: Error opening file: + +The error message should either be improved, or the operation on zero-length file should be allowed. Some other backends, as e.g. raw backend for regular files, seem to allow empty files.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1600681 b/results/classifier/mode-gemma3:12b/user/1600681 new file mode 100644 index 00000000..42508a45 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1600681 @@ -0,0 +1,47 @@ + + +Usermode qemu-mips64 does not run on 32 bit i686 hosts + +Hi, + +This issue happens when building Yocto project on i686 hosts. + +Yocto version: 2.1 (krogoth branch) +qemu: 2.5 +gobject-introspection: 1.46 + +and +Yocto version: 2.2 (master/branch) +qemu: 2.6 +gobject-introspection: 1.48 + +Host: Fedora 23 (i686) or Debian 8 (i686) + +Steps: +1. Set MACHINE = "qemumips64" +2. Run bitbake gobject-introspection + +I got some errors like below: + +env PATH=".libs:/buildarea/poky/build/tmp/sysroots-uninative/i686-linux/usr/bin:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin/python3-native:/buildarea/p oky/scripts:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin/mips64-poky-linux:/buildarea/poky/build/tmp/sysroots/qemumips64/usr/bin/crossscripts:/buildarea /poky/build/tmp/sysroots/i686-linux/usr/sbin:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin:/buildarea/poky/build/tmp/sysroots/i686-linux/sbin:/buildarea/ poky/build/tmp/sysroots/i686-linux/bin:/buildarea/poky/scripts:/buildarea/poky/bitbake/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" /buildarea/p oky/build/tmp/work/mips64-poky-linux/gobject-introspection/1.48.0-r0/build/g-ir-scanner-qemuwrapper ./.libs/g-ir-compiler --includedir=../gobject-introspection-1 .48.0 --includedir=../gobject-introspection-1.48.0/gir --includedir=. --includedir=. --includedir=./gir --includedir=. ../gobject-introspection-1.48.0/gir/freety pe2-2.0.gir -o gir/freetype2-2.0.typelib +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/fontconfig-2.0.typelib' failed +make[2]: *** [gir/fontconfig-2.0.typelib] Error 1 +make[2]: *** Waiting for unfinished jobs.... +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/freetype2-2.0.typelib' failed +make[2]: *** [gir/freetype2-2.0.typelib] Error 1 +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/DBus-1.0.typelib' failed +make[2]: *** [gir/DBus-1.0.typelib] Error 1 + + +You can check Yocto bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9285 + +I attached the full compile log.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1603734 b/results/classifier/mode-gemma3:12b/user/1603734 new file mode 100644 index 00000000..8e267afe --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1603734 @@ -0,0 +1,9 @@ + + +Hang in fsqrt + +At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions 2.6.0 and git (2.6.50) for some input values, likely due to an infinite loop at fpu/softfloat.c:6569. + +Steps to reproduce: +1) Compile attached code: gcc -o test test.c -lm +2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1605123 b/results/classifier/mode-gemma3:12b/user/1605123 new file mode 100644 index 00000000..aa00c2aa --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1605123 @@ -0,0 +1,30 @@ + + +PEXT returns wrong values, seemingly switches arguments + +Hi, + +I fiddled with BMI2 instructions and discovered that pext instructions +emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It +seemingly switches up its arguments. I suspect that the error is around the +gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext +in target-i386/int_helper.c and it works fine. + +I ran my program on a CPU with BMI2 instruction set too, and it indeed +returns different values. + +I didn't check pdep, it could have the same problem. + +$ qemu-x86_64 --version +qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux + +I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". + +$ gcc --version +gcc (Debian 5.4.0-6) 5.4.0 20160609 + +Best regards, +Lénárd Szolnoki
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1605443 b/results/classifier/mode-gemma3:12b/user/1605443 new file mode 100644 index 00000000..7a70f5df --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1605443 @@ -0,0 +1,13 @@ + + +QEMU epoll for i386-linux-user on arm host is broken in 2.6 + +I'm trying to get wine running on qemu-i386 on arm. + +I found that 2.5.1 is OK, but 2.6 is not. + +By bisecting, I found commit 928bed6a057cedd6110e634865e021a24029785a is the problem. + +I reverted this commit, and then epoll is OK now. + +It seems that the commit broke epoll of qemu-i386 on arm.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1606 b/results/classifier/mode-gemma3:12b/user/1606 new file mode 100644 index 00000000..dd33f2b0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1606 @@ -0,0 +1,31 @@ + + +riscv: fence.i is not functional +Description of problem: +The attached user-level test is designed to do the following (in iteration): + + - Thread P0 on CPU0 changes some text/code, while + + - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code. + +Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification). +Steps to reproduce: +1. echo 2 > /proc/sys/vm/nr_hugepages +2. ./CoRF+fence.i +Additional information: +Example output: +```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c) +Test CoRF+fence.i Allowed +Histogram (4 states) +25784 :>1:x5=0xa009; 1:x7=2; +24207 *>1:x5=0xa009; 1:x7=1; <-- THIS LINE +8 :>1:x5=0xa019; 1:x7=1; +1 :>1:x5=0xa019; 1:x7=2; +Ok +Witnesses +Positive: 24207 Negative 25793 +Condition exists (1:x5=0xa009 /\ 1:x7=1) is validated +Observation CoRF+fence.i Sometimes 24207 25793 +Time CoRF+fence.i 0.85 +Hash= +``` diff --git a/results/classifier/mode-gemma3:12b/user/1609 b/results/classifier/mode-gemma3:12b/user/1609 new file mode 100644 index 00000000..a64f8885 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1609 @@ -0,0 +1,21 @@ + + +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Description of problem: +SPARC emulation: userspace program run from gdb crashes OS running in emulator +Steps to reproduce: +As a user (not root!): +1. as -Q n -K PIC -b -L mandelbrot.s +2. ld -m a.out -o test +3. gdb ./test +4. run + +`as' is from gnu binutils (binutils-2.20.1-sol26-sparc-local.gz). +Additional information: +[mandelbrot.s](/uploads/edfe6f1fd01fa39ecce9ba4201454ae3/mandelbrot.s) + +screenshot: https://imgur.com/a/JD51DJA + +It could very well be a bug in my assembly code, but it is still strange that it crashes the whole system. + +~"kind::Bug"[in_asm.dat.xz](/uploads/6bb43ce2b7d6973da4751d236fb44e12/in_asm.dat.xz) diff --git a/results/classifier/mode-gemma3:12b/user/1611979 b/results/classifier/mode-gemma3:12b/user/1611979 new file mode 100644 index 00000000..a3d1bf99 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1611979 @@ -0,0 +1,5 @@ + + +GTK+ interface, backspace is broken in the monitor console + +this has been broken for over 2 years
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1612 b/results/classifier/mode-gemma3:12b/user/1612 new file mode 100644 index 00000000..6a428903 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1612 @@ -0,0 +1,53 @@ + + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include <arm_sve.h> +#include <stdio.h> + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, + 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, + 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/mode-gemma3:12b/user/1613817 b/results/classifier/mode-gemma3:12b/user/1613817 new file mode 100644 index 00000000..0a4a76ba --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1613817 @@ -0,0 +1,58 @@ + + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1614348 b/results/classifier/mode-gemma3:12b/user/1614348 new file mode 100644 index 00000000..971a293a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1614348 @@ -0,0 +1,41 @@ + + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1615079 b/results/classifier/mode-gemma3:12b/user/1615079 new file mode 100644 index 00000000..f993bc8d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1615079 @@ -0,0 +1,5 @@ + + +GTK+ UI virtual consoles scrolling broken + +"In the virtual consoles, you can use Ctrl-Up, Ctrl-Down, Ctrl-PageUp and Ctrl-PageDown to move in the back log."
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1617929 b/results/classifier/mode-gemma3:12b/user/1617929 new file mode 100644 index 00000000..4c560e09 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1617929 @@ -0,0 +1,52 @@ + + +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/mode-gemma3:12b/user/1619896 b/results/classifier/mode-gemma3:12b/user/1619896 new file mode 100644 index 00000000..686ab809 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1619896 @@ -0,0 +1,52 @@ + + +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/mode-gemma3:12b/user/1620 b/results/classifier/mode-gemma3:12b/user/1620 new file mode 100644 index 00000000..678d5399 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1620 @@ -0,0 +1,96 @@ + + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include <stdio.h> + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/mode-gemma3:12b/user/1623 b/results/classifier/mode-gemma3:12b/user/1623 new file mode 100644 index 00000000..46cb6eb3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1623 @@ -0,0 +1,11 @@ + + +vec_lde and vec_expte semi-randomly produce the wrong results +Description of problem: +I found that while implementing the Altivec support for the rust [stdarch](https://github.com/rust-lang/stdarch). +Steps to reproduce: +1. Install rust nightly (e.g. using https://rustup.rs/) +2. `git clone https://github.com/rust-lang/stdarch` +3. You need to either cross compile or compile and run the tests for `crates/core_arch`. +Additional information: +Both `valgrind` and running on power9 produce the correct results diff --git a/results/classifier/mode-gemma3:12b/user/1623020 b/results/classifier/mode-gemma3:12b/user/1623020 new file mode 100644 index 00000000..56f15232 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1623020 @@ -0,0 +1,57 @@ + + +emulate amd64 binary on arm7 host + +I'm trying to run a Go program compiled for amd64 on a Raspberry Pi. Here is an example : + +=== +// main.go +package main + +func main() { + println("hello world") +} +=== + +Then here is the output I'm getting : + +=== +> GOARCH=amd64 go build main.go +> ../qemu/build/x86_64-linux-user/qemu-x86_64 -strace ./main +29213 arch_prctl(4098,4823880,0,0,0,0) = 0 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4622132)bad timediv = 11 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address) +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4624923)panic during panic + = 19 +29213 write(2,0,4623731) +runtime stack: + = 16 +29213 write(2,0,4622922)fatal error: = 13 +29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43 +29213 write(2,0,4620094) + = 1 +29213 write(2,0,4635135)runtime: panic before malloc heap initialized + = 46 +29213 write(2,0,4627441)stack trace unavailable + = 24 +29213 exit_group(4) +=== + +I'm running the latest qemu (commit 7263da78045dc91cc207f350911efe4259e99b3c), which was compiled with "../configure --target-list=x86_64-linux-user --static". + +The go version is 1.7.1, and the system "Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux".
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1624 b/results/classifier/mode-gemma3:12b/user/1624 new file mode 100644 index 00000000..7ea102d0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1624 @@ -0,0 +1,25 @@ + + +8.0.0: Crash when emulating MIPS executable +Description of problem: +A change to QEMU introduced within the 6.0.0 development cycle causes MIPS executable to crash. +Similar problem occurred within the same time-frame for Aarch64 executables, but was fixed. +Patches in QEMU causing both Aarch64 and MIPS occurrences are identified and attached below. +Steps to reproduce: +1. Download attached core_test.zip archive. +2. Run pre-built MIPS executable with QEMU. +3. Observe the crash somewhere in tdelete. +4. Source for the test is here: https://github.com/VectorChief/QuadRay-engine +5. The binaries were built with GCC 9.4 cross-compilers using slightly modified makefiles (-ggdb3) for gdb-multiarch +6. Building on Ubuntu 22.04 and Ubuntu 23.04 also reproduces the problem, so it's not OS or compiler specific. +Additional information: +Archive with pre-built binaries: [core_test.zip](/uploads/529833c6f83aeec253df647a94868f8a/core_test.zip) + +Patch breaking Aarch64: [qemu_arm_br.diff](/uploads/476321e40a551e964be41a8bfda96613/qemu_arm_br.diff) +commit 8fe35e0444be88de4e3ab80a2a0e210a1f6d663d + +Patch fixing Aarch64: [qemu_arm_fix.diff](/uploads/2db3892d6839e9a4dfaf427359d6f004/qemu_arm_fix.diff) +commit ae30e86661b0f48562cd95918d37cbeec5d02262 + +Patch breaking MIPS: [qemu_mips_br.diff](/uploads/0a482e61c1245e5783364db845a55dfa/qemu_mips_br.diff) +commit 96e5b4c7584d623f6cdcb0083829c19141b2b130 diff --git a/results/classifier/mode-gemma3:12b/user/1631625 b/results/classifier/mode-gemma3:12b/user/1631625 new file mode 100644 index 00000000..c7179659 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1631625 @@ -0,0 +1,17 @@ + + +target-mips/dsp_helper.c: two possible bad shifts + +target-mips/dsp_helper.c:3480:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Source code is + + temp = temp & ((0x01 << (size + 1)) - 1); + +If size >= 32, then better code might be + + temp = temp & ((0x01UL << (size + 1)) - 1); + +target-mips/dsp_helper.c:3509:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Duplicate
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1641637 b/results/classifier/mode-gemma3:12b/user/1641637 new file mode 100644 index 00000000..3d43cb82 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1641637 @@ -0,0 +1,715 @@ + + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +Thanks!
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1641861 b/results/classifier/mode-gemma3:12b/user/1641861 new file mode 100644 index 00000000..11d05c92 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1641861 @@ -0,0 +1,38 @@ + + +ARM QEMU doesn't enforce that RES0 bits in FPSCR are non-writeable + +Hi all, we systematically tested the QEMU implementation for emulating arm user mode programs. We found that QEMU incorrectly emulate the FPSCR register. The following the proof of code: + +/*********** Beginning of the bug: arm.c **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov r2, %0\n" + "ldr r0, [r2]\n"::"r"((char *)(i0)));; + asm("vmsr fpscr, r0"); + asm("mov r2, %0\n" + "vmrs r4, fpscr\n" + "str r4, [r2]\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} +unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00}; + +/*********** End fo the bug **********/ + +When the program is compiled into arm binary code and running on a real arm machine, and running in qemu, we have the following result + +$ arm-linux-gnueabihf-gcc arm.c -o arm -static +$ ./arm +000000000000000000000000fff7009f +$ qemu-arm arm +000000000000000000000000ffffffff + +According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be reserved as zero. However, arm qemu fails to keep these bits to be zero: these bits can be actually modified in QEMU. + +Thanks!
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1648 b/results/classifier/mode-gemma3:12b/user/1648 new file mode 100644 index 00000000..c49036d4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1648 @@ -0,0 +1,60 @@ + + +linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash +Description of problem: +Corrent Print Result: + +sp: cdd3b4e8 + +SUCCEEDED! + +qemu-x86_64 Print Result: + +sp: 2804170 + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Segmentation fault + +Reason of Bug: + +sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*) + +For example on x86_64: + +reference to "qemu/linux-user/i386/signal.c" + +``` +# define TARGET_FPSTATE_FXSAVE_OFFSET 0 + +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + struct target_fpstate fpstate QEMU_ALIGNED(16); +}; +#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET ( \ + offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET) +``` + +offsetof(struct rt_sigframe, fpstate) align of 16 + +TARGET_FPSTATE_FXSAVE_OFFSET is 0 + +TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64 + +so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect! + +Fix the bug: + +``` +struct rt_sigframe { + abi_ulong pretcode; + struct target_ucontext uc; + struct target_siginfo info; + abi_ulong unused QEMU_ALIGNED(16); + struct target_fpstate fpstate; +}; +``` + +offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64. diff --git a/results/classifier/mode-gemma3:12b/user/1655700 b/results/classifier/mode-gemma3:12b/user/1655700 new file mode 100644 index 00000000..e1eacf5c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1655700 @@ -0,0 +1,27 @@ + + +disas/libvixl/vixl/invalset.h: possible dodgy code in binary search ? + + +[qemu/disas/libvixl/vixl/invalset.h:442]: (style) Array index 'low' is used before limits check. + +Source code is + + while (!IsValid(elements[low]) && (low < high)) ++low; + +Also: + +qemu/disas/libvixl/vixl/invalset.h:450]: (style) Array index 'middle' is used before limits check. + +The source code is + + while (!IsValid(elements[high]) && (low < high)) --high; + +Mind you, these lines of code look similar but didn't get reported: + + while (!IsValid(elements[middle]) && (middle < high - 1)) ++middle; + while (!IsValid(elements[middle]) && (low + 1 < middle)) --middle; + +Given that binary search is notoriously tricky to get correct and a standard C library routine +I am puzzled as to why the standard library routine didn't get used, with of course a custom +comparison function.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1659901 b/results/classifier/mode-gemma3:12b/user/1659901 new file mode 100644 index 00000000..6d0e1dc7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1659901 @@ -0,0 +1,11 @@ + + +Regression: SIGSEGV running Java + +I have a build script that bootstraps a Debian armhf image. Part of the process involves running a Java program while inside a chroot. I am using Debian's qemu-user-static package to run the armhf Java binary on an amd64 system. + +qemu-user-static version 1:2.7+dfsg-3~bpo8+2 works fine. Version 1:2.8+dfsg-1~bpo8+1 always causes Java to crash with a SIGSEGV. The location of the crash appears to be random and hasn't been the same twice. + +I am using the Azul Systems Zulu Embedded Java runtime, rather than the regular OpenJDK runtime, because the Zulu runtime has an arm32 JIT whereas OpenJDK is interpreter-only on arm32. + +I can reproduce the problem easily by mounting the image created by my build script and executing "java -XshowSettings -version" in a chroot. I can give you the image if that would help debug the problem.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1662468 b/results/classifier/mode-gemma3:12b/user/1662468 new file mode 100644 index 00000000..4471ce28 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1662468 @@ -0,0 +1,5 @@ + + +[feature request] qemu-img convert should respond to control-T like dd + +Since qemu-img convert is a long-running operation, it would be nice if it reported progress in response to control-T (SIGINFO) to show progress information, much like dd, fsck, dump, cp, etc.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1668 b/results/classifier/mode-gemma3:12b/user/1668 new file mode 100644 index 00000000..351c0ced --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1668 @@ -0,0 +1,47 @@ + + +Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user) +Description of problem: +Spawn a Fedora 38 container using `s390x` linux-user based emulation + +``` +$ podman run -it --platform linux/s390x fedora:latest +``` + +Install clang inside it + +``` +sh-5.2# dnf -y install clang +``` + +Try to run clang + +``` +sh-5.2# clang --version +clang version 16.0.4 (Fedora 16.0.4-1.fc38) +Target: s390x-redhat-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +sh-5.2# clang --help +clang-16: error: unsupported option '--help'; did you mean '--help'? +clang-16: error: no input files +``` + +Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help. In fact all options except for `--version` appear to be broken: + +``` +sh-5.2# echo "void foo(void) {}" > foo.c +sh-5.2# clang -c foo.c +clang-16: error: unknown argument: '-c' +``` + + +IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation. + +It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16. + +Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455) + +This was originally reported in Fedora at + + https://bugzilla.redhat.com/show_bug.cgi?id=2209635 diff --git a/results/classifier/mode-gemma3:12b/user/1670 b/results/classifier/mode-gemma3:12b/user/1670 new file mode 100644 index 00000000..2db7d758 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1670 @@ -0,0 +1,11 @@ + + +Cannot statically build x86_64-softmmu with Darwin(Intel) +Description of problem: +I am using `Podman` and currently,`Podman` uses qemu on macOS. The `Podman` team has adopted a scheme to dynamically compile `qemu` (https://github.com/containers/podman-machine-qemu). However, I am currently trying to use static compilation for both amd64 and arm64 targets. + +I have searched many articles online, most of which are about static compilation on Linux. Very few articles mention static compilation on macOS, and some mention that `softmmu` does not support static compilation. However, I have not found any concrete evidence to support this claim. + +I also want to ask another question: Does `qemu` support static compilation on macOS? +Additional information: +[meson-log.txt](/uploads/6e32691488533a06c64dc34ee4514135/meson-log.txt) diff --git a/results/classifier/mode-gemma3:12b/user/1671 b/results/classifier/mode-gemma3:12b/user/1671 new file mode 100644 index 00000000..a7d7472b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1671 @@ -0,0 +1,1359 @@ + + +segfault/errors in gdbstub with linux userspace emulator (qemu-riscv64), from racy behavior with singal handler? +Description of problem: +Often, qemu segfaults, sometimes GDB just spits out a wall of "Ignoring packet error, continuing..." and ~hangs: I don't get a GDB command prompt quickly, if at all, and when I ctrl-c I see "The target is not responding to GDB commands. Stop debugging it? (y or n)". +Steps to reproduce: +1. Run the `testb3` binary from below as described +2. Connect via GDB and `continue` +3. Multiple threads (independently) SIGABRT themselves when they fail their test(s), which happens quickly on my machine (which has 16 physical cores) +Additional information: +From the coredump, it looks like there's a lot of cooks in the gdbstub kitchen: + +``` + Id Target Id Frame +* 1 Thread 0x7febc02ef6c0 (LWP 3922802) gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 + 2 Thread 0x7febc06db6c0 (LWP 3922792) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 3 Thread 0x7febc03b26c0 (LWP 3922799) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 4 Thread 0x7febc0f5d6c0 (LWP 3922751) 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 + 5 Thread 0x7febc0f5ebc0 (LWP 3922750) safe_syscall_base () + at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 + 6 Thread 0x7febc01696c0 (LWP 3922808) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 7 Thread 0x7febc04f76c0 (LWP 3922794) 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 + 8 Thread 0x7febc026d6c0 (LWP 3922804) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 9 Thread 0x7febc01aa6c0 (LWP 3922807) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 10 Thread 0x7febc075c6c0 (LWP 3922793) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 11 Thread 0x7febc04756c0 (LWP 3922796) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 12 Thread 0x7febc01eb6c0 (LWP 3922806) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 13 Thread 0x7febc022c6c0 (LWP 3922805) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 14 Thread 0x7febc03f36c0 (LWP 3922798) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 15 Thread 0x7febc04346c0 (LWP 3922797) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 16 Thread 0x7febc03716c0 (LWP 3922800) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 + 17 Thread 0x7febc04b66c0 (LWP 3922795) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 18 Thread 0x7febc02ae6c0 (LWP 3922803) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 + 19 Thread 0x7febc03306c0 (LWP 3922801) 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +``` + +Each of those `read` and `send` threads look something similar to this one: + +``` +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +``` + +Which, at a guess, seems like there's maybe 20 different concurrent processes fighting over the singular [gdbstub state](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L57)? Specifically, they're all stomping on each other by writing to the same [buffer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/user.c#L136) and advancing the [current CPU list pointer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L1422), which causes the "bad packet" cross-talk and the segfault respectively. + +<details><summary>full backtrace</summary> + +``` +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +(gdb) thread apply all bt + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +(gdb) thread apply all bt full + +Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)): +#0 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82 +No locals. +#2 0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161 +No locals. +#3 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#4 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#5 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#7 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#8 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#9 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)): +#0 0x00007febc16de96c in read () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38 +No locals. +#2 gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148 +No locals. +#3 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#4 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#5 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#6 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#7 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#8 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962 +No locals. + +Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)): +#0 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29 +No locals. +#2 qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464 +No locals. +#3 0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261 +No locals. +#4 0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541 +No locals. +#5 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#6 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)): +#0 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38 +No locals. +#2 gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39 +No locals. +#3 0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62 +No locals. +#4 gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164 +No locals. +#5 0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181 +No locals. +#6 handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410 +No locals. +#7 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#8 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#9 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)): +#0 safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75 +No locals. +#1 0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678 +No locals. +#2 do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804 +No locals. +#3 do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891 +No locals. +#4 0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476 +No locals. +#5 0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375 +No locals. +#6 0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55 +No locals. +#7 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#8 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#9 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)): +#0 gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282 +No locals. +#1 0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411 +No locals. +#2 0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#3 0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673 +No locals. +#4 handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661 +No locals. +#5 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838 +No locals. +#6 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856 +No locals. +#7 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953 +No locals. +#8 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113 +No locals. +#9 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153 +No locals. +#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042 +No locals. +#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153 +No locals. +#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93 +No locals. +#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621 +No locals. +#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. +#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6 +No symbol table info available. + +``` + +</details> + + + +- coredump + - [core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst](/uploads/071fc96520ca4008941044802c176d6a/core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst) + - [qemu-riscv64](/uploads/f203d5aed8559d80c2d66e439bb4dddf/qemu-riscv64) (the binary the coredump was generated from) + - download both, extract corefile, use `DEBUGINFOD_URLS=https://debuginfod.archlinux.org gdb /path/to/qemu-riscv64 -c /tmp/coredump` to debug +- reproducer + - [testb3.tar.xz](/uploads/84bdbb547e01527c3d804e0d88c6c9fe/testb3.tar.xz) (includes testb3 + sysroot to work with command line above) + - This binary is a cross-compiled `testb3` from [WebKit](https://github.com/WebKit/WebKit/blob/9755847ab1d40841374b2467b3036d943b723183/Source/JavaScriptCore/b3/testb3_1.cpp#L927) ; sorry, that's about all I know about it so far + - A GDB you might use to connect is [SiFive's](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14.tar.gz). I got more consistent segfaults with a more recent gdb (12.1), but I'm not sure how to tell you how to get that `gdb` besides "creating a riscv64 poky distribution" (what I did), which is likely not helpful. diff --git a/results/classifier/mode-gemma3:12b/user/1673976 b/results/classifier/mode-gemma3:12b/user/1673976 new file mode 100644 index 00000000..7b2980e5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1673976 @@ -0,0 +1,13 @@ + + +linux-user clone() can't handle glibc posix_spawn() (causes locale-gen to assert) + +I'm running a command command (locale-gen) inside of an armv7h chroot mounted on my x86_64 desktop by putting qemu-arm-static into /usr/bin/ of the chroot file system and I get a core dump. + +locale-gen +Generating locales... + en_US.UTF-8...localedef: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +/usr/bin/locale-gen: line 41: 34 Aborted (core dumped) localedef -i $input -c -f $charset -A /usr/share/locale/locale.alias $locale + +I've done this same thing successfully for years, but this breakage has appeared some time in the last 3 or so months. Possibly with the update to qemu version 2.8.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1675108 b/results/classifier/mode-gemma3:12b/user/1675108 new file mode 100644 index 00000000..81a7a5bb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1675108 @@ -0,0 +1,24 @@ + + +Cocoa UI always crashes on startup + +Commit 8bb93c6f99a42c2e0943bc904b283cd622d302c5 ("ui/console: ensure graphic updates don't race with TCG vCPUs") causes the graphic update to run on a non-main thread, which Cocoa is not happy with. It crashes immediately after startup. + +$ i386-softmmu/qemu-system-i386 +2017-03-22 10:09:25.113 qemu-system-i386[15968:9538245] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'nextEventMatchingMask should only be called from the Main Thread!' +*** First throw call stack: +( + 0 CoreFoundation 0x00007fff91e72e7b __exceptionPreprocess + 171 + 1 libobjc.A.dylib 0x00007fffa6a5ccad objc_exception_throw + 48 + 2 AppKit 0x00007fff900953fd -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 4471 + 3 qemu-system-i386 0x0000000104f75a49 cocoa_refresh + 233 + 4 qemu-system-i386 0x0000000104e0312c process_queued_cpu_work + 140 + 5 qemu-system-i386 0x0000000104d1a73c qemu_tcg_rr_cpu_thread_fn + 284 + 6 libsystem_pthread.dylib 0x00007fffa7557aab _pthread_body + 180 + 7 libsystem_pthread.dylib 0x00007fffa75579f7 _pthread_body + 0 + 8 libsystem_pthread.dylib 0x00007fffa75571fd thread_start + 13 +) +libc++abi.dylib: terminating with uncaught exception of type NSException +Abort trap: 6 + +System: macOS 10.12.3, Xcode 8.2.1
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1682 b/results/classifier/mode-gemma3:12b/user/1682 new file mode 100644 index 00000000..fcc79b18 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1682 @@ -0,0 +1,5 @@ + + +QEMU-USER macOS support +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1695 b/results/classifier/mode-gemma3:12b/user/1695 new file mode 100644 index 00000000..c5f7301e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1695 @@ -0,0 +1,13 @@ + + +Latest Windows MSI does not include libssp-0.dll +Description of problem: +The latest Qemu MSI installer for Windows (https://qemu.weilnetz.de/w64/2023/qemu-w64-setup-20230530.exe) does not include libssp-0.dll, which is why the executables fail to run. + +This Mingw library should be included when building the MSI if stack protection is enabled. +Steps to reproduce: +1. Install the latest qemu MSI +2. Try to invoke any qemu command +3. Use Dependency Walker to easily find missing dependencies (https://www.dependencywalker.com/) +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1696180 b/results/classifier/mode-gemma3:12b/user/1696180 new file mode 100644 index 00000000..fa475298 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1696180 @@ -0,0 +1,21 @@ + + +Issues with qemu-img, libgfapi, and encryption at rest + +Hi, + +Encryption-at-rest has been supported for some time now. The client is responsible for encrypting the files with a help of a master key file. I have a properly setup environment and everything appears to be working fine but when I use qemu-img to move a file to gluster I get the following: + + +# qemu-img convert -f raw -O raw linux.iso gluster://gluster01/virt0/linux.raw +[2017-06-06 16:52:25.489720] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.490778] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.492263] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_lookup+0x4e5) [0x7f30f7a36d35] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL +[2017-06-06 16:52:25.497226] E [mem-pool.c:579:mem_put] (-->/lib64/libglusterfs.so.0(syncop_create+0x44d) [0x7f30f7a3cf5d] -->/lib64/libglusterfs.so.0(+0x59f02) [0x7f30f7a32f02] -->/lib64/libglusterfs.so.0(mem_put+0x190) [0x7f30f7a24a60] ) 0-mem-pool: mem-pool ptr is NULL + +On and on until I get this message: + +[2017-06-06 17:00:03.467361] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-0: All subvolumes are down. Going offline until atleast one of them comes back up. +[2017-06-06 17:00:03.467442] E [MSGID: 108006] [afr-common.c:4409:afr_notify] 0-virt0-replicate-1: All subvolumes are down. Going offline until atleast one of them comes back up. + +I asked for help assuming it's a problem with glusterfs and was told it appears qemu-img's implementation of libgfapi doesn't call the xlator function correctly.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1696353 b/results/classifier/mode-gemma3:12b/user/1696353 new file mode 100644 index 00000000..b28e969b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1696353 @@ -0,0 +1,37 @@ + + +golang binaries fail to start under linux-user + +With current master golang binaries fail when run under linux-user, for example: + +[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide +runtime: failed to create new OS thread (have 2 already; errno=22) +fatal error: newosproc + +runtime stack: +runtime.throw(0x45f879, 0x9) + /usr/lib/golang/src/runtime/panic.go:566 +0x78 +runtime.newosproc(0x1092c000, 0x1093bfe0) + /usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0 +runtime.newm(0x4ae1e8, 0x0) + /usr/lib/golang/src/runtime/proc.go:1572 +0x12c +runtime.main.func1() + /usr/lib/golang/src/runtime/proc.go:126 +0x24 +runtime.systemstack(0x5ef900) + /usr/lib/golang/src/runtime/asm_arm.s:247 +0x80 +runtime.mstart() + /usr/lib/golang/src/runtime/proc.go:1079 + +goroutine 1 [running]: +runtime.systemstack_switch() + /usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8 +runtime.main() + /usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac +runtime.goexit() + /usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4 + +The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail: + +https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155 + +The attached patch allows golang binaries to start under linux-user.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1696773 b/results/classifier/mode-gemma3:12b/user/1696773 new file mode 100644 index 00000000..3022b113 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1696773 @@ -0,0 +1,9 @@ + + +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/mode-gemma3:12b/user/1697 b/results/classifier/mode-gemma3:12b/user/1697 new file mode 100644 index 00000000..2e28dd4a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1697 @@ -0,0 +1,21 @@ + + +qemu-arm -cpu cortex-m55 dummy_test qemu-arm: ../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed. +Description of problem: +Basic testing failed for cortex m55 +Steps to reproduce: +1.Pulled the newest qemu 8.0.50 + +2.Create a Dummy test with only return 0 in main function + +3.run ` arm-none-eabi-gcc -o dummy_test -O2 -g -mcpu=cortex-m55 dummy_test.cc --specs=rdimon.specs` and then `qemu-arm -cpu cortex-m55 dummy_test` + +`arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.` + +`qemu-arm version 8.0.50 (v8.0.0-1739-g5f9dd6a8ce) +Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers` +Additional information: +It is a known problem in another issues: https://gitlab.com/qemu-project/qemu/-/issues/1528#note_1389268261. diff --git a/results/classifier/mode-gemma3:12b/user/1701808 b/results/classifier/mode-gemma3:12b/user/1701808 new file mode 100644 index 00000000..ae0768a2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1701808 @@ -0,0 +1,18 @@ + + +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/mode-gemma3:12b/user/1701971 b/results/classifier/mode-gemma3:12b/user/1701971 new file mode 100644 index 00000000..11cf4c5c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1701971 @@ -0,0 +1,47 @@ + + +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/mode-gemma3:12b/user/1701973 b/results/classifier/mode-gemma3:12b/user/1701973 new file mode 100644 index 00000000..85464743 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1701973 @@ -0,0 +1,19 @@ + + +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/mode-gemma3:12b/user/1701974 b/results/classifier/mode-gemma3:12b/user/1701974 new file mode 100644 index 00000000..caac9b3d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1701974 @@ -0,0 +1,19 @@ + + +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/mode-gemma3:12b/user/1704638 b/results/classifier/mode-gemma3:12b/user/1704638 new file mode 100644 index 00000000..33179edc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1704638 @@ -0,0 +1,67 @@ + + +weak symbol access makes qemu in user mode hang for mips, mips64 + +A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL). + +With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9". + +How to reproduce for mips: +- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread +- Set environment variables for running qemu-mips. +- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips + +How to reproduce for mips64: +- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread +- Set environment variables for running qemu-mips64. +- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64 + +When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code': + +$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726 +... +Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done. +Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726 +... +(gdb) info threads + Id Target Id Frame +* 1 Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 + 2 Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +(gdb) where +#0 __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 +#1 0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80 +#2 0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) + at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60 +#3 0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167 +#4 cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350 +#5 0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124 +#6 cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229 +#7 0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646 +#8 <signal handler called> +#9 __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47 +#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21 +#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434 +#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68 +#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58) + at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962 +#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, + cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295 +#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365 +#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673 +#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236 +#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>) + at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860 +(gdb) thread 2 +[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))] +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +38 ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden. +(gdb) where +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26 +#2 qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399 +#3 0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249 +#4 0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333 +#5 0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1705118 b/results/classifier/mode-gemma3:12b/user/1705118 new file mode 100644 index 00000000..743002ee --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1705118 @@ -0,0 +1,58 @@ + + +qemu user mode: rt signals not implemented for sparc guests + +The documentation +<https://qemu.weilnetz.de/doc/qemu-doc.html#Features> says that +qemu in user mode supports POSIX signal handling. + +Catching SIGSEGV according to POSIX, however, does not work on + ppc, ppc64, ppc64le, s390x, sparc64. +It does work, however, on + aarch64, alpha, arm, hppa, m68k, mips, mips64, sh4. + +How to reproduce: +The attached program runs fine (exits with code 0) on + - real hardware Linux/PowerPC64 (in 32-bit and 64-bit mode), + - real hardware Linux/PowerPC64LE, + - qemu-system-s390x emulated Linux/s390x, + - real hardware Linux/SPARC64. +$ gcc -O -Wall testsigsegv.c; ./a.out; echo $? +0 + +For ppc: +$ powerpc-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc +$ ~/inst-qemu/2.9.0/bin/qemu-ppc testsigsegv-ppc +$ echo $? +3 + +For ppc64: +$ powerpc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64 +$ ~/inst-qemu/2.9.0/bin/qemu-ppc64 testsigsegv-ppc64 +$ echo $? +3 + +For ppc64le: +$ powerpc64le-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-ppc64le +$ ~/inst-qemu/2.9.0/bin/qemu-ppc64le testsigsegv-ppc64le +$ echo $? +3 + +For s390x: +$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-s390x +$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x +$ echo $? +3 +$ s390x-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -DAVOID_LINUX_S390X_COMPAT -o testsigsegv-s390x-a +$ ~/inst-qemu/2.9.0/bin/qemu-s390x testsigsegv-s390x-a +$ echo $? +0 +So, the test fails here because the Linux/s390x kernel omits the least +significant 12 bits of the fault address in the 'si_addr' field. But +qemu-s390x is not compatible with the Linux/s390x behaviour: it puts +the complete fault address in the 'si_addr' field. + +For sparc64: +$ sparc64-linux-gnu-gcc-5 -O -Wall -static testsigsegv.c -o testsigsegv-sparc64 +$ ~/inst-qemu/2.9.0/bin/qemu-sparc64 testsigsegv-sparc64 +Segmentation fault (core dumped)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1706825 b/results/classifier/mode-gemma3:12b/user/1706825 new file mode 100644 index 00000000..d197b06b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1706825 @@ -0,0 +1,14 @@ + + +qemu-user fails to run wineserver on ppc64el host + +When attempting to run wineserver on a 64-bit ppc64el host via QEMU's user-mode i386 emulation, a file locking operation fails. + +Command line: +qemu-i386-static /usr/lib/wine-development/wineserver32 + +Output: +wineserver: fcntl /tmp/.wine-0/server-17-14d21bf/lock: Invalid argument + +Relevant portion of strace: +fcntl(6, F_SETLK64, 0x3fffe8802218) = -1 EINVAL (Invalid argument)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1707 b/results/classifier/mode-gemma3:12b/user/1707 new file mode 100644 index 00000000..ce858480 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1707 @@ -0,0 +1,25 @@ + + +linux-user qemu-x86_64 can't exec a binary on aarch64 or Loongarch. +Description of problem: +on master branch, we build an simply hello.c with x86_cross gcc. +then. run './build/qemu-x86_64 hello', no output. +Steps to reproduce: +1. build an hello.c with x86_64 cross. use --static. +2. build qemu-x86_64 on aarch64 or LoongArch host. +3. run './build/qemu-x86_64 hello' +Additional information: +[strace.txt](/uploads/5362e0e9b04ad9a582470faf4a9fcedb/strace.txt) + + + + [hello](/uploads/12d9277fa4e853286414f575010a37ac/hello) + + +The following commit causes this problem． + +commit 86f04735ac2088d5c069c3d1712212ec7428c562 +Author: Helge Deller <deller@gmx.de> +Date: Sun Dec 25 09:23:19 2022 +0100 + + linux-user: Fix brk() to release pages diff --git a/results/classifier/mode-gemma3:12b/user/1709170 b/results/classifier/mode-gemma3:12b/user/1709170 new file mode 100644 index 00000000..a0ac428d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1709170 @@ -0,0 +1,13 @@ + + +QEMU fails to honor O_TMPFILE + +When making a call like + + open("/tmp", O_TMPFILE | O_RDWR); + +under QEMU, we ged -EISDIR. + +Under any kernel 3.11 or later, we are supposed to get an unnamed file in /tmp. In case the filesystem for /tmp does not support unnamed files, we are supposed to get EOPNOTSUPP. + +[I don't know the QEMU version, since this happened in a system I don't have access to]
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1715162 b/results/classifier/mode-gemma3:12b/user/1715162 new file mode 100644 index 00000000..60291359 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1715162 @@ -0,0 +1,74 @@ + + +qemu-user crashing when writing core dump + +I've a binary I'm running in qemux86-64 but it is segfaulting. Whilst qemu writes the core dump for that, qemu itself is segfaulting. + +(gdb) bt full +#0 0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6 +No symbol table info available. +#1 0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598 + cpu = <optimized out> + env = <optimized out> + ts = 0x55917a42d160 + core_dumped = <optimized out> + act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647, + 18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010} +#2 0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11, + k=k@entry=0x55917a42d190) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596 + handler = <optimized out> + set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104, + 94083255852784, 94083309703424, 3351315493}} + target_old_set = {sig = {0}} + sa = <optimized out> + ts = 0x55917a42d160 +#3 0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674 + sig = 11 + ts = 0x55917a42d160 + set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}} + blocked_set = <optimized out> +#4 0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369 + trapnr = 14 + pc = <optimized out> + ret = <optimized out> + info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509, + 842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0, + 12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877}, + _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = { + _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}}, + _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792}, + _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}} +#5 0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) + at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862 + regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0, + rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0, + rsp = 274888401360, ss = 0} + regs = 0x7ffda5b29fc0 + info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944, + end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0, + brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576, + entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256, + auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408, + arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0, + personality = 0} + info = 0x7ffda5b2a070 + bprm = { + buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3, + e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0, + filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>} + ts = <optimized out> + env = 0x55917a41c2a0 + cpu = 0x55917a414010 + target_environ = 0x55917a42a8f0 + wrk = 0x55917a42ac30 + target_argv = 0x55917a42d120 + target_argc = 5 + i = <optimized out> + ret = <optimized out> + execfd = <optimized out> + +(I'll reproduce this with glibc debug symbols shortly)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1716292 b/results/classifier/mode-gemma3:12b/user/1716292 new file mode 100644 index 00000000..af1b1e99 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1716292 @@ -0,0 +1,32 @@ + + +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/mode-gemma3:12b/user/1716767 b/results/classifier/mode-gemma3:12b/user/1716767 new file mode 100644 index 00000000..69b60b2b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1716767 @@ -0,0 +1,36 @@ + + +file(1) fails with "Invalid argument" on qemu-sh4-user + +We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file: + +(sid_sh4)root@vs94:/# file /bin/bash +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +Running with "-d" yields more output: + +(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail +322: >> 7 byte&,=97,"(ARM)"] +0 == 97 = 0 +mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1) +mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000 + +323: >> 7 byte&,=-1,"(embedded)"] +0 == 18446744073709551615 = 0 +[try softmagic 1] +[try elf -1] +/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument) +(sid_sh4)root@vs94:/# + +It seems that the comparison above has a bogus (overflown?) value. + +On actual hardware, it works: + +root@tirpitz:~> file /bin/bash +/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped +root@tirpitz:~> + +I have uploaded a chroot with Debian unstable which allows to reproduce the issue: + +> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1721275 b/results/classifier/mode-gemma3:12b/user/1721275 new file mode 100644 index 00000000..01c197a0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1721275 @@ -0,0 +1,28 @@ + + +Support more ARM CPUs + +Hi, + +This is an enhancement request, rather than a bug report. + +After some discussions/presentations during the last Linaro Connect (SFO17), I understand that it may be easy to add support for more ARM CPUs in QEMU. I am interested in user-mode, if that matters. + +I'm primarily using QEMU for GCC validations, and I'd like to make sure that GCC doesn't generate instructions not supported by the CPU it's supposed to generate code for. + +I'd like to have: +cortex-m0 +cortex-m4 +cortex-m7 +cortex-m23 +cortex-m33 + +cortex-a35 +cortex-a53 +cortex-a57 + +Is it possible? +Is it the right place to ask? +Should I file separate requests for each? + +Thanks
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1722 b/results/classifier/mode-gemma3:12b/user/1722 new file mode 100644 index 00000000..5f09ce5d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1722 @@ -0,0 +1,89 @@ + + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/mode-gemma3:12b/user/1724485 b/results/classifier/mode-gemma3:12b/user/1724485 new file mode 100644 index 00000000..81e71140 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1724485 @@ -0,0 +1,20 @@ + + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1725267 b/results/classifier/mode-gemma3:12b/user/1725267 new file mode 100644 index 00000000..9156a2c9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1725267 @@ -0,0 +1,33 @@ + + +armeb regression since qemu version 2.8 + +Hi, + +I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1. + +I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe. + +# with 2.7: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +$ echo $? +0 +# with 2.8, 2.10.1: +$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) +$ echo $? +134 + +The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c + +Running with -d in_asm shows a difference early in the startup code: +IN: _dl_sysdep_start +[...] +0x40a17790: 908ff103 addls pc, pc, r3, lsl #2 + +and then the next address is not the same with qemu 2.7 and 2.10.1 + +I hope you have enough data/information to reproduce and confirm/fix the problem. + +Thanks
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1726394 b/results/classifier/mode-gemma3:12b/user/1726394 new file mode 100644 index 00000000..686d0852 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1726394 @@ -0,0 +1,7 @@ + + +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/mode-gemma3:12b/user/1726910 b/results/classifier/mode-gemma3:12b/user/1726910 new file mode 100644 index 00000000..d04011dc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1726910 @@ -0,0 +1,13 @@ + + +UI request: add a function key toolbar (f1-f12) + +I run old DOS programs under FreeDOS using QEMU. + +It's common when running/testing DOS applications to use the function keys. Some of these (such as F10) are intercepted by the window system. For example, some DOS program installers use F10 to install the software, but F10 is intecepted by the window system. + +The standard solution is to jump to the QEMU console and use sendkey to send a specific function key to the QEMU guest (often needed for 'sendkey f10'). But this does not seem to be very user friendly for new users. Nor is it very fast if you need to this often. + +I propose QEMU add a toolbar with the function keys. + +I've attached a mockup of one possible design, with a simple toolbar for F1-F12. A possible modification would be to add "modifier" buttons for Ctrl and Shift and Alt to make it easier for users to enter combinations like Ctrl-F12 or Alt-F10 or Shift-F1.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1727737 b/results/classifier/mode-gemma3:12b/user/1727737 new file mode 100644 index 00000000..41eea95f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1727737 @@ -0,0 +1,27 @@ + + +qemu-arm stalls on a GCC sanitizer test since qemu-2.7 + +Hi, + +I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. + +After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 + +I'm attaching a tarball containing: +alloca_instruments_all_paddings.exe : the testcase, and the needed libs: +lib/librt.so.1 +lib/libdl.so.2 +lib/ld-linux-armhf.so.3 +lib/libasan.so.5 +lib/libc.so.6 +lib/libgcc_s.so.1 +lib/libpthread.so.0 +lib/libm.so.6 + +To reproduce the problem: +$ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe +returns in less than a second with qemu-2.7, and never with qemu-2.8 + +Using -d in_asm suggests that the program "almost" completes and qemu seems to stall on: +0x40b6eb44: e08f4004 add r4, pc, r4
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1728116 b/results/classifier/mode-gemma3:12b/user/1728116 new file mode 100644 index 00000000..7fad6847 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1728116 @@ -0,0 +1,49 @@ + + +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/mode-gemma3:12b/user/1728325 b/results/classifier/mode-gemma3:12b/user/1728325 new file mode 100644 index 00000000..441d7283 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1728325 @@ -0,0 +1,62 @@ + + +POWER8: Wrong behaviour with float-to-int punning + +Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8' produces wrong results at runtime. I don't think gcc is at fault here. + +--- +#include <stdio.h> + +int getWord(const float x) +{ + return *(int*)&x; +} + +void main() +{ + int foo = getWord(+123.456f); + int bar = getWord(-123.456f); + + printf("%d\n", foo); + printf("%d\n", bar); + return; +} +--- + +This prints: +--- +0 +0 +--- + +Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the expected result: +--- +1123477881 +-1024005767 +--- + + +The different between the two programs is: + +--- power7.s ++++ power8.s +@@ -6,9 +6,9 @@ + .globl getWord + .type getWord, @function + getWord: +- stfs 1,-16(1) +- ori 2,2,0 +- lwa 3,-16(1) ++ xscvdpspn 0,1 ++ mfvsrwz 3,0 ++ extsw 3,3 + blr + .long 0 + .byte 0,0,0,0,0,0,0,0 + .size getWord,.-getWord + + +Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly. + +https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40 +https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1729 b/results/classifier/mode-gemma3:12b/user/1729 new file mode 100644 index 00000000..7c06921b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1729 @@ -0,0 +1,49 @@ + + +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/mode-gemma3:12b/user/1730101 b/results/classifier/mode-gemma3:12b/user/1730101 new file mode 100644 index 00000000..955438bb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1730101 @@ -0,0 +1,7 @@ + + +The guest is only starting after its SDL window gets focus + +I’m using i3wm and have workspace assigning rules that make QEMU’s SDL window be assigned to a workspace I don’t really switch to. + +When I run start a guest machine, its SDL window is moved to that workspace (I never see it); but the machine freezes after displaying that black window. It only starts booting after I switch to the workspace and view the window.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1734 b/results/classifier/mode-gemma3:12b/user/1734 new file mode 100644 index 00000000..1cf9a833 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1734 @@ -0,0 +1,18 @@ + + +mmap-ing more than 1GB of files fails on v8.0 of QEMU, but works on older version +Description of problem: +Trying to run an application using QEMU user mode for an ARM binary. My host system is Ubuntu 22.04 based. The v6.2 from Ubuntu repos is able to mmap files that contain more than 1GB of address space, but version 8.0 that I compiled will not. + +I created a repo with a readme, and a simple application that you can use to demonstrate the problem: +https://github.com/mwales/qemu_mmap_test + +Example application simply takes a list of files, mmaps the entire file into memory, and then computes a checksum of the file data. Once the file(s) sizes exceed around 1GB, the mmap calls will fail because the memory from 0x00000000 - 0x40000000 has been exhausted. +Steps to reproduce: +1. Compile test application that mmaps entire files +2. Create 5 256MB test files +3. Run the program tell it to mmap all the files. The first 3 files succeed, but the 4th when run gets a -1 returned from mmap. +Additional information: +Lots of details on my github writeup and a demo of the bug in question. + +It seems that this 1GB limit is an artifact of where QEMU loaded the original ELF binary at (0x40000000). I've also been playing around with moving that address using the -B 0x80000000 option, but I've encountered other problems doing that. As I diagnose that, I figured I would write up this report on what I've seen so far incase I'm doing something dumb / creating a bad build or something. diff --git a/results/classifier/mode-gemma3:12b/user/1734792 b/results/classifier/mode-gemma3:12b/user/1734792 new file mode 100644 index 00000000..5d5d3def --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1734792 @@ -0,0 +1,9 @@ + + +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/mode-gemma3:12b/user/1735384 b/results/classifier/mode-gemma3:12b/user/1735384 new file mode 100644 index 00000000..ba6b3557 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1735384 @@ -0,0 +1,22 @@ + + +OpenJDK JVM segfaults on qemu-sh4 (regression) + +Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4: + +(sid-sh4-sbuild)root@nofan:/# java -version +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +(sid-sh4-sbuild)root@nofan:/# + +An older version works fine: + +(sid-sh4-sbuild)root@nofan:/# java -version +openjdk version "9.0.1" +OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) +OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) +(sid-sh4-sbuild)root@nofan:/# + +Haven't had time for bisecting this yet. + +Adrian
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1737 b/results/classifier/mode-gemma3:12b/user/1737 new file mode 100644 index 00000000..4b5bce8c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1737 @@ -0,0 +1,51 @@ + + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1738434 b/results/classifier/mode-gemma3:12b/user/1738434 new file mode 100644 index 00000000..3d486553 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1738434 @@ -0,0 +1,30 @@ + + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +Environment: +QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img +Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 +Host OS: Windows 10 x64 version 1703 build 15063.786
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1738545 b/results/classifier/mode-gemma3:12b/user/1738545 new file mode 100644 index 00000000..14c8047b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1738545 @@ -0,0 +1,33 @@ + + +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/mode-gemma3:12b/user/1740219 b/results/classifier/mode-gemma3:12b/user/1740219 new file mode 100644 index 00000000..68de3caf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1740219 @@ -0,0 +1,61 @@ + + +static linux-user ARM emulation has several-second startup time + +static linux-user emulation has several-second startup time + +My problem: I'm a Parabola packager, and I'm updating our +qemu-user-static package from 2.8 to 2.11. With my new +statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` +went from taking 0.006s to 3s! This does not happen with the normal +dynamically linked 2.11, or the old static 2.8. + +What happens is it gets stuck in +`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` +does is map 2 parts of the address space: `[base, base+guest_size]` +and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find +an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, +...)` decide where the first range is, and then check if that ++0xffff0000 is also available. If it isn't, then it starts trying +`mmap(base, ...)` for the entire address space from low-address to +high-address. + +"Normally," it finds an accaptable `base` within the first 2 tries. +With a static 2.11, it's taking thousands of tries. + +---- + +Now, from my understanding, there are 2 factors working together to +cause that in static 2.11 but not the other builds: + + - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 + - PIE (and thus ASLR) is disabled for static builds + +For some reason that I don't understand, with the smaller +`guest_size` the initial `mmap(NULL, guest_size, ...)` usually +returns an acceptable address range; but larger `guest_size` makes it +consistently return a block of memory that butts right up against +another already mapped chunk of memory. This isn't just true on the +older builds, it's true with the 2.11 builds if I use the `-R` flag to +shrink the `guest_size` back down to 0xf7000000. That is with +linux-hardened 4.13.13 on x86-64. + +So then, it it falls back to crawling the entire address space; so it +tries base=0x00001000. With ASLR, that probably succeeds. But with +ASLR being disabled on static builds, the text segment is at +0x60000000; which is does not leave room for the needed +0xffff1000-size block before it. So then it tries base=0x00002000. +And so on, more than 6000 times until it finally gets to and passes +the text segment; calling mmap more than 12000 times. + +---- + +I'm not sure what the fix is. Perhaps try to mmap a continuous chunk +of size 0xffff1000, then munmap it and then mmap the 2 chunks that we +actually need. The disadvantage to that is that it does not support +the sparse address space that the current algorithm supports for +`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big +mmap fails, then it could fall back to a sparse search; though I'm not +sure the current algorithm is a good choice for it, as we see in this +bug. Perhaps it should inspect /proc/self/maps to try to find a +suitable range before ever calling mmap?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1741 b/results/classifier/mode-gemma3:12b/user/1741 new file mode 100644 index 00000000..7bbe1766 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1741 @@ -0,0 +1,3 @@ + + +95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64 diff --git a/results/classifier/mode-gemma3:12b/user/1743 b/results/classifier/mode-gemma3:12b/user/1743 new file mode 100644 index 00000000..9cb55bbf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1743 @@ -0,0 +1,18 @@ + + +QEm+Android emulator crashes on x86 host (but not mac M1) +Description of problem: +Using QEmu+Android emulator crashes when using tflite on x86 hosts (but not M1 macs). +Steps to reproduce: +1. Install android toolchain, including emulator (sdkmanager, adb, avdmanager etc) +2. Start android emulator on an x86 host +3. Follow instructions to download and run tflite benchmarking tool [here](https://www.tensorflow.org/lite/performance/measurement) +4. Crashes with the following error + +``` +06-27 17:38:28.093 8355 8355 F ndk_translation: vendor/unbundled_google/libs/ndk_translation/intrinsics/intrinsics_impl_x86_64.cc:86: CHECK failed: 524288 == 0 +``` + +We have tried with many different models and the result is always the same. The same models run fine when the emulator runs on a mac M1 host. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1748612 b/results/classifier/mode-gemma3:12b/user/1748612 new file mode 100644 index 00000000..47c26621 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1748612 @@ -0,0 +1,17 @@ + + +qemu-user option -strace -D <file> doesn't work + +I have been trying to access qemu -strace output from a script +The main problem was it was on stderr, the strace output was merged with my program's stderr output. +Then I tried to use the -D option, to log the output to a file. +This didn't work even if the log file was created, but it was empty. + +I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU) + + +I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now. + +removed declaration here and here: +https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108 +https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1749393 b/results/classifier/mode-gemma3:12b/user/1749393 new file mode 100644 index 00000000..9e7ee860 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1749393 @@ -0,0 +1,28 @@ + + +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/mode-gemma3:12b/user/1753186 b/results/classifier/mode-gemma3:12b/user/1753186 new file mode 100644 index 00000000..03f0ad87 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1753186 @@ -0,0 +1,18 @@ + + +qemu-nbd: always first snapshot loaded from VDI images with snapshots + +When mounting a virtual box disk image of a VM with snapshots, always the state of the first snapshot is shown. + +How to reproduce: +1. Create a new VirtualBox VM or use an existing one, while choosing VDI as the disk image format. +2. Create a snapshot of the VM. +3. Modify the file system from within the VM enough that differences to the snapshotted version are apparent. +4. Create another snapshot. +5. Shut down the VM. +6. Mount the partition from the disk image with `qemu-nbd -c /dev/nbd0 /path/to/disk.vdi; mount /dev/nbd0pX /mnt` + +Expected result: The mounted disk image shall represent the latest state of the VM +Actual result: The mounted disk image represents the VM state at the first snapshot + +version information: qemu-nbd-2.11.1(openSUSE Tumbleweed)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1755 b/results/classifier/mode-gemma3:12b/user/1755 new file mode 100644 index 00000000..ac5ea0fa --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1755 @@ -0,0 +1,22 @@ + + +qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.) +Description of problem: +I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit +"Make the commpage executable". +Steps to reproduce: +1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host) + +2.# compile for cortex-m3: + +3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs + +4.qemu-arm -cpu cortex-m3 hello.exe.m3 +.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed. + +5. # compile for cortex-a9: + +6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs + +7. qemu-arm -cpu cortex-a9 hello.exe.a9 +Hello diff --git a/results/classifier/mode-gemma3:12b/user/1756 b/results/classifier/mode-gemma3:12b/user/1756 new file mode 100644 index 00000000..1b7a6e75 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1756 @@ -0,0 +1,45 @@ + + +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/mode-gemma3:12b/user/1756519 b/results/classifier/mode-gemma3:12b/user/1756519 new file mode 100644 index 00000000..9b4c6b12 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1756519 @@ -0,0 +1,48 @@ + + +qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create + +qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: + +(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed +** +ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 + + +Backtrace obtained via gdb: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 +#1 0x0000000060139b21 in abort () at abort.c:79 +#2 0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, + func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") + at gtestutils.c:2430 +#3 0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, + func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453 +#4 0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 +#5 0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 +#6 0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874 +#7 0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68) + at qom/object.c:1926 +#8 0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122 +#9 0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68) + at qom/qom-qobject.c:27 +#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191 +#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 +#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 +#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881 +#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, + child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 +#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, + arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 +#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600 +#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311 +#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463 +#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + + +Attached is a test case source code extracted from libgomp test suite. + +Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. + +I will attach statically linked riscv64 binary executable if size limits permit.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1756807 b/results/classifier/mode-gemma3:12b/user/1756807 new file mode 100644 index 00000000..3749fea9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1756807 @@ -0,0 +1,69 @@ + + +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/mode-gemma3:12b/user/1756927 b/results/classifier/mode-gemma3:12b/user/1756927 new file mode 100644 index 00000000..69c48b03 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1756927 @@ -0,0 +1,20 @@ + + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +The last entry should read 'long-descriptor'. + + +Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 +Ubuntu verison: 16.04 LTS +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1759264 b/results/classifier/mode-gemma3:12b/user/1759264 new file mode 100644 index 00000000..c9d62078 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1759264 @@ -0,0 +1,10 @@ + + +fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns + +After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered. + +helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity. + +The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However, +I'm not sure if this breaks other targets and I have no easy way to test it.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1759522 b/results/classifier/mode-gemma3:12b/user/1759522 new file mode 100644 index 00000000..f03fa370 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1759522 @@ -0,0 +1,58 @@ + + +windows qemu-img create vpc/vhdx error + +On windows, using qemu-img (version 2.11.90) to create vpc/vhdx virtual disk tends to fail. Here's the way to reproduce: + +1. Install qemu-w64-setup-20180321.exe + +2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create a vhdx: + Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size` is incorrect): + image: disk.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 1.4M + cluster_size: 8388608 + +4. On Windows 10 (V1709), double click disk.vhdx gives an error: + Make sure the file is in an NTFS volume and isn't in a compressed folder or volume. + + Using Disk Management -> Action -> Attach VHD gives an error: + The requested operation could not be completed due to a virtual disk system limitation. Virtual hard disk files must be uncompressed and uneccrypted and must not be sparse. + +Comparison with Windows 10 created VHDX: + +1. Using Disk Management -> Action -> Create VHD: + File name: win.vhdx + Virtual hard disk size: 512MB + Virtual hard disk format: VHDX + Virtual hard disk type: Fixed size + +2. Detach VHDX + +3. Execute `qemu-img info win.vhdx` gives the result: + image: win.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 516M + cluster_size: 33554432 + +Comparison with qemu-img under Ubuntu: + +1. Version: qemu-img version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 2004-2008 Fabrice Bellard + +2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M + Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576 block_size=0 subformat=fixed + +3. qemu-img info lin.vhdx + image: lin.vhdx + file format: vhdx + virtual size: 512M (536870912 bytes) + disk size: 520M + cluster_size: 8388608 + +4. Load lin.vhdx under Windows 10 is ok + +The same thing happens on `vpc` format with or without `oformat=fixed`, it seems that windows version of qemu-img has some incorrect operation? My guess is that windows version of qemu-img doesn't handle the description field of vpc/vhdx, which leads to an incorrect `disk size` field.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1760 b/results/classifier/mode-gemma3:12b/user/1760 new file mode 100644 index 00000000..984f0993 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1760 @@ -0,0 +1,55 @@ + + +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/mode-gemma3:12b/user/1761153 b/results/classifier/mode-gemma3:12b/user/1761153 new file mode 100644 index 00000000..4bc543a4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1761153 @@ -0,0 +1,25 @@ + + +qemu-user incorrect mmap for large files on 64bits host and 32bits executable. + +qemu-user seems to incorrectly mmap a file if the offset is > 4GiB and guest binary is 32 bits elf. + +See attached test program `test_mmap.c`. + +``` +$ gcc -g -m32 -march=i386 test_mmap.c -o test_mmap +$ file test_mmap +test_mmap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=e36db05f4dfd8a9cfde8a969214a242c1f5a4b49, with debug_info, not stripped +$ uname -a +Linux localhost.localdomain 4.15.10-300.fc27.x86_64 #1 SMP Thu Mar 15 17:13:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux +$ qemu-i386 --version +qemu-i386 version 2.10.1(qemu-2.10.1-2.fc27) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ ./test_mmap +$ qemu-i386 test_mmap +Incorrect data 1 +``` + +Tested with qemu-i386 packaged in Fedora 27 and qemu-i386 compiled from git master (094b62cd9c) + +The issue was firstly detected on (more complex program) using qemu-arm (with 32bits binary) so it is probably a 32/64bits problem independently of the cpu family.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1761401 b/results/classifier/mode-gemma3:12b/user/1761401 new file mode 100644 index 00000000..d7533131 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1761401 @@ -0,0 +1,12 @@ + + +ARM/Neon: vcvt rounding error + +Hello, + +While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. + +The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. +The expected result is 125, but we get 126 instead. + +Maybe it's just a matter of default rounding mode?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1761535 b/results/classifier/mode-gemma3:12b/user/1761535 new file mode 100644 index 00000000..398d24f0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1761535 @@ -0,0 +1,38 @@ + + +qemu-aarch64-static docker arm64v8/openjdk coredump + +I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. + +To reproduce (and get to the core dump): + +$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version +qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash +root@bf75cf45d311:/# javac +Usage: javac <options> <source files> +where possible options include: + -g Generate all debugging info +<...snip...> + @<filename> Read options and filenames from file + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +...TERMINAL HANGS... + + +To get the core dump, In a separate terminal: + +# snapshot the file system of the hung image +$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump + +# connect with known working qemu +$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash + +$$ ls -lat +total 10608 +<snip> +-rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core +drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp +<snip>
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1763 b/results/classifier/mode-gemma3:12b/user/1763 new file mode 100644 index 00000000..e92ea820 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1763 @@ -0,0 +1,14 @@ + + +ldd fails with qemu-aarch64 +Description of problem: +see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172 +Steps to reproduce: +1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls + +Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries. +Additional information: +``` +WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested +ldd: exited with unknown exit code (139) +``` diff --git a/results/classifier/mode-gemma3:12b/user/1763536 b/results/classifier/mode-gemma3:12b/user/1763536 new file mode 100644 index 00000000..c3d50368 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1763536 @@ -0,0 +1,85 @@ + + +go build fails under qemu-ppc64le-static (qemu-user) + +I am using qemu-user (built static) in a docker container environment. When running multi-threaded go commands in the container (go build for example) the process may hang, report segfaults or other errors. I built qemu-ppc64le from the upstream git (master). + +I see the problem running on a multi core system with Intel i7 processors. +# cat /proc/cpuinfo | grep "model name" +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz +model name : Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz + +Steps to reproduce: +1) Build qemu-ppc64le as static and copy into docker build directory named it qemu-ppc64le-static. + +2) Add hello.go to docker build dir. + +package main +import "fmt" +func main() { + fmt.Println("hello world") +} + +3) Create the Dockerfile from below: + +FROM ppc64le/golang:1.10.1-alpine3. +COPY qemu-ppc64le-static /usr/bin/ +COPY hello.go /go + +4) Build container +$ docker build -t qemutest -f Dockerfile ./go + +5) Run test +$ docker run -it qemutest + +/go # /usr/bin/qemu-ppc64le-static --version +qemu-ppc64le version 2.11.93 (v2.12.0-rc3-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +/go # go version +go version go1.10.1 linux/ppc64le + +/go # go build hello.go +fatal error: fatal error: stopm holding locksunexpected signal during runtime execution + +panic during panic +[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1003528c] + +runtime stack: +runtime: unexpected return pc for syscall.Syscall6 called from 0xc42007f500 +stack: frame={sp:0xc4203be840, fp:0xc4203be860} stack=[0x4000b7ecf0,0x4000b928f0) + +syscall.Syscall6(0x100744e8, 0x3d, 0xc42050c140, 0x20, 0x18, 0x10422b80, 0xc4203be968[signal , 0x10012d88SIGSEGV: segmentation violation, 0xc420594000 code=, 0x00x1 addr=0x0 pc=0x1003528c) +] + +runtime stack: + /usr/local/go/src/syscall/asm_linux_ppc64x.s:61runtime.throw(0x10472d19, 0x13) + + /usr/local/go/src/runtime/panic.go:0x6c616 +0x68 + + +runtime.stopm() + /usr/local/go/src/runtime/proc.go:1939goroutine +10x158 + [runtime.exitsyscall0semacquire(0xc42007f500) + /usr/local/go/src/runtime/proc.go:3129 +]: +0x130 +runtime.mcall(0xc42007f500) + /usr/local/go/src/runtime/asm_ppc64x.s:183 +0x58sync.runtime_Semacquire +(0xc4201fab1c) + /usr/local/go/src/runtime/sema.go:56 +0x38 + +---- +Note the results may differ between attempts, hangs and other faults sometimes happen. +---- +If I run "go: single threaded I don't see the problem, for example: + +/go # GOMAXPROCS=1 go build -p 1 hello.go +/go # ./hello +hello world + +I see the same issue with arm64. I don't think this is a go issue, but don't have a real evidence to prove that. This problem looks similar to other problem I have seen reported against qemu running multi-threaded applications.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1765970 b/results/classifier/mode-gemma3:12b/user/1765970 new file mode 100644 index 00000000..96420a0b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1765970 @@ -0,0 +1,63 @@ + + +qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x + +I use a qemu-user chroot + binfmt to build software targetting a raspberry pi. After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host), I noticed that on my uclibc-ng chroot qemu-arm will segfault when running python and importing the portage module. + +I have bisected qemu down to this commit: + +https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07 + +If I recompile and change MAX_RESERVED_VA (from the above commit) back to 0x77000000 the problem goes away. NB I have no idea what that does, I just thought I'd see. + + +Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the uclibc-ng one. Not sure why. + + +The following backtrace was generated from running qemu-arm in gdb and recreating the segfault: + +(gdb) where +#0 0x0000000060726046 in static_code_gen_buffer () +#1 0x0000000060048789 in cpu_tb_exec (cpu=0x6278e310, + itb=0x60725f80 <static_code_gen_buffer+314624>) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167 +#2 0x000000006004937f in cpu_loop_exec_tb (cpu=0x6278e310, + tb=0x60725f80 <static_code_gen_buffer+314624>, last_tb=0x7fffffffd138, + tb_exit=0x7fffffffd130) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627 +#3 0x0000000060049600 in cpu_exec (cpu=0x6278e310) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736 +#4 0x00000000600511c3 in cpu_loop (env=0x627965b0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585 +#5 0x00000000600534eb in main (argc=4, argv=0x7fffffffd9b8, + envp=0x7fffffffd9e0) + at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882 + + + +(gdb) info reg +rax 0x627965b0 1652123056 +rbx 0x62717870 1651603568 +rcx 0x606da000 1617797120 +rdx 0x60726000 1618108416 +rsi 0x60726000 1618108416 +rdi 0x627965b0 1652123056 +rbp 0x7fffffffd0c0 0x7fffffffd0c0 +rsp 0x7fffffffd080 0x7fffffffd080 +r8 0x0 0 +r9 0x2 2 +r10 0x0 0 +r11 0x629280a0 1653768352 +r12 0x60260e40 1613106752 +r13 0x0 0 +r14 0x606a5018 1617580056 +r15 0x0 0 +rip 0x60048789 0x60048789 <cpu_tb_exec+266> +eflags 0x10282 [ SF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 +(gdb)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1768 b/results/classifier/mode-gemma3:12b/user/1768 new file mode 100644 index 00000000..24cce069 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1768 @@ -0,0 +1,34 @@ + + +Could not allocate more than ~2GB with qemu-user +Description of problem: +On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.) +Steps to reproduce: +1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");] +2. Only 1 64MB chunck is allocated in the upper 2GB memory space +3. Failed to allocate after about 2GB. +Additional information: +The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t). +The testing program is the following: +``` +#include <stdio.h> +#include <stdlib.h> + +int main(int argc,char *argv[]) { + unsigned int a; + unsigned int i; + char *al; + unsigned int sss=1U*1024*1024*64; + for(a=0;a<128;a++) { + al=malloc(sss); + if(al!=NULL) { + printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al); + } + else { + printf("Cannot alloc %d\n",(a+1)*sss); + perror("Cannot alloc"); + exit(1); + } + } +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/1770859 b/results/classifier/mode-gemma3:12b/user/1770859 new file mode 100644 index 00000000..6ea004bf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1770859 @@ -0,0 +1,5 @@ + + +qemu-img compare -m option is missing + +Comparing images using multiple streams (like qemu-img convert) maybe effectively sped up when one of the images (or both) is RBD. qemu-img convert does it's job perfectly while converting. Please implement the same for image comparison. Since operations are read-only, -W is useless, but may be introduced as well for debugging/performance purposes.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1771 b/results/classifier/mode-gemma3:12b/user/1771 new file mode 100644 index 00000000..c0539d6c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1771 @@ -0,0 +1,35 @@ + + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/mode-gemma3:12b/user/1772166 b/results/classifier/mode-gemma3:12b/user/1772166 new file mode 100644 index 00000000..bff3436c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1772166 @@ -0,0 +1,14 @@ + + +qemu 2.4.1: dereferencing pointer to incomplete type ‘struct ucontext’ + +Trying to compile qemu release 2.4.1 + +Getting compile error + +user-exec.c: In function ‘cpu_resume_from_signal’: +user-exec.c:72:37: error: dereferencing pointer to incomplete type ‘struct ucontext’ + sigprocmask(SIG_SETMASK, &uc->uc_sigmask, NULL); + ^~ +user-exec.c: In function ‘cpu_arm_signal_handler’: +user-exec.c:214:41: error: dereferencing pointer to incomplete type ‘struct ucontext’
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1773743 b/results/classifier/mode-gemma3:12b/user/1773743 new file mode 100644 index 00000000..ca2e748c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1773743 @@ -0,0 +1,23 @@ + + +qemu-user -g xxx -E LD_PROFILE=xxx segfault + +Here is two simple steps to reproduce the bug: + +$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls + +(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) + +In a other window launch: + +$ gdb +(gdb) target remote :12345 +(gdb) c + +At this point qemu will segfault. + +It seems this problem is appends when sigprof passed to gdb. +One way I have found to bypass this: +patch gdbstub.c gdb_handlesig and ignore sig if +sig == TARGET_SIGPROF +(which means now I can't catch sigprof on gdb anymore)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1774149 b/results/classifier/mode-gemma3:12b/user/1774149 new file mode 100644 index 00000000..c0a07c03 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1774149 @@ -0,0 +1,78 @@ + + +qemu-user x86_64 x86 gdb call function from gdb doesn't work + +While running qemu user x86_64 x86 with gdb server, calling functions are not working. + +Here is how to reproduce it: + +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +Could not fetch register "fs_base"; remote failure reply 'E14' + +In other cases we also got the error: +Could not fetch register "orig_rax"; remote failure reply 'E14' + +Here is how I patched it (it is only a workaround): + +diff --git a/gdbstub.c b/gdbstub.c +index 2a94030..5749efe 100644 +--- a/gdbstub.c ++++ b/gdbstub.c +@@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t *mem_buf, int reg) + return r->get_reg(env, mem_buf, reg - r->base_reg); + } + } ++#ifdef TARGET_X86_64 ++ return 8; ++#elif TARGET_I386 ++ return 4; ++#endif + return 0; + } + +(Our guess for this issue was, gdb is requesting for 'fake' registers to know register size) + +Once we patched that, we got another problem while calling functions from gdb: We could call functions, but only once. + +Here is how to reproduce it: +run in a terminal: +$ qemu-x86_64 -g 12345 -L / /bin/ls + +In another terminal run gdb: +(gdb) file /bin/ls +(gdb) target remote :12345 +(gdb) b _init +(gdb) c +(gdb) call malloc(1) +$1 = (void *) 0x620010 +(gdb) call malloc(1) +Cannot access memory at address 0x40007ffb8f + +Here is how we patched it to make it work: + +diff --git a/exec.c b/exec.c +index 03238a3..d303922 100644 +--- a/exec.c ++++ b/exec.c +@@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr, + if (!(flags & PAGE_VALID)) + return -1; + if (is_write) { +- if (!(flags & PAGE_WRITE)) ++ if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG))) + return -1; + /* XXX: this code should not depend on lock_user */ + if (!(p = lock_user(VERIFY_WRITE, addr, l, 0))) + +From what we saw, there is a page which is passed to read-only after first execution, and gdb need to write on that page to put a breakpoint. (on the stack) + +We suspect this is linked to this: +https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1774853 b/results/classifier/mode-gemma3:12b/user/1774853 new file mode 100644 index 00000000..2a8331e1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1774853 @@ -0,0 +1,9 @@ + + +claims temp file is used by another process + +QEMU emulator version 2.12.50 (v2.12.0-12378-g99a34dc4d2-dirty) + +"c:\Program Files\qemu\qemu-system-x86_64.exe" -net none -parallel none -bios OVMF.fd -L . -hda fat:rw:image +vvfat image chs 1024,16,63 +c:\Program Files\qemu\qemu-system-x86_64.exe: -hda fat:rw:image: Could not open 'C:\Users\tsiros\AppData\Local\Temp\qem5B92.tmp': The process cannot access the file because it is being used by another process.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1775366 b/results/classifier/mode-gemma3:12b/user/1775366 new file mode 100644 index 00000000..7589197f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1775366 @@ -0,0 +1,15 @@ + + + [Feature request] qemu-ga - Allow unexpected parameter + +It whould be nice if the qemu-ga allowed received messages to contain fields which is not part of the spec. In my example I have a host which sends the following request: + +{"execute":"guest-exec","arguments":{"path":"prl_nettool","capture-output":true,"execute-in-shell":false,"arg":[...]}} + +Right now this request is rejected with the following error: + +{"error": {"class": "GenericError", "desc": "Parameter 'execute-in-shell' is unexpected"}} + +My situation is the hosting provider I use does have some customized solution which sends some extra arguments. I have manually patched my qemu-ga so it accepts the "execute-in-shell" parameter but I don't think this should be necessary. + +Instead of "Error" it should just be a "warning" returned to the user of qemu-ga but the call should still be executed.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1776478 b/results/classifier/mode-gemma3:12b/user/1776478 new file mode 100644 index 00000000..312a59c7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1776478 @@ -0,0 +1,48 @@ + + +Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation + +Hey, +I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins. + +When running a compilation of DISTRHO-Ports we get: + +lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE +Makefile:62: recipe for target 'gen_lv2' failed +make[1]: *** [gen_lv2] Error 134 +make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports' +Makefile:104: recipe for target 'lv2' failed +make: *** [lv2] Error 2 + + +lv2_ttl_generator source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator + +The command that is ruining is +lv2_ttl_generator ./TAL-Filter-2.so + +And ./TAL-Filter-2.so source is here: +https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source + + + +Is there a way to debug what is going on? +This runs fine on a Raspberrypi which is armv7 + +A workaround would also help. + + +Bug in Zynthian: +https://github.com/zynthian/zynthian-sys/issues/59 +Bug in DISTRHO-Ports: +https://github.com/DISTRHO/DISTRHO-Ports/issues/29 + +Using qemu-arm-static version from master from two days ago: +qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7 + +Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3) + +Thanks, +Guy
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1776920 b/results/classifier/mode-gemma3:12b/user/1776920 new file mode 100644 index 00000000..bb98107e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1776920 @@ -0,0 +1,5 @@ + + +qemu-img convert on Mac OSX creates corrupt images + +An image created by qemu-img create, then modified by another program is converted to bad/corrupt image when using convert sub command on Mac OSX. The same convert works on Linux. The version of qemu-img is 2.12.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1777226 b/results/classifier/mode-gemma3:12b/user/1777226 new file mode 100644 index 00000000..3598e25f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1777226 @@ -0,0 +1,17 @@ + + +qemu-user warnings confuse userland applications + +I recently observed that warning messages emitted by qemu-user can confuse applications when reading from stdout/stderr. This was observed with the configure script of OpenJDK-11 on qemu-sh4: + +configure: Found potential Boot JDK using configure arguments +configure: Potential Boot JDK found at /usr/lib/jvm/java-10-openjdk-sh4 is incorrect JDK version (qemu: Unsupported syscall: 318); ignoring +configure: (Your Boot JDK version must be one of: 10 11) +configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK +configure exiting with result code 1 + +See: https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=sh4&ver=11%7E18-1&stamp=1529119043&raw=0 + +Commenting out the line of code which emits the warning fixes the problem for me and the configure script finishes without problems. + +Thus, qemu should be modified to avoid cluttering stdout or stderr with its own messages and rather send those warnings to a log file or similar.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1779 b/results/classifier/mode-gemma3:12b/user/1779 new file mode 100644 index 00000000..9a7948e1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1779 @@ -0,0 +1,32 @@ + + +PowerPC AltiVec source vector subnormal values are not flushed to zero +Description of problem: +AltiVec specifies that source and result vectors are flushed to zero (in NJ mode). Only result vectors are flushed to zero. +Steps to reproduce: +1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +See the offending Rust program: + +``` +#![feature(stdsimd, powerpc_target_feature)] + +use std::arch::powerpc::*; + +#[target_feature(enable = "altivec")] +unsafe fn add(x: f32, y: f32) -> f32 { + let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) }; + array[0] +} + +pub fn main() { + let result = unsafe { add(-1.0857398e-38, 0.) }; + assert_eq!(result, 0.); + + // if the input is flushed, the result will be +0 + // if only the output is flushed, the result is -0 + assert!(result.is_sign_positive()); +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/1779447 b/results/classifier/mode-gemma3:12b/user/1779447 new file mode 100644 index 00000000..6e152111 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1779447 @@ -0,0 +1,14 @@ + + +SLIRP SMB silently fails with MacOS smbd + +When using the -net user,id=net0,ipv6=off,smb=/path/to/share/option,hostfwd=tcp::19500-:22 I can successfully mount_smbfs the shared directory on the guest when QEMU is running on a Linux or FreeBSD host. However, on a MacOS host the mount_smbfs command just fails with +`mount_smbfs: unable to open connection: syserr = Connection reset by peer`. +After some debugging it turns out this is because the smbd shipped by macos is incompatible and doesn't use the same config file/command line arguments. + +I have since got it working by compiling the sources form samba.org and using the --smbd= configure option pointing to that binary. + +Would it be possible to print a warning message or even better abort the launch saying smbd is incompatible with QEMU if the -smb= flag is passed? It appears that smbd should die with an error code on invalid arguments so QEMU should be able to report that. + + +This was happening with QEMU built from git sources at c1c2a435905ae76b159c573b0c0d6f095b45ebc6.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1779955 b/results/classifier/mode-gemma3:12b/user/1779955 new file mode 100644 index 00000000..9900fb56 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1779955 @@ -0,0 +1,32 @@ + + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access + +When read() function takes an mmap'ed address as output buffer, it returns EFAULT. The expected behavior is it should just work. + +The following code works for qemu-system-arm, but not for qemu-arm-static. + + + +Steps to reproduce (please substitute /path/to/qemu-arm-static with the path of the binary, and /tmp/a.cpp with the example source code attached): + +# First register binfmt_misc +[hidden]$ docker run --rm --privileged multiarch/qemu-user-static:register --reset + +# Compile the code and run +[hidden]$ docker run --rm -it -v /tmp/a.cpp:/tmp/a.cpp -v /path/to/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/ubuntu:18.04 bash -c '{ apt update -y && apt install -y g++; } >& /dev/null && g++ -std=c++14 /tmp/a.cpp -o /tmp/a.out && echo hehe > /tmp/haha.txt && /tmp/a.out' +ofd=3 +ftruncate=0 +mmap=0xff3f5000 +fd=4 +0xff3f5023 -1 14 + + + +The expected result in qemu-system-arm as well as natively on x86_64 host: +hidden$ ./a.out +ofd=3 +ftruncate=0 +mmap=0xb6fb7000 +fd=4 +0xb6fb7023 5 0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1780 b/results/classifier/mode-gemma3:12b/user/1780 new file mode 100644 index 00000000..88eabbb7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1780 @@ -0,0 +1,19 @@ + + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/1781281 b/results/classifier/mode-gemma3:12b/user/1781281 new file mode 100644 index 00000000..3ec3bcc8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1781281 @@ -0,0 +1,30 @@ + + +qemu-ppc64le uncaught target signal 4 (Illegal instruction) + +qemu-ppc64le version 2.12.0 +host machine: x86_64 Arch Linux + +I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. +0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +#1 0x000055555567ee68 in ?? () +#2 0x000055555567fd18 in ?? () +#3 0x00005555556805ef in process_pending_signals () +#4 0x0000555555661e69 in cpu_loop () +#5 0x000055555561fd72 in main () + +This can be reproduced by downloading this patch (patchset 1): + +https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 + +and running + +qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" + +I don't observe any issues when running the code on a POWER9 machine.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1782107 b/results/classifier/mode-gemma3:12b/user/1782107 new file mode 100644 index 00000000..e1141d37 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1782107 @@ -0,0 +1,13 @@ + + +Random errors when emulating armv7 and using dh + +Howdy, +I'm encountering random errors when using qemu to cross-package my project using dh. In previous iterations of my project it would only fail once every two attempts. Now it fails every time. + +Example error included. + + + +If you'd like to try and replicate this error, a version of my project is publicly available with simple instructions on how to package it (using qemu) here: +https://github.com/Nadav-Ruskin/configsite
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1783362 b/results/classifier/mode-gemma3:12b/user/1783362 new file mode 100644 index 00000000..fcacac3d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1783362 @@ -0,0 +1,49 @@ + + +qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 + +As shown in https://github.com/beehive-lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host executing a ELF 64-bit LSB executable, ARM aarch64 binary. + +Steps to reproduce the bug: + +- (cross-)compile the attached source file: + +$ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c -o mmap_qemu + +- Execute in a x86_64 host with qemu-user and qemu-user-binfmt: + +$ ./mmap_qemu +alloc: 0 +MAP_FAILED: -1 +errno: 0 +mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +- Execute in a ARM host without any additional dependecy: + +$ ./mmap_qemu +alloc: -1 +MAP_FAILED: -1 +errno: 22 + +The bug is present in Fedora: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.17.7-200.fc28.x86_64 + +And also in Ubuntu: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.15.0-23-generic + +Possibly related to: + +- https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html +- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1783437 b/results/classifier/mode-gemma3:12b/user/1783437 new file mode 100644 index 00000000..e66f39a6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1783437 @@ -0,0 +1,11 @@ + + +read-modify-write page faults error code has write bit unset + +Consider the attached C file, which does a read-modify-write of the form `add [mem], reg`, where `mem` points to a non-present page. In the resulting page fault, the W/R bit is not set, while real hardware does set this bit. + +% gcc -m32 qemu-bug1.c&& ./a.out && qemu-i386 ./a.out +page fault: addr=0x70000000 err=0x6 +page fault: addr=0x70000000 err=0x4 + +Tested on the qemu-3.0.0-rc1 release.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1785203 b/results/classifier/mode-gemma3:12b/user/1785203 new file mode 100644 index 00000000..91550c89 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1785203 @@ -0,0 +1,45 @@ + + +accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. + +qemu-riscv64 version 2.12.93 crashes when mincore() is called with invalid pointer with the following message: + +qemu-riscv64: /opt/qemu/accel/tcg/translate-all.c:2511: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600014ef + +Testcase: + +#include <sys/mman.h> + +int main (void) +{ + unsigned char v; + return mincore ((void *) 0x00000010000000000, 1, &v); +} + +Backtrace: + +#0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 +#1 0x000000006000140a in abort () at abort.c:79 +#2 0x00000000600012ec in __assert_fail_base ( + fmt=0x6024eae8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", + file=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=2511, + function=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") at assert.c:92 +#3 0x000000006010e10e in __assert_fail ( + assertion=assertion@entry=0x601b9758 "start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)", file=file@entry=0x601b9658 "/opt/qemu/accel/tcg/translate-all.c", line=line@entry=2511, + function=function@entry=0x601b9810 <__PRETTY_FUNCTION__.23867> "page_check_range") + at assert.c:101 +#4 0x000000006003e916 in page_check_range (start=start@entry=1099511627776, len=len@entry=1, + flags=flags@entry=1) at /opt/qemu/accel/tcg/translate-all.c:2511 +#5 0x0000000060057717 in access_ok (size=1, addr=1099511627776, type=0) + at /opt/qemu/linux-user/qemu.h:567 +#6 lock_user (copy=0, len=1, guest_addr=1099511627776, type=0) + at /opt/qemu/linux-user/qemu.h:567 +#7 do_syscall (cpu_env=cpu_env@entry=0x622fca28, num=232, arg1=1099511627776, arg2=1, + arg3=274886298751, arg4=0, arg5=274886298808, arg6=66518, arg7=0, arg8=0) + at /opt/qemu/linux-user/syscall.c:11635 +#8 0x0000000060066c5c in cpu_loop (env=env@entry=0x622fca28) + at /opt/qemu/linux-user/riscv/cpu_loop.c:55 +#9 0x0000000060002156 in main (argc=<optimized out>, argv=0x7fffffffed68, + envp=<optimized out>) at /opt/qemu/linux-user/main.c:819
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1788 b/results/classifier/mode-gemma3:12b/user/1788 new file mode 100644 index 00000000..6b390ea7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1788 @@ -0,0 +1,31 @@ + + +Floating point rounding fails on mps3-an547 amd cortex-m55 while using LLVM-embedded-toolchain-for-Arm and Picolibic. +Description of problem: +Rounding of long double gives unexpected result. Simple code as example: +``` +#include <math.h> +int main(void) +{ + long double value = -8.5L; + long rounded_value = lrintl(value); + if( -8 == rounded_value ) + { + return 0; + } + return 1; +} +``` +Steps to reproduce: +1. Checkout project: [LLVM-embedded-toolchain-for-ARM](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm) +2. Configure it with option -DLLVM_TOOLCHAIN_LIBRARY_VARIANTS=armv8.1m.main_hard_nofp_mve +3. Build project +4. Run Picolbic tests with ninja picolibc_armv8.1m.main_hard_nofp_mve-test + +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. +Additional information: +As a result long_double test fails with incorrect rounding. +Last qemu version which successfully execute mentioned test is: qemu 7.0.0 downloaded via [qemu-7.0.0](https://download.qemu.org/qemu-7.0.0.tar.bz2). +Issue is present since qemu version 7.1. diff --git a/results/classifier/mode-gemma3:12b/user/1790260 b/results/classifier/mode-gemma3:12b/user/1790260 new file mode 100644 index 00000000..0ea48201 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1790260 @@ -0,0 +1,13 @@ + + +binfmt support not working for x86 host and x86_64 guest + +this is a problem in the qemu-binfmt-conf.sh script and maybe somewhere else. the version i checked is the current github mirror https://github.com/qemu/qemu/blob/master/scripts/qemu-binfmt-conf.sh + +i am running linux mint 19 32bit on a 32bit x86 cpu and i want to run some applications that are only available as x86_64 packages. i use multiarch and qemu and it works for simple applications like cacafire. however i want to run the application natively from the shell without having to use qemu-x86_64 <path>. i also installed the binfmt-support package. when i run update-binfmts --display then an extry for x86_64 is missing and transparent execution is not working. + +the problem seems to be in the qemu-binfmt-conf.sh script. it disables the creation of entries for cpus of the same family. this is not a problem if you are using a 64bit cpu because 32bit binaries run on it natively but it doesnt work in the opposite way. hacking line 310 to + + if [ "$cpu" = "x86_64" ] || [ "$host_family" != "$family" ] ; then + +and running it with the --systemd ALL parameter causes a x86_64 config file to be created. it still doesnt work but that might have different causes.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1791763 b/results/classifier/mode-gemma3:12b/user/1791763 new file mode 100644 index 00000000..34344eae --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1791763 @@ -0,0 +1,15 @@ + + +broken signal handling in nios2 user-mode emulation + +This bug is against the 3.0 release. + +It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. + +Some problems I've identified and tried to fix with the attached patch are: + +- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. + +- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. + +With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1793119 b/results/classifier/mode-gemma3:12b/user/1793119 new file mode 100644 index 00000000..4f318af0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1793119 @@ -0,0 +1,31 @@ + + +Wrong floating-point emulation on AArch64 with FPCR set to zero + +On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). + +I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`. + +Output on real hardware: +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` equals `q`. + +Output on qemu 3.0.0 (Linux user-mode emulation): +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` is not equal to `q`. + +Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv". + +Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1793539 b/results/classifier/mode-gemma3:12b/user/1793539 new file mode 100644 index 00000000..f308eebf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1793539 @@ -0,0 +1,11 @@ + + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 + +During the build of gedit for RISC-V this error occurs: + +$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4 + +https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1793608 b/results/classifier/mode-gemma3:12b/user/1793608 new file mode 100644 index 00000000..046522a1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1793608 @@ -0,0 +1,18 @@ + + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1794086 b/results/classifier/mode-gemma3:12b/user/1794086 new file mode 100644 index 00000000..0d96f759 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1794086 @@ -0,0 +1,49 @@ + + +readlink(2) returns incorrect size for /proc/self/exe + +readlink(2) seems to ignore the size of supplied buffer for the resolved name and always returns the actual size of the resolved name instead. + +Steps to reproduce: + +```bash +echo '#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, const char** argv) +{ + if(argc < 2) exit(1); + char buf[1]; + printf("%d\n", readlink(argv[1], buf, sizeof(buf))); +}' >test.c + +# I used GCC mipsel cross-compiler to reproduce this bug +mipsel-linux-gnu-gcc-5.5 test.c -o a.out + +echo "PWD: `pwd`" +qemu-mipsel ./a.out /proc/self/exe +``` + +Expected output (observed when running a.out natively on Linux 4.17 amd64): +``` +PWD: /tmp/test +1 +``` + +Output observed when running with qemu-mipsel 2.1.2: +``` +PWD: /tmp/test +15 +``` + +According to POSIX description of readlink [1], the function shall return the number of bytes written to the supplied buffer, which obviously cannot exceed size of the buffer. + +Note that the bug is only reproduced with links within /proc filesystem; links to the regular files within /home are resolved normally. + +The bug is present in qemu-mipsel 2.1.2: + +# qemu-mipsel -version +qemu-mipsel version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) 2003-2008 Fabrice Bellard + +[1]: http://pubs.opengroup.org/onlinepubs/009695399/functions/readlink.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1796 b/results/classifier/mode-gemma3:12b/user/1796 new file mode 100644 index 00000000..6246361d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1796 @@ -0,0 +1,18 @@ + + +qemu-img does not accept backing image file path, only file name +Description of problem: +In `qemu-img create ... -b <backing_image> ... <snapshot_image>`, <backing_image> cannot be a file path, but must be a file name. <backing_image> and <snapshot_image> are forced to be in the same directory for the command to work. +Steps to reproduce: +``` +$ mkdir test +$ qemu-img create -f qcow2 test/a.img 1G +... +$ qemu-img create -f qcow2 -b test/a.img -F qcow2 test/a.img.snap +qemu-img: test/a.img.snap: Could not open 'test/test/a.img': No such file or directory +Could not open backing image. +$ qemu-img create -f qcow2 -b a.img -F qcow2 test/a.img.snap +... +$ ls test +a.img a.img.snap +``` diff --git a/results/classifier/mode-gemma3:12b/user/1796754 b/results/classifier/mode-gemma3:12b/user/1796754 new file mode 100644 index 00000000..39e83388 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1796754 @@ -0,0 +1,19 @@ + + +ioctl SIOCGIFCONF causes qemu-aarch64-static to crash with "received signal outside vCPU context" + +To reproduce it, compile the attached crash.c under aarch64 to a.out and execute on x86_64 +qemu-aarch64-static ./a.out + +It will print the following and crash: + +socket=3 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60038cd6 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6000157a + +The version of qemu-aarch64-static is + +qemu-aarch64 version 3.0.0 (qemu-3.0.0-1.fc29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +But it did also happen in previous versions so it is not a regression but a bug existed ever since.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1800156 b/results/classifier/mode-gemma3:12b/user/1800156 new file mode 100644 index 00000000..9675bb86 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1800156 @@ -0,0 +1,7 @@ + + +windows 8.1 loose grab/leave window on windowed + +Hello, i am new to QEMU and i encounter that annoying issue (windowed) when i move the mouse a bit too much then it leave the window. + +Windows 8.1, Latest QEMU (Windows binaries).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1802915 b/results/classifier/mode-gemma3:12b/user/1802915 new file mode 100644 index 00000000..14e0336e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1802915 @@ -0,0 +1,9 @@ + + +GTK display refresh rate is throttled + +Guest OS running with GL enabled GTK display shows a reduced refresh rate, e.g. moving cursor around with iGVT-g DMA Buf. + +It seems that a default refresh interval GUI_REFRESH_INTERVAL_DEFAULT (30ms) is defined in include/ui/console.h, throttling the display refresh rate at 33Hz. + +To correct this throttle issue, a shorter interval should be applied to display change listener or the default value should be used.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1805913 b/results/classifier/mode-gemma3:12b/user/1805913 new file mode 100644 index 00000000..f388be8e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1805913 @@ -0,0 +1,23 @@ + + +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/mode-gemma3:12b/user/1807 b/results/classifier/mode-gemma3:12b/user/1807 new file mode 100644 index 00000000..1d1f545a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1807 @@ -0,0 +1,26 @@ + + +sparc64 always segfaults doesn't work on Ubuntu 23.04 +Description of problem: +It segfaults when it tries to use 'printf' or 'puts' to print to the screen. +Steps to reproduce: +Do the following at the command line + +``` +$ sparc64-linux-gnu-g++ --version +sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp +$ sparc64-linux-gnu-g++ -o test test.cpp -static +$ qemu-sparc64-static --version +qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2) +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +$ qemu-sparc64-static ./test +Segmentation fault (core dumped) +$ qemu-sparc-static ./test +qemu-sparc-static: ./test: Invalid ELF image for this architecture +$ qemu-sparc32plus-static ./test +qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture +``` diff --git a/results/classifier/mode-gemma3:12b/user/1808563 b/results/classifier/mode-gemma3:12b/user/1808563 new file mode 100644 index 00000000..8f299b33 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1808563 @@ -0,0 +1,19 @@ + + +Listing the contents of / lists QEMU_LD_PREFIX instead + +Seeing this in qemu-user version 3.1.0 + +Demo: +$ QEMU_LD_PREFIX=$(pwd)/usr/armv7a-cros-linux-gnueabi ../run/qemu-arm /tmp/coreutils --coreutils-prog=ls / +etc lib usr +$ ls / +boot etc lib lib64 lost+found mnt root sbin sys usr +bin dev export home lib32 net proc run tmp var +$ ls usr/armv7a-cros-linux-gnueabi +etc lib usr + +In strace, the openat for "/" is remapped to the directory specified in QEMU_LD_PREFIX: +[pid 5302] openat(AT_FDCWD, "/tmp/qemu/usr/armv7a-cros-linux-gnueabi", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 + +As an aside, if I change the code to do chdir("/"); opendir("."); it works fine.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1808565 b/results/classifier/mode-gemma3:12b/user/1808565 new file mode 100644 index 00000000..26a7a7b3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1808565 @@ -0,0 +1,9 @@ + + +Reading /proc/self/task/<pid>/maps is not remapped to the target + +Seeing this in qemu-user 3.1.0 + +The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly. + +These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1809304 b/results/classifier/mode-gemma3:12b/user/1809304 new file mode 100644 index 00000000..678988ac --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1809304 @@ -0,0 +1,19 @@ + + +qemu-img convert is freezing for some DMG files. + +Recently, I created a file using hdiutil from MacOS (using Zlib compression): + +$ hdiutil create -volname MyVolName -srcfolder /path/to/my/vol/ -ov -format UDZO myvolname.dmg + +But, when I try to convert this volume using qemu-img convert, this command is freezing. + +I'm using the upstream version to test it. + +It is freezing inside the binary search method to retrieve the chunk. + +But, I still don't know why. + +I'm attaching the file as an example. + +It can be mounted using MacOS or other Linux apps like hfsleuth and darling-dmg.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1810343 b/results/classifier/mode-gemma3:12b/user/1810343 new file mode 100644 index 00000000..cdb9fd68 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1810343 @@ -0,0 +1,14 @@ + + +qemu-nbd -l and -s options don't work together + +When using qemu-nbd with -l to load a snapshot along with -s to create new active layer the tool fails to find the snapshot specified on the command line: + +For example the following does not work: + sudo qemu-nbd -s --load-snapshot=files --connect /dev/nbd0 rootfs.qcow2 + Failed to load snapshot: Can't find snapshot + +However, the following option works + sudo qemu-nbd -s --connect /dev/nbd0 rootfs.qcow2 +and so does + sudo qemu-nbd --load-snapshot=files --connect /dev/nbd0 rootfs.qcow2
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1810433 b/results/classifier/mode-gemma3:12b/user/1810433 new file mode 100644 index 00000000..7c763ce1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1810433 @@ -0,0 +1,49 @@ + + +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/mode-gemma3:12b/user/1811711 b/results/classifier/mode-gemma3:12b/user/1811711 new file mode 100644 index 00000000..1cf92701 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1811711 @@ -0,0 +1,73 @@ + + +qemu-img can not convert virtualbox virtual disk formats qcow + +Hello, I'm working with QEMU on macOS, and am experiencing issues working with the `qemu-img` command. + +Info +---- +$ sw_vers +ProductName: Mac OS X +ProductVersion: 10.13.6 +BuildVersion: 17G4015 + +VirtualBox +---------- +$ VBoxManage --version +6.0.0r127566 + +$ qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +$ qemu-img --version +qemu-img version 3.1.50 (v3.1.0-rc2-745-g147923b1a9-dirty) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers + +Steps to reproduce +------------------ + +> Prereq VirtualBox needs to be installed to run the `VBoxManage` command + +$ VBoxManage createmedium disk --filename vbox-vdisk-exp.qcow --format qcow --size 5 +0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% +Medium created. UUID: e2b36955-3791-4c0e-93d4-913669b1d9fb + +$ file vbox-vdisk-exp.qcow +vbox-vdisk-exp.qcow: QEMU QCOW Image (v1), 5242880 bytes + +$ qemu-img info vbox-vdisk-exp.qcow +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +# Convert vbox virtualdisk to qcow2 format using `qemu-img` +$ qemu-img convert -f qcow vbox-vdisk-exp.qcow -O qcow2 vbox-vdisk-exp-convert.qcow2 + +$ file vbox-vdisk-exp-convert.qcow2 +vbox-vdisk-exp-convert.qcow2: QEMU QCOW Image (v3), 5242880 bytes + +# Print info about qemu-img converted image from vbox created qcow image +$ qemu-img info vbox-vdisk-exp-convert.qcow2 mutts-6 | 0 < 10:53:00 +image: vbox-vdisk-exp-convert.qcow2 +file format: qcow2 +virtual size: 5.0M (5242880 bytes) +disk size: 196K +cluster_size: 65536 +Format specific information: + compat: 1.1 + lazy refcounts: false + refcount bits: 16 + corrupt: false + +# Print info about vbox created qcow image +qemu-img info vbox-vdisk-exp.qcow mutts-6 | 0 < 10:53:19 +image: vbox-vdisk-exp.qcow +file format: qcow +virtual size: 5.0M (5242880 bytes) +disk size: 8.0K +cluster_size: 4096 + +I've attached a zip file containing the vbox created qcow image along with the image that `qemu-img` converted.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1811916 b/results/classifier/mode-gemma3:12b/user/1811916 new file mode 100644 index 00000000..d670437c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1811916 @@ -0,0 +1,5 @@ + + +SDL2 interface didn't follow the current X11 keyboard layout for hotkeys + +My X11 was configured to use Dvorak keyboard layout, with setxkbmap(1). Despite the window title said 'Press Ctrl-Alt-G to exit grab' after it grabbed the mouse, pressing this hotkey don't have any effects, and I has to switch to a virtual terminal to kill(1) that qemu process. By debugging the program I found it is using the raw key code to handle the key events, so I must use CTRL-ALT-I to exit the grab, in my keyboard.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1812 b/results/classifier/mode-gemma3:12b/user/1812 new file mode 100644 index 00000000..325abc9b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1812 @@ -0,0 +1,27 @@ + + +older programs running under qemu-aarch64 segfaults +Description of problem: +Numerous aarch64 programs segfaults when run under qemu-aarch64. +Steps to reproduce: +1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup): +``` +debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian +or +debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/ +``` +2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/ +3. chroot /tmp/jessie-arm64/ +4. ./qemu-aarch64 /bin/ls +``` +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +``` +Additional information: +Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 . My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange. + +Not all programs segfaults. dash works, ls or bash does not. + +A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information. To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed. + +Reverting the mentioned commit makes everything work again. diff --git a/results/classifier/mode-gemma3:12b/user/1812861 b/results/classifier/mode-gemma3:12b/user/1812861 new file mode 100644 index 00000000..bf2a4184 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1812861 @@ -0,0 +1,24 @@ + + +QEMU in user-mode emulation mode crashes when the user program jumps to an invalid address + +Running this code: + +void (*func)() = 0x12345678; + +int main() +{ + func(); + return 0; +} + +Produces the following output: + +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed. +Segmentation fault + +The expected result is as follows: + +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1813307 b/results/classifier/mode-gemma3:12b/user/1813307 new file mode 100644 index 00000000..c1e6f670 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1813307 @@ -0,0 +1,23 @@ + + +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/mode-gemma3:12b/user/1813398 b/results/classifier/mode-gemma3:12b/user/1813398 new file mode 100644 index 00000000..651fb258 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1813398 @@ -0,0 +1,43 @@ + + +qemu user calls malloc after fork in multi-threaded process + +qemu user may hang in malloc on a musl based system because +it calls malloc after fork (in a pthread_atfork handler) +in the child process. + +this is undefined behaviour since the parent process is +multi-threaded and only as-safe functions may be called +in the child then. (if malloc/free is called concurrently +with fork the malloc state will be corrupted in the child, +it works on glibc because glibc takes the malloc locks +before the fork syscall, but that breaks the as-safety of +fork and thus non-conforming to posix) + +discussed at +https://www.openwall.com/lists/musl/2019/01/26/1 + +the bug is hard to reproduce (requires the call_rcu thread +to call free concurrently with do_fork in the main thread), +this one is observed with qemu-arm 3.1.0 running on x86_64 +executing an arm busybox sh: + +(gdb) bt +#0 malloc (n=<optimized out>, n@entry=9) at src/malloc/malloc.c:306 +#1 0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@entry=9) at gmem.c:99 +#2 0x000000006018bcab in g_strdup (str=<optimized out>, str@entry=0x60200abf "call_rcu") at gstrfuncs.c:363 +#3 0x000000006016e31d in qemu_thread_create (thread=thread@entry=0x7ffe367d1870, name=name@entry=0x60200abf "call_rcu", + start_routine=start_routine@entry=0x60174c00 <call_rcu_thread>, arg=arg@entry=0x0, mode=mode@entry=1) + at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526 +#4 0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327 +#5 0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26 +#6 0x00000000601be8db in fork () at src/process/fork.c:33 +#7 0x000000006009d191 in do_fork (env=0x627aaed0, flags=flags@entry=17, newsp=newsp@entry=0, parent_tidptr=parent_tidptr@entry=0, + newtls=newtls@entry=0, child_tidptr=child_tidptr@entry=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:5528 +#8 0x00000000600af894 in do_syscall1 (cpu_env=cpu_env@entry=0x627aaed0, num=num@entry=2, arg1=arg1@entry=0, arg2=arg2@entry=-8700192, + arg3=<optimized out>, arg4=8, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:7042 +#9 0x00000000600a835c in do_syscall (cpu_env=cpu_env@entry=0x627aaed0, num=2, arg1=0, arg2=-8700192, arg3=<optimized out>, + arg4=<optimized out>, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:11533 +#10 0x00000000600c265f in cpu_loop (env=env@entry=0x627aaed0) at /home/pmos/build/src/qemu-3.1.0/linux-user/arm/cpu_loop.c:360 +#11 0x00000000600417a2 in main (argc=<optimized out>, argv=0x7ffe367d57b8, envp=<optimized out>) + at /home/pmos/build/src/qemu-3.1.0/linux-user/main.c:819
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1813406 b/results/classifier/mode-gemma3:12b/user/1813406 new file mode 100644 index 00000000..5fbf245a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1813406 @@ -0,0 +1,9 @@ + + +qemu-img convert malfunction on macOS + +On macOS 10.13.6, `qemu-img convert` failed to convert a qcow2 into a new qcow2 (for the purpose of shrinking the image). + +A 50GB (3.7GB allocated) qcow2 image was used as source. The qemu-img convert output was a 3.4MB file. + +qemu-img from HomeBrew were tested. Both 2.11.1 and 3.1.0_1 failed to convert a qcow2 image.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1814352 b/results/classifier/mode-gemma3:12b/user/1814352 new file mode 100644 index 00000000..2346af8a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1814352 @@ -0,0 +1,25 @@ + + +SIOCGIFNAME takes a struct ifreq not an integer + +The ioctl SIOCGIFNAME takes a pointer to a struct ifreq, not an integer. This leads to if_indextoname() not correctly returning interface names (well, not if they're longer than 4 characters including the trailing NULL ;-). + +This is observed on v3.1.0. + +The following one-line patch will be sent to the qemu-devel mailing list: + +""" +diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h +index ae8951625f..37501f575c 100644 +--- a/linux-user/ioctls.h ++++ b/linux-user/ioctls.h +@@ -178,7 +178,7 @@ + #endif /* CONFIG_USBFS */ + + IOCTL(SIOCATMARK, IOC_R, MK_PTR(TYPE_INT)) +- IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(TYPE_INT)) ++ IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_int_ifreq))) + IOCTL(SIOCGIFFLAGS, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) + IOCTL(SIOCSIFFLAGS, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) + IOCTL(SIOCGIFADDR, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_sockaddr_ifreq))) +"""
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1814381 b/results/classifier/mode-gemma3:12b/user/1814381 new file mode 100644 index 00000000..0512cebf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1814381 @@ -0,0 +1,27 @@ + + +qemu can't resolve ::1 when no network is available + +I'm not sure if this is a qemu thing or a getaddrinfo/glibc thing, or +even just something about my laptop. However we have a test failure +in nbdkit which only occurs when my laptop is not connected to wifi or +other networking. It boils down to: + + $ qemu-img info --image-opts "file.driver=nbd,file.host=::1,file.port=1234" + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': addre +ss resolution failed for ::1:1234: Address family for hostname not supported + +In a successful case it should connect to a local NBD server on port +1234, but if you don't have that you will see: + + qemu-img: Could not open 'file.driver=nbd,file.host=::1,file.port=1234': Faile +d to connect socket: Connection refused + +I can ‘ping6 ::1’ fine. + +It also works if I replace ‘::1’ with ‘localhost6’. + +My /etc/hosts contains: + +127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 +::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1815024 b/results/classifier/mode-gemma3:12b/user/1815024 new file mode 100644 index 00000000..1e49af93 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1815024 @@ -0,0 +1,17 @@ + + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1815423 b/results/classifier/mode-gemma3:12b/user/1815423 new file mode 100644 index 00000000..258a5496 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1815423 @@ -0,0 +1,66 @@ + + +x86_64 TCG: Incorrect floating point cast to int. + +I used exaample from: +https://stackoverflow.com/questions/3986795/what-is-the-result-of-casting-float-inf-inf-and-nan-to-integer-in-c + +#include <stdio.h> +#include <math.h> + +int main(int argc, char** argv) { + float a = INFINITY; + float b = -INFINITY; + float c = NAN; + + printf("float %f %f %f\n", a, b, c); + printf("int %d %d %d\n", (int) a, (int) b, (int) c); + printf("uint %u %u %u\n", (unsigned int) a, (unsigned int) b, (unsigned int) c); + printf("lint %ld %ld %ld\n", (long int) a, (long int) b, (long int) b); + printf("luint %lu %lu %lu\n", (unsigned long int) a, (unsigned long int) b, (unsigned long int) c); + + return 0; +} + +And got different results on real computer and on qemu. + +output from real HW is the same as on stackoverflow: + +$ gcc test.c && ./a.out +float inf -inf nan +int -2147483648 -2147483648 -2147483648 +uint 0 0 0 +lint -9223372036854775808 -9223372036854775808 -9223372036854775808 +luint 0 9223372036854775808 9223372036854775808 + + +But on qemu I got another results: + +float inf -inf nan +int 2147483647 -2147483648 2147483647 +uint 4294967295 0 4294967295 +lint 9223372036854775807 -9223372036854775808 -9223372036854775808 +luint 18446744073709551615 9223372036854775808 9223372036854775807 + +qemu launch string: +/qemu-system-x86_64 -m 1024 -cpu core2duo -serial stdio -netdev user,id=network0 -device e1000,netdev=network0 -kernel my_kernel + + +qemu version: +x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 3.1.50 (v3.1.0-1676-ge47f81b617-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + + +This bug affect some javascript (surprise) calculations: + +var conversion = "01234567890"; +var x; +var result = conversion[x & 42]; +console.log(result) + + +In example, var x is "undefined" +and when do calculation "x & 42" on js we should get 0 (it is documented feature), but actually got "42" + +and "result" sould be "0" but actually we got "undefined"
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1817239 b/results/classifier/mode-gemma3:12b/user/1817239 new file mode 100644 index 00000000..f79202bb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1817239 @@ -0,0 +1,52 @@ + + +add '--targets' option to qemu-binfmt-conf.sh + +I'd like to ask for the addition of option '--targets' to scripts/qemu-binfmt-conf.sh, in order to allow registering the interpreters for the given list of architectures only, instead of using all of the ones defined in qemu_target_list. The following is a possible patch that implements it: + + qemu-binfmt-conf.sh | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/qemu-binfmt-conf.sh b/qemu-binfmt-conf.sh +index b5a1674..be4a19b 100644 +--- a/qemu-binfmt-conf.sh ++++ b/qemu-binfmt-conf.sh +@@ -170,6 +170,7 @@ usage() { + Usage: qemu-binfmt-conf.sh [--qemu-path PATH][--debian][--systemd CPU] + [--help][--credential yes|no][--exportdir PATH] + [--persistent yes|no][--qemu-suffix SUFFIX] ++ [--targets TARGETS] + + Configure binfmt_misc to use qemu interpreter + +@@ -189,6 +190,8 @@ Usage: qemu-binfmt-conf.sh [--qemu-path PATH][--debian][--systemd CPU] + --persistent: if yes, the interpreter is loaded when binfmt is + configured and remains in memory. All future uses + are cloned from the open file. ++ --targets: comma-separated list of targets. If provided, only ++ the targets in the list are registered. + + To import templates with update-binfmts, use : + +@@ -324,7 +327,7 @@ CREDENTIAL=no + PERSISTENT=no + QEMU_SUFFIX="" + +-options=$(getopt -o ds:Q:S:e:hc:p: -l debian,systemd:,qemu-path:,qemu-suffix:,exportdir:,help,credential:,persistent: -- "$@") ++options=$(getopt -o ds:Q:S:e:hc:p:t: -l debian,systemd:,qemu-path:,qemu-suffix:,exportdir:,help,credential:,persistent:,targets: -- "$@") + eval set -- "$options" + + while true ; do +@@ -380,6 +383,10 @@ while true ; do + shift + PERSISTENT="$1" + ;; ++ -t|--targets) ++ shift ++ qemu_target_list="$(echo "$1" | tr ',' ' ')" ++ ;; + *) + break + ;; +-- +2.20.1
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1818075 b/results/classifier/mode-gemma3:12b/user/1818075 new file mode 100644 index 00000000..e7d85554 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1818075 @@ -0,0 +1,55 @@ + + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1818483 b/results/classifier/mode-gemma3:12b/user/1818483 new file mode 100644 index 00000000..c1557a4b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1818483 @@ -0,0 +1,44 @@ + + +qemu user mode does not support binfmt_misc config with flags include "P" + +Hi Sir: +During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name. +For example in test module "Devscripts" +the test item for broken tarball expected the warning info: +<tar: This does not look like a tar archive +tar: ******* > +but the output was: +</bin/tar: This does not look like a tar archive +/bin/tar: ******> +the cause is the config file of binfmt_misc was set not to send argv0, for example: +type command "tar" after chroot: +========================== +lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot . +[sudo] password for lpeng: +root@lpeng-VirtualBox:/# tar +/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options +Try '/bin/tar --help' or '/bin/tar --usage' for more information. +root@lpeng-VirtualBox:/# +=========================== + +by adding output log in main()@qemu/Linux-user/main.c +we found the original input command was changed, and qemu do not know that, we got the input args: +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----NULL--- + +Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu. +But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]" + + +After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command +argv_0----/usr/bin/qemu-mips64el-static--- +argv_1----/bin/tar--- +argv_2----tar--- + +We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it? +looking forward your suggestions. + +Thanks +luyou
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1820686 b/results/classifier/mode-gemma3:12b/user/1820686 new file mode 100644 index 00000000..4f823b4f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1820686 @@ -0,0 +1,7 @@ + + +risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' + +QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. + +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1821006 b/results/classifier/mode-gemma3:12b/user/1821006 new file mode 100644 index 00000000..efc5a4b7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1821006 @@ -0,0 +1,37 @@ + + +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/mode-gemma3:12b/user/1821430 b/results/classifier/mode-gemma3:12b/user/1821430 new file mode 100644 index 00000000..2c5b933e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1821430 @@ -0,0 +1,34 @@ + + +qemu-user-arm (4.0.0-rc0) crashes + +I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. +qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: + +first case (sadly I don't have more data handy, can reproduce at a later time if needed): +(gdb) x/i $pc +=> 0xfffce314: vseleq.f64 d0, d17, d0 + +second case (llvm-config): +qemu cmdline: +qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode + +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +output from gdb(arm) attached to qemu-user-arm +Program received signal SIGILL, Illegal instruction. +0xf9f77f80 in ?? () +(gdb) bt +#0 0xf9f77f80 in ?? () +#1 0xfffd796c in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) x/i $pc +=> 0xf9f77f80: vrintm.f64 d18, d18 + + +The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) +work flawlessly. + +This is clearly a regression. +Please fix before releasing 4.0.0.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1821444 b/results/classifier/mode-gemma3:12b/user/1821444 new file mode 100644 index 00000000..f399bef5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1821444 @@ -0,0 +1,31 @@ + + +qemu-ppc (user) incorrectly translates float32 arithmetics + +I'm using qemu-3.1.0 (Gentoo). + +When I was running regression test suite via qemu-ppc for GHC I noticed a few uint32_t<->float32 failures I did not expect to encounter. + +Here is an example + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + printf("0x1 = %e\n", *(volatile float*)&i); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && ./a +0x1 = 2.802597e-45 + +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/ +a 100% 826KB 102.0KB/s 00:08 + +$ ssh timberdoodle.ppc64.dev.gentoo.org ./a +0x1 = 1.401298e-45 +$ qemu-ppc ./a +0x1 = 2.802597e-45 + +Looks like off-by-one bit somewhere. I'm not sure if it's FPU instruction or some internals of printf() that are emulated incorrectly.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1821515 b/results/classifier/mode-gemma3:12b/user/1821515 new file mode 100644 index 00000000..1b025492 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1821515 @@ -0,0 +1,40 @@ + + +qemu-ppc (user) incorrectly converts float(nan)->double(non-nan) + +Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs. +Here is the minimal reproducer: + +```c +// cat a.c +#include <stdio.h> +#include <math.h> +#include <stdint.h> + +int main() { + volatile float f1 = NAN; + volatile float f2 = NAN; + printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n", + f1, *(volatile uint32_t*)&f1, + f2, *(volatile uint32_t*)&f2, + (f1 >= f2) ? "True" + : "False"); + volatile double d = f1; + printf ("d (%e, %#llx)\n", + d, *(volatile uint64_t*)&d); +} +``` + +``` +# incorrect execution: +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a +f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True +d (5.104236e+38, 0x47f8000000000000) + +# correct execution +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/; ssh timberdoodle.ppc64.dev.gentoo.org ./a +f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False +d (nan, 0x7ff8000000000000) +``` + +Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1824 b/results/classifier/mode-gemma3:12b/user/1824 new file mode 100644 index 00000000..cc9c3213 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1824 @@ -0,0 +1,3 @@ + + +[8.x] qemu-user does not build under CentOS 7 any longer diff --git a/results/classifier/mode-gemma3:12b/user/1825452 b/results/classifier/mode-gemma3:12b/user/1825452 new file mode 100644 index 00000000..e26e6ef3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1825452 @@ -0,0 +1,27 @@ + + +Pulse audio backend doesn't work in v4.0.0-rc4 release + +Using Gentoo linux, build from source: qemu v4.0.0-rc4 release (eeba63fc7fface36f438bcbc0d3b02e7dcb59983) + +Pulse audio backend doesn't initialize because of the: +audio/paaudio.c: +- if (!popts->has_server) { +- char pidfile[64]; +- char *runtime; +- struct stat st; +- +- runtime = getenv("XDG_RUNTIME_DIR"); +- if (!runtime) { +- return NULL; +- } +- snprintf(pidfile, sizeof(pidfile), "%s/pulse/pid", runtime); +- if (stat(pidfile, &st) != 0) { +- return NULL; +- } +- } +XDG_RUNTIME_DIR is not set for me. There is no /run/user directory exist in my system. + +Also: +$ less ~/.pulse/client.conf +default-server = unix:/home/ivan/.pulse_server
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1826172 b/results/classifier/mode-gemma3:12b/user/1826172 new file mode 100644 index 00000000..9b11888d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1826172 @@ -0,0 +1,37 @@ + + +Compilation on MSYS2/MinGW-w64 fails with error: "__USE_MINGW_ANSI_STDIO" redefined + +Compilation against latest GIT version fails at the following step: + + CC qga/commands.o +In file included from qga/commands.c:13: +C:/Tempy-chan/qemu/include/qemu/osdep.h:97: error: "__USE_MINGW_ANSI_STDIO" redefined [-Werror] + #define __USE_MINGW_ANSI_STDIO 1 + +In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/vadefs.h:9, + from C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw_stdarg.h:14, + from C:/msys64/mingw64/x86_64-w64-mingw32/include/stdarg.h:140, + from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/include/stdarg.h:1, + from C:/Tempy-chan/qemu/include/qemu/osdep.h:88, + from qga/commands.c:13: +C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw.h:431: note: this is the location of the previous definition + #define __USE_MINGW_ANSI_STDIO 0 /* was not defined so it should be 0 */ + +cc1.exe: all warnings being treated as errors +make: *** [/c/Tempy-chan/qemu/rules.mak:69: qga/commands.o] Error 1 + +Passing --extra-cflags="-D__USE_MINGW_ANSI_STDIO" to configure resolves the error. Digging deeper in x86_64-w64-mingw32/include/_mingw.h, it looks like __USE_MINGW_ANSI_STDIO is only defined for _GNU_SOURCE in C++ compilation. With C only code it's ignored and doesn't define __USE_MINGW_ANSI_STDIO as expected: + +/* We are activating __USE_MINGW_ANSI_STDIO for various define indicators. + Note that we enable it also for _GNU_SOURCE in C++, but not for C case. */ +#if (defined (_POSIX) || defined (_POSIX_SOURCE) || defined (_POSIX_C_SOURCE) \ + || defined (_ISOC99_SOURCE) \ + || defined (_XOPEN_SOURCE) || defined (_XOPEN_SOURCE_EXTENDED) \ + || (defined (_GNU_SOURCE) && defined (__cplusplus)) \ + || defined (_SVID_SOURCE)) \ + && !defined(__USE_MINGW_ANSI_STDIO) +/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined + * and If user did _not_ specify it explicitly... */ +# define __USE_MINGW_ANSI_STDIO 1 +#endif
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1826175 b/results/classifier/mode-gemma3:12b/user/1826175 new file mode 100644 index 00000000..110df5a6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1826175 @@ -0,0 +1,30 @@ + + +Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib" + +I submitted this bug to Capstone directly but I figured it'd be useful to post it here too. The IS_MINGW check in the Makefile for Capstone fails under MSYS2 MinGW-w64 because cc --version doesn't have mingw in the output anymore: + +$ whereis cc +cc: /mingw64/bin/cc.exe + +$ cc --version +cc.exe (Rev2, Built by MSYS2 project) 8.3.0 +Copyright (C) 2018 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +Really simple patch: + +diff --git "a/Makefile" "b/Makefile" +index 063f50db..1d9f042e 100644 +--- "a/Makefile" ++++ "b/Makefile" +@@ -288,7 +288,7 @@ CFLAGS := $(CFLAGS:-fPIC=) + # On Windows we need the shared library to be executable + else + # mingw? +-IS_MINGW := $(shell $(CC) --version | grep -i mingw | wc -l) ++IS_MINGW := $(shell $(CC) --version | grep -i msys2 | wc -l) + ifeq ($(IS_MINGW),1) + EXT = dll + AR_EXT = lib
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1828723 b/results/classifier/mode-gemma3:12b/user/1828723 new file mode 100644 index 00000000..43e4fa70 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1828723 @@ -0,0 +1,7 @@ + + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1828867 b/results/classifier/mode-gemma3:12b/user/1828867 new file mode 100644 index 00000000..f643d8c7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1828867 @@ -0,0 +1,10 @@ + + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed"
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1829079 b/results/classifier/mode-gemma3:12b/user/1829079 new file mode 100644 index 00000000..10fbe765 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1829079 @@ -0,0 +1,18 @@ + + +Can't build static on ARM (Raspbian) + +I am trying to build static QEMU on Raspbian, chrooted into using systemd-nspawn with QEMU 4.0.0. +This is how my compiling looks: +https://pastebin.com/PYZYeRCN +Just the problematic part: +https://pastebin.com/7LxWPMxA +How I do the compiling: +https://pastebin.com/pYM17A6R (I plan to share this tutorial when it will work) +It is a coincidence, or the build fails because it cannot find lp11-kit. I did some symlinks: +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 /usr/lib/libp11-kit.so.0 +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so /usr/lib/libp11-kit.so +(should I also symlink libp11.so and libp11.so.2? I think I have installed all required p11 packages! + +Git commit hash: git rev-parse HEAD +e329ad2ab72c43b56df88b34954c2c7d839bb373
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1829459 b/results/classifier/mode-gemma3:12b/user/1829459 new file mode 100644 index 00000000..c6544b0c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1829459 @@ -0,0 +1,37 @@ + + +qemu seems to lack support for pid namespace. + +# Version + +qemu-4.0.0 + +# commands used to launch qemu-aarch64 in user mode. + +printf '%s\n' ':qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-aarch64:'"${QEMU_BINFMT_FLAGS}" >/proc/sys/fs/binfmt_misc/register + +> sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin +> sudo chroot $RPI /bin/ksh -l + +# host + +Gentoo Linux amd64 + +# Guest + +Gentoo Linux aarch64 + +# The problem that I have + +"emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid argument". +"emerge" is Gentoo's package manager that compiles and installs packages. + +# How to reproduce the issue + +Execute + +unshare --pid -- echo hello world + +or + +python -c "import portage.process; portage.process.spawn(['echo', 'hello', 'world'], unshare_pid=True)"
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1830415 b/results/classifier/mode-gemma3:12b/user/1830415 new file mode 100644 index 00000000..86418ea1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1830415 @@ -0,0 +1,16 @@ + + +linux-user elf loader issue + +all versions up to 4.0 (I didn't test others) +file affected linux-user/elfload.c +function load_elf_image + +if (phdr[i].p_type == PT_LOAD) { + +- abi_ulong a = phdr[i].p_vaddr - phdr[i].p_offset; ++ abi_ulong a = phdr[i].p_vaddr ; // - phdr[i].p_offset; + if (a < loaddr) { + loaddr = a; + +To the best of my understanding of the elf format p_offset is not a virtual offset. In fact, when I load statically compiled applications, the load fails because the libc before main is trying to access phdr in the executable image but that memory is not mapped -- this is caused by the wrong loaddr above.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1832281 b/results/classifier/mode-gemma3:12b/user/1832281 new file mode 100644 index 00000000..fc928a2b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1832281 @@ -0,0 +1,53 @@ + + +tcg bug master / 4.0.0 v8 operation >>> and |= + +vm guest is linux, executed with tcg +running this Node.js snippet leads to + +$ node +> a = undefined +undefined +> a >>> 0 +4294967295 + +host node +$ node +> a = undefined +undefined +> a >>> 0 +0 + +same with |= + +node +Welcome to Node.js v12.4.0. +Type ".help" for more information. +> let buffer +undefined +> buffer |= 0 +0 + +vm with tcg: + +$ ./out/Release/node --version +v12.4.0 +./out/Release/node -e "let buffer; buffer |= 0; console.log(buffer);" +-1 + + +vm guest is debian x86_64 latest release +vm guest is started with ./x86_64-softmmu/qemu-system-x86_64 -vnc :0 -cdrom debian-9.9.0-amd64-netinst.iso -m 4G -smp cores=6,threads=1,sockets=1 -nic user,hostfwd=tcp:ipv4addr:2233-:22 -cpu qemu64 debian.img + +git tag v4.0.0 and master, commit a578cdfbdd8f9beff5ced52b7826ddb1669abbbf, for building qemu-system-x86_64 was used. + +Node.js as compiled on the vm guest (v12.4.0 / master) + + +see also +https://github.com/nodejs/node/issues/19348#issuecomment-500465502 + +I need further assistance to track down the cause of the bug. + +Kind regards +Manuel
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1832353 b/results/classifier/mode-gemma3:12b/user/1832353 new file mode 100644 index 00000000..8f4ad659 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1832353 @@ -0,0 +1,22 @@ + + +cpu_exec: Assertion !have_mmap_lock() failed + +Hi, + +I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: + +qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. + +including with master qemu as of today. + +I'm attaching a tarball containing: +qemu-assert: +cmd lib proc_ptr_51.exe + +qemu-assert/lib: +ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 + +where cmd is the basic command used to launch the test & reproduce the failure. + +Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1832422 b/results/classifier/mode-gemma3:12b/user/1832422 new file mode 100644 index 00000000..ee67cf10 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1832422 @@ -0,0 +1,11 @@ + + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1832916 b/results/classifier/mode-gemma3:12b/user/1832916 new file mode 100644 index 00000000..90574b23 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1832916 @@ -0,0 +1,7 @@ + + +linux-user does not check PROT_EXEC + +At no point do we actually verify that a page is PROT_EXEC before translating. All we end up verifying is that the page is readable. Not the same thing, obviously. + +The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1833668 b/results/classifier/mode-gemma3:12b/user/1833668 new file mode 100644 index 00000000..74f33a5a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1833668 @@ -0,0 +1,29 @@ + + +linux-user: Unable to run ARM binaries on Aarch64 + +Download a ARM package from https://packages.debian.org/sid/busybox-static + +Here tested with: busybox-static_1.30.1-4_armel.deb + +$ file busybox.armel +busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14) + +$ qemu-aarch64 busybox.armel +busybox.armel: Invalid ELF image for this architecture + +$ qemu-aarch64 -cpu cortex-a7 busybox.armel +unable to find CPU model 'cortex-a7' + +Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1, +while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty: + +$ gdb -q aarch64-linux-user/qemu-aarch64 +(gdb) p aarch64_cpus +$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", + initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}} +(gdb) p arm_cpus +$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}}
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1833871 b/results/classifier/mode-gemma3:12b/user/1833871 new file mode 100644 index 00000000..9edbe005 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1833871 @@ -0,0 +1,18 @@ + + +qemu-img convert file.vmdk: Invalid footer + +Steps to reproduce +- Open ESXi 6.5 Web UI +- Export OVF +- qemu-img convert disk.vmdk disk.qcow2 + +Error: + + qemu-img: Could not open './disk-1.vmdk': Invalid footer + +I found another person having this problem here: +https://forum.proxmox.com/threads/error-converting-vmdk-file-to-qcow2-file.38264/ +As I guess from the answer, the guy went over to manually copy the flat file from the datastore instead of using the ovf-exported file. + +Nevertheless, I think this bug should be investigated further and closed. Probably it is just some metadata issue and should not be too hard to fix once the root of the problem is found.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1835 b/results/classifier/mode-gemma3:12b/user/1835 new file mode 100644 index 00000000..b0bee843 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1835 @@ -0,0 +1,20 @@ + + +IPv4 guest/outbound port forwarding not working +Description of problem: +Python http server running on the host can receive the first http request from guest and provides correct response, but the resent request gets stuck. Package couldn't be seen in `tcpdump` running on host. +Steps to reproduce: +1. Build libslirp, I am using HEAD @ master. +1. Build your QEMU with user network enabled to use slirp (`./configure -target-list=x86_64-softmmu --enable-slirp`). +1. Ran a Python server on host listening to port `6655` (`python3 -m http.server --bind :: 6655`). +1. Boot your QEMU with aforementioned QEMU command line, I am forwarding a server address to host's local address `guestfwd=tcp:10.0.2.100:6657-tcp:127.0.0.1:6655`. For image, I am using a ordinary Fedora 38 workstation live cdrom. +1. In your guest OS (emulated enviroment), open a terminal and run `curl http://10.0.2.100:6657`, this sends a http get to the +slirp outbound forwarding server. You should see the Python http server gets the request and provides correct response `::ffff:127.0.0.1 - - [17/Aug/2023 18:24:34] "GET / HTTP/1.1" 200 -`, nothing but just `ls` the directory. +5. Repeat step 4, you will see the `curl` command gets stuck. +Additional information: +I've added a .pacp capturing line in QEMU command line and investigated it via Wireshark, noticed the slirp gets the http get, but after that being stuck in some place, I saw the guest sending keep alive request to slirp, so I think this could be something in the QEMU side. + + + + + diff --git a/results/classifier/mode-gemma3:12b/user/1835693 b/results/classifier/mode-gemma3:12b/user/1835693 new file mode 100644 index 00000000..e67ff999 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1835693 @@ -0,0 +1,19 @@ + + +s390x binaries segfault + +Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. + +$ cat hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ s390x-linux-gnu-g++ -o hello hello.cpp + +$ qemu-s390x-static hello +Segmentation fault
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1835839 b/results/classifier/mode-gemma3:12b/user/1835839 new file mode 100644 index 00000000..a8303fb7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1835839 @@ -0,0 +1,23 @@ + + +qemu-user: $0 incorrectly always reports absolute path + +We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1]. + +The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked. + +A simple reproducer is this: + +On normal system (no emulation): + +root@nofan:~> sh -c 'echo $0' +sh +root@nofan:~> + +On qemu-user: + +(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0' +/bin/sh +(sid-m68k-sbuild)root@nofan:/# + +> [1] https://lists.debian.org/debian-68k/2019/07/msg00007.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1836558 b/results/classifier/mode-gemma3:12b/user/1836558 new file mode 100644 index 00000000..db8ff9a3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1836558 @@ -0,0 +1,50 @@ + + +Qemu-ppc Memory leak creating threads + +When creating c++ threads (with c++ std::thread), the resulting binary has memory leaks when running with qemu-ppc. + +Eg the following c++ program, when compiled with gcc, consumes more and more memory while running at qemu-ppc. (does not have memory leaks when compiling for Intel, when running same binary on real powerpc CPU hardware also no memory leaks). + +(Note I used function getCurrentRSS to show available memory, see https://stackoverflow.com/questions/669438/how-to-get-memory-usage-at-runtime-using-c; calls commented out here) + +Compiler: powerpc-linux-gnu-g++ (Debian 8.3.0-2) 8.3.0 (but same problem with older g++ compilers even 4.9) +Os: Debian 10.0 ( Buster) (but same problem seen on Debian 9/stetch) +qemu: qemu-ppc version 3.1.50 + + + +--- + +#include <iostream> +#include <thread> +#include <chrono> + + +using namespace std::chrono_literals; + +// Create/run and join a 100 threads. +void Fun100() +{ +// auto b4 = getCurrentRSS(); +// std::cout << getCurrentRSS() << std::endl; + for(int n = 0; n < 100; n++) + { + std::thread t([] + { + std::this_thread::sleep_for( 10ms ); + }); +// std::cout << n << ' ' << getCurrentRSS() << std::endl; + t.join(); + } + std::this_thread::sleep_for( 500ms ); // to give OS some time to wipe memory... +// auto after = getCurrentRSS(); + std::cout << b4 << ' ' << after << std::endl; +} + + +int main(int, char **) +{ + Fun100(); + Fun100(); // memory used keeps increasing +}
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1837 b/results/classifier/mode-gemma3:12b/user/1837 new file mode 100644 index 00000000..9d1a1de6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1837 @@ -0,0 +1,37 @@ + + +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/mode-gemma3:12b/user/1838 b/results/classifier/mode-gemma3:12b/user/1838 new file mode 100644 index 00000000..7ab9dcb9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1838 @@ -0,0 +1,3 @@ + + +Win9x on qemu 8.0.3 - Impossible to launch a win32 app diff --git a/results/classifier/mode-gemma3:12b/user/1840646 b/results/classifier/mode-gemma3:12b/user/1840646 new file mode 100644 index 00000000..546778d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1840646 @@ -0,0 +1,13 @@ + + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122: logical fault + +qemu-4.1.0/roms/SLOF/lib/libnet/ping.c:122:16: warning: Logical conjunction always evaluates to false: alen <= 0 && alen >= sizeof(args) - 1. [incorrectLogicOperator] + +Source code is + + if (alen <= 0 && alen >= sizeof(args) - 1) { + +Maybe better code: + + if (alen <= 0 || alen >= sizeof(args) - 1) {
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1841442 b/results/classifier/mode-gemma3:12b/user/1841442 new file mode 100644 index 00000000..f683670e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1841442 @@ -0,0 +1,57 @@ + + +floating point emulation can fail to set FE_INEXACT + +Floating point emulation can fail to set FE_INEXACT in some circumstances. This shows up quite often in glibc's "math" tests. A similar test is attached. + +On ppc64le native: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +On x86_64: +-- +$ gcc nextafter.c -o nextafter -lm +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x30 +FE_INEXACT FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-system-ppc64 +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x8000000 +FE_UNDERFLOW +0x0000000000000000 0.000000 +-- + +Using qemu-x86_64: +-- +$ ./nextafter $(./nextafter) +0x0000000000000001 0.000000 +0x0 + +0x0 + +0x0000000000000000 0.000000 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +Since the issue happens nearly identically on different targets, I suspect the issue lies somewhere in fpu/softfloat.c.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1841491 b/results/classifier/mode-gemma3:12b/user/1841491 new file mode 100644 index 00000000..a1d01822 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1841491 @@ -0,0 +1,37 @@ + + +floating point emulation can fail to set FE_UNDERFLOW + +Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. + +This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. + +On ppc64le native: +-- +$ gcc -c -O2 fma.c +$ gcc -O2 test-fma.c fma.o -lm -o test-fma +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x1p-1022 +-- + +On qemu-system-ppc64: +-- +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0x2000000 +FE_INEXACT +0x1p-1022 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1841990 b/results/classifier/mode-gemma3:12b/user/1841990 new file mode 100644 index 00000000..e5a3eaef --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1841990 @@ -0,0 +1,40 @@ + + +instruction 'denbcdq' misbehaving + +Instruction 'denbcdq' appears to have no effect. Test case attached. + +On ppc64le native: +-- +gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq +$ ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x22080000000000000000000000000000 +$ ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x22080000000000000000000000000001 +$ ./test-denbcdq $(seq 0 99) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x22080000000000000000000000000080 +-- + +With "qemu-ppc64le -cpu power9" +-- +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x0000000000000000000000000000000c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x0000000000000000000000000000001c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x0000000000000000000000000000100c +-- + +I started looking at the code, but I got confused rather quickly. Could be related to endianness? I think denbcdq arrived on the scene before little-endian was a big deal. Maybe something to do with utilizing implicit floating-point register pairs... I don't think the right data is getting to helper_denbcdq, which would point back to the gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1843205 b/results/classifier/mode-gemma3:12b/user/1843205 new file mode 100644 index 00000000..02fd9b74 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1843205 @@ -0,0 +1,104 @@ + + +Inaccurate Fmod on i386 + +# Qemu Version + +```bash +$ qemu-i386 --version +qemu-i386 version 3.0.1 (qemu-3.0.1-4.fc29) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +``` + +# Failing Source Code (C) + +```c +#include <math.h> +#include <stdio.h> + +int main() +{ + double x = 29860476080414620.0; + double y = 17.0; + double z = fmod(x, y); + printf("%f\n", z); + return 0; +} +``` + +The code was compiled with GCC (8.3.1) on x86-64 with the flags `-O3 -m32 -lm -static`. + +# Emitted (Annotated) Assembly + +In order to facilitate debugging the issue, the following assembly was generated to show nothing unusual occurred during compilation. The assembly was generated with flags `-S -O3 -m32 -lm`, and then annotated to show the operands to fmod. + +```asm + .file "a.c" + .text + .section .rodata.str1.1,"aMS",@progbits,1 +.LC2: + .string "%f\n" + .section .text.startup,"ax",@progbits + .p2align 4,,15 + .globl main + .type main, @function +main: +.LFB16: + .cfi_startproc + leal 4(%esp), %ecx + .cfi_def_cfa 1, 0 + andl $-16, %esp + pushl -4(%ecx) + pushl %ebp + .cfi_escape 0x10,0x5,0x2,0x75,0 + movl %esp, %ebp + pushl %ecx + .cfi_escape 0xf,0x3,0x75,0x7c,0x6 + subl $4, %esp + pushl $1076953088 ; high 32-bits of double for y + pushl $0 ; low 32-bits of double for y + pushl $1130005884 ; high 32-bits of double for x + pushl $2003187687 ; low 32-bits of double for x + call fmod + movl $.LC2, (%esp) + fstpl 4(%esp) + call printf + movl -4(%ebp), %ecx + .cfi_def_cfa 1, 0 + addl $16, %esp + xorl %eax, %eax + leave + .cfi_restore 5 + leal -4(%ecx), %esp + .cfi_def_cfa 4, 4 + ret + .cfi_endproc +.LFE16: + .size main, .-main + .ident "GCC: (GNU) 8.3.1 20190223 (Red Hat 8.3.1-2)" + .section .note.GNU-stack,"",@progbits +``` + +# Result + +Running the compiled binary on x86_64 produces the expected value of `15.000000`, while using `qemu-i386 <binary>` produces the unexpected result of `-4.000000`. + +This was tested against: + +1. Qemu 3.0.1 for Fedora 29. +2. Qemu 4.1.0 built from source, downloaded from https://download.qemu.org/qemu-4.1.0.tar.xz +3. Qemu built-from-source against commit 90b1e3afd33226b6078fec6d77a18373712a975c. + +# Building Qemu + +Qemu built-from-source was compiled as follows: + +```bash +mkdir build && cd build +../configure --disable-kvm --target-list="i386-linux-user" +make -j 5 +``` + +# Results + +All built versions of Qemu running the 32-bit failed to produce the accurate result. Using qemu-x86_64 against an x86_64 binary built from the same C source code produces correct results. Running the 32-bit binary natively produces the correct result.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1843651 b/results/classifier/mode-gemma3:12b/user/1843651 new file mode 100644 index 00000000..5557c192 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1843651 @@ -0,0 +1,82 @@ + + +m68k fpu bug + +On gcc123 cfarm machine, +I was testing m68k executables generated by Free Pascal Compiler. + +muller@gcc123:~/pas/check$ cat inf.pp +function get_double(x : double):double; + begin + get_double:=x; + end; + + +var + y : double; + py : pbyte; + i : byte; +begin + y:=1.0/0.0; + py:=@y; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; + y:=get_double(y)+1; +{$ifdef ENDIAN_LITTLE} + write('little endian y='); + for i:=7 downto 0 do +{$else not ENDIAN_LITTLE} + write('big endian y='); + for i:=0 to 7 do +{$endif} + write(hexstr(py[i],2)); + writeln; +end. +muller@gcc123:~/pas/check$ ppc68k inf +Free Pascal Compiler version 3.3.1-r20:42973M [2019/09/11] for m68k +Copyright (c) 1993-2019 by Florian Klaempfl and others +Target OS: Linux for m68k +Compiling inf.pp +Assembling program +Linking inf +33 lines compiled, 0.1 sec +muller@gcc123:~/pas/check$ ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ qemu-m68k ./inf +big endian y=7FF0000000000000 +big endian y=7FFFFFFFFFFFFFFF +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k ./inf +qemu-m68k qemu-m68k-fixed +muller@gcc123:~/pas/check$ ~/sys-root/bin/qemu-m68k-fixed ./inf +big endian y=7FF0000000000000 +big endian y=7FF0000000000000 + +~/sys-root/bin/qemu-m68k is 4.1.0 release, +~/sys-root/bin/qemu-m68k-fixed is the same source with a unique change: + +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h:214:#if defined(TARGET_M68K) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-215-#define floatx80_infinity_low LIT64(0x0000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-216-#else +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-217-#define floatx80_infinity_low LIT64(0x8000000000000000) +gnu/qemu/qemu-4.1.0/fpu/softfloat-specialize.h-218-#endif + +the M68K branch value is set to the same value as the other branch. + +The problem of the M68K specific floatx86_infinity_low values +is that is enters in conflict with +muller@gcc123:~/pas/check$ grep -nA6 invalid_enc /home/muller/gnu/qemu/qemu-4.1.0/include/fpu/softfloat.h +752:static inline bool floatx80_invalid_encoding(floatx80 a) +753-{ +754- return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0; +755-} + +And thus the m68k variant of floatx80 representing +Infinity is +considered as an invalid encoding, and thus converted into a NaN 7FFFFFFFFFFFFFFF
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1845185 b/results/classifier/mode-gemma3:12b/user/1845185 new file mode 100644 index 00000000..42210ae1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1845185 @@ -0,0 +1,47 @@ + + +Cannot build qemu utils (qemu-img.exe, qemu-edid.exe, qemu-io.exe) statically with MSYS64 on Windows because intl and iconv libs are not loaded + +Using MSYS2 and mingw32 instructions from https://wiki.qemu.org/Hosts/W32#Native_builds_with_MSYS2, I could not statically build the qemu-utils using the latest qemu master branch. + +Steps to reproduce the issue: +1. Install MSYS2 on a Windows 10 x64 box +2. Install required mingw64 toolchain: pacman -S base-devel mingw-w64-x86_64-toolchain git python mingw-w64-x86_64-glib2 mingw64/mingw-w64-x86_64-gtk3 mingw64/mingw-w64-x86_64-SDL2 +3. clone qemu +4. Run configure for static build for the tools only + ./configure --disable-user --disable-system --disable-docs --enable-tools --disable-guest-agent --disable-capstone --disable-sheepdog --enable-debug --static + # I had to remove sheepdog, capstone and guest agent because other errors popped out, but this not the purpose of this bug report +5. Run 'make -j'. the following errors appeared, signaling that intl lib is not loaded. If I add intl lib, iconv lib need to be loaded too. + +make: *** [/home/ader1990/qemu/rules.mak:124: qemu-img.exe] Error 1 +make: *** Waiting for unfinished jobs.... +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1522): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x154f): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x157e): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15ad): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x15dc): undefined reference to `libintl_sprintf' +C:/msys64l/mingw64/lib\libglib-2.0.a(giowin32.c.obj):(.text+0x1622): more undefined references to `libintl_sprintf' follow +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x43): undefined reference to `libintl_textdomain' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x52): undefined reference to `libintl_gettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x203): undefined reference to `libintl_bindtextdomain' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x21e): undefined reference to `libintl_bind_textdomain_codeset' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x2c1): undefined reference to `libintl_dgettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x4e1): undefined reference to `libintl_dcgettext' +C:/msys64l/mingw64/lib\libglib-2.0.a(ggettext.c.obj):(.text+0x53a): undefined reference to `libintl_dngettext' + + +Patch to fix the issue (added intl and iconv to the libs): + +diff --git a/configure b/configure +index 30aad233d1..e2ab8ef026 100755 +--- a/configure ++++ b/configure +@@ -920,7 +920,7 @@ if test "$mingw32" = "yes" ; then + DSOSUF=".dll" + # MinGW needs -mthreads for TLS and macro _MT. + QEMU_CFLAGS="-mthreads $QEMU_CFLAGS" +- LIBS="-lwinmm -lws2_32 -liphlpapi $LIBS" ++ LIBS="-lwinmm -lws2_32 -liphlpapi -lintl -liconv $LIBS" + write_c_skeleton; + if compile_prog "" "-liberty" ; then + LIBS="-liberty $LIBS"
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1847232 b/results/classifier/mode-gemma3:12b/user/1847232 new file mode 100644 index 00000000..68805e9f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1847232 @@ -0,0 +1,15 @@ + + +qemu TCG in s390x mode issue with calculating HASH + +When using go on s390x on Debian x64 (buster) (host) and debian s390x (sid) (guest) I run into the following problem : + +The following occurs while trying to build a custom project : + +go: <email address hidden>: Get https://proxy.golang.org/github.com/%21factom%21project/basen/@v/v0.0.0-20150613233007-fe3947df716e.mod: local error: tls: bad record MAC + +Doing a git bisect I find that this problem only occurs on and after commit 08ef92d556c584c7faf594ff3af46df456276e1b + +Before that commit, all works fine. Past this commit, build always fails. + +Without any proof, It looks like a hash calculation bug related to using z/Arch vector facilities...
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1847467 b/results/classifier/mode-gemma3:12b/user/1847467 new file mode 100644 index 00000000..6e6b6659 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1847467 @@ -0,0 +1,18 @@ + + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1847906 b/results/classifier/mode-gemma3:12b/user/1847906 new file mode 100644 index 00000000..3f97fa43 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1847906 @@ -0,0 +1,10 @@ + + +Cocoa display hangs on macOS 10.15 (Catalina) + +I have downloaded the latest stable source tarball 4.1.0 and compiled it (i386-softmmu target). + +After opening a black window, QEMU hangs (spinning beach ball). +When building with `--disable-cocoa --enable-sdl`, display seems to work fine. + +The same happened when I tried to build QEMU through HomeBrew and MacPorts.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1848556 b/results/classifier/mode-gemma3:12b/user/1848556 new file mode 100644 index 00000000..c4600c8c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1848556 @@ -0,0 +1,12 @@ + + +qemu-img check failing on remote image in Eoan + +The "qemu-img check" function is failing on remote (HTTP-hosted) images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils version 1:3.1+dfsg-2ubuntu3.5, the following worked: + +$ /usr/bin/qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img +No errors were found on the image. +19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters +Image end offset: 514064384 + +The 10.193.37.117 server holds an Apache server that hosts the cloud images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-0ubuntu9, the same command never returns. (I've left it for up to an hour with no change.) I'm able to wget the image from the same server and installation on which qemu-img check fails. I've tried several .img files on the server, ranging from Bionic to Eoan, with the same results with all of them.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1849879 b/results/classifier/mode-gemma3:12b/user/1849879 new file mode 100644 index 00000000..d234ea69 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1849879 @@ -0,0 +1,12 @@ + + +qemu-arm should accept vmrs apsr_nzcv, fpscr on M-profile + +I've noticed that qemu-arm for cortex-M considers +vmrs apsr_nzcv, fpscr +as an illegal instruction. + +In this case, rt==15 means APSR, and the instruction should be accepted and executed like for A-profile. + +I posted a small patch: +https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg06978.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1851095 b/results/classifier/mode-gemma3:12b/user/1851095 new file mode 100644 index 00000000..206e1839 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1851095 @@ -0,0 +1,5 @@ + + +[feature request] awareness of instructions that are well emulated + +While qemu's scalar emulation tends to be excellent, qemu's SIMD emulation tends to be incorrect (except for arm64 from x86_64). Until these code paths are audited, which is probably a large job, it would be nice if qemu knew its emulation of this class of instructions was not very good, and thus it would give up on finding these instructions if a "careful" operation is passed.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1852115 b/results/classifier/mode-gemma3:12b/user/1852115 new file mode 100644 index 00000000..25f3d11c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1852115 @@ -0,0 +1,46 @@ + + +qemu --static user build fails with fedora rawhide glibc-2.30.9000 + +Building qemu latest git 654efcb511d on fedora rawhide fails with this configure line: + +./configure \ + --static \ + --disable-system \ + --enable-linux-user \ + --disable-werror \ + --disable-tools \ + --disable-capstone + +make fails with: + +/usr/bin/ld: linux-user/syscall.o: in function `do_syscall1': +/root/qemu.git/linux-user/syscall.c:7769: undefined reference to `stime' +collect2: error: ld returned 1 exit status + +Seems related to this glibc change: https://sourceware.org/git/?p=glibc.git;a=commit;h=12cbde1dae6fa4a9a792b64564c7e0debf7544cc + +... + ++* The obsolete function stime is no longer available to newly linked ++ binaries and it has been removed from <time.h> header. This function ++ has been deprecated in favor of clock_settime. ++ + +# rpm -q glibc +glibc-2.30.9000-17.fc32.x86_64 + + +FWIW there's some other messages but I don't think they are fatal: + +/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/9/../../../../lib64/libglib-2.0.a(gutils.c.o): in function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0xe0): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +/usr/bin/ld: (.text+0x11e): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking + + +Also, --disable-capstone is required to avoid this error, but it is pre-existing, not sure if it's a bug, if so I can file a separate one: + + LINK aarch64-linux-user/qemu-aarch64 +/usr/bin/ld: cannot find -lcapstone +collect2: error: ld returned 1 exit status
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1854 b/results/classifier/mode-gemma3:12b/user/1854 new file mode 100644 index 00000000..8b964558 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1854 @@ -0,0 +1,20 @@ + + +s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Description of problem: +The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 . +Reverting that commit fixes the issue. +Steps to reproduce: +1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below. +2. Run it under qemu-s390x. + +``` + ./qemu-s390x nolibc-test +** +ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached +Aborted (core dumped) + +``` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/1856837 b/results/classifier/mode-gemma3:12b/user/1856837 new file mode 100644 index 00000000..e3917a59 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1856837 @@ -0,0 +1,42 @@ + + +qemu 4.2.0 arm segmentation fault with gcc 9.2 + +As discussed with f4bug yesterday on IRC here comes the bug description. + +I'm building/configured qemu-4.2.0 on an x86_64 (gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516) with target-list "arm-softmmu,arm-linux-user" and debug enabled. I use the arm-linux-user variant, "qemu-arm". + +Then i'm trying to cross-compile (arm gcc) an old version of googles v8 (as i need this version of the lib for binary compatibility) which uses qemu during build. + +It worked with gcc 5.4.0 but not with 9.2.0. I also tried with 6.5.0, 7.4.0 and 8.3.0 but those are also causing the same segmentation fault. + +The executed command wich breaks qemu is: + + qemu-arm /tmp/build/out/arm.release/mksnapshot.arm --log-snapshot-positions --logfile /tmp/build/out/arm.release/obj.host/v8_snapshot/geni/snapshot.log --random-seed 314159265 /tmp/build/out/arm.release/obj.host/v8_snap + +The printed error message is: + +ARMv7=1 VFP3=1 VFP32DREGS=1 NEON=0 SUDIV=0 UNALIGNED_ACCESSES=1 MOVW_MOVT_IMMEDIATE_LOADS=0 USE_EABI_HARDFLOAT=1 +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Calling qemu with gdb gives the following information: + + Thread 1 "qemu-arm" received signal SIGSEGV, Segmentation fault. + 0x0000555555d63d11 in static_code_gen_buffer () + +and + + (gdb) bt + #0 0x0000555555d63d11 in static_code_gen_buffer () + #1 0x0000555555628d58 in cpu_tb_exec (itb=<optimized out>, cpu=0x555557c33930) at + /tmp/build/qemu/accel/tcg/cpu-exec.c:172 + #2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x555557c33930) at /tmp/build/qemu/accel/tcg/cpu-exec.c:618 + #3 cpu_exec (cpu=cpu@entry=0x555557c2b660) at /tmp/build/qemu/accel/tcg/cpu-exec.c:731 + #4 0x0000555555661578 in cpu_loop (env=0x555557c33930) at /tmp/build/qemu/linux-user/arm/cpu_loop.c:219 +#5 0x00005555555d6d76 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at /tmp/build/qemu/linux-user/main.c:865 + +Calling qemu-arm with debug switch "-d in_asm,int,op_opt" shows the log in the attached file. + +Thanks for any hints! +Fabian
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1857811 b/results/classifier/mode-gemma3:12b/user/1857811 new file mode 100644 index 00000000..faff4944 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1857811 @@ -0,0 +1,9 @@ + + +qemu user static binary seems to lack support for network namespace. + +Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message. + +Unable to configure loopback interface: Operation not supported + +If I disable emerge's network-sandbox which utilizes network namespace, the error disappears.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1858461 b/results/classifier/mode-gemma3:12b/user/1858461 new file mode 100644 index 00000000..93fd2172 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1858461 @@ -0,0 +1,25 @@ + + +Please refactor linux-user/mips/cpu_loop.c + +Hello. I am working with qemu on test images. I've added a new syscall (436) to qemu but received ENOSYS from mips application. + +Please open "linux-user/mips/cpu_loop.c". I've added at the end of "mips_syscall_args" the following: + +``` +MIPS_SYS(sys_getdents64_x32, 3) +``` + +But + +``` +syscall_num = env->active_tc.gpr[2] - 4000; +if (syscall_num >= sizeof(mips_syscall_args)) { + ret = -TARGET_ENOSYS; +``` + +returns -TARGET_ENOSYS + +We can see that "linux-user/mips/cpu_loop.c" differs a lot from "linux-user/arm/cpu_loop.c". Arm has it's own "ARM_NR_BASE" and etc. + +Can you please refactor mips cpu loop in the same way as arm? Thank you.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1859291 b/results/classifier/mode-gemma3:12b/user/1859291 new file mode 100644 index 00000000..5109a501 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1859291 @@ -0,0 +1,5 @@ + + +RISC-V incorrect exception generated + +When using 'ecall' from supervisor mode, user exception is raised instead of supervisor exception. The problem is located under 'target/riscv/insn_trans/trans_priviledged.inc.c' in function 'static bool trans_ecall(DisasContext *ctx, arg_ecall *a)'. Best regards, Serge Teodori
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1860053 b/results/classifier/mode-gemma3:12b/user/1860053 new file mode 100644 index 00000000..24a44f33 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1860053 @@ -0,0 +1,22 @@ + + +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/mode-gemma3:12b/user/1860056 b/results/classifier/mode-gemma3:12b/user/1860056 new file mode 100644 index 00000000..2f161e6a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1860056 @@ -0,0 +1,22 @@ + + +mips binaries segfault + +Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host. + +Example: + + +$ cat mips/test/hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello +qemu: uncaught target signal 11 (Segmentation fault) - core dumped + +Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1860553 b/results/classifier/mode-gemma3:12b/user/1860553 new file mode 100644 index 00000000..9140ebb4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1860553 @@ -0,0 +1,16 @@ + + +cmake crashes on qemu-alpha-user with Illegal Instruction + +I tried building cmake on Debian unstable for Alpha today using qemu-user and the compiled cmake binary crashed with "Illegal Instruction": + +g++ -Wl,-z,relro -Wl,--as-needed -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -I/<<PKGBUILDDIR>>/Build/Bootstrap.cmk -I/<<PKGBUILDDIR>>/Source -I/<<PKGBUILDDIR>>/Source/LexerParser -I/<<PKGBUILDDIR>>/Utilities cmAddCustomCommandCommand.o cmAddCustomTargetCommand.o cmAddDefinitionsCommand.o cmAddDependenciesCommand.o cmAddExecutableCommand.o cmAddLibraryCommand.o cmAddSubDirectoryCommand.o cmAddTestCommand.o cmArgumentParser.o cmBreakCommand.o cmBuildCommand.o cmCMakeMinimumRequired.o cmCMakePolicyCommand.o cmCPackPropertiesGenerator.o cmCacheManager.o cmCommand.o cmCommandArgumentParserHelper.o cmCommands.o cmCommonTargetGenerator.o cmComputeComponentGraph.o cmComputeLinkDepends.o cmComputeLinkInformation.o cmComputeTargetDepends.o cmConditionEvaluator.o cmConfigureFileCommand.o cmContinueCommand.o cmCoreTryCompile.o cmCreateTestSourceList.o cmCustomCommand.o cmCustomCommandGenerator.o cmDefinePropertyCommand.o cmDefinitions.o cmDepends.o cmDependsC.o cmDisallowedCommand.o cmDocumentationFormatter.o cmEnableLanguageCommand.o cmEnableTestingCommand.o cmExecProgramCommand.o cmExecuteProcessCommand.o cmExpandedCommandArgument.o cmExportBuildFileGenerator.o cmExportFileGenerator.o cmExportInstallFileGenerator.o cmExportSet.o cmExportSetMap.o cmExportTryCompileFileGenerator.o cmExprParserHelper.o cmExternalMakefileProjectGenerator.o cmFileCommand.o cmFileCopier.o cmFileInstaller.o cmFileTime.o cmFileTimeCache.o cmFileTimes.o cmFindBase.o cmFindCommon.o cmFindFileCommand.o cmFindLibraryCommand.o cmFindPackageCommand.o cmFindPathCommand.o cmFindProgramCommand.o cmForEachCommand.o cmFunctionCommand.o cmFSPermissions.o cmGeneratedFileStream.o cmGeneratorExpression.o cmGeneratorExpressionContext.o cmGeneratorExpressionDAGChecker.o cmGeneratorExpressionEvaluationFile.o cmGeneratorExpressionEvaluator.o cmGeneratorExpressionLexer.o cmGeneratorExpressionNode.o cmGeneratorExpressionParser.o cmGeneratorTarget.o cmGetCMakePropertyCommand.o cmGetDirectoryPropertyCommand.o cmGetFilenameComponentCommand.o cmGetPipes.o cmGetPropertyCommand.o cmGetSourceFilePropertyCommand.o cmGetTargetPropertyCommand.o cmGetTestPropertyCommand.o cmGlobalCommonGenerator.o cmGlobalGenerator.o cmGlobalUnixMakefileGenerator3.o cmGlobVerificationManager.o cmHexFileConverter.o cmIfCommand.o cmIncludeCommand.o cmIncludeGuardCommand.o cmIncludeDirectoryCommand.o cmIncludeRegularExpressionCommand.o cmInstallCommand.o cmInstallCommandArguments.o cmInstallDirectoryGenerator.o cmInstallExportGenerator.o cmInstallFilesCommand.o cmInstallFilesGenerator.o cmInstallGenerator.o cmInstallScriptGenerator.o cmInstallSubdirectoryGenerator.o cmInstallTargetGenerator.o cmInstallTargetsCommand.o cmInstalledFile.o cmLinkDirectoriesCommand.o cmLinkItem.o cmLinkLineComputer.o cmLinkLineDeviceComputer.o cmListCommand.o cmListFileCache.o cmLocalCommonGenerator.o cmLocalGenerator.o cmLocalUnixMakefileGenerator3.o cmMSVC60LinkLineComputer.o cmMacroCommand.o cmMakeDirectoryCommand.o cmMakefile.o cmMakefileExecutableTargetGenerator.o cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o cmMakefileUtilityTargetGenerator.o cmMarkAsAdvancedCommand.o cmMathCommand.o cmMessageCommand.o cmMessenger.o cmNewLineStyle.o cmOSXBundleGenerator.o cmOptionCommand.o cmOrderDirectories.o cmOutputConverter.o cmParseArgumentsCommand.o cmPathLabel.o cmPolicies.o cmProcessOutput.o cmProjectCommand.o cmProperty.o cmPropertyDefinition.o cmPropertyDefinitionMap.o cmPropertyMap.o cmReturnCommand.o cmRulePlaceholderExpander.o cmScriptGenerator.o cmSearchPath.o cmSeparateArgumentsCommand.o cmSetCommand.o cmSetDirectoryPropertiesCommand.o cmSetPropertyCommand.o cmSetSourceFilesPropertiesCommand.o cmSetTargetPropertiesCommand.o cmSetTestsPropertiesCommand.o cmSiteNameCommand.o cmSourceFile.o cmSourceFileLocation.o cmState.o cmStateDirectory.o cmStateSnapshot.o cmStringReplaceHelper.o cmStringCommand.o cmSubdirCommand.o cmSystemTools.o cmTarget.o cmTargetCompileDefinitionsCommand.o cmTargetCompileFeaturesCommand.o cmTargetCompileOptionsCommand.o cmTargetIncludeDirectoriesCommand.o cmTargetLinkLibrariesCommand.o cmTargetPropCommandBase.o cmTargetPropertyComputer.o cmTargetSourcesCommand.o cmTest.o cmTestGenerator.o cmTimestamp.o cmTryCompileCommand.o cmTryRunCommand.o cmUnexpectedCommand.o cmUnsetCommand.o cmUVHandlePtr.o cmUVProcessChain.o cmVersion.o cmWhileCommand.o cmWorkingDirectory.o cmake.o cmakemain.o cmcmd.o cm_string_view.o cmCommandArgumentLexer.o cmCommandArgumentParser.o cmExprLexer.o cmExprParser.o cmListFileLexer.o Directory.o EncodingCXX.o FStream.o Glob.o RegularExpression.o SystemTools.o EncodingC.o ProcessUNIX.o String.o System.o Terminal.o uv-src-strscpy.c.o uv-src-timer.c.o uv-src-uv-common.c.o uv-src-unix-cmake-bootstrap.c.o uv-src-unix-core.c.o uv-src-unix-fs.c.o uv-src-unix-loop.c.o uv-src-unix-loop-watcher.c.o uv-src-unix-no-fsevents.c.o uv-src-unix-pipe.c.o uv-src-unix-poll.c.o uv-src-unix-posix-hrtime.c.o uv-src-unix-posix-poll.c.o uv-src-unix-process.c.o uv-src-unix-signal.c.o uv-src-unix-stream.c.o -ldl -lrt -o cmake +make[2]: Leaving directory '/<<PKGBUILDDIR>>/Build/Bootstrap.cmk' +loading initial cache file /<<PKGBUILDDIR>>/Build/Bootstrap.cmk/InitialCacheFlags.cmake +Illegal instruction +--------------------------------------------- +Error when bootstrapping CMake: +Problem while running initial CMake +--------------------------------------------- + +I'm working on creating a chroot for download to reproduce the issue.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1860610 b/results/classifier/mode-gemma3:12b/user/1860610 new file mode 100644 index 00000000..31661900 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1860610 @@ -0,0 +1,9 @@ + + +cap_disas_plugin leaks memory + +Looking at origin/master head, the function cap_disas_plugin leaks memory. + +per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close. + +I discovered this running qemu under valgrind.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1861161 b/results/classifier/mode-gemma3:12b/user/1861161 new file mode 100644 index 00000000..28776288 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1861161 @@ -0,0 +1,61 @@ + + +qemu-arm-static stuck with 100% CPU when cross-compiling emacs + +Hello, + +I'm trying to build multi-arch docker images for https://hub.docker.com/r/silex/emacs. + +Here is the machine I'm building on: + +root@ubuntu-4gb-fsn1-1:~# lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 18.04.3 LTS +Release: 18.04 +Codename: bionic +root@ubuntu-4gb-fsn1-1:~# uname -a +Linux ubuntu-4gb-fsn1-1 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux + +Whenever I try to build the following alpine Dockerfile https://gitlab.com/Silex777/docker-emacs/blob/master/26.3/alpine/3.9/dev/Dockerfile with this command: + +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build --pull -t test --platform arm . + +It builds fine until this: + +root@ubuntu-4gb-fsn1-1:~# ps -ef | grep qemu +root 26473 26465 99 14:26 pts/0 01:59:58 /usr/bin/qemu-arm-static ../src/bootstrap-emacs -batch --no-site-file --no-site-lisp --eval (setq load-prefer-newer t) -f batch-byte-compile emacs-lisp/macroexp.el + +This is supposed to take a few seconds, but in practice it takes 100% CPU and never ends. When I strace the process I see this: + +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) +getdents64(5, /* 0 entries */, 2048) = 0 +lseek(5, 0, SEEK_SET) = 0 +getdents64(5, /* 5 entries */, 2048) = 120 +tgkill(5875, 5878, SIGRT_2) = -1 EAGAIN (Resource temporarily unavailable) + +It happens with all the QEMU versions I tested: +- 2.11.1 (OS version) +- 4.1.1-1 (from multiarch/qemu-user-static:4.1.1-1) +- 4.2.0-2 (from multiarch/qemu-user-static) + +Any ideas of what I could do to debug it further? + +Kind regards, +Philippe
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1861341 b/results/classifier/mode-gemma3:12b/user/1861341 new file mode 100644 index 00000000..241e9ac3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1861341 @@ -0,0 +1,32 @@ + + +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/mode-gemma3:12b/user/1862167 b/results/classifier/mode-gemma3:12b/user/1862167 new file mode 100644 index 00000000..e5e8c5db --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1862167 @@ -0,0 +1,5 @@ + + +Variation of SVE register size (qemu-user-aarch64) + +Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1863445 b/results/classifier/mode-gemma3:12b/user/1863445 new file mode 100644 index 00000000..150d2f95 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1863445 @@ -0,0 +1,18 @@ + + +assertion failed at translate-all.c:2523 with version 3.1.1 + +I was trying to debug a userspace binary with radare2 and met the following assertion in qemu: + +``` +qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed. +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987 +``` + +``` +# qemu-mipsel --version +qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30) +Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers +``` + +not much to add. seems like qemu is not properly checking for valid addresses
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1866577 b/results/classifier/mode-gemma3:12b/user/1866577 new file mode 100644 index 00000000..639797a6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1866577 @@ -0,0 +1,15 @@ + + +powerpc-none-eabi-gdb.exe GDB 9.1 with QEMU 4.2 gdb-stub comes with Reply contains invalid hex digit 79 + +I am using powerpc-none-eabi-gdb with qemu 4.2, but it comes with +the following error: + +undefinedC:\CI-Tools\msys64\powerpc-none-eabi\usr\local\bin\powerpc-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. + +```Not implemented stop reason (assuming exception): undefined``` +The target architecture is assumed to be powerpc:603 + +``` +Reply contains invalid hex digit 79 +```
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1869073 b/results/classifier/mode-gemma3:12b/user/1869073 new file mode 100644 index 00000000..52e0d8af --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1869073 @@ -0,0 +1,9 @@ + + +qemu-arm-static crashes "segmentation fault" when running "git clone -s" + +I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc". + +The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault". + +I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1869782 b/results/classifier/mode-gemma3:12b/user/1869782 new file mode 100644 index 00000000..da15bf50 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1869782 @@ -0,0 +1,15 @@ + + +qemu-arm-static crashes "segmentation fault" when running "svn checkout" + +I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this. + +Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420 + +I don't get this error with an armv7h chroot. + +Maybe now I'll just try to remove all uses of svn in my build scripts... + +Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it... + +Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1870477 b/results/classifier/mode-gemma3:12b/user/1870477 new file mode 100644 index 00000000..2b603f26 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1870477 @@ -0,0 +1,35 @@ + + +qemu-arm hangs when golang running test + + +1. Environment: +Ubuntu 16.04.5 X86_64 +qemu-arm version 4.2.0 +go version go 1.14.1 linux/arm + +2. Summary: +Sometimes "go run test.go" command hang + + +3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500 + + +test.go +====================================== +package main +import "fmt" +func main(){ + for i:=0; i<1000; i++ { + fmt.Printf("[%d] Hello world\n", i) + } +} +====================================== + +i tested "go run test.go" command called 500 times at qemu arm env. +qemu hangs about 200~300. + +attached strace log. + +please check. +thanks
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1871798 b/results/classifier/mode-gemma3:12b/user/1871798 new file mode 100644 index 00000000..1faceab7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1871798 @@ -0,0 +1,5 @@ + + +Fails to start on Windows host without explicit --disable-pie + +Since commit d2cd29e30736afd4a1e8cac3cf4da360bbc65978, which removed the x86 conditional around PIE, QEMU completely fails to start on a Windows host unless --disable-pie is explicitly given at build time. Even just requesting the help text doesn't work. To make testing easier, this can be replicated with Wine.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1873337 b/results/classifier/mode-gemma3:12b/user/1873337 new file mode 100644 index 00000000..de185244 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1873337 @@ -0,0 +1,13 @@ + + +Arrow keys press is double in some programs in Dos + +Hello, +im trying to use Qemu for Dos machines. + + But there is problem with some programs that arrow key press is double in some problems. As advanced Filemanagers - Dos Navigator or File Wizard, same Scandisk. + +There is gif: +https://www.vogons.org/download/file.php?id=77141&mode=view + + Its blocking to use such problem, unless you use Numlock key for it, but im used 25+ years to arrow keys and its bug.. I guess that it would mess with some games too.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1873898 b/results/classifier/mode-gemma3:12b/user/1873898 new file mode 100644 index 00000000..ddc8d8d9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1873898 @@ -0,0 +1,40 @@ + + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1874674 b/results/classifier/mode-gemma3:12b/user/1874674 new file mode 100644 index 00000000..c5589334 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1874674 @@ -0,0 +1,8 @@ + + +[Feature request] acceptance test class to run user-mode binaries + +Currently the acceptance test framework only target system-mode emulation. +It would be useful to test user-mode too. + +Ref: https://<email address hidden>/msg626610.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1876 b/results/classifier/mode-gemma3:12b/user/1876 new file mode 100644 index 00000000..800137ea --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1876 @@ -0,0 +1,3 @@ + + +Host wayland gtk problem diff --git a/results/classifier/mode-gemma3:12b/user/1876373 b/results/classifier/mode-gemma3:12b/user/1876373 new file mode 100644 index 00000000..e84f27a4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1876373 @@ -0,0 +1,50 @@ + + +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/mode-gemma3:12b/user/1877706 b/results/classifier/mode-gemma3:12b/user/1877706 new file mode 100644 index 00000000..b07982e4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1877706 @@ -0,0 +1,26 @@ + + + [Feature request] qemu does not support for Octeon MIPS64 on X86 + +Description of problem: + +I use mips64-octeon-linux-gnu-gcc cross toolchain on X86,and generate binary file. + +> mips64-octeon-linux-gnu-gcc hello.c -static +> file a.out +> a.out: ELF 32-bit MSB executable, MIPS, N32 MIPS64 rel2 version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, not stripped + +I execute it with mips64-linux-user mode in qemu, it is invalid. + +> ./qemu-5.0.0/mips64-linux-user/qemu-mips64 a.out +> a.out: Invalid ELF image for this architecture + +when I choose mips-linux-user mode, it regards as illegal instruction. + +> ./qemu-5.0.0/mips-linux-user/qemu-mips a.out +> qemu: uncaught target signal 4 (Illegal instruction) - core dumped +> Illegal instruction (core dumped) + +I would like to know, is this due to my problem or does qemu not support Octeon MIPS64 on X86? + +if qemu has supported Octeon MIPS64 on X86, how can I emulate it.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1877794 b/results/classifier/mode-gemma3:12b/user/1877794 new file mode 100644 index 00000000..eea7c876 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1877794 @@ -0,0 +1,5 @@ + + +Constant Folding on 64-bit Subtraction causes SIGILL on linux-user glxgears ppc64le to x86_64 by way of generating bad shift instruction with c=-1 + +Hello, I've been recently working on my own little branch of QEMU implementing the drm IOCTLs, when I discovered that glxgears seems to crash in GLXSwapBuffers(); with a SIGILL. I investigated this for about 2 weeks, manually trying to trace the call stack, only to find that we seemingly crash in a bad shift instruction. Originally intended to be an shr_i64 generated to an RLDICL, we end up with an all ones(-1) c value, which gets thrown to the macro for generating the MB, and replaces the instruction with mostly ones. This new instruction, FFFFFFE0 is invalid on ppc64le, and crashes in a host SIGILL in codegen_buffer. I tried to see if the output of translate.c had this bad instruction, but all I got were two (shr eax, cl) instructions, and upon creating a test program with shr (eax, cl) in it, nothing happened. Then figuring that there was nothing actually wrong with the instruction in the first place, I turned my eye to the optimizer, and completely disabled constant folding for arithmetic instructions. This seemed to actually resolve the issue, and then I slowly enabled constant folding again on various instructions only to find that enabling not on the shifts, but on subtraction seemed to cause the bug to reappear. I am bewildered and frankly at this point I'm not sure I have a chance in hell of figuring out what causes it, so I'm throwing it here.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1878501 b/results/classifier/mode-gemma3:12b/user/1878501 new file mode 100644 index 00000000..ca0d6339 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1878501 @@ -0,0 +1,33 @@ + + +qemu-i386 does not define AT_SYSINFO + +qemu-i386 does not define the AT_SYSINFO auxval when running i386 Linux binaries. + +On most libcs, this is properly handled, but this is mandatory for the i686 Bionic (Android) libc or it will segfault. + +This is due to a blind assumption that getauxval(AT_SYSINFO) will return a valid function pointer: + +The code varies from version to version, but it looks like this: + +void *__libc_sysinfo; +// mangled as _Z19__libc_init_sysinfov +void __libc_init_sysinfo() { + bool dummy; + // __bionic_getauxval = getauxval + __libc_sysinfo = reinterpret_cast<void *>(__bionic_getauxval(AT_SYSINFO, dummy)); +} + +A simple way to reproduce is to compile a basic C program against the NDK: + +int main(void) { return 0; } + +$ i686-linux-android-clang -static empty.c -o empty +$ qemu-i386 -cpu max ./empty +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault + +The place where it segfaults is misleading: It will, at least on the current NDK, crash on __set_thread_area, this is due to it calling a function pointer to __libc_sysinfo returned by __kernel_syscall. + +QEMU 4.1.1 (aarch64) +Pixel 2 XL via Termux
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1878627 b/results/classifier/mode-gemma3:12b/user/1878627 new file mode 100644 index 00000000..38fbd633 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1878627 @@ -0,0 +1,13 @@ + + +audio/mixeng build failure using Clang 10 + +When building with Clang 10 on Fedora 32, we get: + + CC audio/mixeng.o + audio/mixeng.c:274:34: error: implicit conversion from 'unsigned int' to 'float' changes value from 4294967295 to 4294967296 [-Werror,-Wimplicit-int-float-conversion] + static const float float_scale = UINT_MAX / 2.f; + ^~~~~~~~ ~ + /usr/lib64/clang/10.0.0/include/limits.h:56:37: note: expanded from macro 'UINT_MAX' + #define UINT_MAX (__INT_MAX__ *2U +1U) + ~~~~~~~~~~~~~~~~~^~~
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1880225 b/results/classifier/mode-gemma3:12b/user/1880225 new file mode 100644 index 00000000..d1b12f97 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1880225 @@ -0,0 +1,139 @@ + + +Emulation of some arm programs fail with "Assertion `have_guest_base' failed." + +This issue is observer with QEMU ToT, checked out around May 15th (but I believe it is present in current master too), and wasn't present in QEMU v5.0.0. + +I am using 32-bit Intel(R) Pentium(R) M processor 1.73GHz host. + +Arm cross-compiler is a standard cross-compiler that comes with Debian-based distributions, and gcc version is: + +$ arm-linux-gnueabi-gcc --version +arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0 + +Compile this program with cross compiler: + +$ arm-linux-gnueabi-gcc -O2 -static toupper_string.c -o toupper_string-arm + +Emulation with QEMU v5.0.0 is correct, and gives expected output: + +$ ~/Build/qemu-5.0.0/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +CONTROL RESULT: (toupper_string) + nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq + NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ + +While, in case of QEMU master it fails: + +$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm +qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: probe_guest_base: Assertion `have_guest_base' failed. +Aborted + +There are many other programs that exibit the same behavior. The failure is arm-sprecific. + + +----------------------------------------------------- + +source code: (let's call this file toupper_string.c) (similar file is also in attachment) + + +#include <stdlib.h> +#include <string.h> +#include <stdio.h> +#include <unistd.h> + + +#define MAX_STRING_LENGHT 15 +#define NUMBER_OF_RANDOM_STRINGS 100 +#define DEFAULT_NUMBER_OF_REPETITIONS 30000 +#define MAX_NUMBER_OF_REPETITIONS 1000000000 +#define NUMBER_OF_CONTROL_PRINT_ITEMS 5 + +/* Structure for keeping an array of strings */ +struct StringStruct { + char chars[MAX_STRING_LENGHT + 1]; +}; + +/** + * Sets characters of the given string to random small letters a-z. + * @param s String to get random characters. + * @len Length of the input string. + */ +static void gen_random_string(char *chars, const int len) +{ + static const char letters[] = "abcdefghijklmnopqrstuvwxyz"; + + for (size_t i = 0; i < len; i++) { + chars[i] = letters[rand() % (sizeof(letters) - 1)]; + } + chars[len] = 0; +} + +void main (int argc, char* argv[]) +{ + struct StringStruct random_strings[NUMBER_OF_RANDOM_STRINGS]; + struct StringStruct strings_to_be_uppercased[NUMBER_OF_RANDOM_STRINGS]; + int32_t number_of_repetitions = DEFAULT_NUMBER_OF_REPETITIONS; + int32_t option; + + /* Parse command line options */ + while ((option = getopt(argc, argv, "n:")) != -1) { + if (option == 'n') { + int32_t user_number_of_repetitions = atoi(optarg); + /* Check if the value is a negative number */ + if (user_number_of_repetitions < 1) { + fprintf(stderr, "Error ... Value for option '-n' cannot be a " + "negative number.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is a string or zero */ + if (user_number_of_repetitions == 0) { + fprintf(stderr, "Error ... Invalid value for option '-n'.\n"); + exit(EXIT_FAILURE); + } + /* Check if the value is too large */ + if (user_number_of_repetitions > MAX_NUMBER_OF_REPETITIONS) { + fprintf(stderr, "Error ... Value for option '-n' cannot be " + "more than %d.\n", MAX_NUMBER_OF_REPETITIONS); + exit(EXIT_FAILURE); + } + number_of_repetitions = user_number_of_repetitions; + } else { + exit(EXIT_FAILURE); + } + } + + /* Create an array of strings with random content */ + srand(1); + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + gen_random_string(random_strings[i].chars, MAX_STRING_LENGHT); + } + + /* Perform uppercasing of a set of random strings multiple times */ + for (size_t j = 0; j < number_of_repetitions; j++) { + /* Copy initial set of random strings to the set to be uppercased */ + memcpy(strings_to_be_uppercased, random_strings, + NUMBER_OF_RANDOM_STRINGS * (MAX_STRING_LENGHT + 1)); + /* Do actual changing case to uppercase */ + for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) { + int k = 0; + + while (strings_to_be_uppercased[i].chars[k]) { + char ch = strings_to_be_uppercased[i].chars[k] - 32; + memcpy((void *)strings_to_be_uppercased[i].chars + k, + &ch, 1); + k++; + } + } + } + + /* Control printing */ + printf("CONTROL RESULT: (toupper_string)\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", random_strings[i].chars); + } + printf("\n"); + for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) { + printf(" %s", strings_to_be_uppercased[i].chars); + } + printf("\n"); +}
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1880287 b/results/classifier/mode-gemma3:12b/user/1880287 new file mode 100644 index 00000000..ee9dfec4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1880287 @@ -0,0 +1,13 @@ + + +gcc crashes in hppa emulation + +There seems to be a translation bug in the qemu-hppa (qemu v5.0.0) emulation: +A stripped down testcase (taken from Linux kernel build) is attached. + +In there is "a.sh", a shell script which calls gcc-9 (fails with both debian gcc-9.3.0-11 or gcc-9.3.0-12). and "a.iii", the preprocessed source. + +When starting a.sh, in the emulation gcc crashes with segfault. +On real hardware gcc succeeds to compile the source. + +In a hppa-user chroot running "apt update && apt install gcc-9" should be sufficient to get the needed reproducer environment.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1880332 b/results/classifier/mode-gemma3:12b/user/1880332 new file mode 100644 index 00000000..1e214fed --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1880332 @@ -0,0 +1,9 @@ + + +Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault) + +I've come across a very specific situation, but I'm sure it could be replicated in other cases. + +In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs. + +I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1880518 b/results/classifier/mode-gemma3:12b/user/1880518 new file mode 100644 index 00000000..26ab3768 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1880518 @@ -0,0 +1,18 @@ + + +issue while installing docker inside s390x container + +This is in reference to https://github.com/multiarch/qemu-user-static/issues/108. +I am facing issue while installing docker inside s390x container under qemu on Ubuntu 18.04 host running on amd64. +Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel host after running +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +enabled +interpreter /usr/bin/qemu-s390x-static +flags: F +offset 0 +magic 7f454c4602020100000000000000000000020016 +mask ffffffffffffff00fffffffffffffffffffeffff +I could get docker service up with the following trick. +printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' > /etc/docker/daemon.json +But even though docker service comes up, images are not getting pulled, docker pull fails with the following error. +failed to register layer: Error processing tar file(exit status 1):
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1880722 b/results/classifier/mode-gemma3:12b/user/1880722 new file mode 100644 index 00000000..f0c07f2b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1880722 @@ -0,0 +1,16 @@ + + +Problems related to checking page crossing in use_goto_tb() + +The discussion that led to this bug discovery can be found in this +mailing list thread: +https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html + +A workaround for this problem would be to check for page crossings for +both the user and system modes in the use_goto_tb() function across +targets. Some targets like "hppa" already implement this fix but others +don't. + +To solve the root cause of this problem, the linux-user/mmap.c should +be fixed to do all the invalidations required. By doing so, up to 6.93% +performance improvements will be achieved.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1881450 b/results/classifier/mode-gemma3:12b/user/1881450 new file mode 100644 index 00000000..efb29aca --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1881450 @@ -0,0 +1,25 @@ + + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1882123 b/results/classifier/mode-gemma3:12b/user/1882123 new file mode 100644 index 00000000..68e4e689 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1882123 @@ -0,0 +1,60 @@ + + +ARM cpu emulation regression on QEMU 4.2.0 + +[*] Summary + +Latest QEMU has an ARM CPU emulation regression. +Regression is reproducible by building any C# project with .NET Core SDK 3.1.300 on Debian 10 armhf. + +Affected releases: QEMU 4.2.0, 5.0.0 +Not affected releases: QEMU 4.1.0, QEMU 4.1.1 + + +[*] Detail + +qemu-system-arm fails to run .NET Core SDK 3.1 on Debian 10 armhf. + +I occasionally test my C# projects on the virtual armhf/arm64 system emulated by QEMU. +MSBuild, a build engine of the .NET Core SDK, crashes on QEMU 4.2.0 or later. +The crash only happens when MSBuild tries to do any JIT compiling (dotnet build / dotnet test). + +I attached MSBuild crash logs. MSBuild always crashes with SEHException, which means it tried to call C binary from .NET binary. + +The issue affects QEMU 4.2.0 and 5.0.0. +QEMU 4.1.0, 4.1.1, and real Raspberry Pi 2 machine is not affected by this issue, and .NET Core SDK works completely fine. +Thus, I think an ARM CPU regression happened between QEMU 4.1.1 ~ QEMU 4.2.0. + + +[*] Environment + +[Host OS] +Distribution: Linux Mint 19.3 amd64 +CPU: AMD Ryzen 5 3600 +Kernel: Ubuntu 5.3.0-51-generic + +[QEMU Arguments] +qemu-system-arm \ + -smp 3 -M virt -m 4096 \ + -kernel vmlinuz-4.19.0-9-armmp-lpae \ + -initrd initrd.img-4.19.0-9-armmp-lpae \ + -append "root=/dev/vda2" \ + -drive if=none,file=debian_arm.qcow2,format=qcow2,id=hd \ + -device virtio-blk-device,drive=hd \ + -netdev user,id=mynet,hostfwd=tcp::<PORT>-:22 \ + -device virtio-net-device,netdev=mynet \ + -device virtio-rng-device\ + +[QEMU Guest OS] +Distribution: Debian 10 Buster armhf +Kernel: Debian 4.19.0-9-armmp-lpae +.NET Core SDK: 3.1.300 + +[Raspberry Pi 2] +Distribution: Raspberry Pi OS Buster armhf (20200527) + +[Tested C# Projects] +This is a list of C# projects I have tested on QEMU and RPI2. +- https://github.com/ied206/Joveler.DynLoader +- https://github.com/ied206/Joveler.Compression +- https://github.com/ied206/ManagedWimLib
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1883268 b/results/classifier/mode-gemma3:12b/user/1883268 new file mode 100644 index 00000000..b8acc4a8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1883268 @@ -0,0 +1,39 @@ + + +random errors on aarch64 when executing __aarch64_cas8_acq_rel + +Hello, + +Since I upgraded to qemu-5.0 when executing the GCC testsuite, +I've noticed random failures of g++.dg/ext/sync-4.C. + +I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain) + +The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI. + +In seems the problem occurs in f13, which leads to a call to abort() + +The preprocessed version of f13/t13 are as follows: +static bool f13 (void *p) __attribute__ ((noinline)); +static bool f13 (void *p) +{ + return (__sync_bool_compare_and_swap((ditype*)p, 1, 2)); +} +static void t13 () +{ + try { + f13(0); + } + catch (...) { + return; + } + abort(); +} + + +When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084) +__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0) + +I'm not quite sure what's wrong :-( + +I've not noticed such random problems with native aarch64 hardware.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1883560 b/results/classifier/mode-gemma3:12b/user/1883560 new file mode 100644 index 00000000..4770202b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1883560 @@ -0,0 +1,33 @@ + + +mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build + +From time to time I find check-tcg crashes with a one of the MIPS binaries. The last time it crashed was running the test: + + ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-user/threadcount + +Inevitably after some time noodling around wondering what could be causing this weird behaviour I wonder if it is a build issue. I wipe all the mips* build directories, re-run configure and re-build and voila problem goes away. + +It seems there must be some sort of build artefact which isn't being properly re-generated on a build update which causes weird problems. Additional data point if I: + + rm -rf mips64el-linux-user + ../../configure + make + +then I see failures in mip32 builds - eg: + + GEN mipsn32el-linux-user/config-target.h + In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10, + from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, + from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5: + /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef + #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H + + make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1 + make[1]: *** Waiting for unfinished jobs.... + +which implies there is a cross dependency between different targets somewhere. If I executed: + + rm -rf mips* + +before re-configuring and re-building then everything works again.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1883784 b/results/classifier/mode-gemma3:12b/user/1883784 new file mode 100644 index 00000000..38db32ed --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1883784 @@ -0,0 +1,11 @@ + + +[ppc64le] qemu behavior differs from ppc64le hardware + +I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing). + +I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu. + +I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked). They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value). + +Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1884982 b/results/classifier/mode-gemma3:12b/user/1884982 new file mode 100644 index 00000000..dd273532 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1884982 @@ -0,0 +1,16 @@ + + +User-emu documentation mentions inexistent "runtime" downloads + +The official documentation for the user-space emulator[1] contains many references to binary blobs no longer provided by QEMU.org for download. The parts mentioning them should be rephrased to avoid confusion and instructions for building these components should be provided (maybe as a reference to the LFS book with some scripts). The specific parts are: + +* qemu-XXX-i386-wine.tar.gz, a wine build under the prefix /wine. +* qemu-runtime-i386-XXX-.tar.gz, a glibc build. + + [1]: https://www.qemu.org/docs/master/user/main.html + +In addition, the documentation contains many other instances of inexistent "tar.gz" files, such as in "Network emulation". Most of these are inherited from the days of texi documentation more than 10 years ago, and they are so old that GitHub's blame have become unreliable. Someone really should run `fgrep -r 'tar.gz' doc' on the QEMU source tree. + +The issue was previously reported as [2], but nobody bother enough to google the filename to find out where the confused user got the idea from. + + [2]: https://<email address hidden>/msg569174.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1885332 b/results/classifier/mode-gemma3:12b/user/1885332 new file mode 100644 index 00000000..6555745c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1885332 @@ -0,0 +1,96 @@ + + +Error in user-mode calculation of ELF aux vector's AT_PHDR + + +I have an (admittedly strange) statically-linked ELF binary for Linux that runs just fine on top of the Linux kernel in QEMU full-system emulation, but crashes before main in user-mode emulation. Specifically, it crashes when initializing thread-local storage in glibc's _dl_aux_init, because it reads out a strange value from the AT_PHDR entry of the ELF aux vector. + +The binary has these program headers: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065874 0x00075874 0x00075874 0x00570 0x00570 R 0x4 + PHDR 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x00900000 0x00900000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65de8 0x65de8 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03f44 0x03f44 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +If I build the Linux kernel with the following patch to the very end of create_elf_tables in fs/binfmt_elf.c + + /* Put the elf_info on the stack in the right place. */ + elf_addr_t *my_auxv = (elf_addr_t *) mm->saved_auxv; + int i; + for (i = 0; i < 15; i++) { + printk("0x%x = 0x%x", my_auxv[2*i], my_auxv[(2*i)+ 1]); + } + if (copy_to_user(sp, mm->saved_auxv, ei_index * sizeof(elf_addr_t))) + return -EFAULT; + return 0; + +and run it like this: + + qemu-system-arm \ + -M versatilepb \ + -nographic \ + -dtb ./dts/versatile-pb.dtb \ + -kernel zImage \ + -M versatilepb \ + -m 128M \ + -append "earlyprintk=vga,keep" \ + -initrd initramfs + +after I've built the kernel initramfs like this (where "init" is the binary in question): + + make ARCH=arm versatile_defconfig + make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- all -j10 + cp "$1" arch/arm/boot/init + cd arch/arm/boot + echo init | cpio -o --format=newc > initramfs + +then I get the following output. This is the kernel's view of the aux vector for this binary: + + 0x10 = 0x1d7 + 0x6 = 0x1000 + 0x11 = 0x64 + 0x3 = 0x900000 + 0x4 = 0x20 + 0x5 = 0xb + 0x7 = 0x0 + 0x8 = 0x0 + 0x9 = 0x101b8 + 0xb = 0x0 + 0xc = 0x0 + 0xd = 0x0 + 0xe = 0x0 + 0x17 = 0x0 + 0x19 = 0xbec62fb5 + +However, if I run "qemu-arm -g 12345 binary" and use GDB to peek at the aux vector at the beginning of __libc_start_init (for example, using this Python GDB API script: https://gist.github.com/langston-barrett/5573d64ae0c9953e2fa0fe26847a5e1e), then I see the following values: + + AT_PHDR = 0xae000 + AT_PHENT = 0x20 + AT_PHNUM = 0xb + AT_PAGESZ = 0x1000 + AT_BASE = 0x0 + AT_FLAGS = 0x0 + AT_ENTRY = 0x10230 + AT_UID = 0x3e9 + AT_EUID = 0x3e9 + AT_GID = 0x3e9 + AT_EGID = 0x3e9 + AT_HWCAP = 0x1fb8d7 + AT_CLKTCK = 0x64 + AT_RANDOM = -0x103c0 + AT_HWCAP2 = 0x1f + AT_NULL = 0x0 + +The crucial difference is in AT_PHDR (0x3), which is indeed the virtual address of the PHDR segment when the kernel calculates it, but is not when QEMU calculates it. + +qemu-arm --version +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.26)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1886097 b/results/classifier/mode-gemma3:12b/user/1886097 new file mode 100644 index 00000000..770fce5d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1886097 @@ -0,0 +1,35 @@ + + +Error in user-mode calculation of ELF program's brk + +There's a discrepancy between the way QEMU user-mode and Linux calculate the initial program break for statically-linked binaries. I have a binary with the following segments: + + Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + EXIDX 0x065a14 0x00075a14 0x00075a14 0x00588 0x00588 R 0x4 + PHDR 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x0a3000 0x000a3000 0x000a3000 0x00160 0x00160 R 0x1000 + LOAD 0x000000 0x00010000 0x00010000 0x65fa0 0x65fa0 R E 0x10000 + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + NOTE 0x000114 0x00010114 0x00010114 0x00044 0x00044 R 0x4 + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x8 + GNU_RELRO 0x066b7c 0x00086b7c 0x00086b7c 0x00484 0x00484 R 0x1 + LOAD 0x07e000 0x00089000 0x00089000 0x03ff4 0x03ff4 R E 0x1000 + LOAD 0x098000 0x00030000 0x00030000 0x01000 0x01000 RW 0x1000 + +The call to set_brk in Linux's binfmt_elf.c receives these arguments: + + set_brk(0xa3160, 0xa3160, 1) + +Whereas in QEMU, info->brk gets set to 0x88f00. When the binary is run in QEMU, it crashes on the second call to brk, whereas it runs fine on real ARM hardware. I think the trouble is that the program break is set to an address lower than the virtual address of a LOAD segment (the program headers, in this case). + +I believe that this discrepancy arises because in QEMU, info->brk is only incremented when the LOAD segment in question has PROT_WRITE. For this binary, the LOAD segment with write permissions and the highest virtual address is + + LOAD 0x066b7c 0x00086b7c 0x00086b7c 0x02384 0x02384 RW 0x10000 + +which overlaps with the TLS segment: + + TLS 0x066b7c 0x00086b7c 0x00086b7c 0x00010 0x00030 R 0x4 + +However, the Linux kernel puts the program break after the loadable segment with the highest virtual address, regardless of flags. So I think the fix is for QEMU to do the same.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1886793 b/results/classifier/mode-gemma3:12b/user/1886793 new file mode 100644 index 00000000..284ea47d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1886793 @@ -0,0 +1,168 @@ + + +"go install" command fails while running inside s390x docker container on x86_64 host using qemu + +Steps to reproduce the issue: + +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +Build the following Docker Image using following Dockerfile.s390x using command docker build -t test/crossbuild:latest-s390x -f Dockerfile.s390x . + +Dockerfile.s390x + +FROM alpine:3.11 as qemu + +ARG QEMU_VERSION=5.0.0-2 +ARG QEMU_ARCHS="s390x" + +RUN apk --update add curl + +#Enable non-native runs on amd64 architecture hosts +RUN for i in ${QEMU_ARCHS}; do curl -L https://github.com/multiarch/qemu-user-static/releases/download/v${QEMU_VERSION}/qemu-${i}-static.tar.gz | tar zxvf - -C /usr/bin; done +RUN chmod +x /usr/bin/qemu-* + +FROM s390x/golang:1.14.2-alpine3.11 +MAINTAINER LoZ Open Source Ecosystem (https://www.ibm.com/developerworks/community/groups/community/lozopensource) + +ARG MANIFEST_TOOL_VERSION=v1.0.2 + +#Enable non-native builds of this image on an amd64 hosts. +#This must be the first RUN command in this file! +COPY --from=qemu /usr/bin/qemu-*-static /usr/bin/ + +#Install su-exec for use in the entrypoint.sh (so processes run as the right user) +#Install bash for the entry script (and because it's generally useful) +#Install curl to download glide +#Install git for fetching Go dependencies +#Install ssh for fetching Go dependencies +#Install mercurial for fetching go dependencies +#Install wget since it's useful for fetching +#Install make for building things +#Install util-linux for column command (used for output formatting). +#Install grep and sed for use in some Makefiles (e.g. pulling versions out of glide.yaml) +#Install shadow for useradd (it allows to use big UID) +RUN apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +RUN apk upgrade --no-cache + +#Disable ssh host key checking +RUN echo 'Host *' >> /etc/ssh/ssh_config \ + && echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +ENV CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +RUN go install -v std + +#Install glide +RUN go get github.com/Masterminds/glide +ENV GLIDE_HOME /home/user/.glide + +#Install dep +RUN go get github.com/golang/dep/cmd/dep + +#Install ginkgo CLI tool for running tests +RUN go get github.com/onsi/ginkgo/ginkgo + +#Install linting tools. +RUN wget -O - -q https://install.goreleaser.com/github.com/golangci/golangci-lint.sh | sh -s v1.20.0 +RUN golangci-lint --version + +#Install license checking tool. +RUN go get github.com/pmezard/licenses + +#Install tool to merge coverage reports. +RUN go get github.com/wadey/gocovmerge + +#Install CLI tool for working with yaml files +RUN go get github.com/mikefarah/yaml + +#Delete all the Go sources that were downloaded, we only rely on the binaries +RUN rm -rf /go/src/* + +#Install vgo (should be removed once we take Go 1.11) +RUN go get -u golang.org/x/vgo + +#Ensure that everything under the GOPATH is writable by everyone +RUN chmod -R 777 $GOPATH + +RUN curl -sSL https://github.com/estesp/manifest-tool/releases/download/${MANIFEST_TOOL_VERSION}/manifest-tool-linux-s390x > manifest-tool && \ + chmod +x manifest-tool && \ + mv manifest-tool /usr/bin/ + +COPY entrypoint.sh /usr/local/bin/entrypoint.sh +ENTRYPOINT ["/sbin/tini", "--", "/usr/local/bin/entrypoint.sh"] + + + + +The build just hangs at RUN go install -v std + + + +Also, while running the same command inside s390x container on x86_64 host, error Illegal instruction (core dumped) is thrown. +Register x86_64 host with the latest qemu-user-static. +docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + +docker run -it -v /home/test/qemu-s390x-static:/usr/bin/qemu-s390x-static s390x/golang:1.14.2-alpine3.11 + +Inside s390x container: + +apk update && apk add --no-cache su-exec curl bash git openssh mercurial make wget util-linux tini file grep sed shadow +apk upgrade --no-cache + +#Disable ssh host key checking +echo 'Host *' >> /etc/ssh/ssh_config +echo ' StrictHostKeyChecking no' >> /etc/ssh/ssh_config + +#Disable cgo so that binaries we build will be fully static. +export CGO_ENABLED=0 + +#Recompile the standard library with cgo disabled. This prevents the standard library from being +#marked stale, causing full rebuilds every time. +go install -v std +Describe the results you re +This gives the following error: +Illegal instruction (core dumped) + + + +Environment: +x86_64 Ub18.04 4.15.0-101-generic Ubuntu SMP x86_64 GNU/Linux + +QEMU user static version: 5.0.0-2 + +Container application: Docker + +Client: Docker Engine - Community + Version: 19.03.11 + API version: 1.40 + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:12:22 2020 + OS/Arch: linux/amd64 + Experimental: false + +Server: Docker Engine - Community + Engine: + Version: 19.03.11 + API version: 1.40 (minimum version 1.12) + Go version: go1.13.10 + Git commit: 42e35e61f3 + Built: Mon Jun 1 09:10:54 2020 + OS/Arch: linux/amd64 + Experimental: false + containerd: + Version: 1.2.13 + GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 + runc: + Version: 1.0.0-rc10 + GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd + docker-init: + Version: 0.18.0 + GitCommit: fec3683 + +Additional information optionally: +When I build the same Dockerfile.s390x on an s390x machine, it is built successfully.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1887306 b/results/classifier/mode-gemma3:12b/user/1887306 new file mode 100644 index 00000000..1539318e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1887306 @@ -0,0 +1,57 @@ + + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1887318 b/results/classifier/mode-gemma3:12b/user/1887318 new file mode 100644 index 00000000..090caf47 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1887318 @@ -0,0 +1,6 @@ + + +impossible to install in OSX Yosemite 10.10.5 + +the Brew method has glib problems, glib is impossible to install. +the MacPorts method has a very long .log file.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1888165 b/results/classifier/mode-gemma3:12b/user/1888165 new file mode 100644 index 00000000..2b90889a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1888165 @@ -0,0 +1,16 @@ + + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1888303 b/results/classifier/mode-gemma3:12b/user/1888303 new file mode 100644 index 00000000..9c651167 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1888303 @@ -0,0 +1,22 @@ + + +Intermittent buggines with user mode emulation of x86-64 on aarch64 + +QEMU Version: 5.0.0 +./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static + +Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm + +aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. + +On aarch64 machine, invoke: + +./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile + +Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. + +But, about once every 10 times, it will not sefault and will continue working just fine forever. + +The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. + +This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1888728 b/results/classifier/mode-gemma3:12b/user/1888728 new file mode 100644 index 00000000..03fd05e2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1888728 @@ -0,0 +1,21 @@ + + +Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed. + +Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with: + +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed. +Aborted +root@nofan:~/qemu> + +The problem can be worked around by bind-mounting /proc from the host system into the target chroot: + +root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/ +root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/ +bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) +(sid-m68k-sbuild)root@nofan:/# + +Host system is an up-to-date Debian unstable (2020-07-23). + +I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1889033 b/results/classifier/mode-gemma3:12b/user/1889033 new file mode 100644 index 00000000..1635e865 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1889033 @@ -0,0 +1,96 @@ + + +qemu-img permission denied on vmdk creation on CIFS share + + +- on a CIFS mount qemu-img claims not to have permissions to write into a file. +- VMDK sparse file creation succeeds +- VMDK Flat file creation create the flat-file, but fails to write the description-file +- VMDK flat file creation succeeds on native linux mount such as ~/tmp or /tmp +- same effect as root or non-root +- same effect with selinux setenforce 0 + +a) I would have expected that the monolithic flat would have created only one large file just like sparse, but it seems to create a description file, in addition to the storing file. +b) I am aware that qemu-img may have problem opening very large files on CIFS, however, this file is not very large + +Windows-10 latest updated 2004 19041.388 +Linux VM, Fedora-32 in Virtualbox 6.1.12 +# rpm -qa | grep qemu-img +qemu-img-4.2.0-7.fc32.x86_64 + +mount options: +mount -t cifs //10.x,x,x/$shname /mnt/hshare -o defaults,username=gana,rw,uid=1000,gid=1000,vers=3.0 + +[root@fedora ~]# cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +qemu-img: test1.vmdk: Could not write description: Permission denied +[root@fedora createvmdk]# ls -l test1*.* +-rwxr-xr-x. 1 gana gana 104857600 Jul 26 23:02 test1-flat.vmdk +-rwxr-xr-x. 1 gana gana 0 Jul 26 23:02 test1.vmdk +[root@fedora createvmdk]# du -k test1*.* +0 test1-flat.vmdk +0 test1.vmdk +# (doesn't seem to be really flat) + +creation in /tmp works +# cd /tmp +[root@fedora tmp]# qemu-img create -f vmdk test1.vmdk 100M -o subformat=monolithicFlat +Formatting 'test1.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicFlat +[root@fedora tmp]# ls -l /tmp/test1*.* +-rw-r--r--. 1 root root 104857600 Jul 26 22:43 /tmp/test1-flat.vmdk +-rw-r--r--. 1 root root 313 Jul 26 22:43 /tmp/test1.vmdk +[root@fedora createvmdk]# du -k /tmp/test1*.* +4 /tmp/test1-flat.vmdk +4 /tmp/test1.vmdk + +[root@fedora createvmdk]# cat /tmp/test1.vmdk +# Disk DescriptorFile +version=1 +CID=5f13c13d +parentCID=ffffffff +createType="monolithicFlat" + +# Extent description +RW 204800 FLAT "test1-flat.vmdk" 0 + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" + + +On the other-hand creating a sparse file works +cd /mnt/hshare/some/folder/createvmdk/ +[root@fedora createvmdk]# qemu-img create -f vmdk test2.vmdk 100M -o subformat=monolithicSparse +Formatting 'test2.vmdk', fmt=vmdk size=104857600 compat6=off hwversion=undefined subformat=monolithicSparse +[root@fedora createvmdk]# ls l test2*.* +-rwxr-xr-x. 1 gana gana 65536 Jul 26 22:52 test2.vmdk +[root@fedora createvmdk]# du -k /tmp/test2*.* +12 /tmp/test2.vmdk + +test2.vmdk is a binary file +inside it, located among garbled ascii characters is an embedded VMDK description +```` +# Disk DescriptorFile +version=1 +CID=cf302a20 +parentCID=ffffffff +createType="monolithicSparse" + +# Extent description +RW 204800 SPARSE "test2.vmdk" + +# The Disk Data Base +#DDB + +ddb.virtualHWVersion = "4" +ddb.geometry.cylinders = "203" +ddb.geometry.heads = "16" +ddb.geometry.sectors = "63" +ddb.adapterType = "ide" +```
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1889411 b/results/classifier/mode-gemma3:12b/user/1889411 new file mode 100644 index 00000000..e9716f59 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1889411 @@ -0,0 +1,65 @@ + + +RISC-V: Unable to unwind the stack upon signals + +Consider the following program: + +=============================================================== +#include <stdio.h> +#include <stdlib.h> + +#define NOINLINE __attribute__ ((noinline)) + +void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ } + +void NOINLINE level1(void) { abort_me(); } + +void NOINLINE level2(void) { level1(); } + +void NOINLINE level3(void) { level2(); } + +void NOINLINE level4(void) { level3();} + +int main(void) { + level4(); + return 0; +} +=============================================================== + +$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c +$ qemu-riscv64 -g 31337 ./c & +$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c +Reading symbols from c... +Remote debugging using localhost:31337 +Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1... +0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1 +Breakpoint 1 at 0x4000000632: file c.c, line 7. +Continuing. + +Breakpoint 1, abort_me () at c.c:7 +7 abort(); /* trigger SIGABRT */ +#0 abort_me () at c.c:7 +#1 0x0000004000000642 in level1 () at c.c:11 +#2 0x0000004000000658 in level2 () at c.c:15 +#3 0x000000400000066e in level3 () at c.c:19 +#4 0x0000004000000684 in level4 () at c.c:23 +#5 0x000000400000069a in main () at c.c:27 +=============================================================== + +So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack: + +(gdb) c +Continuing. + +Program received signal SIGABRT, Aborted. +0x0000004000858074 in ?? () +(gdb) bt +#0 0x0000004000858074 in ?? () + + + +I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel. + + +Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b +RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/189 b/results/classifier/mode-gemma3:12b/user/189 new file mode 100644 index 00000000..309e76c4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/189 @@ -0,0 +1,3 @@ + + +Intel GVT-g works in X11, segfaults in wayland diff --git a/results/classifier/mode-gemma3:12b/user/1890 b/results/classifier/mode-gemma3:12b/user/1890 new file mode 100644 index 00000000..c33ec828 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1890 @@ -0,0 +1,27 @@ + + +qemu-arm 8.1.0 Error mapping file: Operation not permitted +Description of problem: +failed to execute the cortex-m binary hello_world, and says: +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +Steps to reproduce: +1. +``` +cat > hello_new.c <<EOF +#include <stdio.h> +int main() +{printf("hello world"); return 0;} +EOF +``` +2. +``` +arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs +``` +3. +``` +qemu-arm -cpu cortex-m55 hello_world +qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted +``` +Additional information: +1, version 8.0.4 version is okay\ +2, arm-none-eabi-gcc version is 10.3.1 20210824 (release) diff --git a/results/classifier/mode-gemma3:12b/user/1890545 b/results/classifier/mode-gemma3:12b/user/1890545 new file mode 100644 index 00000000..f7301da8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1890545 @@ -0,0 +1,27 @@ + + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML + +First I creat a file system that is debian(bullseye amd64)on arm64 machine，then I download google-chrome，however, when I ran Google browser, some errors occurred. + +$ google-chrome --no-sandbox +or +$ qemu-x86_64-static google-chrome --no-sandbox + +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1661:1661:0806/074307.502638:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +[1664:1664:0806/074307.504159:ERROR:nacl_fork_delegate_linux.cc(323)] Bad NaCl helper startup ack (0 bytes) +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +[1637:1678:0806/074308.337567:ERROR:file_path_watcher_linux.cc(315)] inotify_init() failed: Function not implemented (38) +Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank" +qemu: unknown option 'type=utility' +[1637:1680:0806/074313.598432:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye. +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap + +Why? +And then I run firefox,it can be opened, but it can't load any web pages and HTML. +I really need help！ +Thank.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1892081 b/results/classifier/mode-gemma3:12b/user/1892081 new file mode 100644 index 00000000..89937f2e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1892081 @@ -0,0 +1,16 @@ + + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions + +Attached below is a matrix multiplication program for double data +types. The program performs the casting operation "(double)rand()" +when generating random numbers. + +This operation calls the integer to float softfloat conversion +function "int32_to_float_64". + +Adding the "QEMU_FLATTEN" attribute to the function definition +decreases the instructions per call of the function by about 63%. + +Attached are before and after performance screenshots from +KCachegrind.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1893003 b/results/classifier/mode-gemma3:12b/user/1893003 new file mode 100644 index 00000000..91bceaae --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1893003 @@ -0,0 +1,40 @@ + + +qemu linux-user doesn't translate host/target data for iovec I/O + +When using iovec I/O functions (like `readv`), no data translation happens. I'm hitting this issue with libevent upon constructing a bufferevent over an inotify descriptor, and then building for either ppc64 or s390x (both big-endian) on x86_64 (little-endian) and running resulting code with qemu-ppc64 or qemu-s390x on Gentoo using latest QEMU version available (5.0.0-r2). + +The code in question is in https://github.com/transmission/transmission/blob/master/libtransmission/watchdir-inotify.c (`tr_watchdir_inotify_new`, `tr_watchdir_inotify_on_event`). + +While `read` syscall is handled properly, `readv` (which libevent is using in my case) doesn't have any logic to call `host_to_target_data_inotify` or any other translation function, leaving inotify data unchanged (with values in little-endian), which then leads to unit test failures. Quoting `do_syscall1` implementation bits for the reference: + +---8<---begin--- + case TARGET_NR_read: + if (arg2 == 0 && arg3 == 0) { + return get_errno(safe_read(arg1, 0, 0)); + } else { + if (!(p = lock_user(VERIFY_WRITE, arg2, arg3, 0))) + return -TARGET_EFAULT; + ret = get_errno(safe_read(arg1, p, arg3)); + if (ret >= 0 && + fd_trans_host_to_target_data(arg1)) { + ret = fd_trans_host_to_target_data(arg1)(p, ret); + } + unlock_user(p, arg2, ret); + } + return ret; +... + case TARGET_NR_readv: + { + struct iovec *vec = lock_iovec(VERIFY_WRITE, arg2, arg3, 0); + if (vec != NULL) { + ret = get_errno(safe_readv(arg1, vec, arg3)); + unlock_iovec(vec, arg2, arg3, 1); + } else { + ret = -host_to_target_errno(errno); + } + } + return ret; +---8<---end--- + +To reiterate, the issue is not only with `readv` but with other iovec functions as well.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1893010 b/results/classifier/mode-gemma3:12b/user/1893010 new file mode 100644 index 00000000..0c5b0485 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1893010 @@ -0,0 +1,7 @@ + + +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/mode-gemma3:12b/user/1893040 b/results/classifier/mode-gemma3:12b/user/1893040 new file mode 100644 index 00000000..bed701c4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1893040 @@ -0,0 +1,18 @@ + + + External modules retreval using Go1.15 on s390x appears to have checksum and ECDSA verification issues + +We are observing issue while building go-runner image and we suspect it is due to QEMU version being used. As referred in below issue: +https://github.com/golang/go/issues/40949 + +We tried to build go-runner image using go1.15 and register QEMU (docker run --rm --privileged multiarch/qemu-user-static@sha256:c772ee1965aa0be9915ee1b018a0dd92ea361b4fa1bcab5bbc033517749b2af4 --reset -p yes) as mentioned in PR https://github.com/kubernetes/release/pull/1499. We observed below failure during build: + +------------------------------------------------------------------------------------------------------------- +ERROR: executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +------ + > [builder 7/7] RUN CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner .: +------ +failed to solve: rpc error: code = Unknown desc = executor failed running [/bin/sh -c CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} go build -ldflags '-s -w -buildid= -extldflags "-static"' -o go-runner ${package}]: buildkit-runc did not terminate successfully +Makefile:52: recipe for target 'container' failed +make: *** [container] Error 1 +-------------------------------------------------------------------------------------------------------------
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1893667 b/results/classifier/mode-gemma3:12b/user/1893667 new file mode 100644 index 00000000..983ea8ee --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1893667 @@ -0,0 +1,31 @@ + + +Btrfs commands don't work when using user-space emulation of other architectures + +Description of problem: +When doing cross-arch builds with mock, it uses qemu-user-static under the hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that btrfs(8) commands work correctly. + +This is especially important for being able to do cross-arch image builds. + +How reproducible: +Always (on Fedora 33 with qemu-5.1.0-2.fc33) + +Steps to Reproduce: + +$ sudo dnf install mock qemu-user-static wget +$ sudo usermod -a -G mock $USER +$ newgrp mock +$ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux +$ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img && mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol create /foo/subvol && umount /foo && losetup -d /dev/loop9' + + +Actual results: +Fails with errors like "ERROR: cannot create subvolume: Function not implemented" + +Expected results: +Succeeds and creates subvolumes properly. + +Additional info: +There is a patch series from a few days ago to add support for many btrfs ioctls which could fix this... + +https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1894029 b/results/classifier/mode-gemma3:12b/user/1894029 new file mode 100644 index 00000000..a6f9115e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1894029 @@ -0,0 +1,41 @@ + + +qemu-i386 malloc error + +Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong. +This is my test program: + +#include <stdint.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +int main(int argc, char **argv) +{ + void *pa=0,*pb=0,*pc=0,*pd=0; + pa = malloc(sizeof(uint32_t)); + pb = malloc(sizeof(uint32_t)); + pc = malloc(4); + pd = malloc(4); + printf("pa: 0x%x\n",pa); + printf("pb: 0x%x\n",pb); + printf("pc: 0x%x\n",pc); + printf("pd: 0x%x\n",pd); + printf("uint32_t:%d\n",sizeof(uint32_t)); + free(pa); + free(pb); + free(pc); + free(pd); + return 0; +} + +And it is wrong: + +pa: 0x400051a0 +pb: 0x400051b0 +pc: 0x400051c0 +pd: 0x400051d0 +uint32_t:4 + +Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes?? +Is it a BUG??
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1895 b/results/classifier/mode-gemma3:12b/user/1895 new file mode 100644 index 00000000..d23520f4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1895 @@ -0,0 +1,148 @@ + + +qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash +Description of problem: +When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards. + +We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise. +Steps to reproduce: +1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment +2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U` +3. Install gcc inside the container: `sudo pacman -Syu gcc` +4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i) +5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus` +Additional information: +Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware. + +g++ version: g++ (GCC) 13.2.1 20230801 + +testcase.i: + +```c++ +namespace std { +typedef long unsigned size_t; +inline namespace __cxx11 {} +} // namespace std +typedef char uint8_t; +namespace std { +template <typename _Default, typename, template <typename> class> +struct __detector { + using type = _Default; +}; +template <typename _Default, template <typename> class _Op> +using __detected_or = __detector<_Default, void, _Op>; +template <typename _Default, template <typename> class _Op> +using __detected_or_t = typename __detected_or<_Default, _Op>::type; +template <typename> class allocator; +namespace __cxx11 { +template <typename _CharT, typename = _CharT, typename = allocator<_CharT>> +class basic_string; +} +typedef basic_string<char> string; +} // namespace std +template <typename _Tp> class __new_allocator { +public: + typedef _Tp value_type; +}; +namespace std { +template <typename _Tp> using __allocator_base = __new_allocator<_Tp>; +template <typename _Tp> class allocator : public __allocator_base<_Tp> {}; +template <class _E> class initializer_list { + typedef size_t size_type; + typedef _E *iterator; + iterator _M_array; + size_type _M_len; +}; +struct __allocator_traits_base { + template <typename _Tp> using __pointer = typename _Tp::const_pointer; +}; +template <typename _Alloc> struct allocator_traits : __allocator_traits_base { + typedef typename _Alloc::value_type value_type; + using pointer = __detected_or_t<value_type, __pointer>; +}; +} // namespace std +namespace __gnu_cxx { +template <typename _Alloc> +struct __alloc_traits : std::allocator_traits<_Alloc> {}; +} // namespace __gnu_cxx +namespace std { +namespace __cxx11 { +template <typename _CharT, typename, typename _Alloc> class basic_string { + typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits; + +public: + typedef typename _Alloc_traits::pointer pointer; + struct _Alloc_hider { + _Alloc_hider(pointer, _Alloc); + } _M_dataplus; + pointer _M_local_data(); + basic_string(_CharT *, _Alloc __a = _Alloc()) + : _M_dataplus(_M_local_data(), __a) {} + ~basic_string(); +}; +} // namespace __cxx11 +} // namespace std +namespace v8 { +class StartupData {}; +} // namespace v8 +namespace std { +template <typename _Tp> class vector { +public: + typedef _Tp value_type; + vector(initializer_list<value_type>); +}; +namespace builtins { +struct CodeCacheInfo { + string id; + vector<uint8_t> data; +}; +} // namespace builtins +struct IsolateDataSerializeInfo {}; +struct EnvSerializeInfo {}; +struct SnapshotMetadata { + enum { kDefault } type; + string node_version; + string node_arch; + string v8_cache_version_tag; +}; +struct SnapshotData { + enum { kNotOwned } data_ownership; + SnapshotMetadata metadata; + v8::StartupData v8_snapshot_blob_data; + IsolateDataSerializeInfo isolate_data_info; + EnvSerializeInfo env_info; + vector<builtins::CodeCacheInfo> code_cache; +} snapshot_data{ + SnapshotData::kNotOwned, + SnapshotMetadata::kDefault, + "", + "", + "", + {}, + {}, + {}, + {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, + {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}}; +} // namespace std +``` diff --git a/results/classifier/mode-gemma3:12b/user/1895080 b/results/classifier/mode-gemma3:12b/user/1895080 new file mode 100644 index 00000000..c0df2809 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1895080 @@ -0,0 +1,38 @@ + + +pgb_reserved_va: Assertion `addr == test' failed + +This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-user. + +Firstly, compile fails: +Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o +../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function) + FLAG_GENERIC(FALLOC_FL_KEEP_SIZE), + +I have to add below include to linux-user/strace.c +diff --git a/linux-user/strace.c b/linux-user/strace.c +index 11fea14fba..22e51d4a8a 100644 +--- a/linux-user/strace.c ++++ b/linux-user/strace.c +@@ -7,6 +7,7 @@ + #include <sys/mount.h> + #include <arpa/inet.h> + #include <netinet/tcp.h> ++#include <linux/falloc.h> + #include <linux/if_packet.h> + #include <linux/netlink.h> + #include <sched.h> + +Then trying qemu-riscv32 with a simple ELF, I get: +linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. + +strace shows that: +mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000 +write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed. +) = 103 + +The source code is in the function pgb_reserved_va (linux-user/elfload.c). I think mmap cannot guarantee that the returned pointer (test) equals to the parameter of addr. So is this a bug to assert (addr == test)? + +Attached configure script and test ELF file. + +Thanks.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1895305 b/results/classifier/mode-gemma3:12b/user/1895305 new file mode 100644 index 00000000..c238b276 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1895305 @@ -0,0 +1,50 @@ + + +pthread_cancel fails with "RT33" with musl libc + +From my testing it seems that QEMU built against musl libc crashes on pthread_cancel cancel calls - if the binary is also built with musl libc. + +Minimal sample: + +#include <pthread.h> +#include <stdio.h> +#include <unistd.h> +void* threadfunc(void* ignored) { + while (1) { + pause(); + } + return NULL; +} +int main() { + pthread_t thread; + pthread_create(&thread, NULL, &threadfunc, NULL); + sleep(1); + pthread_cancel(thread); + printf("OK, alive\n"); +} + +In an Alpine Linux aarch64 chroot (on an x86_64 host) the binary will just output RT33 and has exit code 161. + +Using qemu-aarch64 on an x86_64 host results in the output (fish shell) + fish: “qemu-aarch64-static ./musl-stat…” terminated by signal Unknown (Unknown) +or (bash) + Real-time signal 2 + +and exit code 164. + +It doesn't matter whether the binary is linked dynamically or static. You can see my test results in the following table: + +| | QEMU glibc | QEMU musl | +|----------------------|------------|-----------| +| binary glibc dynamic | ✓ | ✓ | +| binary glibc static | ✓ | ✓ | +| binary musl dynamic | ✓ | ✗ | +| binary musl static | ✓ | ✗ | + +Both QEMU builds are v5.1.0 (glibc v2.32 / musl v1.2.1) + +I've uploaded all my compile and test commands (plus a script to conveniently run them all) to https://github.com/z3ntu/qemu-pthread_cancel . It also includes the built binaries if needed. The test script output can be found at https://github.com/z3ntu/qemu-pthread_cancel/blob/master/results.txt + +Further links: +- https://gitlab.com/postmarketOS/pmaports/-/issues/190#note_141902075 +- https://gitlab.com/postmarketOS/pmbootstrap/-/issues/1970
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1896298 b/results/classifier/mode-gemma3:12b/user/1896298 new file mode 100644 index 00000000..e3e8a307 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1896298 @@ -0,0 +1,21 @@ + + +TCG memory leak with FreeDOS 'edit' + +qemu trunk as of today leaks memory FAST when freedos' edit is running. + +To reproduce, download: + +https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/cdrom.iso + +Then run: + +$ qemu-system-i386 -cdrom cdrom.iso + +select your language then select "return to DOS", then type + +> edit + +it will consume memory at ~10MB/s + +This does NOT happen when adding -enable-kvm
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1897783 b/results/classifier/mode-gemma3:12b/user/1897783 new file mode 100644 index 00000000..dfd03374 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1897783 @@ -0,0 +1,27 @@ + + +avocado tests not running on aarch64 host + +$ lsb_release -a +No LSB modules are available. +Distributor ID: Ubuntu +Description: Ubuntu 20.04.1 LTS +Release: 20.04 +Codename: focal + +$ make check-venv + VENV /home/phil/qemu/build/tests/venv + PIP /home/phil/qemu/tests/requirements.txt + ERROR: Command errored out with exit status 1: + command: /home/phil/qemu/build/tests/venv/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"'; __file__='"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ic25ctcg + cwd: /tmp/pip-install-w1h2bh4a/pycdlib/ + Complete output (6 lines): + usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] + or: setup.py --help [cmd1 cmd2 ...] + or: setup.py --help-commands + or: setup.py cmd --help + + error: invalid command 'bdist_wheel' + ---------------------------------------- + ERROR: Failed building wheel for pycdlib +$
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1898011 b/results/classifier/mode-gemma3:12b/user/1898011 new file mode 100644 index 00000000..1c9fc4b4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1898011 @@ -0,0 +1,32 @@ + + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM + +Run this program: + +#include <sys/mman.h> +#include <stdio.h> +int main() { + for (int i = 30; i <= 44; i++) { + fprintf(stderr, "trying 2**%d\n", i); + mmap((void*)0x600000000000,1ULL << i, + PROT_NONE, + MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0); + } +} + +(tried qemu-x86_64 and qemu-aarch64, 4.2.1 and trunk/5.1.50) + +On each iteration qemu will consume 2x more physical RAM, +e.g. when mapping 2^42 it will have RSS of 16Gb. + +On normal linux it works w/o consuming much RAM, due to MAP_NORESERVE. + +Also: qemu -strace prints 0 instead of the correct size starting from size=2^32 +and prints -2147483648 for size=2^31. + +mmap(0x0000600000000000,1073741824,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,-2147483648,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000 + +mmap(0x0000600000000000,0,PROT_NONE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED|MAP_NORESERVE,-1,0) = 0x0000600000000000
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1901 b/results/classifier/mode-gemma3:12b/user/1901 new file mode 100644 index 00000000..36dabd56 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1901 @@ -0,0 +1,21 @@ + + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/mode-gemma3:12b/user/1902267 b/results/classifier/mode-gemma3:12b/user/1902267 new file mode 100644 index 00000000..553c3982 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1902267 @@ -0,0 +1,33 @@ + + +CPU not support 32-bit stack in 32-bit unreal mode + +QEMU version 5.0.0 supports 32-bit and 16-bit unreal mode. Great! +Unfortunately, QEMU does not support 32-bit stack in unreal 32-bit mode. +After the INT instruction, the stack is switched to 16-bit, which should not be the case. +At BOCHS, my code works 100%. At QEMU not works. + +Sample code to find out: + +use32 +cli +mov ax,cs +shl eax,16 +mov ax,NewInt80h +mov [IDT32+4*80h],eax +mov edx,esp +mov esp,0x10000 +int 80h +NewInt80h: +xchg esp,edx +cmp edx,0x10000-6 +jnz IsStack16Bit + +Stack selector loaded from GDT: +GDT: +real32_GDT +dq 0 +dw 0xFFFF,0x0000,9A00h,0xCF ; 32-bit code descriptor +dw 0xFFFF,0x0000,9200h,0x8F ; 4 GB data descriptor +dw 0xFFFF,0x0000,9A00h,0x00 ; 16-bit code descriptor +dw 0xFFFF,0x0000,9200h,0xCF ; 32-bit data descriptor stack
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1904 b/results/classifier/mode-gemma3:12b/user/1904 new file mode 100644 index 00000000..0512ce61 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1904 @@ -0,0 +1,18 @@ + + +Windows LTO build fails +Description of problem: +LTO likes to delete `win32_close_exception_handler` which causes an error when linking +``` +[2736/5786] Linking target qemu-system-avr.exe +FAILED: qemu-system-avr.exe +"cc" "-m64" "-mcx16" @qemu-system-avr.exe.rsp +`win32_close_exception_handler' referenced in section `.xdata' of C:\msys64\tmp\cceRwR4N.ltrans59.ltrans.o: defined in discarded section `.text' of libqemuutil.a.p/util_oslib-win32.c.obj (symbol from plugin) +collect2.exe: error: ld returned 1 exit status +``` +Steps to reproduce: +1. `./configure --enable-lto` +2. `make` +Additional information: +Looks like the offending commit is d89f30b4df13dfe389a4d6cf8a30b2f87c4c166e "win32: wrap socket close() with an exception handler". +Undoing the commit or marking the exception handler as `__attribute__ ((noinline, used))` both appear to fix the issue. diff --git a/results/classifier/mode-gemma3:12b/user/1904210 b/results/classifier/mode-gemma3:12b/user/1904210 new file mode 100644 index 00000000..5780a09e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1904210 @@ -0,0 +1,53 @@ + + +Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) + +This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. + +Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). + +Which means, it could be a bug in recent release. + +You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. + +In 2.5.0 version the -strace logs: +116 uname(0xf6ffed40) = 0 +116 brk(NULL) = 0x0009f000 +116 brk(0x0009fd00) = 0x0009fd00 +116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 +116 brk(0x000c0d00) = 0x000c0d00 +116 brk(0x000c1000) = 0x000c1000 +116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 +116 fstat64(1,0xf6ffe8e8) = 0 +116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 +116 fstat64(0,0xf6ffe7d0) = 0 +116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 +116 write(1,0xa5548,6)input: = 6 +116 read(0,0xa6550,4096)flag{ + = 6 +116 write(1,0xa5548,7)wrong! + = 7 +116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) +116 exit_group(0) + +In 2.11.1, it shows: +113 uname(0xfffeed30) = 0 +113 brk(NULL) = 0x0009f000 +113 brk(0x0009fd00) = 0x0009fd00 +113 readlink("/proc/self/exe",0xfffede68,4096) = 21 +113 brk(0x000c0d00) = 0x000c0d00 +113 brk(0x000c1000) = 0x000c1000 +113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 +113 fstat64(1,0xfffee8d8) = 0 +113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 +113 fstat64(0,0xfffee7c0) = 0 +113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 +113 write(1,0xa5548,6)input: = 6 +113 read(0,0xa6550,4096)flag{ + = 6 +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1905356 b/results/classifier/mode-gemma3:12b/user/1905356 new file mode 100644 index 00000000..7771b613 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1905356 @@ -0,0 +1,14 @@ + + +No check for unaligned data access in ARM32 instructions + +hi + +According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. + +I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. + +To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. + +Regards +Muhui
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1906193 b/results/classifier/mode-gemma3:12b/user/1906193 new file mode 100644 index 00000000..389e2bc2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1906193 @@ -0,0 +1,59 @@ + + +riscv32 user mode emulation: fork return values broken + +When running in a chroot with riscv32 (on x86_64; qemu git master as of today): + +The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! + +gcc-10.2 + +=============================================== +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> +#include <sys/wait.h> + +main(c, v) + int c; + char **v; +{ + pid_t pid, p; + int s, i, n; + + s = 0; + pid = fork(); + if (pid == 0) + exit(42); + + /* wait for the process */ + p = wait(&s); + if (p != pid) + exit (255); + + if (WIFEXITED(s)) + { + int r=WEXITSTATUS(s); + if (r!=42) { + printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); + } + } +} +=============================================== + +(riscv-ilp32 chroot) farino /tmp # ./wait-test-short +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 + +=============================================== +(riscv-ilp32 chroot) farino /tmp # gcc --version +gcc (Gentoo 10.2.0-r1 p2) 10.2.0 +Copyright (C) 2020 Free Software Foundation, Inc. +Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es +gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. + +(riscv-ilp32 chroot) farino /tmp # ld --version +GNU ld (Gentoo 2.34 p6) 2.34.0 +Copyright (C) 2020 Free Software Foundation, Inc. +This program is free software; you may redistribute it under the terms of +the GNU General Public License version 3 or (at your option) a later version. +This program has absolutely no warranty.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1906536 b/results/classifier/mode-gemma3:12b/user/1906536 new file mode 100644 index 00000000..2ac21d54 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1906536 @@ -0,0 +1,32 @@ + + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 + +Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. + +To reproduce the issue: + +$ cat rdvl.s +.global _start +_start: + rdvl x0, #1 + asr x0, x0, #4 + mov x8, #93 // exit + svc #0 +$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o +$ aarch64-linux-gnu-ld rdvl.o +$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done +1 +2 +4 +4 +4 + +For a QEMU built prior to the above revision, we get the output: +1 +2 +4 +8 +16 + +as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1907210 b/results/classifier/mode-gemma3:12b/user/1907210 new file mode 100644 index 00000000..4e54fd3b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1907210 @@ -0,0 +1,20 @@ + + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1907926 b/results/classifier/mode-gemma3:12b/user/1907926 new file mode 100644 index 00000000..60d63633 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1907926 @@ -0,0 +1,7 @@ + + +Implement TPM2 configuration for emulators that provide TCP interface + +swtpm provides several interfaces for its emulated device: unix socket (can be used by qemu), chardev. swtpm also provides TCP interface for the device which is very convenient for testing as it does not require root permissions. + +It would be very useful to have QEMU to work with TPM devices emulated via TCP.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1907969 b/results/classifier/mode-gemma3:12b/user/1907969 new file mode 100644 index 00000000..c7174ff9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1907969 @@ -0,0 +1,60 @@ + + +linux-user/i386: Segfault when mixing threads and signals + +Given the following C program, qemu-i386 will surely and certainly segfault when executing it. +The problem is only noticeable if the program is statically linked to musl's libc and, as written +in the title, it only manifests when targeting i386. + +Removing the pthread calls or the second raise() makes it not segfault. + +The crash is in some part of the TCG-generated code, right when it tries to perform a +%gs-relative access. + +If you want a quick way of cross-compiling this binary: + +* Download a copy of the Zig compiler from https://ziglang.org/download/ +* Compile it with + `zig cc -target i386-linux-musl <C-FILE> -o <OUT>` + +``` +#include <pthread.h> +#include <signal.h> +#include <stdio.h> +#include <string.h> +#include <sys/types.h> +#include <unistd.h> +#include <asm/prctl.h> +#include <sys/syscall.h> + +void sig_func(int sig) +{ + write(1, "hi!\n", strlen("hi!\n")); +} + +void func(void *p) { } + +typedef void *(*F)(void *); + +int main() +{ + pthread_t tid; + + struct sigaction action; + action.sa_flags = 0; + action.sa_handler = sig_func; + + if (sigaction(SIGUSR1, &action, NULL) == -1) { + return 1; + } + + // This works. + raise(SIGUSR1); + + pthread_create(&tid, NULL, (F)func, NULL); + pthread_join(tid, NULL); + + // This makes qemu segfault. + raise(SIGUSR1); +} +```
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1908551 b/results/classifier/mode-gemma3:12b/user/1908551 new file mode 100644 index 00000000..f3e6a803 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1908551 @@ -0,0 +1,56 @@ + + +aarch64 SVE emulation breaks strnlen and strrchr + +arm optimized-routines have sve string functions with test code. + +the test worked up until recently: with qemu-5.2.0 i see + +$ qemu-aarch64 build/bin/test/strnlen +PASS strnlen +PASS __strnlen_aarch64 +__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80" +__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a" +__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab" +__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c" +__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00" +__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35 +input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc" +FAIL __strnlen_aarch64_sve + +however the test passes with + +qemu-aarch64 -cpu max,sve-max-vq=2 + +there should be nothing vector length specific in the code. + +i haven't debugged it further, to reproduce the issue clone +https://github.com/ARM-software/optimized-routines + +and run 'make build/bin/test/strnlen' with a config.mk like + +SUBS = string +ARCH = aarch64 +CROSS_COMPILE = aarch64-none-linux-gnu- +CC = $(CROSS_COMPILE)gcc +CFLAGS = -std=c99 -pipe -O3 +CFLAGS += -march=armv8.2-a+sve +EMULATOR = qemu-aarch64 + +(native compilation works too, and you can run 'make check' to +run all string tests) this will build a static linked executable +into build/bin/test. if you want a smaller test case edit +string/test/strnlen.c
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1908626 b/results/classifier/mode-gemma3:12b/user/1908626 new file mode 100644 index 00000000..fddc61c1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1908626 @@ -0,0 +1,67 @@ + + +Atomic test-and-set instruction does not work on qemu-user + +I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: +``` + host: CentOS7 x86_64 + container: centos:centos7.9.2009 --platform linux/arm64/v8 + qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ +``` + +However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock +has something wrong. +``` +https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h +https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c +``` + +So I extract its spinlock implementation into one test C source file (see attachment file), +and get reprodcued: + +``` +$ gcc spinlock_qemu.c +$ ./a.out +C -- slock inited, lock value is: 0 +parent 139642, child 139645 +P -- slock lock before, lock value is: 0 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +... +... +... +``` + +NOTE: this code always works on PHYSICAL ARM64 server.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1909 b/results/classifier/mode-gemma3:12b/user/1909 new file mode 100644 index 00000000..6d4b68ea --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1909 @@ -0,0 +1,52 @@ + + +regression: 8.0.0 segfaults on coverage counter increment +Description of problem: +With qemu 8.0.0, my test program segfaults while incrementing a gcov counter: + +``` +Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/2i $pc +=> 0x4bc9a8 <__CortexA53843419_464004>: str x8, [x9, #2512] + 0x4bc9ac <__CortexA53843419_464004+4>: b 0x464008 <mock_hyp_params_Destroy+24> +(gdb) p $x8 +$10 = 1 +(gdb) p $x9 +$11 = 5234688 +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) stepi + +Program received signal SIGSEGV, Segmentation fault. +0x00000000004bc9a8 in __CortexA53843419_464004 () +(gdb) x/x $x9+2512 +0x4fe9d0 <__llvm_gcov_ctr.5>: 0x00000000 +(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep 4fe9d0 +00000000004fe9d0 l O .bss 0000000000000008 __llvm_gcov_ctr.5 +(gdb) shell qemu-aarch64 --version +qemu-aarch64 version 8.0.0 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +(gdb) +``` + +With qemu 6.2.0, it doesn't segfault (at least not at this point, you +may ignore the segfault at the end due to a bug in the test program). +``` +$ /usr/bin/qemu-aarch64 --version +qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + +$ /usr/bin/qemu-aarch64 ./build/gcov/out/test_hyp-props.out +test_hyp-props.c:13:test__setup_str_prop:PASS +test_hyp-props.c:14:test__log_print_handler:PASS +test_hyp-props.c:15:test__setup_log_print_prop:PASS +test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS +test_hyp-props.c:17:test__vm_info_alloc:PASS +test_hyp-props.c:18:test__memory_status_get:PASS +test_hyp-props.c:19:test__memory_status_get_fail:PASS +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage. +2. Run it with qemu-aarch64 8.0.0 +3. Hopefully, it will segfault early for no good reason. diff --git a/results/classifier/mode-gemma3:12b/user/1909770 b/results/classifier/mode-gemma3:12b/user/1909770 new file mode 100644 index 00000000..97cddfed --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1909770 @@ -0,0 +1,220 @@ + + +qemu-cris segfaults upon loading userspace binary + +I am on commit 65a3c5984074313602fb5f61cc5f464abfb020c7 (latest as far as I know). I compiled qemu with --enable-debug. + +I'm trying to run a userspace CRIS binary (`./qemu-cris -cpu crisv10 ./basic`), but this segfaults. When opening the coredump in gdb, I get + +gdb-peda$ bt +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +#7 0x0000564a2f786cee in _start () + +Or as a full backtrace: +gdb-peda$ bt full +#0 0x00007f272a2e1ee1 in __memset_avx2_erms () from /usr/lib/libc.so.6 +No symbol table info available. +#1 0x0000564a2f7bcda7 in zero_bss (elf_bss=0x82134, last_bss=0x84000, + prot=0x3) at ../linux-user/elfload.c:1865 + host_start = 0x92134 + host_map_start = 0x93000 + host_end = 0x94000 +#2 0x0000564a2f7bff65 in load_elf_image ( + image_name=0x7fffe9f5703d "./basic", image_fd=0x3, + info=0x7fffe9f547c0, pinterp_name=0x7fffe9f545b0, + bprm_buf=0x7fffe9f54920 "\177ELF\001\001\001") + at ../linux-user/elfload.c:2801 + vaddr = 0x82134 + vaddr_em = 0x82140 + vaddr_len = 0x2000 + vaddr_po = 0x134 + vaddr_ps = 0x82000 + vaddr_ef = 0x82134 + elf_prot = 0x3 + eppnt = 0x7fffe9f54974 + ehdr = 0x7fffe9f54920 + phdr = 0x7fffe9f54954 + load_addr = 0x80000 + load_bias = 0x0 + loaddr = 0x80000 + hiaddr = 0x1082140 + error = 0x80000 + i = 0x1 + retval = 0x273d2e9c + prot_exec = 0x4 + err = 0x0 + __func__ = "load_elf_image" +#3 0x0000564a2f7c0a12 in load_elf_binary (bprm=0x7fffe9f54920, + info=0x7fffe9f547c0) at ../linux-user/elfload.c:3104 + interp_info = { + load_bias = 0x0, + load_addr = 0x0, + start_code = 0x0, + end_code = 0x0, + start_data = 0x0, + end_data = 0x0, + start_brk = 0x0, + brk = 0x0, + reserve_brk = 0x0, + start_mmap = 0x0, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x0, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x0, + loadmap_addr = 0x0, + nsegs = 0x0, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + elf_ex = { + e_ident = "|\214\t1\000\000\000\000\262\002\356_\000\000\000", + e_type = 0x8c7c, + e_machine = 0x3109, + e_version = 0x0, + e_entry = 0x5fee02b2, + e_phoff = 0x0, + e_shoff = 0x31098c7c, + e_flags = 0x0, + e_ehsize = 0x0, + e_phentsize = 0x0, + e_phnum = 0x0, + e_shentsize = 0x0, + e_shnum = 0x0, + e_shstrndx = 0x0 + } + elf_interpreter = 0x0 + scratch = 0x7f272a358021 <read+97> "H\213D$\bH\203\304(\303\017\037D" +#4 0x0000564a2f81f290 in loader_exec (fdexec=0x3, + filename=0x7fffe9f5703d "./basic", argv=0x564a2f9f3cc0, + envp=0x564a2fa12600, regs=0x7fffe9f54860, infop=0x7fffe9f547c0, + bprm=0x7fffe9f54920) at ../linux-user/linuxload.c:147 + retval = 0x400 +#5 0x0000564a2f7c4f9f in main (argc=0x4, argv=0x7fffe9f54e78, + envp=0x7fffe9f54ea0) at ../linux-user/main.c:808 + regs1 = { + orig_r10 = 0x0, + r0 = 0x0, + r1 = 0x0, + r2 = 0x0, + r3 = 0x0, + r4 = 0x0, + r5 = 0x0, + r6 = 0x0, + r7 = 0x0, + r8 = 0x0, + r9 = 0x0, + r10 = 0x0, + r11 = 0x0, + r12 = 0x0, + r13 = 0x0, + acr = 0x0, + srs = 0x0, + mof = 0x0, + spc = 0x0, + ccs = 0x0, + srp = 0x0, + erp = 0x0, + exs = 0x0, + eda = 0x0 + } + regs = 0x7fffe9f54860 + info1 = { + load_bias = 0x0, + load_addr = 0x80000, + start_code = 0x80000, + end_code = 0x80133, + start_data = 0xffffffff, + end_data = 0x0, + start_brk = 0x0, + brk = 0x80133, + reserve_brk = 0x1000000, + start_mmap = 0x80000000, + start_stack = 0x0, + stack_limit = 0x0, + entry = 0x80106, + code_offset = 0x0, + data_offset = 0x0, + saved_auxv = 0x0, + auxv_len = 0x0, + arg_start = 0x0, + arg_end = 0x0, + arg_strings = 0x0, + env_strings = 0x0, + file_string = 0x0, + elf_flags = 0x0, + personality = 0x0, + alignment = 0x2000, + loadmap_addr = 0x0, + nsegs = 0x2, + loadsegs = 0x0, + pt_dynamic_addr = 0x0, + interpreter_loadmap_addr = 0x0, + interpreter_pt_dynamic_addr = 0x0, + other_info = 0x0, + note_flags = 0x0 + } + info = 0x7fffe9f547c0 + bprm = { + buf = "\177ELF\001\001\001\000\000\000\000\000\000\000\000\000\002\000L\000\001\000\000\000\006\001\b\000\064\000\000\000\264\006\000\000\000\000\000\000\064\000 \000\003\000(\000\016\000\r\000\001\000\000\000\000\000\000\000\000\000\b\000\000\000\b\000\063\001\000\000\063\001\000\000\005\000\000\000\000 \000\000\001\000\000\000\064\001\000\000\064!\b\000\064!\b\000\000\000\000\000\f\000\000\000\006\000\000\000\000 \000\000\004\000\000\000\224\000\000\000\224\000\b\000\224\000\b\000$\000\000\000$\000\000\000\004\000\000\000\004\000\000\000\004\000\000\000\024\000\000\000\003\000\000\000GNU\000PH\017'i\204\231\070e\000\247\376\211\230\236\336Nf7\372\204\342\356\213n\206\214\342\374\201\352\253\370\201\353\273"..., + p = 0x0, + fd = 0x3, + e_uid = 0x3e8, + e_gid = 0x3d9, + argc = 0x1, + envc = 0x43, + argv = 0x564a2f9f3cc0, + envp = 0x564a2fa12600, + filename = 0x7fffe9f5703d "./basic", + core_dump = 0x0 + } + ts = 0x564a2fa25400 + env = 0x564a2fa24a08 + cpu = 0x564a2fa1c730 + optind = 0x3 + target_environ = 0x564a2fa12600 + wrk = 0x7fffe9f550b8 + target_argv = 0x564a2f9f3cc0 + target_argc = 0x1 + i = 0x1 + ret = 0x7fff + execfd = 0x3 + log_mask = 0x0 + max_reserved_va = 0xffffe000 +#6 0x00007f272a1a4152 in __libc_start_main () from /usr/lib/libc.so.6 +No symbol table info available. +#7 0x0000564a2f786cee in _start () +No symbol table info available. + + +The binary itself is just a basic binary that prints "hello\n" to stdout. I have attached it.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1909921 b/results/classifier/mode-gemma3:12b/user/1909921 new file mode 100644 index 00000000..29f8a0d0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1909921 @@ -0,0 +1,24 @@ + + + Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e + +Hello, + +I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition). +I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it. + +This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it. +The error given by qemu is the following : + +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e + +(The pc= value is always different, I guess it is randomly generated). + +My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1) + +Could you please help me? Why am I facing this error? + +Feel free to ask any questions regarding this matter in order to find a solution to it! + +Regards
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1910 b/results/classifier/mode-gemma3:12b/user/1910 new file mode 100644 index 00000000..2ebc9f05 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1910 @@ -0,0 +1,64 @@ + + +Signal handlers in x86_64 userspace have wrongly aligned stack +Description of problem: +Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause. + +```plaintext +> qemu-x86_64 /usr/bin/ruby -e '`true`' +-e:1: [BUG] Segmentation fault at 0x0000000000000000 +ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu] + +-- Control frame information ----------------------------------------------- +c:0003 p:---- s:0011 e:000010 CFUNC :` +c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] +c:0001 p:0000 s:0003 E:0015b0 DUMMY [FINISH] + +-- Ruby level backtrace information ---------------------------------------- +-e:1:in `<main>' +-e:1:in ``' + +-- Machine register context ------------------------------------------------ + RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98 + RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000 + RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000 + R8: 0x00002aaaab2aaa50 R9: 0x0000000000000050 R10: 0x0000000000000008 + R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310 + R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246 + +-- C level backtrace information ------------------------------------------- +``` + +```plaintext +(gdb) x/i $pc +=> 0x2aaaab50f98a: movaps %xmm0,(%rsp) +(gdb) p/x $rsp +$3 = 0x2aaaab2a9998 +``` +Steps to reproduce: +1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'``` +Additional information: +The x86_64 psABI says: + +> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point. + +However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`. + +The relevant kernel code: + +https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123 + +```plaintext + sp -= frame_size; + + if (ia32_frame) + /* + * Align the stack pointer according to the i386 ABI, + * i.e. so that on function entry ((sp + 4) & 15) == 0. + */ + sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4; + else + sp = round_down(sp, FRAME_ALIGNMENT) - 8; +``` + +CC @lvivier @bonzini @rth7680 diff --git a/results/classifier/mode-gemma3:12b/user/1910605 b/results/classifier/mode-gemma3:12b/user/1910605 new file mode 100644 index 00000000..bf0b9ba1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1910605 @@ -0,0 +1,18 @@ + + +qemu-arm-static ioctl USBDEVFS_BULK return -1 (EFAULT) Bad address + + + +Snippet of code sample: + +struct usbdevfs_bulktransfer Bulk; +Bulk.ep = hUsb->UsbOut; +Bulk.len = Len; +Bulk.data = (void *)pData; +Bulk.timeout = Timeout; +Bytes = ioctl(hUsb->fd, USBDEVFS_BULK, &Bulk) + +The above code sample return -1 (EFAULT) Bad address when using qemu-arm-static but is running ok when on qemu-aarch64-static. + +I use a 64-bit intel laptop
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1912 b/results/classifier/mode-gemma3:12b/user/1912 new file mode 100644 index 00000000..8a0c7d5d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1912 @@ -0,0 +1,3 @@ + + +linux-user: (recursive) segfault when built with -static -disable-pie diff --git a/results/classifier/mode-gemma3:12b/user/1912107 b/results/classifier/mode-gemma3:12b/user/1912107 new file mode 100644 index 00000000..09cf2c01 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1912107 @@ -0,0 +1,10 @@ + + +Option to constrain linux-user exec() to emulated CPU only + +When trying to reproduce a bug someone reported on an actual AMD K10[1], I tried to directly throw `qemu_x86-64 -cpu +phenom path/to/wrongly-labelled-instruction-set/gcc 1.c` at the problem, but failed to get an "illegal instruction" as expected. A quick investigation reveals that the error is actually caused by one of gcc's child processess, and that the said process is being ran directly on the host. A similar problem happens with trying to call stuff with /usr/bin/env. + + [1]: https://github.com/Homebrew/brew/issues/1034 + +Since both the host and the guest are x86_64, I deemed binfmt inapplicable to my case. I believe that QEMU should offer a way to modify exec() and other spawning syscalls so that execution remains on an emulated CPU in such a case. Call it an extra layer of binfmt, if you must.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1912790 b/results/classifier/mode-gemma3:12b/user/1912790 new file mode 100644 index 00000000..9fabaf20 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1912790 @@ -0,0 +1,65 @@ + + +qemu-aarch64-static segfaults python3 + +qemu-aarch64-static is segfaulting in a debian build process using debootstrap. + +``` +Type "apropos word" to search for commands related to "word"... +Reading symbols from /usr/bin/qemu-aarch64-static... +Reading symbols from /usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug... +[New LWP 21817] +[New LWP 21819] + +warning: Corrupted shared library list: 0xd5f140 != 0x0 +Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed +Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/python3.9 -c import imp; print(imp.get_ta'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +43 return mmap_lock_count > 0 ? true : false; +[Current thread is 1 (LWP 21817)] +(gdb) bt +#0 have_mmap_lock () at ../../linux-user/mmap.c:43 +#1 0x000000000058eb2c in page_set_flags (start=start@entry=4194304, end=end@entry=26451968, flags=flags@entry=8) at ../../accel/tcg/translate-all.c:2568 +#2 0x00000000005638cd in target_mmap (start=start@entry=4194304, len=<optimized out>, len@entry=22257160, target_prot=target_prot@entry=0, flags=16434, + fd=fd@entry=-1, offset=offset@entry=0) at ../../linux-user/mmap.c:602 +#3 0x000000000057042d in load_elf_image (image_name=0x7ffff7b7e8d8 "/usr/bin/python3.9", image_fd=3, info=info@entry=0x7ffff7b7ce70, + pinterp_name=pinterp_name@entry=0x7ffff7b7cbd0, bprm_buf=bprm_buf@entry=0x7ffff7b7d080 "\177ELF\002\001\001") at ../../linux-user/elfload.c:2700 +#4 0x0000000000570b9c in load_elf_binary (bprm=bprm@entry=0x7ffff7b7d080, info=info@entry=0x7ffff7b7ce70) at ../../linux-user/elfload.c:3104 +#5 0x00000000005c2fdb in loader_exec (fdexec=fdexec@entry=3, filename=<optimized out>, argv=argv@entry=0x2622910, envp=envp@entry=0x2686340, + regs=regs@entry=0x7ffff7b7cf70, infop=infop@entry=0x7ffff7b7ce70, bprm=<optimized out>) at ../../linux-user/linuxload.c:147 +#6 0x00000000004027f7 in main (argc=<optimized out>, argv=0x7ffff7b7d638, envp=<optimized out>) at ../../linux-user/main.c:810 + +(gdb) i r +rax 0x0 0 +rbx 0x400000 4194304 +rcx 0x7a95d2 8033746 +rdx 0x8 8 +rsi 0x193a000 26451968 +rdi 0x400000 4194304 +rbp 0x400000 0x400000 +rsp 0x7ffff7b7c978 0x7ffff7b7c978 +r8 0xffffffff 4294967295 +r9 0x0 0 +r10 0x4032 16434 +r11 0x206 518 +r12 0x193a000 26451968 +r13 0x8 8 +r14 0x8 8 +r15 0x193a000 26451968 +rip 0x562f20 0x562f20 <have_mmap_lock> +eflags 0x10206 [ PF IF RF ] +cs 0x33 51 +ss 0x2b 43 +ds 0x0 0 +es 0x0 0 +fs 0x0 0 +gs 0x0 0 + +``` + +Python3.9 is run as part of the installation of python3-minimal and the segfaults happens reliably here. Debian versionn bullseye (testing) + +Version: qemu-aarch64 version 5.2.0 (Debian 1:5.2+dfsg-3) + +Host is a qemu-system-x86_64: Linux runner 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1912934 b/results/classifier/mode-gemma3:12b/user/1912934 new file mode 100644 index 00000000..1454948c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1912934 @@ -0,0 +1,19 @@ + + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ).
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1913 b/results/classifier/mode-gemma3:12b/user/1913 new file mode 100644 index 00000000..2059d0ab --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1913 @@ -0,0 +1,21 @@ + + +Regression in 8.1.1: qemu-aarch64-static running ldconfig +Description of problem: +Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs) +Steps to reproduce: +1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/ +2. Extract it +3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1 + +```bash +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.0 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<works> +$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst +$ qemu-aarch64-static --version +qemu-aarch64 version 8.1.1 +$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs +<segfault> +``` diff --git a/results/classifier/mode-gemma3:12b/user/1913913 b/results/classifier/mode-gemma3:12b/user/1913913 new file mode 100644 index 00000000..bb808e08 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1913913 @@ -0,0 +1,20 @@ + + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1913926 b/results/classifier/mode-gemma3:12b/user/1913926 new file mode 100644 index 00000000..97fc2c13 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1913926 @@ -0,0 +1,31 @@ + + +[QEMU User-Mode] Mesa Fails To Load RadeonSI Driver When In Docker Image + +# System Details +AMD Ryzen 7 3700U +Ubuntu 20.04 Focal Focus + +# Dockerfile + +FROM arm32v7/debian:bullseye + +RUN apt-get update && apt-get install -y mesa-utils + +ENTRYPOINT glxgears + +# Instructions For Reproduction +1. Install Docker +2. Build Docker Image: docker build --tag mesa-arm-test . +3. Run: docker run -v /tmp/.X11-unix:/tmp/.X11-unix --device /dev/dri:/dev/dri -e "DISPLAY=${DISPLAY}" mesa-arm-test + +The Output Is: + +amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-38) +amdgpu: amdgpu_device_initialize failed. +libGL error: failed to create dri screen +libGL error: failed to load driver: radeonsi +libGL error: failed to get magic +libGL error: failed to load driver: radeonsi + +It then appears to run using software rendering.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1914021 b/results/classifier/mode-gemma3:12b/user/1914021 new file mode 100644 index 00000000..619c8c3d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1914021 @@ -0,0 +1,29 @@ + + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +readelf -h a.out_err +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1915327 b/results/classifier/mode-gemma3:12b/user/1915327 new file mode 100644 index 00000000..77c76805 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1915327 @@ -0,0 +1,36 @@ + + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU + +QEMU version: +1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging + +Consider the following little program: + +$ cat 1.c +#include <stdio.h> +int main() { + int mem = 0x12345678; + register long rax asm("rax") = 0x1234567812345678; + register int edi asm("edi") = 0x77777777; + asm("cmpxchg %[edi],%[mem]" + : [ mem ] "+m"(mem), [ rax ] "+r"(rax) + : [ edi ] "r"(edi)); + long rax2 = rax; + printf("rax2 = %lx\n", rax2); +} + +According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU: + +$ gcc 1.c +$ ./a.out +rax2 = 1234567812345678 + +However, QEMU appears to zero extend EAX to RAX: + +$ qemu-x86_64 ./a.out +rax2 = 12345678 + +This is also the case for lock cmpxchg. + +Found in BPF development context: https://lore<email address hidden>
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1915531 b/results/classifier/mode-gemma3:12b/user/1915531 new file mode 100644 index 00000000..c3f61eb2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1915531 @@ -0,0 +1,56 @@ + + +qemu-user child process hangs when forking due to glib allocation + +I and others have recently been using qemu-user for RISCV64 extensively. We have had many hangs. We have found that hangs happen in process with multiple threads and forking. For example +`cargo` (a tool for the Rust compiler). + +It does not matter if there are a lot of calls to fork. What seems to matter most is that there are many threads running. So this happens more often on a CPU with a massive number of cores, and if nothing else is really running. The hang happens in the child process of the fork. + +To reproduce the problem, I have attached an example of C++ program to run through qemu-user. + +Here are the stacks of the child processes that hanged. This is for qemu c973f06521b07af0f82893b75a1d55562fffb4b5 with glib 2.66.4 + +------- +Thread 1: +#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 +#1 0x00007f54e190c77c in g_mutex_lock_slowpath (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1462 +#2 0x00007f54e190d222 in g_mutex_lock (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1486 +#3 0x00007f54e18e39f2 in magazine_cache_pop_magazine (countp=0x7f54280e6638, ix=2) at ../glib/gslice.c:769 +#4 thread_memory_magazine1_reload (ix=2, tmem=0x7f54280e6600) at ../glib/gslice.c:845 +#5 g_slice_alloc (mem_size=mem_size@entry=40) at ../glib/gslice.c:1058 +#6 0x00007f54e18f06fa in g_tree_node_new (value=0x7f54d4066540 <code_gen_buffer+419091>, key=0x7f54d4066560 <code_gen_buffer+419123>) at ../glib/gtree.c:517 +#7 g_tree_insert_internal (tree=0x555556aed800, key=0x7f54d4066560 <code_gen_buffer+419123>, value=0x7f54d4066540 <code_gen_buffer+419091>, replace=0) at ../glib/gtree.c:517 +#8 0x00007f54e186b755 in tcg_tb_insert (tb=0x7f54d4066540 <code_gen_buffer+419091>) at ../tcg/tcg.c:534 +#9 0x00007f54e1820545 in tb_gen_code (cpu=0x7f54980b4b60, pc=274906407438, cs_base=0, flags=24832, cflags=-16252928) at ../accel/tcg/translate-all.c:2118 +#10 0x00007f54e18034a5 in tb_find (cpu=0x7f54980b4b60, last_tb=0x7f54d4066440 <code_gen_buffer+418835>, tb_exit=0, cf_mask=524288) at ../accel/tcg/cpu-exec.c:462 +#11 0x00007f54e1803bd9 in cpu_exec (cpu=0x7f54980b4b60) at ../accel/tcg/cpu-exec.c:818 +#12 0x00007f54e1735a4c in cpu_loop (env=0x7f54980bce40) at ../linux-user/riscv/cpu_loop.c:37 +#13 0x00007f54e1844b22 in clone_func (arg=0x7f5402f3b080) at ../linux-user/syscall.c:6422 +#14 0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477 +#15 0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 + +Thread 2: +#1 0x00007f54e18a8d6e in qemu_futex_wait (f=0x7f54e1dc7038 <rcu_call_ready_event>, val=4294967295) at /var/home/valentin/repos/qemu/include/qemu/futex.h:29 +#2 0x00007f54e18a8f32 in qemu_event_wait (ev=0x7f54e1dc7038 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:460 +#3 0x00007f54e18c0196 in call_rcu_thread (opaque=0x0) at ../util/rcu.c:258 +#4 0x00007f54e18a90eb in qemu_thread_start (args=0x7f5428244930) at ../util/qemu-thread-posix.c:521 +#5 0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477 +#6 0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +------- + +Thread 1 seems to be the really hanged process. + +The problem is that glib is used in many places. Allocations are done through g_slice. g_slice has a global state that is not fork safe. + +So even though the cpu thread is set to exclusive before forking, it is not enough. Because there are other uses of glib data structures that are not part of the cpu loop (I think). So it seems not to be synchronized by `start_exclusive`, `end_exclusive`. + +So if one of the use of glib data structure is used during the fork, an allocation might lock a mutex in g_slice. + +When the cpu loop resumes in forked process, then the use of any glib data structure might just hang on a locked mutex in g_slice. + +So as a work-around we have starting using is setting environment `G_SLICE=always-malloc`. This resolves the hangs. + +I have opened an issue upstream: https://gitlab.gnome.org/GNOME/glib/-/issues/2326 + +As fork documentation says, the child should be async-signal-safe. However, glibc's malloc is safe in fork child even though it is not async-signal-safe. So it is not that obvious where the responsability is. Should glib handle this case like malloc does? Or should qemu not use glib in the fork child?
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1915682 b/results/classifier/mode-gemma3:12b/user/1915682 new file mode 100644 index 00000000..9ab38ebf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1915682 @@ -0,0 +1,100 @@ + + +i386-linux-user wine exception regression tests fail + +When trying to run wine (latest devel from git) regression tests for ntdll in a statically linked qemu-i386 (commit 392b9a74b9b621c52d05e37bc6f41f1bbab5c6f8) on arm32 (raspberry pi 4) in a debian buster chroot, the exception tests fail at the first test with an infinite exception loop. + +WINEDEBUG=+seh wine wine/dlls/ntdll/tests/ntdll_test.exe exception + + +Working x86_64 system running 32-bit code + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=7ffc2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:NtGetContextThread 0xfffffffe: dr0=42424240 dr1=00000000 dr2=126bb070 dr3=0badbad0 dr6=00000000 dr7=ffff0115 + + +Non-working qemu + +0024:warn:seh:dispatch_exception EXCEPTION_ACCESS_VIOLATION exception (code=c0000005) raised +0024:trace:seh:dispatch_exception eax=00000000 ebx=3ffe2000 ecx=004e0ef4 edx=003c0004 esi=003c0000 edi=00000000 +0024:trace:seh:dispatch_exception ebp=0085fa08 esp=0085f9ac cs=0023 ds=002b es=002b fs=003b gs=0033 flags=00000246 +0024:trace:seh:call_vectored_handlers calling handler at 7B00B460 code=c0000005 flags=0 +0024:trace:seh:call_vectored_handlers handler at 7B00B460 returned 0 +0024:trace:seh:call_stack_handlers calling handler at 004178B0 code=c0000005 flags=0 +0024:trace:seh:call_stack_handlers handler at 004178B0 returned 0 +0024:trace:seh:dispatch_exception call_stack_handlers continuing +0024:trace:seh:dispatch_exception call_stack_handlers ret status = 0 +0024:trace:seh:dispatch_exception code=0 flags=1 addr=7BC2389C ip=7bc2389c tid=0024 + +The non-working verion is never managing to set the CPU context using NtContinue/SetContextThread back to the correct running thread stack and IP. It executes as if the context restore just returns to the function that called NtContinue() (dispatch_exception(), not the function that raised the exception or one of its parent exception handlers). + +It looks like NtSetContextThread(), specifically the asm function set_full_cpu_context() is being handled incorrectly. + +wine code below. note interesting use of iret with no previous interrupt call. The exception handler is called with a jmp. + +/*********************************************************************** + * set_full_cpu_context + * + * Set the new CPU context. + */ +extern void set_full_cpu_context( const CONTEXT *context ); +__ASM_GLOBAL_FUNC( set_full_cpu_context, + "movl $0,%fs:0x1f8\n\t" /* x86_thread_data()->syscall_frame = NULL */ + "movl 4(%esp),%ecx\n\t" + "movw 0x8c(%ecx),%gs\n\t" /* SegGs */ + "movw 0x90(%ecx),%fs\n\t" /* SegFs */ + "movw 0x94(%ecx),%es\n\t" /* SegEs */ + "movl 0x9c(%ecx),%edi\n\t" /* Edi */ + "movl 0xa0(%ecx),%esi\n\t" /* Esi */ + "movl 0xa4(%ecx),%ebx\n\t" /* Ebx */ + "movl 0xb4(%ecx),%ebp\n\t" /* Ebp */ + "movw %ss,%ax\n\t" + "cmpw 0xc8(%ecx),%ax\n\t" /* SegSs */ + "jne 1f\n\t" + /* As soon as we have switched stacks the context structure could + * be invalid (when signal handlers are executed for example). Copy + * values on the target stack before changing ESP. */ + "movl 0xc4(%ecx),%eax\n\t" /* Esp */ + "leal -4*4(%eax),%eax\n\t" + "movl 0xc0(%ecx),%edx\n\t" /* EFlags */ + ".byte 0x36\n\t" + "movl %edx,3*4(%eax)\n\t" + "movl 0xbc(%ecx),%edx\n\t" /* SegCs */ + ".byte 0x36\n\t" + "movl %edx,2*4(%eax)\n\t" + "movl 0xb8(%ecx),%edx\n\t" /* Eip */ + ".byte 0x36\n\t" + "movl %edx,1*4(%eax)\n\t" + "movl 0xb0(%ecx),%edx\n\t" /* Eax */ + ".byte 0x36\n\t" + "movl %edx,0*4(%eax)\n\t" + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "movl %eax,%esp\n\t" + "popl %eax\n\t" + "iret\n" + /* Restore the context when the stack segment changes. We can't use + * the same code as above because we do not know if the stack segment + * is 16 or 32 bit, and 'movl' will throw an exception when we try to + * access memory above the limit. */ + "1:\n\t" + "movl 0xa8(%ecx),%edx\n\t" /* Edx */ + "movl 0xb0(%ecx),%eax\n\t" /* Eax */ + "movw 0xc8(%ecx),%ss\n\t" /* SegSs */ + "movl 0xc4(%ecx),%esp\n\t" /* Esp */ + "pushl 0xc0(%ecx)\n\t" /* EFlags */ + "pushl 0xbc(%ecx)\n\t" /* SegCs */ + "pushl 0xb8(%ecx)\n\t" /* Eip */ + "pushl 0x98(%ecx)\n\t" /* SegDs */ + "movl 0xac(%ecx),%ecx\n\t" /* Ecx */ + "popl %ds\n\t" + "iret" )
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1915925 b/results/classifier/mode-gemma3:12b/user/1915925 new file mode 100644 index 00000000..cca2f4e9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1915925 @@ -0,0 +1,19 @@ + + +ARM semihosting HEAPINFO results wrote to wrong address + +This affects latest development branch of QEMU. + +According to the ARM spec of the HEAPINFO semihosting call: + +https://developer.arm.com/documentation/100863/0300/Semihosting-operations/SYS-HEAPINFO--0x16-?lang=en + +> the PARAMETER REGISTER contains the address of a pointer to a four-field data block. + +However, QEMU treated the PARAMETER REGISTER as pointing to a four-field data block directly. + +Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting-newlib + +This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. + +Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1916344 b/results/classifier/mode-gemma3:12b/user/1916344 new file mode 100644 index 00000000..b5640f7f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1916344 @@ -0,0 +1,26 @@ + + +User mode networking not working properly on QEMU on Mac OS X host + +Steps to reproduce: + +1. Install QEMU using homebrew on Mac OS X (I used Big Sur) +2. Spin up a guest VM (say) Cent OS8 using user mode networking. +3. Install podman inside the guest +4. Run podman pull alpine + +The result is: + +[root@localhost ~]# podman pull alpine +Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf) +Trying to pull docker.io/library/alpine:latest... +Getting image source signatures +Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB + unexpected EOF +Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF + +This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest. + +This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X. + +This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1917184 b/results/classifier/mode-gemma3:12b/user/1917184 new file mode 100644 index 00000000..f0db6bd9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1917184 @@ -0,0 +1,7 @@ + + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip + +When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault. + +qemu version 5.2.0, x86-64 host.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1917591 b/results/classifier/mode-gemma3:12b/user/1917591 new file mode 100644 index 00000000..6a72ec2f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1917591 @@ -0,0 +1,30 @@ + + +qemu-i386 under aarch64: Segfaulting on Steamcmd + +I am trying to set up a Valheim server on my Raspberry Pi. I have installed the aarch64 image of Arm Arch Linux. + +I installed qemu-user-static from the AUR: https://aur.archlinux.org/packages/qemu-user-static/ +I have correctly set up binfmt support: https://aur.archlinux.org/packages/binfmt-qemu-static-all-arch/ + +This allows me to successfully run i386 and amd64 docker images: + +[alarm@server ~]$ sudo docker run --rm i386/debian uname -a +WARNING: The requested image's platform (linux/386) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 9fd8d345b0aa 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 i686 GNU/Linux + +and + +[alarm@server ~]$ sudo docker run --rm amd64/debian uname -a +WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 4f50fd228ab6 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 x86_64 GNU/Linux + +However, when I try to run the docker image that is going to host the server, the download of Valheim never succeeds because the used steamcmd application segfaults: + +The following command successfully runs the server: sudo docker run -d --name valheim-server -p 2456-2458:2456-2458/udp -e SERVER_NAME="My Server" -e WORLD_NAME="Neotopia" -e SERVER_PASS="secret" lloesche/valheim-server + +However, when we look into the container's logs via this command: sudo docker logs valheim-server + +We see the following entry in the log file: ./steamcmd.sh: line 38: 86 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@" + +This means that the download never completes, and therefor the Valheim server is never actually started. Any help would be much appreciated. If there is anything unclear or if you need more details, please let me know!
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1918026 b/results/classifier/mode-gemma3:12b/user/1918026 new file mode 100644 index 00000000..70295929 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1918026 @@ -0,0 +1,31 @@ + + +RISCV64 32-bit AMOs incorrectly simulated + +Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) + +test: + amomaxu.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); // FAIL, saw -11 +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); // FAIL, raw -11 +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); + +test: + amomax.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); // FAIL, saw -7 + +I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1918149 b/results/classifier/mode-gemma3:12b/user/1918149 new file mode 100644 index 00000000..48639fa7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1918149 @@ -0,0 +1,12 @@ + + +qemu-user reports wrong fault_addr in signal handler + +When a SEGV signal occurs and si_addr of the info struct is nil, qemu still tries to translate the address from host to guest (handle_cpu_signal in accel/tcg/user-exec.c). This means, that the actual signal handler, will receive a fault_addr that is something like 0xffffffffbf709000. + +I was able to get this to happen, by branching to a non canonical address on aarch64. +I used 5.2 (commit: 553032db17). However, building from source, this only seems to happen, if I use the same configure flags as the debian build: + +../configure --static --target-list=aarch64-linux-user --disable-system --enable-trace-backends=simple --disable-linux-io-uring --disable-pie --extra-cflags="-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" --extra-ldflags="-Wl,-z,relro -Wl,--as-needed" + +Let me know, if you need more details.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1918975 b/results/classifier/mode-gemma3:12b/user/1918975 new file mode 100644 index 00000000..21f62d23 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1918975 @@ -0,0 +1,7 @@ + + +[Feature request] Propagate interpreter to spawned processes + +I want QEMU user static to propagate interpreter to spawned processes, for instances by adding -R recursive. + +I.e. if my program is interpreted by QEMU static than everything what it launches should be interpreted by it, too.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1920 b/results/classifier/mode-gemma3:12b/user/1920 new file mode 100644 index 00000000..f824e337 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1920 @@ -0,0 +1,13 @@ + + +regrssion on 8.1.x: java/maven fails to run on qemu-aarch64 +Description of problem: +Java process crashes when running simple "mvn -version" command inside qemu-aarch64. "java -version" works. +Last known working version: 8.0.3 (qemu-8.0.3-4.fc39) +Failing versions: 8.1.1 (qemu-8.1.1-1.fc39) and 8.1.0 (qemu-8.1.0-1.fc39) +The same image works on native arm64 machine. +Steps to reproduce: +1. podman run --platform linux/arm64 docker.io/library/maven:3.9-eclipse-temurin-20 mvn -version +2. should display few lines of version information and not a NullPointerException +Additional information: +podman version 4.7.0 diff --git a/results/classifier/mode-gemma3:12b/user/1920602 b/results/classifier/mode-gemma3:12b/user/1920602 new file mode 100644 index 00000000..aa247b9b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1920602 @@ -0,0 +1,21 @@ + + +QEMU crash after a QuickBASIC program integer overflow + +A trivial program compiler with QuickBASIC 4.5 with integer overflow will crash QEMU when ran under MS-DOS 5.0 or FreeDOS 1.2: + +C:\KILLER>type killer.bas +A% = VAL("99999"):PRINT A% + +C:\KILLER>killer.exe +** + ERROR:../qemu-5.2.0/accel/tcg/tcg-cpus.c:541:tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked()) +Aborted + +QEMU version v5.2, compiler for ARM, and started with command line: + +qemu-system-i386 -curses -cpu 486 -m 1 -drive dos.img + +The same test under Ubuntu QEMU and KVM/x86_64 (QEMU emulator version 4.2.1 (Debian 1:4.2-3ubuntu6.14)) will just silently hang the QEMU. On DOSBOX, the machine does not die and program outputs the value -31073. + +The EXE to reproduce the issue is attached.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1924231 b/results/classifier/mode-gemma3:12b/user/1924231 new file mode 100644 index 00000000..addfa82e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1924231 @@ -0,0 +1,103 @@ + + +Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on. + +the QEMU release version where the bug was found. + +apt list --installed | grep qemu +qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.14 amd64 [installed] + + +The installing "libc-bin" which "wget" depends on crashes as below when we execute docker image of Debian GNU/Linux bullseye for ARM64 on Ubuntu 20.04 for AMD64. +This problem also occurs on CI(GitHub Actions)(https://github.com/groonga/groonga/runs/2338497272?check_suite_focus=true#step:11:127). +Probably, The cause of this crash is https://bugs.launchpad.net/qemu/+bug/1749393. +This bug has already been fixed in qemu-user-static pacakge for Ubuntu 20.10. + +However, this fix is not included in qemu-user-static pacakge for Ubuntu 20.04. +Currently, GitHub Actions does not support Ubuntu 20.10. +Therefore, this problem is still happening in CI. + +Would it be possible for you to backport this fix into Ubuntu 20.04? + + +How to reproduce: + +sudo apt install -y qemu-user-static docker.io +sudo docker run --rm arm64v8/debian:bullseye bash -c 'apt update && apt install -y wget' + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] +Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB] +Get:3 http://deb.debian.org/debian bullseye-updates InRelease [40.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 Packages [8084 kB] +Get:5 http://security.debian.org/debian-security bullseye-security/main arm64 Packages [808 B] +Fetched 8311 kB in 4s (2001 kB/s) +Reading package lists... +Building dependency tree... +Reading state information... +2 packages can be upgraded. Run 'apt list --upgradable' to see them. + +WARNING: apt does not have a stable CLI interface. Use with caution in scripts. + +Reading package lists... +Building dependency tree... +Reading state information... +The following additional packages will be installed: + ca-certificates libpsl5 openssl publicsuffix +The following NEW packages will be installed: + ca-certificates libpsl5 openssl publicsuffix wget +0 upgraded, 5 newly installed, 0 to remove and 2 not upgraded. +Need to get 2111 kB of archives. +After this operation, 5844 kB of additional disk space will be used. +Get:1 http://deb.debian.org/debian bullseye/main arm64 openssl arm64 1.1.1k-1 [829 kB] +Get:2 http://deb.debian.org/debian bullseye/main arm64 ca-certificates all 20210119 [158 kB] +Get:3 http://deb.debian.org/debian bullseye/main arm64 libpsl5 arm64 0.21.0-1.2 [57.1 kB] +Get:4 http://deb.debian.org/debian bullseye/main arm64 wget arm64 1.21-1 [946 kB] +Get:5 http://deb.debian.org/debian bullseye/main arm64 publicsuffix all 20210108.1309-1 [121 kB] +debconf: delaying package configuration, since apt-utils is not installed +Fetched 2111 kB in 0s (12.9 MB/s) +Selecting previously unselected package openssl. +(Reading database ... 6640 files and directories currently installed.) +Preparing to unpack .../openssl_1.1.1k-1_arm64.deb ... +Unpacking openssl (1.1.1k-1) ... +Selecting previously unselected package ca-certificates. +Preparing to unpack .../ca-certificates_20210119_all.deb ... +Unpacking ca-certificates (20210119) ... +Selecting previously unselected package libpsl5:arm64. +Preparing to unpack .../libpsl5_0.21.0-1.2_arm64.deb ... +Unpacking libpsl5:arm64 (0.21.0-1.2) ... +Selecting previously unselected package wget. +Preparing to unpack .../archives/wget_1.21-1_arm64.deb ... +Unpacking wget (1.21-1) ... +Selecting previously unselected package publicsuffix. +Preparing to unpack .../publicsuffix_20210108.1309-1_all.deb ... +Unpacking publicsuffix (20210108.1309-1) ... +Setting up libpsl5:arm64 (0.21.0-1.2) ... +Setting up wget (1.21-1) ... +Setting up openssl (1.1.1k-1) ... +Setting up publicsuffix (20210108.1309-1) ... +Setting up ca-certificates (20210119) ... +debconf: unable to initialize frontend: Dialog +debconf: (TERM is not set, so the dialog frontend is not usable.) +debconf: falling back to frontend: Readline +debconf: unable to initialize frontend: Readline +debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/aarch64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) +debconf: falling back to frontend: Teletype +Updating certificates in /etc/ssl/certs... +129 added, 0 removed; done. +Processing triggers for libc-bin (2.31-11) ... +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault +dpkg: error processing package libc-bin (--configure): + installed libc-bin package post-installation script subprocess returned error exit status 139 +Processing triggers for ca-certificates (20210119) ... +Updating certificates in /etc/ssl/certs... +0 added, 0 removed; done. +Running hooks in /etc/ca-certificates/update.d... +done. +Errors were encountered while processing: + libc-bin +E: Sub-process /usr/bin/dpkg returned an error code (1)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1926044 b/results/classifier/mode-gemma3:12b/user/1926044 new file mode 100644 index 00000000..4464fd81 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1926044 @@ -0,0 +1,32 @@ + + +QEMU-user doesn't report HWCAP2_MTE + +Reproducible on ffa090bc56e73e287a63261e70ac02c0970be61a + +Host Debian 5.10.24 x86_64 GNU + +Configured with "configure --disable-system --enable-linux-user --static" + +This one works and prints "OK" as expected: +clang tests/tcg/aarch64/mte-3.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out && echo OK + + +This one fails and print "0": +cat mytest.c +#include <stdio.h> +#include <sys/auxv.h> + +#ifndef HWCAP2_MTE +#define HWCAP2_MTE (1 << 18) +#endif + +int main(int ac, char **av) +{ + printf("%d\n", (int)(getauxval(AT_HWCAP2) & HWCAP2_MTE)); +} + + +clang mytest.c -target aarch64-linux-gnu -fsanitize=memtag -march=armv8+memtag +qemu-aarch64 --cpu max -L /usr/aarch64-linux-gnu ./a.out
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1926202 b/results/classifier/mode-gemma3:12b/user/1926202 new file mode 100644 index 00000000..03189221 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1926202 @@ -0,0 +1,20 @@ + + +qemu-user can't run some ppc binaries + +qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. + +The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: + +$ uname -m +x86_64 +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t qemu-bug:centos -f Dockerfile.centos . +$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . +$ qemu-ppc version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-ppc-static ./helloworld-centos.static.ppc +emu: uncaught target signal 4 (Illegal instruction) - core dumped +[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc + +I can also provide the binary if necessary.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1926246 b/results/classifier/mode-gemma3:12b/user/1926246 new file mode 100644 index 00000000..92414bc3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1926246 @@ -0,0 +1,52 @@ + + +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/mode-gemma3:12b/user/1926521 b/results/classifier/mode-gemma3:12b/user/1926521 new file mode 100644 index 00000000..94944e2f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1926521 @@ -0,0 +1,64 @@ + + +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/mode-gemma3:12b/user/1926996 b/results/classifier/mode-gemma3:12b/user/1926996 new file mode 100644 index 00000000..9670e2dd --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1926996 @@ -0,0 +1,22 @@ + + +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/mode-gemma3:12b/user/1927530 b/results/classifier/mode-gemma3:12b/user/1927530 new file mode 100644 index 00000000..bbbb9db2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1927530 @@ -0,0 +1,41 @@ + + +qemu-aarch64 MTE fails to report tag mismatch + +Hi, + +While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests). + +I am attaching: +bitfield-2.exe +ld-linux-aarch64.so.1 +libc.so.6 +libdl.so.2 +libhwasan.so.0 +libm.so.6 +libpthread.so.0 +librt.so.1 + +The testcase can be executed via: +qemu-aarch64 -L . bitfield-2.exe + +it currently generates: +HWAddressSanitizer:DEADLYSIGNAL +==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 (pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137) +==21137==The signal is caused by a UNKNOWN memory access. +==21137==Hint: address points to the zero page. + #0 0x550084e318 in GetAccessInfo /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 + #1 0x550084e318 in HwasanOnSIGTRAP /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401 + #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426 + #3 0x5f01651fec (<unknown module>) + #4 0x550084b508 in __hwasan_load2 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379 + #5 0x400768 in f /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17 + #6 0x4007d0 in main /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24 + #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308 + #8 0x400688 (/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688) + +HWAddressSanitizer can not provide additional info. +SUMMARY: HWAddressSanitizer: SEGV /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 in GetAccessInfo +==21146==ABORTING + +while the testcase expects HWAddressSanitizer: tag-mismatch on address 0x.....
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1930 b/results/classifier/mode-gemma3:12b/user/1930 new file mode 100644 index 00000000..f323b483 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1930 @@ -0,0 +1,48 @@ + + +qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX +Description of problem: +We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` + +We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error. +Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated. +Steps to reproduce: +1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178. +2. Write a simple hello world program. + +``` + #include <stdio.h> + + int main(void) { + return printf("Hello World!"); + } +``` + +3. Source QNX SDP to set some environment variables. + + `$ source ./qnx710/qnxsdp-env.sh` + +4. Compile using the QNX compiler. + + `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c` + +5. Running the binary as it is results to: + +``` + $ ./hello-world + aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory +``` + +5. Running using QEMU emulator results to segmentation fault. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` diff --git a/results/classifier/mode-gemma3:12b/user/1936977 b/results/classifier/mode-gemma3:12b/user/1936977 new file mode 100644 index 00000000..ef7c0626 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1936977 @@ -0,0 +1,9 @@ + + + qemu-arm-static crashes "segmentation fault" when running "git clone" + +This is a reopen of #1869073 for `qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.17 amd64`. + +`git clone` reproducably segfaults in `qemu-arm-static` chroot. + +#1869073 mentions this should have been fixed for newer versions of QEMU, but for `focal` there's no newer version available, even in `focal-backports`.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/1941 b/results/classifier/mode-gemma3:12b/user/1941 new file mode 100644 index 00000000..4ff15b7d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1941 @@ -0,0 +1,104 @@ + + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/mode-gemma3:12b/user/1942 b/results/classifier/mode-gemma3:12b/user/1942 new file mode 100644 index 00000000..05e99d25 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1942 @@ -0,0 +1,11 @@ + + +GCC segfault (ICE) while building in qemu-user sparc64 +Steps to reproduce: +1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64 +2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2` + +Resulting compilation will fail with an internal compilation error. +Additional information: +This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package. +Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt) diff --git a/results/classifier/mode-gemma3:12b/user/1952 b/results/classifier/mode-gemma3:12b/user/1952 new file mode 100644 index 00000000..21b0d5b8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1952 @@ -0,0 +1,98 @@ + + +elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader +Description of problem: +Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this + +``` +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Steps to reproduce: +1. Obtain latest Zig nightly +2. Compile simple static C program using Zig's ELF linker: + +``` +$ echo "int main() { return 0 };" > simple.c +$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000 +$ qemu-x86_64 simple +fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error) +``` +Additional information: +Note that running `simple` directly it's correctly mmaped and executed by the kernel: + +``` +$ ./simple +$ echo $status +0 +``` + +The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely: + +``` +vaddr2 - vaddr1 >= off2 - off1 +``` + +Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault: + +```diff +diff --git a/linux-user/elfload.c b/linux-user/elfload.c +index f21e2e0c3d..eabb4fed03 100644 +--- a/linux-user/elfload.c ++++ b/linux-user/elfload.c +@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd, + for (i = 0; i < ehdr->e_phnum; ++i) { + struct elf_phdr *eppnt = phdr + i; + if (eppnt->p_type == PT_LOAD) { +- abi_ulong a = eppnt->p_vaddr - eppnt->p_offset; ++ abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1); + if (a < loaddr) { + loaddr = a; + } +``` + +The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig: + +``` +$ readelf -l simple + +Elf file type is EXEC (Executable file) +Entry point 0x1002000 +There are 7 program headers, starting at offset 64 + +Program Headers: + Type Offset VirtAddr PhysAddr + FileSiz MemSiz Flags Align + PHDR 0x0000000000000040 0x0000000001000040 0x0000000001000040 + 0x0000000000000188 0x0000000000000188 R 0x8 + LOAD 0x0000000000000000 0x0000000001000000 0x0000000001000000 + 0x00000000000001c8 0x00000000000001c8 R 0x1000 + LOAD 0x0000000000021000 0x0000000001001000 0x0000000001001000 + 0x0000000000000078 0x0000000000000078 R 0x1000 + LOAD 0x0000000000022000 0x0000000001002000 0x0000000001002000 + 0x000000000000065a 0x000000000000065a R E 0x1000 + LOAD 0x0000000000023000 0x0000000001003000 0x0000000001003000 + 0x0000000000000060 0x0000000000000278 RW 0x1000 + GNU_EH_FRAME 0x0000000000021064 0x0000000001001064 0x0000000001001064 + 0x0000000000000014 0x0000000000000014 R 0x4 + GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 + 0x0000000000000000 0x0000000000000000 RW 0x1 + + Section to Segment mapping: + Segment Sections... + 00 + 01 + 02 .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr + 03 .text .init .fini + 04 .data .got .bss + 05 .eh_frame_hdr + 06 +``` + +As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get + +``` +a := 0x1001000 - 0x21000 = 0xfe000 +``` + +and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`. diff --git a/results/classifier/mode-gemma3:12b/user/1953 b/results/classifier/mode-gemma3:12b/user/1953 new file mode 100644 index 00000000..e22b5a17 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1953 @@ -0,0 +1,148 @@ + + +Segmentation fault when compiling elixir app on qemu aarch64 on x86_64 host +Description of problem: +When I try to install an elixir escript using + +``` +mix escript.install github upmaru/pakman --force +``` + +I run into a segfault with the following output + +``` + + +Build and Deploy +failed Oct 22, 2023 in 1m 27s +2s +2s +22s +56s +remote: Compressing objects: 86% (144/167) +remote: Compressing objects: 87% (146/167) +remote: Compressing objects: 88% (147/167) +remote: Compressing objects: 89% (149/167) +remote: Compressing objects: 90% (151/167) +remote: Compressing objects: 91% (152/167) +remote: Compressing objects: 92% (154/167) +remote: Compressing objects: 93% (156/167) +remote: Compressing objects: 94% (157/167) +remote: Compressing objects: 95% (159/167) +remote: Compressing objects: 96% (161/167) +remote: Compressing objects: 97% (162/167) +remote: Compressing objects: 98% (164/167) +remote: Compressing objects: 99% (166/167) +remote: Compressing objects: 100% (167/167) +remote: Compressing objects: 100% (167/167), done. +remote: Total 2568 (delta 86), reused 188 (delta 58), pack-reused 2341 +origin/HEAD set to develop +Resolving Hex dependencies... +Resolution completed in 0.872s +New: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +* Getting tesla (Hex package) +* Getting jason (Hex package) +* Getting yaml_elixir (Hex package) +* Getting slugger (Hex package) +* Getting finch (Hex package) +* Getting mint (Hex package) +* Getting castore (Hex package) +* Getting hpax (Hex package) +* Getting mime (Hex package) +* Getting nimble_options (Hex package) +* Getting nimble_pool (Hex package) +* Getting telemetry (Hex package) +* Getting yamerl (Hex package) +Resolving Hex dependencies... +Resolution completed in 0.413s +Unchanged: + castore 1.0.4 + finch 0.16.0 + hpax 0.1.2 + jason 1.4.1 + mime 2.0.5 + mint 1.5.1 + nimble_options 1.0.2 + nimble_pool 1.0.0 + slugger 0.3.0 + telemetry 1.2.1 + tesla 1.7.0 + yamerl 0.10.0 + yaml_elixir 2.8.0 +All dependencies are up to date +==> mime +Compiling 1 file (.ex) +Generated mime app +==> nimble_options +Compiling 3 files (.ex) +qemu: uncaught target signal 11 (Segmentation fault) - core dumped +Segmentation fault (core dumped) +``` +Steps to reproduce: +1. Create a repo using the github action zacksiri/setup-alpine +2. Install elixir +3. run `mix escript.install github upmaru/pakman --force` +Additional information: +You can use the following github action config as an example / starting point. + + +```yml +name: 'Deployment' + +on: + push: + branches: + - main + - master + - develop + +jobs: + build_and_deploy: + name: Build and Deploy + runs-on: ubuntu-latest + steps: + - name: 'Checkout' + uses: actions/checkout@v3 + with: + ref: ${{ github.event.workflow_run.head_branch }} + fetch-depth: 0 + + - name: 'Setup Alpine' + uses: zacksiri/setup-alpine@master + with: + branch: v3.18 + arch: aarch64 + qemu-repo: edge + packages: | + zip + tar + sudo + alpine-sdk + coreutils + cmake + elixir + + - name: 'Setup PAKman' + run: | + export MIX_ENV=prod + + mix local.rebar --force + mix local.hex --force + mix escript.install github upmaru/pakman --force + shell: alpine.sh {0} +``` + +I'm using alpine 3.18 which has otp25 with jit enabled so I suspect this is something to do with https://gitlab.com/qemu-project/qemu/-/issues/1034 diff --git a/results/classifier/mode-gemma3:12b/user/1955 b/results/classifier/mode-gemma3:12b/user/1955 new file mode 100644 index 00000000..611f71e5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1955 @@ -0,0 +1,28 @@ + + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/mode-gemma3:12b/user/1962 b/results/classifier/mode-gemma3:12b/user/1962 new file mode 100644 index 00000000..a549a71e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1962 @@ -0,0 +1,31 @@ + + +systemd-tmpfiles-setup-dev-early.service fails in emulated systemd-nspawn container +Description of problem: +When booting a fresh `debootstrap`ed Debian Trixie/testing rootfs with foreign architecture via `systemd-nspawn` and `qemu-user-static`, invoked via `systemd-binfmt`, the `systemd-tmpfiles-setup-dev-early.service` service within the guest fails, which leads to `/dev` not existing (respectively no default content), so that several other guest system components fail as well, like any console/shell access: +``` +Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully... +systemd-tmpfiles-setup-dev-early.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev-early.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev-early.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully. +See 'systemctl status systemd-tmpfiles-setup-dev-early.service' for details. +Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev... +systemd-tmpfiles-setup-dev.service: Failed to set up credentials: Invalid argument +systemd-tmpfiles-setup-dev.service: Main process exited, code=exited, status=243/CREDENTIALS +systemd-tmpfiles-setup-dev.service: Failed with result 'exit-code'. +[FAILED] Failed to start systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev. +See 'systemctl status systemd-tmpfiles-setup-dev.service' for details. +``` +Steps to reproduce: +1. `apt install debootstrap systemd-container qemu-user-static` +2. `systemctl restart systemd-binfmt` +3. `mkdir rootfs` +4. `debootstrap --variant=minbase --include=systemd-sysv --arch=arm64 trixie ./rootfs 'https://deb.debian.org/debian'` +5. `systemd-nspawn -bD rootfs` +Additional information: +On Bookworm guest systems and/or without QEMU emulation, this works without issues, so I guess systemd recently started to use a certain syscall for the `ImportCredential=tmpfiles.*` method in systemd units, which is not supported by QEMU, probably similar to https://github.com/systemd/systemd/pull/28954? + +I hope it is fine to report it here. Always difficult to decide whether to report to the distribution (Debian) or one, and in case which, of the related projects, which do not work together. + +Debian Trixie currently ships `systemd 254.4-1` btw. I am not sure whether the issue was introduced with 253 or 254, since the linked issue prevented booting such containers on an earlier stage with 253, which was fixed in 254, which has the here reported issue. diff --git a/results/classifier/mode-gemma3:12b/user/1963 b/results/classifier/mode-gemma3:12b/user/1963 new file mode 100644 index 00000000..812a9307 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1963 @@ -0,0 +1,30 @@ + + +EOF is not detected, when semihosting is reading from stdin +Description of problem: +QEMU hangs. +Steps to reproduce: +1. Run the program with stdin from a pipe. +Additional information: +The code is compiled from this source: +``` +#include <stdio.h> + +int main(int argc, char** argv) { + int i = -1; + int result = scanf("%d", &i); + printf("result = %d, i = %d\n", result, i); + return 0; +} +``` +compiled with GCC and picolibc: +``` +arm-none-eabi-gcc --specs=picolibc.specs -march=armv7-m ~/sources/picolibc/git/test-stdin.c -o test-stdin -lc -lsemihost --crt0=hosted -O0 -g +``` +[test-stdin](/uploads/dbd2650c8e0aaca353fd7630ac9c8440/test-stdin) +The execution hangs at semihosting SYS_READC(0x7) call: +``` + movs r0, #7 +(...) + bkpt #0xab +``` diff --git a/results/classifier/mode-gemma3:12b/user/1964 b/results/classifier/mode-gemma3:12b/user/1964 new file mode 100644 index 00000000..88cf0d32 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1964 @@ -0,0 +1,9 @@ + + +QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties +Description of problem: +QEMU TCG faulted in RUNDLL32 at Windows 98SE Display Properties. 100% consistently reproducible across multiple host operating systems and CPU architectures and all types of QEMU emulated display controllers supported by Windows 98SE (`VGA, cirrus-vga and vmware-svga`). It is a user-mode fault so the OS simply terminated the faulting process, OS remains fully functional after the fault and the same fault can be repeated. Should be extremely helpful in debugging. Last known good QEMU version without this bug is 7.1.0. For x86_64, KVM and WHPX do not have the issue and can be used to gain access to Display Properties. On AArch64, last known good QEMU version is the only way to gain access to Display Properties. +Steps to reproduce: +See attached recorded video. + + diff --git a/results/classifier/mode-gemma3:12b/user/1967248 b/results/classifier/mode-gemma3:12b/user/1967248 new file mode 100644 index 00000000..d3960bb7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1967248 @@ -0,0 +1,40 @@ + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/197 b/results/classifier/mode-gemma3:12b/user/197 new file mode 100644 index 00000000..313d3747 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/197 @@ -0,0 +1,3 @@ + + +Unpredictable behaviour resulting in User process faults diff --git a/results/classifier/mode-gemma3:12b/user/1977 b/results/classifier/mode-gemma3:12b/user/1977 new file mode 100644 index 00000000..840d3452 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1977 @@ -0,0 +1,32 @@ + + +MSYS2 build fails with link errors on Window 10 22H2 +Description of problem: +Linking target tests/plugin/libbb.dll fails with undefined references in below attached output +Steps to reproduce: +1. Open MSYS2 build environment on Windows 10 +2. mkdir build && cd build && ../configure --prefix=/home/Admin --enable-sdl --enable-gtk --target-list=arm-softmmu +3. make -j4 +Additional information: +[2300/2631] Linking target tests/plugin/libbb.dll +FAILED: tests/plugin/libbb.dll +"cc" "-m64" "-mcx16" -o tests/plugin/libbb.dll plugins/qemu_plugin_api.lib tests/plugin/libbb.dll.p/bb.c.obj tests/plugin/libbb.dll.p/.._.._contrib_plugins_win32_linker.c.obj "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=tests/plugin/libbb.dll.a" "-fstack-protector-strong" "-Wl,--no-seh" "-Wl,--nxcompat" "-Wl,--dynamicbase" "-Wl,--high-entropy-va" "-Wl,--warn-common" "C:/msys64/ucrt64/lib/libglib-2.0.dll.a" "C:/msys64/ucrt64/lib/libintl.dll.a" "C:/msys64/ucrt64/lib/libgmodule-2.0.dll.a" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-ladvapi32" "-Wl,--end-group" +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_tb_trans': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:84:(.text+0x4f): undefined reference to `__imp_qemu_plugin_tb_n_insns' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:87:(.text+0x62): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_inline' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:93:(.text+0xba): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_exec_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `plugin_exit': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x1cb): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:55:(.text+0x204): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `vcpu_idle': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:66:(.text+0x299): undefined reference to `__imp_qemu_plugin_outs' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: tests/plugin/libbb.dll.p/bb.c.obj: in function `qemu_plugin_install': +C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:114:(.text+0x2e8): undefined reference to `__imp_qemu_plugin_bool_parse' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:141:(.text+0x3d5): undefined reference to `__imp_qemu_plugin_register_vcpu_tb_trans_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:142:(.text+0x3ea): undefined reference to `__imp_qemu_plugin_register_atexit_cb' +C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\msys64\home\Admin\qemu\build/../tests/plugin/bb.c:138:(.text+0x420): undefined reference to `__imp_qemu_plugin_register_vcpu_idle_cb' +collect2.exe: error: ld returned 1 exit status +[2301/2631] Compiling C object tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj +[2302/2631] Compiling C object tests/libtestqapi.a.p/meson-generated_.._test-qapi-visit.c.obj +[2303/2631] Compiling C object tests/plugin/libinsn.dll.p/.._.._contrib_plugins_win32_linker.c.obj +ninja: build stopped: subcommand failed. diff --git a/results/classifier/mode-gemma3:12b/user/1994 b/results/classifier/mode-gemma3:12b/user/1994 new file mode 100644 index 00000000..ade84502 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/1994 @@ -0,0 +1,3 @@ + + +MacOS window sizing bug diff --git a/results/classifier/mode-gemma3:12b/user/2011 b/results/classifier/mode-gemma3:12b/user/2011 new file mode 100644 index 00000000..3901fbf8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2011 @@ -0,0 +1,3 @@ + + +ARM emulation layer for Windows x86_64 OS request diff --git a/results/classifier/mode-gemma3:12b/user/2035 b/results/classifier/mode-gemma3:12b/user/2035 new file mode 100644 index 00000000..64b6942a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2035 @@ -0,0 +1,56 @@ + + +TCG Plugin exit callback not executing +Description of problem: +I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success. + +**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?** +Steps to reproduce: +1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system` +2. Compiled plugin with +``` +gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0` +``` +3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu` +4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu +Additional information: +test_plugin.c +``` +#include <inttypes.h> +#include <assert.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <stdio.h> +#include <qemu-plugin.h> + +QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION; + +static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb) +{ + int n_insns = qemu_plugin_tb_n_insns(tb); + printf("> New TB of size %d\n", n_insns); + + for (int i = 0; i < n_insns; i++) { + struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i); + char * disassembly = qemu_plugin_insn_disas(insn); + printf(" > Instruciton: %s\n", disassembly); + } +} + +static void plugin_exit(qemu_plugin_id_t id, void *p) +{ + printf("> Goodbye from plugin. %d\n", id); +} + +QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id, + const qemu_info_t *info, + int argc, char **argv) +{ + printf("> Hello From Plugin!\n"); + qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans); + qemu_plugin_register_atexit_cb(id, plugin_exit, NULL); + printf("> Everything was registered\n"); + return 0; +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/2038 b/results/classifier/mode-gemma3:12b/user/2038 new file mode 100644 index 00000000..8d8f6880 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2038 @@ -0,0 +1,18 @@ + + +simpletrace.py does nothing, and syntax error when called from bash script +Description of problem: +The simpletrace python script appears to do nothing when I run it as above. + +It appears to run (but do nothing) when called from my terminal but there is also a syntax error when I run it from the bash script above. + +``` +SyntaxError: invalid syntax + File "<fstring>", line 1 + (pid=) + ^ +``` + +I think this syntax error is caused by the line `print(f'{event.name} {delta_ns / 1000:0.3f} {pid=} ' + ' '.join(fields))` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2048 b/results/classifier/mode-gemma3:12b/user/2048 new file mode 100644 index 00000000..541a4e4f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2048 @@ -0,0 +1,3 @@ + + +Host: Wayland sdl display problem diff --git a/results/classifier/mode-gemma3:12b/user/205 b/results/classifier/mode-gemma3:12b/user/205 new file mode 100644 index 00000000..a4ebfa33 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/205 @@ -0,0 +1,3 @@ + + +Arrow keys press is double in some programs in Dos diff --git a/results/classifier/mode-gemma3:12b/user/206818 b/results/classifier/mode-gemma3:12b/user/206818 new file mode 100644 index 00000000..bb503fa4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/206818 @@ -0,0 +1,45 @@ + + +qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() + +Binary package hint: qemulator + +Hy + +I simply opened qemulator and than qemulator crashed said the bug report utility +but qemulator was open and work . + +i dont know were the error is but i will report it anyway . + +I use: + Ubuntu hardy (development branch) +Release: 8.04 + +qemulator version 0.5-3 + +regards peter + +ProblemType: Crash +Architecture: i386 +Date: Tue Mar 25 22:27:24 2008 +DistroRelease: Ubuntu 8.04 +ExecutablePath: /usr/share/qemulator/qemulator.py +InterpreterPath: /usr/bin/python2.5 +NonfreeKernelModules: nvidia +Package: qemulator 0.5-3 +PackageArchitecture: all +ProcCmdline: python /usr/bin/qemulator +ProcEnviron: + PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games + LANG=en_US.UTF-8 + SHELL=/bin/bash +PythonArgs: ['/usr/bin/qemulator'] +SourcePackage: qemulator +Title: qemulator.py crashed with IndexError in on_comboboxMachinetype_changed() +Traceback: + Traceback (most recent call last): + File "/usr/share/qemulator/qml_machinesetup.py", line 661, in on_comboboxMachinetype_changed + row = model[active] + IndexError: could not find tree path +Uname: Linux 2.6.24-12-386 i686 +UserGroups: adm admin audio cdrom dialout dip fax floppy lpadmin netdev plugdev powerdev sambashare scanner tape video
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/2072564 b/results/classifier/mode-gemma3:12b/user/2072564 new file mode 100644 index 00000000..cd1cf990 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2072564 @@ -0,0 +1,47 @@ + + +qemu-aarch64-static segfaults running ldconfig.real (amd64 host) + +This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host. + +When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example: + +$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 +root@8861ff640a1c:/# /sbin/ldconfig.real +Segmentation fault + +If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static: + +$ gdb --args qemu-aarch64-static ./ldconfig.real +GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git +Copyright (C) 2024 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-aarch64-static... +Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo... +(gdb) r +Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +[New Thread 0x7ffff76006c0 (LWP 28378)] + +Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault. +0x00007fffe801645b in ?? () +(gdb) disassemble +No function contains program counter for selected frame. + +It looks like this is a known qemu regression after v8.1.1: +https://gitlab.com/qemu-project/qemu/-/issues/1913 + +Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/2078 b/results/classifier/mode-gemma3:12b/user/2078 new file mode 100644 index 00000000..38b38223 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2078 @@ -0,0 +1,36 @@ + + +Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target +Description of problem: +I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests. Certain arithmetic operation that will trap in the guest will crash Qemu. First case encountered is below. +Steps to reproduce: +1. Compile and run the following program in the m68k guest: + +``` +virt68k:thorpej 3$ cat crash-qemu.c +#include <limits.h> +#include <stdlib.h> + +int divisor = -1; + +int +main(int argc, char *argv[]) +{ + + if (argc > 1) + divisor = atoi(argv[1]); + + return INT_MIN / divisor; +} +virt68k:thorpej 4$ +``` + +Another minimal case would be: + +``` +move.l #-2147483648,%d0 +move.l #-1,%d1 +divsl.l %d1,%d1:%d0 +``` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2082 b/results/classifier/mode-gemma3:12b/user/2082 new file mode 100644 index 00000000..6a3893db --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2082 @@ -0,0 +1,46 @@ + + +"Unable to find a guest_base to satisfy all guest address mapping requirements" running certain x86_64 binaries on aarch64 host +Description of problem: +Copying from: + + https://bugzilla.redhat.com/show_bug.cgi?id=2256916 + +With ``qemu-x86_64-static`` from ``qemu-8.1.3-1.fc39``, I can no longer run on the m1 the ``x86_64`` binary created by https://github.com/containers/PodmanHello + +If I try with ``qemu-x86_64-static`` from ``qemu-7.2.7-1.fc38`` then this works. + +If I build the binary manually on a fc39 x86 system with ``gcc -O2 -static -o podman_hello_world podman_hello_world.c``, then I can also run it successfully with ``qemu-8.1.3-1.fc39``. +It's only the static binary built inside the alpine container which cannot be run on the M1. + + +Misc tests I ran: + +``` +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.alpine +qemu-x86_64-static-8.1.3: /var/roothome/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef + +$ ./qemu-x86_64-static-7.2.7 podman_hello_world.alpine +!... Hello Podman World ...! +[...] + +$ ./qemu-x86_64-static-8.1.3 podman_hello_world.fc39 +!... Hello Podman World ...! +[...] +``` + +The issue is still present with ``qemu-8.2.0-0.3.rc2.fc40`` + +I also could not reproduce on ``x86_64`` machines. I just tried it on fc39 installed on non-Apple ``aarch64`` hardware, and I'm seeing the same issue: + +``` +# rpm -qf /usr/bin/qemu-x86_64-static +qemu-user-static-x86-8.1.3-1.fc39.aarch64 + +# qemu-x86_64-static ./podman_hello_world.alpine +qemu-x86_64-static: /root/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements + 0000000000000000-0000000000000fff + 0000000000400000-00000000004047ef +``` diff --git a/results/classifier/mode-gemma3:12b/user/2083 b/results/classifier/mode-gemma3:12b/user/2083 new file mode 100644 index 00000000..9fe21e20 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2083 @@ -0,0 +1,113 @@ + + +AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result +Description of problem: +The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer: + +``` +import numpy as np +vl = 128 +esize = 32 +dim = vl // esize + +A = range(16) +B = range(16, 32) +C = np.zeros((4, 4,), dtype=np.int32) + +for row in range(dim): + for col in range(dim): + for k in range(4): + C[row, col] += A[4*row + k] * B[4*col + k] + +print(C) + +[[ 110 134 158 182] + [ 390 478 566 654] + [ 670 822 974 1126] + [ 950 1166 1382 1598]] +``` + +main.c +``` +#include <stdio.h> +#include <stdint.h> + +void foo(int *dst); + +int main() { + int32_t dst[16]; + foo(dst); + + // This should print: + // >>> 110 134 158 182 + // >>> 390 478 566 654 + // >>> 670 822 974 1126 + // >>> 950 1166 1382 1598 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%d ", dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S + +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.b + index z0.b, #0, #1 + mov z1.d, z0.d + add z1.b, z1.b, #16 + + zero {za} + smopa za0.s, p0/m, p0/m, z0.b, z1.b + + // Read the first 4x4 sub-matrix of elements from tile 0: + mov w12, #0 + mova z0.s, p0/m, za0h.s[w12, #0] + mova z1.s, p0/m, za0h.s[w12, #1] + mova z2.s, p0/m, za0h.s[w12, #2] + mova z3.s, p0/m, za0h.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme main.c foo.S +$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out +>>> 110 478 158 654 +>>> 0 0 0 0 +>>> 670 1166 974 1598 +>>> 0 0 0 0 +``` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2089 b/results/classifier/mode-gemma3:12b/user/2089 new file mode 100644 index 00000000..fac9e1d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2089 @@ -0,0 +1,29 @@ + + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/mode-gemma3:12b/user/2101 b/results/classifier/mode-gemma3:12b/user/2101 new file mode 100644 index 00000000..c560b971 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2101 @@ -0,0 +1,19 @@ + + +[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/mode-gemma3:12b/user/2112 b/results/classifier/mode-gemma3:12b/user/2112 new file mode 100644 index 00000000..3ad23d42 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2112 @@ -0,0 +1,28 @@ + + +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/mode-gemma3:12b/user/2122 b/results/classifier/mode-gemma3:12b/user/2122 new file mode 100644 index 00000000..2aab80b5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2122 @@ -0,0 +1,9 @@ + + +qemu-user-static segfault running ldconfig on host x86_64 with client arm64 +Description of problem: +qemu segfault +Steps to reproduce: +1. download ubuntu jammy arm64 rootfs (I assume any will do) +2. mount it (with /proc from host so apt is happy) +3. execute an apt uninstall that triggers libc-bin processing diff --git a/results/classifier/mode-gemma3:12b/user/2123 b/results/classifier/mode-gemma3:12b/user/2123 new file mode 100644 index 00000000..03ada55f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2123 @@ -0,0 +1,33 @@ + + +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/mode-gemma3:12b/user/2136 b/results/classifier/mode-gemma3:12b/user/2136 new file mode 100644 index 00000000..965448ae --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2136 @@ -0,0 +1,37 @@ + + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/mode-gemma3:12b/user/2138 b/results/classifier/mode-gemma3:12b/user/2138 new file mode 100644 index 00000000..666d617e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2138 @@ -0,0 +1,24 @@ + + +Build failure on macOS when using --disable-cocoa +Description of problem: +Build fails: + +``` +../qemu-8.2.1/meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Steps to reproduce: +1. On macOS run `./configure --disable-cocoa` + +Result: + +``` +Compiler for language objc skipped: feature cocoa disabled +``` +``` +../meson.build:3741:13: ERROR: No host machine compiler for 'audio/coreaudio.m' +``` +Additional information: +It seems your build script contains the assumption that an Objective-C compiler is not needed when the Cocoa UI is disabled, but it still appears to be needed to compile the CoreAudio code regardless of UI. + +This was originally reported to MacPorts here: https://trac.macports.org/ticket/67984 diff --git a/results/classifier/mode-gemma3:12b/user/2147 b/results/classifier/mode-gemma3:12b/user/2147 new file mode 100644 index 00000000..1bdb67d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2147 @@ -0,0 +1,11 @@ + + +The Windows version of QEMU runs the semihost project without printing +Description of problem: +In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything. + +I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters. +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2149 b/results/classifier/mode-gemma3:12b/user/2149 new file mode 100644 index 00000000..3a9724e0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2149 @@ -0,0 +1,13 @@ + + +Segfault in libvhost-user and libvduse because of invalid pointer arithmetic with indirect read +Description of problem: +Hello, this is my first experience communicating with open-source community. I have already reported the problem and have submitted patches through qemu-devel mailing list https://mail.gnu.org/archive/html/qemu-devel/2024-01/msg02533.html, as instructed in https://www.qemu.org/docs/master/devel/submitting-a-patch.html, albeit getting no response from any maintainer. I know, that everyone are very busy and are spammed everyday from millions of threads, but I am getting very upset, that such a trivial bug lives in code base for many years and even have been copied to "sister"-library without proper review. So, excuse me, if I am taking this issue too personally. + +The problem - when one tries to use libvhost-user\libvduse and triggers for some reason non-zero-copy mode (like pushing a lot of data) of indirect descriptor reading routine `virtqueue_read_indirect_desc`, any time one got to read more than one descriptor - one would overwrite stack and depending on one's luck getting some weird behaviour, or simple crash moments later, when other code tries to access broken data. + +Steps to reproduce are non-trivial, because depends on one's host and VM (one simply gets random crashes here and there, with core dumps pointing somewhere around given libraries), but anyone who can read C code, can clearly see that pointer arithmetic of `struct vring_desc *desc` is wrong. + +Maybe, I got instructions wrong and posted fixes to wrong mailing list, maybe, nobody cares, so thank you for attention. I'll be glad to hear any advice on how can I help with fixing this simple error, besides what has been done already. + +Thank you. diff --git a/results/classifier/mode-gemma3:12b/user/2156 b/results/classifier/mode-gemma3:12b/user/2156 new file mode 100644 index 00000000..a1ec0838 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2156 @@ -0,0 +1,17 @@ + + +Userland QEMU segfaults when emulating itself thrice +Description of problem: +See title. +``` +$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0} +[1] 15705 segmentation fault (core dumped) qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true +``` +Steps to reproduce: +1. Execute command above +Additional information: +Coredump (~322MB uncompressed) +[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz) + +SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6 diff --git a/results/classifier/mode-gemma3:12b/user/2157 b/results/classifier/mode-gemma3:12b/user/2157 new file mode 100644 index 00000000..88dd658e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2157 @@ -0,0 +1,45 @@ + + +qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB +Description of problem: +`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB +(such as LoongArch, ppc64le, arm64 with 3 level page tables). +Steps to reproduce: +1. Compile x86 binary which makes a single exit(0) syscall: + ``` + cat > exit0.S << EOF + #include <sys/syscall.h> + .text + .global _start + _start: + movl $__NR_exit, %eax + movl $0, %ebx + int $0x80 + EOF + i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S + ``` + Alternatively one might compile it on a x86 host: + ``` + gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S + ``` + and transfer the `exit0` binary to ppc64/LoongArch/arm64 system + + 2. Run the `exit0` binary with `qemu-i386` + ``` + qemu-i386-static ./exit0 + ``` + + # +Additional information: +`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 + LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 + NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 + GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 +``` + +Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) +alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/mode-gemma3:12b/user/2160 b/results/classifier/mode-gemma3:12b/user/2160 new file mode 100644 index 00000000..64d737af --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2160 @@ -0,0 +1,3 @@ + + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-libusb" diff --git a/results/classifier/mode-gemma3:12b/user/2168 b/results/classifier/mode-gemma3:12b/user/2168 new file mode 100644 index 00000000..8a6fc83a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2168 @@ -0,0 +1,34 @@ + + +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/mode-gemma3:12b/user/2170 b/results/classifier/mode-gemma3:12b/user/2170 new file mode 100644 index 00000000..879f4bfe --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2170 @@ -0,0 +1,46 @@ + + +qemu-x86_64 crashes when the application calls pthread_getattr_np() +Description of problem: +QEMU user emulation crashes with this program: +``` +#define _GNU_SOURCE +#include <stdio.h> +#include <pthread.h> + +int main() +{ + pthread_attr_t attr; + int error = pthread_getattr_np(pthread_self(), &attr); + + printf("%d\n", error); + return 0; +} +``` +Steps to reproduce: +1. Compile the program above +2. Run QEMU +Additional information: +QEMU crashes with: +``` +qemu-x86_64: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault (core dumped) + +``` + +In gdb I get this backtrace: +``` +#0 0x0000555555627d6d in open_self_maps_2 (opaque=0x7fffffffc020, guest_start=18446744073699065856, guest_end=<optimized out>, flags=12) at ../linux-user/syscall.c:8089 +#1 0x000055555560ce67 in walk_memory_regions (priv=priv@entry=0x7fffffffc020, fn=fn@entry=0x555555627d30 <open_self_maps_2>) at ../accel/tcg/user-exec.c:176 +#2 0x0000555555628b3a in open_self_maps_1 (smaps=<optimized out>, fd=<optimized out>, env=<optimized out>) at ../linux-user/syscall.c:8112 +#3 open_self_maps (cpu_env=<optimized out>, fd=3) at ../linux-user/syscall.c:8122 +#4 0x0000555555631e24 in do_guest_openat (cpu_env=cpu_env@entry=0x55555583ae20, dirfd=dirfd@entry=-100, fname=fname@entry=0x2aaaab496eb4 "/proc/self/maps", flags=524288, mode=mode@entry=0, safe=safe@entry=true) at ../linux-user/syscall.c:8381 +#5 0x0000555555638f71 in do_syscall1 (cpu_env=cpu_env@entry=0x55555583ae20, num=num@entry=257, arg1=arg1@entry=4294967196, arg2=arg2@entry=46912506523316, arg3=arg3@entry=524288, arg4=arg4@entry=0, arg5=<optimized out>, arg6=<optimized out>, arg8=0, arg7=0) at ../linux-user/syscall.c:9075 +#6 0x000055555563b659 in do_syscall (cpu_env=cpu_env@entry=0x55555583ae20, num=257, arg1=4294967196, arg2=46912506523316, arg3=524288, arg4=0, arg5=8, arg6=1, arg7=0, arg8=0) at ../linux-user/syscall.c:13658 +#7 0x000055555558db19 in cpu_loop (env=env@entry=0x55555583ae20) at ../linux-user/x86_64/../i386/cpu_loop.c:242 +#8 0x00005555555898d8 in main (argc=<optimized out>, argv=0x7fffffffdd38, envp=<optimized out>) at ../linux-user/main.c:1012 + +``` + +This bug was introduced in the rewrite of `open_self_maps` in 7b7a3366e142d3baeb3fd1d3660a50e7956c19eb. +The current master (5767815218efd3cbfd409505ed824d5f356044ae) is still affected. diff --git a/results/classifier/mode-gemma3:12b/user/2175 b/results/classifier/mode-gemma3:12b/user/2175 new file mode 100644 index 00000000..ddceb1e5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2175 @@ -0,0 +1,40 @@ + + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2177 b/results/classifier/mode-gemma3:12b/user/2177 new file mode 100644 index 00000000..789ae49d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2177 @@ -0,0 +1,3 @@ + + +msys2-32bit CI job fails with "error: target not found: mingw-w64-i686-dtc" diff --git a/results/classifier/mode-gemma3:12b/user/2197 b/results/classifier/mode-gemma3:12b/user/2197 new file mode 100644 index 00000000..861b7cea --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2197 @@ -0,0 +1,60 @@ + + +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/mode-gemma3:12b/user/2200 b/results/classifier/mode-gemma3:12b/user/2200 new file mode 100644 index 00000000..221be81c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2200 @@ -0,0 +1,11 @@ + + +QEMU OpenGL of SDL and GTK not working properly on Windows hosts +Description of problem: +QEMU OpenGL of SDL and GTK not working properly on Windows hosts. +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2202 b/results/classifier/mode-gemma3:12b/user/2202 new file mode 100644 index 00000000..1ab30f84 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2202 @@ -0,0 +1,35 @@ + + +Crash in contrib/elf2dmp +Description of problem: +The elf2dmp program crash. +``` +$ ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +Using Linux mmap +[1] 994585 segmentation fault ./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +``` +Steps to reproduce: +1. build the qemu project following standard steps +2. navigate to the `build` directory and run `./contrib/elf2dmp/elf2dmp ./crash_1 /dev/null` + +The [crash_1](/uploads/d0890c0f8873b8264c417b0f98ee83a4/crash_1) file. +Additional information: +Run in GDB. +``` +$ gdb ./contrib/elf2dmp/elf2dmp +... +(gdb) set args ./crash_1 /dev/null +(gdb) r +Starting program: /data/share/qemu_latest/build/contrib/elf2dmp/elf2dmp ./crash_1 /dev/null +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". +Using Linux mmap + +Program received signal SIGSEGV, Segmentation fault. +init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +66 Elf64_Nhdr *start = (void *)((uint8_t *)qe->map + phdr[0].p_offset); +(gdb) bt +#0 init_states (qe=0x7fffffff83f0) at ../contrib/elf2dmp/qemu_elf.c:66 +#1 QEMU_Elf_init (qe=qe@entry=0x7fffffff83f0, filename=<optimized out>) at ../contrib/elf2dmp/qemu_elf.c:235 +#2 0x0000555555555508 in main (argc=<optimized out>, argv=0x7fffffffdb58) at ../contrib/elf2dmp/main.c:538 +``` diff --git a/results/classifier/mode-gemma3:12b/user/2207 b/results/classifier/mode-gemma3:12b/user/2207 new file mode 100644 index 00000000..aaa434f9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2207 @@ -0,0 +1,13 @@ + + +WerFault.exe – Application Error. The memory could not be read in Win7 i386 +Description of problem: +WerFault Application Errors always occur when I open IE or even control panel. It's OK on QEMU 7.2 & 8.0 version according to my debug experience about qemu-system-i386 flavor in the last few months. +Steps to reproduce: +1. pulling _tag: v8.2.0_ code +2. emulating Windows 7 OS on aarch64 Host with TCG acceleration mechanism +3. just opening IE for maybe two or three times after the virtual machine has started +Additional information: +The error is displayed by Chinese. It says _WerFault.exe – Application Error. The instruction at 0x779f77b2 referenced memory at 0x6d0f6d20. The memory could not be read._ in English + + diff --git a/results/classifier/mode-gemma3:12b/user/2223 b/results/classifier/mode-gemma3:12b/user/2223 new file mode 100644 index 00000000..9224f70c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2223 @@ -0,0 +1,37 @@ + + +Weird behavior on RISC-V code running on QEMU +Description of problem: +I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels. + +This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**: + +```c +for(int i=0; i < NUMBER_OF_ITEMS; i++){ + createAndPushItem(i); + + // the function above does the exact same thing as the commented code below + // yet, the commented code does not work and will crash the program. but why?? + + // int index = priorities[i]; + // void *value = (void *) getValue(i + 1); + // LinkedListItem_t *item = createItem(index, value); + // if(item){ + // push(item, &list); + // } +} +``` + +The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success. Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets. +Steps to reproduce: +1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) +2. follow the readme to install the toolchain +3. follow the readme to compile the program and run it +Additional information: +The expected output is supposed to be: + + + +but when one decides to use the commented snippet instead of the function, the program hangs right before sorting the linked list for the first time: + + diff --git a/results/classifier/mode-gemma3:12b/user/2248 b/results/classifier/mode-gemma3:12b/user/2248 new file mode 100644 index 00000000..204c1150 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2248 @@ -0,0 +1,38 @@ + + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/mode-gemma3:12b/user/225 b/results/classifier/mode-gemma3:12b/user/225 new file mode 100644 index 00000000..a4a37b98 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/225 @@ -0,0 +1,3 @@ + + +Menu is not clickable on OSX Catalina diff --git a/results/classifier/mode-gemma3:12b/user/2262 b/results/classifier/mode-gemma3:12b/user/2262 new file mode 100644 index 00000000..9feb4ab4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2262 @@ -0,0 +1,201 @@ + + +linux-user riscv32: wait4/waitpid returns wrong value +Description of problem: +Background job started by bash shell in riscv32 chroot environment under qemu linux-user emulation hangs indefinitely. + +strace shows repeated waitid flood `waitid(P_ALL, -1, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0`. +Steps to reproduce: +1. cross compile a riscv32 environment with crossdev on gentoo or other way and chroot into it. +2. run `sleep 1000 &` +3. run `ls` +4. infinite hangs + +I have a small reproducer that I think may uncover the issue, but I am not 100% sure. I also tried running qemu with sanitizers enabled, but it produces no warning. Happy to provide a tar bar of my riscv32 rootfs if needed. + +<details><summary>simple_shell.c</summary> + +``` +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <string.h> +#include <sys/wait.h> +#include <signal.h> + +#define MAX_LINE 80 /* The maximum length command */ + +#define BACKGROUND 0 +#define FOREGROUND 1 + +struct Job { + pid_t pid; + char command[MAX_LINE]; + int state; // 0 for background, 1 for foreground +}; + +struct Job jobs[10]; // Maximum 10 background jobs +int num_jobs = 0; + +void handle_signal(int signum) { + // Do nothing for now +} + +int launch_process(char **args, int state) { + pid_t pid; + int status; + + pid = fork(); + if (pid == 0) { + // Child process + if (execvp(args[0], args) == -1) { + perror("Error in execvp"); + exit(EXIT_FAILURE); + } + } else if (pid < 0) { + // Error forking + perror("Error forking"); + } else { + // Parent process + if (state == FOREGROUND) { + // Wait for the child process to finish if it's foreground + do { + wait4(pid, &status, WUNTRACED, NULL); + } while (!WIFEXITED(status) && !WIFSIGNALED(status)); + } else { + // Background process, add to jobs list + jobs[num_jobs].pid = pid; + strcpy(jobs[num_jobs].command, args[0]); + jobs[num_jobs].state = BACKGROUND; + num_jobs++; + } + } + return 1; +} + +void bg_command(int job_number) { + // Send SIGCONT signal to a background job + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = BACKGROUND; + } +} + +void fg_command(int job_number) { + // Bring a background job to foreground + if (kill(jobs[job_number].pid, SIGCONT) == -1) { + perror("kill"); + } else { + jobs[job_number].state = FOREGROUND; + int status; + wait4(jobs[job_number].pid, &status, WUNTRACED, NULL); + } +} + +int main(void) { + char *args[MAX_LINE/2 + 1]; /* command line arguments */ + int should_run = 1; /* flag to determine when to exit program */ + char command[MAX_LINE]; /* buffer to hold the command */ + char *token; /* token for parsing the command */ + + signal(SIGINT, handle_signal); /* Ignore SIGINT for now */ + signal(SIGTSTP, handle_signal); /* Ignore SIGTSTP for now */ + + while (should_run) { + printf("Shell> "); + fflush(stdout); + fgets(command, MAX_LINE, stdin); /* read command from stdin */ + command[strcspn(command, "\n")] = '\0'; /* remove newline character */ + + if (strcmp(command, "exit") == 0) { + should_run = 0; /* exit the shell */ + continue; + } + + if (strcmp(command, "") == 0) { + continue; /* skip empty commands */ + } + + if (strcmp(command, "cd") == 0) { + char *home = getenv("HOME"); + chdir(home); + continue; + } + + if (strcmp(command, "bg") == 0) { + // Run the most recent background job in the background + bg_command(num_jobs - 1); + continue; + } + + if (strcmp(command, "fg") == 0) { + // Bring the most recent background job to foreground + fg_command(num_jobs - 1); + continue; + } + + token = strtok(command, " "); + int i = 0; + while (token != NULL) { + args[i] = token; + token = strtok(NULL, " "); + i++; + } + args[i] = NULL; + + if (strcmp(args[i-1], "&") == 0) { + args[i-1] = NULL; + launch_process(args, BACKGROUND); + } else { + launch_process(args, FOREGROUND); + } + + pid_t tmp; + // Check if any background jobs have finished + for (int j = 0; j < num_jobs; j++) { + if ((tmp = wait4(jobs[j].pid, NULL, WNOHANG, NULL)) > 0) { + printf("[%d] Done\t%s\n", j, jobs[j].command); + // Remove job from list + for (int k = j; k < num_jobs - 1; k++) { + jobs[k] = jobs[k + 1]; + } + num_jobs--; + } + printf("wait4 ret: %d\n", tmp); + } + } + return 0; +} +``` + +</details> + +<details><summary>loop.c</summary> +int main() {while(1){}} +</details> + +1. compile simple_shell.c, statically for simplicity. `riscv32-unknown-gnu-gcc simple_shell.c --static -o shell_riscv32` +2. compile loop.c to riscv32 or x86_64 (x86_64 is simpler with same result) `gcc loop.c --static -o loop` +3. run shell with qemu user +``` +qemu-user-riscv32 ./shell_riscv32 +shell> ./loop & +[0] Done ./sleep_riscv32 +wait4 ret: 98298 +``` +where it is supposed to return 0 on riscv64 or x86 +Additional information: +More context: +This was found on the side when I was trying to track down a riscv32 infinite loop issue with linux-user emulation that has been blocking riscv32 gentoo bootstrap. I am not certain if my reproducer does reproduced that issue, but feels it is close. strace attached to the process repeats, +``` +waitid(P_ALL, -1, {}, WNOHANG|WEXITED, NULL) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0 +rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0 +waitid(P_ALL, -1, ^Cstrace: Process 237805 detached +``` +It appears to be first mentioned here <https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg05475.html>. diff --git a/results/classifier/mode-gemma3:12b/user/2266 b/results/classifier/mode-gemma3:12b/user/2266 new file mode 100644 index 00000000..85b6ed00 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2266 @@ -0,0 +1,71 @@ + + +qemu-system-x86_64: stuck on watchpoint hit +Description of problem: + +Steps to reproduce: +1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +``` +Additional information: +* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; + l1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +``` diff --git a/results/classifier/mode-gemma3:12b/user/2290 b/results/classifier/mode-gemma3:12b/user/2290 new file mode 100644 index 00000000..ec1e296c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2290 @@ -0,0 +1,145 @@ + + +Wrong multiplication result of 'long double' on m68k +Description of problem: +In both x86 and m68k, 'long double' is an 80-bit format consisting of + - 1 bit sign, 15 bits exponent, + - 1 explicit 1 bit, 63 fraction bits. + +According to <https://en.wikipedia.org/wiki/Extended_precision> and +<https://www.nxp.com/docs/en/reference-manual/M68000PRM.pdf> table 1-6 (page 1-23), with two differences: + - In m68k, there are 16 zero bits as filler after the sign/exponent + word, so that the total size is 96 bits. + - In x86, the minimum exponent of normalized numbers is 1; + in m68k, the minimum exponent of normalized numbers is 0. + +The latter difference is reflected in the values of LDBL_MIN_EXP and +LDBL_MIN in gcc: + +In x86: +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16381) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 3.36210314311209350626267781732175260e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +In m68k (I use Debian 12/Linux): +``` +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN_EXP_ +#define LDBL_MIN_EXP __LDBL_MIN_EXP__ +#define __LDBL_MIN_EXP__ (-16382) +$ echo '#include <float.h>' | gcc -E -dM - | grep __LDBL_MIN__ +#define __LDBL_MIN__ 1.68105157155604675313e-4932L +#define LDBL_MIN __LDBL_MIN__ +``` +Steps to reproduce: +Take this program, foo.c: +``` +/* Show extended-precision https://en.wikipedia.org/wiki/Extended_precision + multiplication bug in QEMU. */ + +#include <stdio.h> + +static void +show (const long double *p) +{ +#ifdef __m68k__ + printf("<S,E: 0x%08X M: 0x%08X%08X>", + ((const unsigned int *) p)[0], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[2]); +#else /* x86 */ + printf("<S,E: 0x%04X M: 0x%08X%08X>", + ((const unsigned short *) p)[4], + ((const unsigned int *) p)[1], + ((const unsigned int *) p)[0]); +#endif + printf (" = %La = %Lg", *p, *p); +} + +static void +show_mult (long double a, long double b) +{ + printf ("Factors: "); + show (&a); + printf ("\n and: "); + show (&b); + long double c = a * b; + printf ("\nProduct: "); + show (&c); + printf ("\n\n"); +} + +/* Return 2^n. */ +static long double +pow2l (int n) +{ + int k = n; + volatile long double x = 1; + volatile long double y = 2; + /* Invariant: 2^n == x * y^k. */ + if (k < 0) + { + y = 0.5L; + k = - k; + } + while (k > 0) + { + if (k != 2 * (k / 2)) + { + x = x * y; + k = k - 1; + } + if (k == 0) + break; + y = y * y; + k = k / 2; + } + /* Now k == 0, hence x == 2^n. */ + return x; +} + +int main () +{ + show_mult (pow2l (-16382), 0.5L); + show_mult (pow2l (-16381), 0.25L); + return 0; +} +``` +Its output on x86: +``` +$ ./a.out +Factors: <S,E: 0x0001 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 + +Factors: <S,E: 0x0002 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x0000 M: 0x4000000000000000> = 0x4p-16385 = 1.68105e-4932 +``` +Its output on m68k: +``` +$ ./a.out +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x4000000000000000> = 0x4p-16386 = 8.40526e-4933 +``` +The product, computed by QEMU, is incorrect. It is only half as large as the +correct value. The expected output should be: +``` +Factors: <S,E: 0x00010000 M: 0x8000000000000000> = 0x8p-16385 = 3.3621e-4932 + and: <S,E: 0x3FFE0000 M: 0x8000000000000000> = 0x8p-4 = 0.5 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 + +Factors: <S,E: 0x00020000 M: 0x8000000000000000> = 0x8p-16384 = 6.72421e-4932 + and: <S,E: 0x3FFD0000 M: 0x8000000000000000> = 0x8p-5 = 0.25 +Product: <S,E: 0x00000000 M: 0x8000000000000000> = 0x8p-16386 = 1.68105e-4932 +``` +Additional information: +In QEMU's source code, I would guess that this multiplication is performed by the `floatx80_mul` function. diff --git a/results/classifier/mode-gemma3:12b/user/2302 b/results/classifier/mode-gemma3:12b/user/2302 new file mode 100644 index 00000000..566272d4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2302 @@ -0,0 +1,27 @@ + + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/mode-gemma3:12b/user/2309 b/results/classifier/mode-gemma3:12b/user/2309 new file mode 100644 index 00000000..c6a9a323 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2309 @@ -0,0 +1,33 @@ + + +qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6 +Description of problem: +qemu-aarch64 seems to hang with 100% cpu usage without any indication. +with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c. +Steps to reproduce: +1. Ensure the test env has 2.36-9+deb12u6 +2. Install the latest rust toolchain. +3. mkdir test_test && cargo init +4. ensure src/main.rs has +``` +fn main() { + println!("Hello, world!"); +} + +#[test] +fn test() { + println!("hAAA!"); +} +``` +5. create .cargo/config.toml +``` +[target.aarch64-unknown-linux-gnu] +linker = "aarch64-linux-gnu-gcc" +runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu" +rustflags = ["-C", "target-cpu=neoverse-n1"] +``` +6. cargo test --target aarch64-unknown-linux-gnu +Additional information: +The issue does not seem to occur with libc6:2.36-9+deb12u4 + +The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6. diff --git a/results/classifier/mode-gemma3:12b/user/2317 b/results/classifier/mode-gemma3:12b/user/2317 new file mode 100644 index 00000000..0cc743d8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2317 @@ -0,0 +1,40 @@ + + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/mode-gemma3:12b/user/2318 b/results/classifier/mode-gemma3:12b/user/2318 new file mode 100644 index 00000000..640b7f54 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2318 @@ -0,0 +1,36 @@ + + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/mode-gemma3:12b/user/2323 b/results/classifier/mode-gemma3:12b/user/2323 new file mode 100644 index 00000000..a0a69278 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2323 @@ -0,0 +1,28 @@ + + +Win/Super key not working correctly under Windows hosts +Description of problem: +I accidentally noticed `Win` key (VK_LWIN) not working correctly on Windows hosts, more specifically: + +1. It is impossible to "hold" `Win`. If one presses and holds `Win`, the guest is spammed with `Win` keypresses, instead of receiving a single `Win` keypress at the point of releasing the button (VK_LWIN button up). +2. It is impossible to make key combinations (shortcuts, hotkeys etc.) that involve the `Win/Super` key. Maybe implicitly solved by fixing #1. + +This behavior is present starting from bc8e883065f36581e4f2352c31a1dfa5f65a82f2 (ui/sdl2: disable SDL_HINT_GRAB_KEYBOARD on Windows). Before it, on the SDL2 keyboard hook `Win/Super` key worked correctly. I demonstrate the problem on Fedora/WinXP, but it affects all guests. +Steps to reproduce: +1. (see additional information) +2. +3. +Additional information: +Short video demonstration on a WinXP guest and a Fedora 39 guest. The qemus used are (qemu-8.0.2 e0968d21e27ef9c406f709180a39a076e786efbe; working correctly) and (qemu-9.0.0 from the release tarball qemu-9.0.0.tar.xz; buggy) + +1. In the WinXP video, I'm pressing and holding the `Win` key for about 3 seconds. In the correct version, the start menu is opened only at the point of release. In the buggy version, the start menu is opened repeatedly tens of times (flickering). You can see the point of release in Nirsoft's KeyboardStateView, when VK_LWIN loses the "pressed" asterisk. + + At the end of the video I'm trying to use the `Win+e` shortcut for WinExplorer. In the buggy version, Outlook is opened instead. This is because the keypresses are processed individually, first `Win` opens the start menu and then `e` opens email application (in this case outlook). In the correct version WinExplorer is opened. + +  +  + +2. In the Fedora video, I'm trying to set up a simple shortcut, I'm pressing on my keyboard `LCTRL+LALT+Super+E`. In the buggy version, the `Super` key is not picked up. All the shortcut combinations involving `Super` are therefore not working. + +  +  diff --git a/results/classifier/mode-gemma3:12b/user/2333 b/results/classifier/mode-gemma3:12b/user/2333 new file mode 100644 index 00000000..4fef1141 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2333 @@ -0,0 +1,47 @@ + + +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/mode-gemma3:12b/user/2340 b/results/classifier/mode-gemma3:12b/user/2340 new file mode 100644 index 00000000..5161d866 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2340 @@ -0,0 +1,35 @@ + + +SPARC fp operation INVALID trap hangs on offending instruction. +Description of problem: +An IEEE Invalid Operation exception is typically not enabled in programs - but if it is and an Invalid Operation occurs, a hardware TRAP should be generated which eventually becomes a SIGFPE. However, instead, the program seems to hang on the offending instruction, never moving forward. + +This small C example (you'll need a C compiler) demonstrates the problem, by enabling the INValid floating-pt exception, then executing the FDTOI instruction which causes an INValid trap because the floating-pt source operand is too large for the 32-bit integer result . The SPARC V9 manual specifies that exception should happen, so it's correct to generate the trap. However, the program simply hangs on the FDTOI instruction instead of receiving the signal. + +It could be something in trap emulation that is the underlying culprit here - other possible IEEE traps (such as division-by-zero) might similarly fail? + +`#include <ieeefp.h>` + +`main()` + +`{` + + `double val;` + + `int i;` + + `fpsetmask(FP_X_INV);` + + `val = 1000000000000003.0; /* Number that is too large for int */` + + `printf("val is %f\n", val);` + + `i = val;` + + `printf("i is %d\n", i);` + +`}` +Steps to reproduce: +1. Enable IEEE iNValid operation traps in the TEM in the FSR. +2. Generate an instruction that causes an iNValid trap +3. Instruction hangs, no SIGFPE is generated diff --git a/results/classifier/mode-gemma3:12b/user/2353 b/results/classifier/mode-gemma3:12b/user/2353 new file mode 100644 index 00000000..888469b4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2353 @@ -0,0 +1,58 @@ + + +linux-user: may map interpreter at address 0 with nonzero guest_base +Description of problem: +QEMU's user-mode emulation will, under certain conditions, map the ELF interpreter at guest address 0. This is not only a violation of Linux's policy never to map anything at the first page of any virtual address space, but also a cause of confusion (and segfaults) within certain libcs; though I only tested with musl. Musl [interprets a NULL base address](https://elixir.bootlin.com/musl/v1.2.4/source/ldso/dlstart.c#L105) as the dynamic linker being invoked directly, causing it to compute its base address incorrectly. + +The problem arises in `load_elf_image()`, which chooses a `load_addr` of 0 for the ELF interpreter (i.e. the musl dynamic loader). This is passed to `target_mmap()`. I do not know whether `target_mmap()` is meant to follow the POSIX rule that (in absence of `MAP_FIXED`) "All implementations interpret an *addr* value of 0 as granting the implementation complete freedom in selecting *pa*" or if 0 is requesting 0. + +QEMU's usermode mmap() implementation translates the guest address to a host address (this is effectively a no-op with `guest_base == 0`) and passes it along to the host Linux. This means that, when `guest_base == 0`, a NULL input address means "put it anywhere," but when `guest_base != 0`, NULL means "put it at (guest address) 0." +Steps to reproduce: +1. Download a rootfs of Alpine Linux AArch64. +2. Install `gcc` (with `apk add gcc`) in the rootfs. `gcc` is not compiled as PIC, making QEMU use a nonzero `guest_base`. +3. Attempt to run `gcc` within the rootfs via QEMU. +Additional information: +I am interested in submitting a MR that fixes this issue, but I do not know which of 4 possible solutions is preferred: + +1. Modify `load_elf_image()` to ensure that `load_addr` is never NULL. +2. Modify `target_mmap()` so that NULLs are passed to the kernel as NULLs. +3. Modify the guest<->host translation facilities (`g2h_untagged` et al) to translate NULL as NULL. Overwhelmingly, a NULL pointer semantically means "there is no pointer here" and not "a pointer to the zeroth address," so treating these as valid addresses in the translation functions is arguably going against the grain. +4. When a nonzero `guest_base` is selected, reserve the first page of the guest VA space, so that the host kernel cannot accidentally put anything there. + +Here is my local patch that implements item 2 above, which indeed stops the segfaults for me: +<details><summary>Patch</summary> + +```diff +diff --git a/linux-user/mmap.c b/linux-user/mmap.c +index be3b9a6..dad29ef 100644 +--- a/linux-user/mmap.c ++++ b/linux-user/mmap.c +@@ -559,7 +559,7 @@ static abi_long mmap_h_eq_g(abi_ulong start, abi_ulong len, + int host_prot, int flags, int page_flags, + int fd, off_t offset) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + abi_ulong last; + + p = mmap(want_p, len, host_prot, flags, fd, offset); +@@ -609,7 +609,7 @@ static abi_long mmap_h_lt_g(abi_ulong start, abi_ulong len, int host_prot, + int mmap_flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t fileend_adj = 0; + int flags = mmap_flags; + abi_ulong last, pass_last; +@@ -739,7 +739,7 @@ static abi_long mmap_h_gt_g(abi_ulong start, abi_ulong len, + int flags, int page_flags, int fd, + off_t offset, int host_page_size) + { +- void *p, *want_p = g2h_untagged(start); ++ void *p, *want_p = start ? g2h_untagged(start) : 0; + off_t host_offset = offset & -host_page_size; + abi_ulong last, real_start, real_last; + bool misaligned_offset = false; +``` +</details> diff --git a/results/classifier/mode-gemma3:12b/user/2371 b/results/classifier/mode-gemma3:12b/user/2371 new file mode 100644 index 00000000..c14718b5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2371 @@ -0,0 +1,54 @@ + + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2372 b/results/classifier/mode-gemma3:12b/user/2372 new file mode 100644 index 00000000..8d9eb5ad --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2372 @@ -0,0 +1,111 @@ + + +A bug in AArch64 UMOPA/UMOPS (4-way) instruction +Description of problem: +umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. + +However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: +``` +// target/arm/tcg/sme_helper.c +#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ +static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ +{ \ + uint64_t sum = 0; \ + /* Apply P to N as a mask, making the inactive elements 0. */ \ + n &= expand_pred_h(p); \ + sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ + sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ + sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ + sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ + return neg ? a - sum : a + sum; \ +} + +DEF_IMOP_64(umopa_d, uint16_t, uint16_t) +``` +When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z20[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA2H[128] = { 0x0, }; +char o_ZA2H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA2H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P1\n" + "add x29, x29, :lo12:i_P1\n" + "ldr p1, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z20\n" + "add x29, x29, :lo12:i_Z20\n" + "ldr z20, [x29]\n" + "adrp x29, i_ZA2H\n" + "add x29, x29, :lo12:i_ZA2H\n" + "mov x15, 0\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h + "adrp x29, o_ZA2H\n" + "add x29, x29, :lo12:o_ZA2H\n" + "mov x15, 0\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "smstop\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2373 b/results/classifier/mode-gemma3:12b/user/2373 new file mode 100644 index 00000000..b633b2ca --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2373 @@ -0,0 +1,97 @@ + + +A bug in AArch64 FMOPA/FMOPS (widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used. + +However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P2[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z16[32] = { // Set only the first element as non-zero + 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA3H[128] = { 0x0, }; +uint64_t i_fpcr = 0x0001000000; // FZ = 1; +char o_ZA3H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA3H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P2\n" + "add x29, x29, :lo12:i_P2\n" + "ldr p2, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z16\n" + "add x29, x29, :lo12:i_Z16\n" + "ldr z16, [x29]\n" + "adrp x29, i_ZA3H\n" + "add x29, x29, :lo12:i_ZA3H\n" + "mov x15, 0\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x81a0aa03\n" // fmopa za3.s, p2/m, p5/m, z16.h, z0.h + "adrp x29, o_ZA3H\n" + "add x29, x29, :lo12:o_ZA3H\n" + "mov x15, 0\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2374 b/results/classifier/mode-gemma3:12b/user/2374 new file mode 100644 index 00000000..aa192dea --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2374 @@ -0,0 +1,113 @@ + + +A bug in AArch64 FMOPA/FMOPS (non-widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. + +However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: +``` +// target/arm/tcg/sme_helper.c +void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, + void *vpm, void *vst, uint32_t desc) +{ +... + float_status fpst; + + /* + * Make a copy of float_status because this operation does not + * update the cumulative fp exception status. It also produces + * default nans. + */ + fpst = *(float_status *)vst; + set_default_nan_mode(true, &fpst); + +... + *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used +... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. + 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z27[32] = { + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA1H[128] = { 0x0, }; +char o_ZA1H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA1H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P0\n" + "add x29, x29, :lo12:i_P0\n" + "ldr p0, [x29]\n" + "adrp x29, i_P6\n" + "add x29, x29, :lo12:i_P6\n" + "ldr p6, [x29]\n" + "adrp x29, i_Z9\n" + "add x29, x29, :lo12:i_Z9\n" + "ldr z9, [x29]\n" + "adrp x29, i_Z27\n" + "add x29, x29, :lo12:i_Z27\n" + "ldr z27, [x29]\n" + "adrp x29, i_ZA1H\n" + "add x29, x29, :lo12:i_ZA1H\n" + "mov x15, 0\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s + "adrp x29, o_ZA1H\n" + "add x29, x29, :lo12:o_ZA1H\n" + "mov x15, 0\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2375 b/results/classifier/mode-gemma3:12b/user/2375 new file mode 100644 index 00000000..c36ae65a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2375 @@ -0,0 +1,87 @@ + + +A bug in AArch64 FJCVTZS instruction +Description of problem: +fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero. + +However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value: +``` +// target/arm/vfp_helper.c +uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus) +{ + float_status *status = vstatus; + uint32_t inexact, frac; + uint32_t e_old, e_new; + + e_old = get_float_exception_flags(status); + set_float_exception_flags(0, status); + frac = float64_to_int32_modulo(value, float_round_to_zero, status); + e_new = get_float_exception_flags(status); + set_float_exception_flags(e_old | e_new, status); + + if (value == float64_chs(float64_zero)) { + /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */ + inexact = 1; + } else { + /* Normal inexact or overflow or NaN */ + inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked. + } + + /* Pack the result and the env->ZF representation of Z together. */ + return deposit64(frac, 32, 32, inexact); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint64_t i_fpcr = 0x01000000; // FZ = 1; +char o_X28[8]; +uint64_t o_nzcv; + +void __attribute__ ((noinline)) show_state() { + char Z = ((o_nzcv >> 30) & 1); + + printf("PSTATE.Z: %d\n", Z); + printf("X28: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_X28[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "adrp x29, i_D27\n" + "add x29, x29, :lo12:i_D27\n" + "ldr d27, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x1e7e037c\n" // fjcvtzs w28, d27 + "mrs x26, nzcv\n" + "adrp x29, o_nzcv\n" + "add x29, x29, :lo12:o_nzcv\n" + "str x26, [x29]\n" + "adrp x29, o_X28\n" + "add x29, x29, :lo12:o_X28\n" + "str x28, [x29]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2376 b/results/classifier/mode-gemma3:12b/user/2376 new file mode 100644 index 00000000..11d3a9f4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2376 @@ -0,0 +1,116 @@ + + +A bug in ARM VCMLA.f16/VCMLA.f32 instructions +Description of problem: +The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. + +The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: +``` +// target/arm/tcg/vec_helper.c +void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float16 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float16); + intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; + intptr_t i, j; + + ... +} + +... + +void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float32 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float32); + intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; + intptr_t i, j; + + ... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +// zero inputs should produce zero output +char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched +char o_D30[8]; +char o_D31[8]; + +void __attribute__ ((noinline)) show_state() { + printf("D30: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D30[i]); + } + printf("\n"); + printf("D31: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D31[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "movw r7, #:lower16:i_D4\n" + "movt r7, #:upper16:i_D4\n" + "vldr d4, [r7]\n" + "movw r7, #:lower16:i_D8\n" + "movt r7, #:upper16:i_D8\n" + "vldr d8, [r7]\n" + "movw r7, #:lower16:i_D30\n" + "movt r7, #:upper16:i_D30\n" + "vldr d30, [r7]\n" + "movw r7, #:lower16:i_D31\n" + "movt r7, #:upper16:i_D31\n" + "vldr d31, [r7]\n" + "adr r7, Lbl_thumb + 1\n" + "bx r7\n" + ".thumb\n" + "Lbl_thumb:\n" + ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 + "adr r7, Lbl_arm\n" + "bx r7\n" + ".arm\n" + "Lbl_arm:\n" + "movw r7, #:lower16:o_D30\n" + "movt r7, #:upper16:o_D30\n" + "vstr d30, [r7]\n" + "movw r7, #:lower16:o_D31\n" + "movt r7, #:upper16:o_D31\n" + "vstr d31, [r7]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/238 b/results/classifier/mode-gemma3:12b/user/238 new file mode 100644 index 00000000..f433a355 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/238 @@ -0,0 +1,3 @@ + + +capstone link failure building linux-user static diff --git a/results/classifier/mode-gemma3:12b/user/2385 b/results/classifier/mode-gemma3:12b/user/2385 new file mode 100644 index 00000000..47719f04 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2385 @@ -0,0 +1,109 @@ + + +sparc: SIGILL stepping over `std` in gdb +Description of problem: +Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not. + +My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix. + +This problem was experienced while testing some shell-spawning assembly: +``` +-bash-4.3$ cat test.s +.section ".text" +.global main +main: + sethi %hi(0x2f626800), %l6 + or %l6, 0x16e, %l6 ! 0x2f62696e + sethi %hi(0x2f6b7000), %l7 + or %l7, 0x368, %l7 ! 0x2f6b7368 + and %sp, %sp, %o0 + add %sp, 0xc, %o1 + xor %o2, %o2, %o2 + add %sp, 0x14, %sp + std %l6, [ %sp + -20 ] + clr [ %sp + -12 ] + st %sp, [ %sp + -8 ] + clr [ %sp + -4 ] + mov 0x3b, %g1 + ta 8 + xor %o7, %o7, %o0 + mov 1, %g1 + ta 8 +``` + +``` +-bash-4.3$ gcc test.s -o test +-bash-4.3$ ./test +$ echo HELLO +HELLO +$ exit +``` + +As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs +``` +-bash-4.3$ gdb test +GNU gdb (GDB) 7.4.1 +[...] +(gdb) disas main +Dump of assembler code for function main: + 0x0001061c <+0>: sethi %hi(0x2f626800), %l6 + 0x00010620 <+4>: or %l6, 0x16e, %l6 ! 0x2f62696e + 0x00010624 <+8>: sethi %hi(0x2f6b7000), %l7 + 0x00010628 <+12>: or %l7, 0x368, %l7 ! 0x2f6b7368 + 0x0001062c <+16>: and %sp, %sp, %o0 + 0x00010630 <+20>: add %sp, 0xc, %o1 + 0x00010634 <+24>: xor %o2, %o2, %o2 + 0x00010638 <+28>: add %sp, 0x14, %sp + 0x0001063c <+32>: std %l6, [ %sp + -20 ] + 0x00010640 <+36>: clr [ %sp + -12 ] + 0x00010644 <+40>: st %sp, [ %sp + -8 ] + 0x00010648 <+44>: clr [ %sp + -4 ] + 0x0001064c <+48>: mov 0x3b, %g1 + 0x00010650 <+52>: ta 8 + 0x00010654 <+56>: xor %o7, %o7, %o0 + 0x00010658 <+60>: mov 1, %g1 + 0x0001065c <+64>: ta 8 +End of assembler dump. +(gdb) b main +Breakpoint 1 at 0x1061c +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) si +0x00010620 in main () +(gdb) +0x00010624 in main () +[...] +Program received signal SIGILL, Illegal instruction. +0x0001063c in main () +``` + +However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve, +but then complains about memory accesses that I've never seen before. +``` +(gdb) r +Starting program: /export/home/bazz/iob/test + +Breakpoint 1, 0x0001061c in main () +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +0xef783af4 in _rt_boot () from /usr/lib/ld.so.1 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +Cannot access memory at address 0x2800007 +Cannot access memory at address 0x2800003 +(gdb) c +Continuing. +$ +``` + +It does eventually get a shell though. + +On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb. diff --git a/results/classifier/mode-gemma3:12b/user/2386 b/results/classifier/mode-gemma3:12b/user/2386 new file mode 100644 index 00000000..a29c8b60 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2386 @@ -0,0 +1,45 @@ + + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2387 b/results/classifier/mode-gemma3:12b/user/2387 new file mode 100644 index 00000000..3b8a975e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2387 @@ -0,0 +1,13 @@ + + +Segmentation fault on booting from ISO when using GTK display with OpenGL enabled +Description of problem: +When trying to boot from the ISO mounted in the `-cdrom` argument, using a GTK display with OpenGL enabled gives a segmentation fault error. If using SDL instead, the whole application kinda freezes most of the times. I managed to get it working once, but I don't know how or why, seemed completely random. After installing it, I can boot from the disk normally with no errors. +Steps to reproduce: +1. Install QEMU for MSYS2 / UCRT64 as described [here](https://www.qemu.org/download/#windows) +2. Download ISO from EndeavourOS website +3. Run `qemu-img create -f qcow2 EndeavourOS.qcow2 64G` to create a disk file +4. Run the script as described above in a `.sh` file +5. See error +Additional information: +I have multiple VMs, included but not limited to Manjaro, Pop!\_OS and Debian, none of them gives this specific error. I also usually avoid SDL because I had multiple issues with the application window completely freezing in the past with "Not responding", and that does not happen with GTK. diff --git a/results/classifier/mode-gemma3:12b/user/2390 b/results/classifier/mode-gemma3:12b/user/2390 new file mode 100644 index 00000000..061776e1 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2390 @@ -0,0 +1,65 @@ + + +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/mode-gemma3:12b/user/2409 b/results/classifier/mode-gemma3:12b/user/2409 new file mode 100644 index 00000000..b92073cc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2409 @@ -0,0 +1,3 @@ + + +High CPU usage on network traffic on Apple laptops diff --git a/results/classifier/mode-gemma3:12b/user/2422 b/results/classifier/mode-gemma3:12b/user/2422 new file mode 100644 index 00000000..d1e9d022 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2422 @@ -0,0 +1,71 @@ + + +`vill` not set after reserved `vsetvli` instruction usage +Description of problem: +The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code. + +Here is the quote from the spec: + +> When `rs1=x0` and `rd=x0`, the instruction operates as if the current +> vector length in `vl` is used as the AVL, and the resulting value is +> written to `vl`, but not to a destination register. This form can +> only be used when VLMAX and hence `vl` is not actually changed by the +> new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio +> that would result in a change of VLMAX is reserved. +> Use of the instruction is also reserved if `vill` was 1 beforehand. +> Implementations may set `vill` in either case. + +Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand". +Steps to reproduce: +1. Create `test.c` +```C +#include <assert.h> + +/* Position of vill in vtype. */ + +#define VILL_BIT (__riscv_xlen - 1) + +/* Return true if vill is 1. */ + +int vill_set_p () +{ + __UINT64_TYPE__ vtype; + asm volatile ("csrr %0, vtype" : "=r"(vtype)); + + return (vtype >> VILL_BIT) & 1; +} + +/* Return true if vill is 0. */ + +int vill_clear_p () +{ + return !vill_set_p (); +} + +int main () +{ + int vl; + + assert (vill_clear_p ()); + + /* Valid: vl = VLMAX. */ + asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl)); + assert (vill_clear_p ()); + + /* Valid: vl and VLMAX not changed. */ + asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n"); + assert (vill_clear_p ()); + + /* Reserved: Reduce VLMAX. */ + asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n"); + assert (vill_set_p ()); + + return 0; +} +``` +2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d` +3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test` +4. The final assertion fails because executing the reserved `vsetvli` did not set `vill` +``` +assertion "vill_set_p ()" failed: file "test.c", line 40, function: main +``` diff --git a/results/classifier/mode-gemma3:12b/user/2423 b/results/classifier/mode-gemma3:12b/user/2423 new file mode 100644 index 00000000..5570a3bc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2423 @@ -0,0 +1,36 @@ + + +`qemu -serial stdio` leaves stdout in non-blocking mode +Description of problem: +When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout. +Steps to reproduce: +Run the following script: + +``` +#!/usr/bin/env bash + +qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio & +PID="$!" +sleep 5 +kill "$PID" +wait "$PID" +echo "EXITING $?" + +sleep 5 +seq 1 400000 +``` + +The seq command will be interrupted prematurely: + +``` +... +5143 +5144 +5145⏎ wResource temporarily unavailable +write: Resource temporarily unavailable +write: Resource temporarily unavailable +``` + +When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600). +Additional information: +Expect a patch from me soon. diff --git a/results/classifier/mode-gemma3:12b/user/2438 b/results/classifier/mode-gemma3:12b/user/2438 new file mode 100644 index 00000000..03cb9e08 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2438 @@ -0,0 +1,3 @@ + + +QEMU needs compat tweak to build against upstream capstone 6 diff --git a/results/classifier/mode-gemma3:12b/user/2446 b/results/classifier/mode-gemma3:12b/user/2446 new file mode 100644 index 00000000..f9c2b4e7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2446 @@ -0,0 +1,62 @@ + + +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/mode-gemma3:12b/user/2448 b/results/classifier/mode-gemma3:12b/user/2448 new file mode 100644 index 00000000..51f9bb3a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2448 @@ -0,0 +1,48 @@ + + +linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin +Description of problem: +When a `*-linux-user` is used as binfmt_misc, and... + +- The `O` (i.e. open-binary) flag is set +- File descriptor 0 is closed when running the executable + +FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable. + +Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior. +Steps to reproduce: +1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary) +2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`) +3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output) + +The correct behavior is (You can see by running the native `cat <&-`): + +``` +cat: -: Bad file descriptor +cat: closing standard input: Bad file descriptor +``` + +Instead, the executable `cat` itself is dumped to stdout. + +Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable. +Additional information: +I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far: + +In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765) + +```c + execfd = qemu_getauxval(AT_EXECFD); + if (execfd == 0) { + execfd = open(exec_path, O_RDONLY); + if (execfd < 0) { + printf("Error while loading %s: %s\n", exec_path, strerror(errno)); + _exit(EXIT_FAILURE); + } + } +``` + +However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value. + +`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`. + +Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay? diff --git a/results/classifier/mode-gemma3:12b/user/2456 b/results/classifier/mode-gemma3:12b/user/2456 new file mode 100644 index 00000000..4eda21d7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2456 @@ -0,0 +1,3 @@ + + +check-tcg multi-threaded tests fail on ppc64 on clang-user CI job diff --git a/results/classifier/mode-gemma3:12b/user/2459 b/results/classifier/mode-gemma3:12b/user/2459 new file mode 100644 index 00000000..5f22c276 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2459 @@ -0,0 +1,3 @@ + + +Qemu in termux network bug diff --git a/results/classifier/mode-gemma3:12b/user/2460 b/results/classifier/mode-gemma3:12b/user/2460 new file mode 100644 index 00000000..f741142e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2460 @@ -0,0 +1,10 @@ + + +Significant performance degradation of qemu-x86_64 starting from version 3 on aarch64 +Description of problem: +When I ran CoreMark with different qemu user-mode versions，guest x86-64-> host arm64, I found that the performance was highest with QEMU 2.x versions, and there was a significant performance degradation starting from QEMU version 3. What is the reason? + +| | | | | | | | | | | | | +|------------------------------------------|-------------|-------------|-------------|-------------|-------------|-------------|------------|-------------|-------------|-------------|-------------| +| qemu version | 2.5.1 | 2.8.0 | 2.9.0 | 2.9.1 | 3.0.0 | 4.0.0 | 5.2.0 | 6.2.0 | 7.2.13 | 8.2.6 | 9.0.1 | +| coremark score | 3905.995703 | 4465.947153 | 4534.119247 | 4538.577912 | 1167.337886 | 1163.399453 | 928.348384 | 1327.051954 | 1301.659616 | 1034.714677 | 1085.304971 | diff --git a/results/classifier/mode-gemma3:12b/user/2483 b/results/classifier/mode-gemma3:12b/user/2483 new file mode 100644 index 00000000..9919ec44 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2483 @@ -0,0 +1,22 @@ + + +m68k: jsr (sp) doesn't work as expected +Description of problem: +Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first. + +``` + ff8241e6 22 4f movea.l SP,A1 + ff8241e8 70 68 moveq #0x68,D0 + LAB_ff8241ea XREF[1]: ff8241ee(j) + ff8241ea 12 d8 move.b (A0)+,(A1)+ + ff8241ec 53 80 subq.l #0x1,D0 + ff8241ee 66 fa bne.b LAB_ff8241ea + ff8241f0 4e 97 jsr (SP) +``` + +`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think? +What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails. + +Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing. + +{width=289 height=759} diff --git a/results/classifier/mode-gemma3:12b/user/2485 b/results/classifier/mode-gemma3:12b/user/2485 new file mode 100644 index 00000000..3aaddc05 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2485 @@ -0,0 +1,49 @@ + + +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/mode-gemma3:12b/user/2486 b/results/classifier/mode-gemma3:12b/user/2486 new file mode 100644 index 00000000..8bd90cec --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2486 @@ -0,0 +1,14 @@ + + +RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message +Description of problem: +The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified. +Disabling the extension using f=false does not actually disable it as shown by the zfinx error message. +Eg. Unsupported extension is explicitly rejected +``` +> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out +qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found +``` +Steps to reproduce: +1. Compile any riscv binary like: `int main() {}` +2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out` diff --git a/results/classifier/mode-gemma3:12b/user/2487 b/results/classifier/mode-gemma3:12b/user/2487 new file mode 100644 index 00000000..fe3788f6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2487 @@ -0,0 +1,70 @@ + + +qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Description of problem: +Using this basic test file: + +```c +int +main (void) +{ + return 0; +} +``` + +compiled into a static executable using an x86_64 toolchain (glibc or musl both tested), + +``` +gwyn ~/qemu-bug # file test1 +test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped + +gwyn ~/qemu-bug # file test2 +test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped +``` + +Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version +qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty) +Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers +``` + +QEMU crashes: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2 +** +ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Aborted +``` +Steps to reproduce: +1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer. +2. Run any simple x86_64 executable. +3. Observe the crash. +Additional information: +Bisected to here: + +``` +commit 15957eb9efe2da67c796612cead95cba28ba9bda +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Oct 27 05:57:31 2023 +0200 + + target/i386: use TSTEQ/TSTNE to test low bits + + When testing the sign bit or equality to zero of a partial register, it + is useful to use a single TSTEQ or TSTNE operation. It can also be used + to test the parity flag, using bit 0 of the population count. + + Do not do this for target_ulong-sized values however; the optimizer would + produce a comparison against zero anyway, and it avoids shifts by 64 + which are undefined behavior. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/emit.c.inc | 5 ++--- + target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- + 2 files changed, 22 insertions(+), 11 deletions(-) +``` diff --git a/results/classifier/mode-gemma3:12b/user/249 b/results/classifier/mode-gemma3:12b/user/249 new file mode 100644 index 00000000..7e28b1a8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/249 @@ -0,0 +1,3 @@ + + +guest OS catches a page fault bug when running dotnet diff --git a/results/classifier/mode-gemma3:12b/user/2491 b/results/classifier/mode-gemma3:12b/user/2491 new file mode 100644 index 00000000..bff24408 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2491 @@ -0,0 +1,17 @@ + + +Performance Regression in QEMU (amd64 Emulating LoongArch64) from 8.0.4 to 9.0.2 +Description of problem: +Previous Performance: In May 2023, we were using QEMU 8.0.4 for qemu-user emulation, and the performance was satisfactory. The setup did not include LSX (Loongson SIMD Extensions) support in either the system or QEMU. Performance results are shown in Figure A. + +Current Performance: Recently, we upgraded to QEMU 9.0.2. Both the system and QEMU now support vectorized instruction sets. However, we observed a performance decline to less than 60% of the previous benchmarks. + +We found that the slowdown is not caused by LSX. Disabling LSX compilation in the new version results in even worse performance. However, there are indeed significant differences between the two systems in terms of LSX support. +Additional information: +We use systemd-nspawn and qemu-binfmt for containerized operations. You can get a clean chroot from lcpu release [here](https://github.com/lcpu-club/loongarchlinux-dockerfile/releases/download/20240806/base-devel-loong64-20240806.tar.zst) + +Figure A, performance in May 2023 + + +Figure B, performance nowadays + diff --git a/results/classifier/mode-gemma3:12b/user/2495 b/results/classifier/mode-gemma3:12b/user/2495 new file mode 100644 index 00000000..afaaa987 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2495 @@ -0,0 +1,74 @@ + + +A bug in x86-64 MMX instructions +Description of problem: +It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x270 + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f84f82ec143 +``` + +However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f98e82ec143 +``` + +I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. + +It seems this bug looks similar to #2474. +Steps to reproduce: +1. Write `test.c` +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uint8_t o_R8[8]; + +void __attribute__ ((noinline)) show_state() { + printf("R8: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_R8[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".intel_syntax noprefix\n" + "mov r8, qword ptr [rip + i_R8]\n" + "movq mm0, qword ptr [rip + i_MM0]\n" + ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" + "mov qword ptr [rip + o_R8], r8\n" + ".att_syntax\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` +3. Run QEMU using this command: `qemu-x86_64 ./test.bin` +4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2497 b/results/classifier/mode-gemma3:12b/user/2497 new file mode 100644 index 00000000..0bfbc312 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2497 @@ -0,0 +1,5 @@ + + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/mode-gemma3:12b/user/2504 b/results/classifier/mode-gemma3:12b/user/2504 new file mode 100644 index 00000000..e93d749b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2504 @@ -0,0 +1,9 @@ + + +linux-user: qemu-x86_64 run /bin/XX got some error on LoongArch machine +Description of problem: +on LoongArch host, chroot x86_64-rootfs then run 'ls' got some error. +Steps to reproduce: +[chrootlog.txt](/uploads/2b77e7d9216396491ef4dc42bf24acc0/chrootlog.txt) +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2506 b/results/classifier/mode-gemma3:12b/user/2506 new file mode 100644 index 00000000..7e5d63af --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2506 @@ -0,0 +1,60 @@ + + +LC_RPATH stripped despite setting INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +Description of problem: +When I try to run qemu, I get the following output: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found +Steps to reproduce: +If the qemu-9.0.2 folder is present, remove it: +``` +$ rm -rf qemu-9.0.2 +``` +Create the source folder: +``` +$ tar xzf qemu-9.0.2.tar.xz +$ cd qemu-9.0.2 +``` + +Make sure the following environment variables are set: +``` +$ export CC=clang +$ export LDFLAGS="-rpath $HOME/local/lib" +$ export INSTALL_REMOVE_ENVIRONMENT_RPATH=FALSE +``` + +Configure as follows: +``` +$ ./configure --prefix=$HOME/local --disable-sdl --enable-slirp --enable-fdt=internal --enable-spice +``` + +Build +``` +$ make -j 10 +``` + +Note there are a large number of linker warnings like this: +> ld: warning: duplicate -rpath '/Users/mj/local/lib' ignored + +Execute this: +``` +$ otool -l build/qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +See this output +> cmd LC_RPATH +> cmdsize 32 +> path /Users/mj/local/lib (offset 12) + +Change directory to $HOME/local/bin & execute: +``` +$ otool -l qemu-system-aarch64 | grep LC_RPATH -A2 +``` + +The output is now empty - the LC_RPATH has been stripped by the install. This results in the failure to execute the resulting binary. Note, I tried using install_name_tool to add the RPATH, but it warned me this changed the signature of the file, and it would not run. + +Executing qemu-system-aarch64 produces the following: +> dyld[93165]: Library not loaded: @rpath/libjpeg.62.dylib +> Referenced from: <85BC1FBA-CA2E-3CAC-9ABF-E5330AC86CAF> /Users/mj/local/bin/qemu-system-aarch64 +> Reason: no LC_RPATH's found diff --git a/results/classifier/mode-gemma3:12b/user/2508 b/results/classifier/mode-gemma3:12b/user/2508 new file mode 100644 index 00000000..e1616a25 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2508 @@ -0,0 +1,3 @@ + + +test-aio unreliable on MSYS2 diff --git a/results/classifier/mode-gemma3:12b/user/2525 b/results/classifier/mode-gemma3:12b/user/2525 new file mode 100644 index 00000000..de484c9f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2525 @@ -0,0 +1,3 @@ + + +bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed. diff --git a/results/classifier/mode-gemma3:12b/user/2529 b/results/classifier/mode-gemma3:12b/user/2529 new file mode 100644 index 00000000..83ffb0e7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2529 @@ -0,0 +1,34 @@ + + +`stack smashing detected` running arm64 image from amd64 machine +Description of problem: +When running a linux/arm64 `ubuntu:20.04` docker image on a linux/amd64 machine, an single command `apt-get update` will through below error +```sh +root@189bd36b9ae7:/# apt-get update +0% [Working]*** stack smashing detected ***: terminated +Reading package lists... Done +E: Method http has died unexpectedly! +E: Sub-process http received signal 6. + +``` + +Tested this is happening for ubuntu:18.04, ubuntu:20.04, ubuntu:22.04 so far + +If running same image directly from an ARM64 host, issue is gone +Steps to reproduce: +1. install QEMU on an AMD64 host machine (Ubuntu20) + ```sh + docker run --rm --privileged multiarch/qemu-user-static --reset -p yes + ``` +2. run linux/arm64 docker image of ubuntu:20.04 + ```sh + docker run --platform linux/arm64 -it --entrypoint /bin/bash ubuntu:20.04 + ``` +3. from within the container, run `apt-get update`, it will through below error + ```sh + root@189bd36b9ae7:/# apt-get update + 0% [Working]*** stack smashing detected ***: terminated + Reading package lists... Done + E: Method http has died unexpectedly! + E: Sub-process http received signal 6. + ``` diff --git a/results/classifier/mode-gemma3:12b/user/2531 b/results/classifier/mode-gemma3:12b/user/2531 new file mode 100644 index 00000000..a553eb0a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2531 @@ -0,0 +1,62 @@ + + +QEMU internal SIGSEGV when creating an x86_64 Debian chroot from an aarch64 host. +Description of problem: +When I try to create a x86_64 Debian chroot using debootstrap from an aarch64 host system, QEMU segfaults causing the process to fail. +Steps to reproduce: +1. Run `sudo apt install debootstrap qemu-user-static binfmt-support` +2. Run `sudo debootstrap --arch amd64 bookworm debian_chroot http://deb.debian.org/debian/` +Additional information: +End of deboostrap output: +``` +I: Configuring dash... +I: Configuring libpam-modules:amd64... +I: Configuring grep... +I: Configuring perl-base... +I: Configuring gzip... +I: Configuring passwd... +I: Configuring login... +I: Configuring apt... +I: Configuring adduser... +I: Configuring libc-bin... +W: Failure while configuring required packages. +W: See /home/allen/debian_chroot/debootstrap/debootstrap.log for details (possibly the package passwd is at fault) +``` + +End of debootstrap log: +``` +$ tail /home/allen/debian_chroot/debootstrap/debootstrap.log -n30 +Setting up grep (3.8-5) ... +Setting up perl-base (5.36.0-7+deb12u1) ... +Setting up gzip (1.12-1) ... +Setting up passwd (1:4.13+dfsg1-1+b1) ... +x86_64-binfmt-P: QEMU internal SIGSEGV {code=MAPERR, addr=0x20} +Segmentation fault +groupadd: group 'shadow' already exists +Group ID 42 has been allocated for the shadow group. You have either +used 42 yourself or created a shadow group with a different ID. +Please correct this problem and reconfigure with dpkg --configure passwd''. + +Note that both user and group IDs in the range 0-99 are globally +allocated by the Debian project and must be the same on every Debian +system. +dpkg: error processing package passwd (--configure): + installed passwd package post-installation script subprocess returned error exit status 1 +Setting up libpam-runtime (1.5.2-6+deb12u1) ... +Setting up login (1:4.13+dfsg1-1+b1) ... +dpkg: apt: dependency problems, but configuring anyway as you requested: + apt depends on adduser. + +Setting up apt (2.6.1) ... +dpkg: adduser: dependency problems, but configuring anyway as you requested: + adduser depends on passwd; however: + Package passwd is not configured yet. + +Setting up adduser (3.134) ... +Processing triggers for libc-bin (2.36-9+deb12u7) ... +Errors were encountered while processing: + passwd +``` + +Full debootstrap log: +[debootstrap.log](/uploads/4eb24abd98a647e08bd03deea897b9dd/debootstrap.log) diff --git a/results/classifier/mode-gemma3:12b/user/2553 b/results/classifier/mode-gemma3:12b/user/2553 new file mode 100644 index 00000000..1180b521 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2553 @@ -0,0 +1,84 @@ + + +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/mode-gemma3:12b/user/2560 b/results/classifier/mode-gemma3:12b/user/2560 new file mode 100644 index 00000000..9a58af8b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2560 @@ -0,0 +1,107 @@ + + +Go garbage collector crashes when using qemu-x86_64 on an aarch64 host +Description of problem: +Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something? + +The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`. + +Output from Go when it crashes: + +``` +$ sudo chroot . go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push + +runtime stack: +runtime.throw({0xa95b29?, 0x797b1e2a383c?}) + runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c +runtime.(*lfstack).push(0x0?, 0xc0005041c0?) + runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45 +runtime.(*spanSetBlockAlloc).free(...) + runtime/mspanset.go:322 +runtime.(*spanSet).reset(0xf46980) + runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219 +runtime.finishsweep_m() + runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd +runtime.gcStart.func2() + runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f +runtime.systemstack(0x0) + runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a +```` +Steps to reproduce: +0. Use an aarch64 host system! + +1. Set up binfmt to use qemu-x86_64: + +``` +$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64 +enabled +interpreter /usr/bin/qemu-x86_64 +flags: OCF +offset 0 +magic 7f454c4602010100000000000000000002003e00 +mask fffffffffffefe00fffffffffffffffffeffffff +``` + +2. Download/extract x86_64 rootfs: + +``` +$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz +``` + +3. Create example app in the x86_64 rootfs: + +``` +package main + +func main() { +} +``` + +4. Build using chroot: + +``` +$ sudo chroot /path/to/x86_64/rootfs apk add go +$ sudo chroot /path/to/x86_64/rootfs go build main.go +runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0 +fatal error: lfstack.push +... +``` + +5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU: + +``` +$ sudo chroot . env GOGC=off go build main.go +# might have to mount /dev to build successfully, but Go doesn't panic! +``` +Additional information: +I've bisected this exact crash/failure to: + +``` +commit 2952b642a555207748dd961fcbfdc48f198eebb6 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Feb 13 10:20:27 2024 -1000 + + linux-user: Split out do_munmap + + Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +Though a different crash starts happening at the commit before that one: + +``` +commit ad87d26e6bb13257409f412224c862fc54025e8b +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jan 2 12:57:55 2024 +1100 + + linux-user: Do early mmap placement only for reserved_va + + For reserved_va, place all non-fixed maps then proceed + as for MAP_FIXED. + + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> +``` + +FYI @rth7680 diff --git a/results/classifier/mode-gemma3:12b/user/2580 b/results/classifier/mode-gemma3:12b/user/2580 new file mode 100644 index 00000000..10b08610 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2580 @@ -0,0 +1,14 @@ + + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/mode-gemma3:12b/user/2590 b/results/classifier/mode-gemma3:12b/user/2590 new file mode 100644 index 00000000..22aa9267 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2590 @@ -0,0 +1,25 @@ + + +qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. +Description of problem: +GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. +Steps to reproduce: +1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +``` +Additional information: +This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/mode-gemma3:12b/user/2592 b/results/classifier/mode-gemma3:12b/user/2592 new file mode 100644 index 00000000..1348f789 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2592 @@ -0,0 +1,39 @@ + + +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/mode-gemma3:12b/user/2595 b/results/classifier/mode-gemma3:12b/user/2595 new file mode 100644 index 00000000..8d8a4599 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2595 @@ -0,0 +1,137 @@ + + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2596 b/results/classifier/mode-gemma3:12b/user/2596 new file mode 100644 index 00000000..6d4ba170 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2596 @@ -0,0 +1,3 @@ + + +linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/mode-gemma3:12b/user/2600 b/results/classifier/mode-gemma3:12b/user/2600 new file mode 100644 index 00000000..1478097c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2600 @@ -0,0 +1,3 @@ + + +qemu-user MAP_SHARED TB invalidation diff --git a/results/classifier/mode-gemma3:12b/user/2604 b/results/classifier/mode-gemma3:12b/user/2604 new file mode 100644 index 00000000..11314405 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2604 @@ -0,0 +1,46 @@ + + +qemu-user-static crash when executing generated NEON code due to failure to detect invalidation +Description of problem: +`qemu-arm-static` crashes 100% of times when attempting to run NEON code. The same executable, when run in `system` emulation mode, works without issue. + +I experience this particular issue when attempting to test GStreamer's Orc library with NEON codegen with QEMU user emulation. +Steps to reproduce: +1. Clone https://gitlab.freedesktop.org/gstreamer/orc.git +2. Build with `meson setup build -Ddefault_library=static; meson compile -C build` +3. Run `qemu-arm-static ./build/tools/orc-bugreport` +Additional information: +The crash always happens inside the same JIT code. It is not a memory access, so there is no reason for QEMU to report SIGSEGV: + +``` +Program received signal SIGSEGV, Segmentation fault. +0x409e503c in ?? () +(gdb) bt +#0 0x409e503c in ?? () +#1 0x00408bc6 in orc_executor_run (ex=0x51cfc0) at ../orc/orcexecutor.c:51 +#2 0x00489692 in orc_test_compare_output_full_for_target (program=0x4bcd90, flags=0, + target_name=0x0) at ../orc-test/orctest.c:800 +#3 0x00489004 in orc_test_compare_output_full (program=0x4bcd90, flags=0) + at ../orc-test/orctest.c:664 +#4 0x00404826 in test_opcode_src (opcode=0x4b098c <opcodes+2400>) + at ../tools/orc-bugreport.c:252 +#5 0x004045d8 in test_opcodes () at ../tools/orc-bugreport.c:188 +#6 0x004043f2 in main (argc=1, argv=0x40800704) at ../tools/orc-bugreport.c:118 +(gdb) disas 0x409e5030 +No function contains specified address. +(gdb) disas 0x409e5030, +10 +Dump of assembler code from 0x409e5030 to 0x409e503a: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +End of assembler dump. +(gdb) disas 0x409e5030, +20 +Dump of assembler code from 0x409e5030 to 0x409e5044: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +=> 0x409e503c: add r3, r3, #16 + 0x409e5040: subs r12, r12, #1 +End of assembler dump. +(gdb) +``` diff --git a/results/classifier/mode-gemma3:12b/user/2606 b/results/classifier/mode-gemma3:12b/user/2606 new file mode 100644 index 00000000..5b1b0ec4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2606 @@ -0,0 +1,200 @@ + + +PowerPC host code is broken on Darwin +Description of problem: +Existing code is just wrong for Darwin ppc, it won’t compile. Assembler syntax needs to be fixed and likely adjusted to correct ABI. +Steps to reproduce: +1. Run the build of qemu on Darwin ppc, see it fail. +Additional information: +This is a patch I used earlier to fix the build (together with few minor unrelated to powerpc fixes): +``` +--- common-user/host/ppc/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc/safe-syscall.inc.S 2023-08-18 18:08:15.000000000 +0800 +@@ -25,17 +25,11 @@ + # else + # error "Unknown ABI" + # endif +-#endif +- +-#ifndef _CALL_SYSV +-# error "Unsupported ABI" + #endif + +- + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -47,11 +41,8 @@ + * arguments being syscall arguments (also 'long'). + */ + safe_syscall_base: +- .cfi_startproc +- stwu 1, -8(1) +- .cfi_def_cfa_offset 8 +- stw 30, 4(1) +- .cfi_offset 30, -4 ++ stwu r1, -8(r1) ++ stw r30, 4(r1) + + /* + * We enter with r3 == &signal_pending +@@ -64,14 +55,14 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- mr 30, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ mr r30, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* + * This next sequence of code works in conjunction with the +@@ -83,25 +74,22 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(30) +- cmpwi 0, 12, 0 ++ lwz r12, 0(r30) ++ cmpwi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- lwz 30, 4(1) /* restore r30 */ +- addi 1, 1, 8 /* restore stack */ +- .cfi_restore 30 +- .cfi_def_cfa_offset 0 ++ lwz r30, 4(r1) /* restore r30 */ ++ addi r1, r1, 8 /* restore stack */ ++ + bnslr+ /* return on success */ + b safe_syscall_set_errno_tail + + /* code path when we didn't execute the syscall */ +-2: lwz 30, 4(1) +- addi 1, 1, 8 +- addi 3, 0, QEMU_ERESTARTSYS ++2: lwz r30, 4(r1) ++ addi r1, r1, 8 ++ addi r3, 0, QEMU_ERESTARTSYS + b safe_syscall_set_errno_tail + +- .cfi_endproc +- + .size safe_syscall_base, .-safe_syscall_base + + +--- common-user/host/ppc64/safe-syscall.inc.S.orig 2022-04-20 03:10:27.000000000 +0800 ++++ common-user/host/ppc64/safe-syscall.inc.S 2022-05-31 13:23:21.000000000 +0800 +@@ -13,7 +13,6 @@ + .global safe_syscall_base + .global safe_syscall_start + .global safe_syscall_end +- .type safe_syscall_base, @function + + .text + +@@ -23,19 +22,10 @@ + * second one the system call number (as a 'long'), and all further + * arguments being syscall arguments (also 'long'). + */ +-#if _CALL_ELF == 2 +-safe_syscall_base: +- .cfi_startproc +- .localentry safe_syscall_base,0 +-#else +- .section ".opd","aw" ++ + .align 3 + safe_syscall_base: +- .quad .L.safe_syscall_base,.TOC.@tocbase,0 +- .previous +-.L.safe_syscall_base: +- .cfi_startproc +-#endif ++ + /* We enter with r3 == &signal_pending + * r4 == syscall number + * r5 ... r10 == syscall arguments +@@ -46,16 +36,15 @@ + * and returns the result in r3 + * Shuffle everything around appropriately. + */ +- std 14, 16(1) /* Preserve r14 in SP+16 */ +- .cfi_offset 14, 16 +- mr 14, 3 /* signal_pending */ +- mr 0, 4 /* syscall number */ +- mr 3, 5 /* syscall arguments */ +- mr 4, 6 +- mr 5, 7 +- mr 6, 8 +- mr 7, 9 +- mr 8, 10 ++ std r14, 16(r1) /* Preserve r14 in SP+16 */ ++ mr r14, r3 /* signal_pending */ ++ mr r0, r4 /* syscall number */ ++ mr r3, r5 /* syscall arguments */ ++ mr r4, r6 ++ mr r5, r7 ++ mr r6, r8 ++ mr r7, r9 ++ mr r8, r10 + + /* This next sequence of code works in conjunction with the + * rewind_if_safe_syscall_function(). If a signal is taken +@@ -66,29 +55,20 @@ + */ + safe_syscall_start: + /* if signal_pending is non-zero, don't do the call */ +- lwz 12, 0(14) +- cmpwi 0, 12, 0 ++ ld r12, 0(r14) ++ cmpdi cr0, r12, 0 + bne- 2f + sc + safe_syscall_end: + /* code path when we did execute the syscall */ +- ld 14, 16(1) /* restore r14 */ ++ ld r14, 16(r1) /* restore r14 */ + bso- 1f + blr + + /* code path when we didn't execute the syscall */ +-2: ld 14, 16(1) /* restore r14 */ +- addi 3, 0, QEMU_ERESTARTSYS ++2: ld r14, 16(r1) /* restore r14 */ ++ addi r3, 0, QEMU_ERESTARTSYS + + /* code path setting errno */ + 1: b safe_syscall_set_errno_tail + nop /* per abi, for the linker to modify */ +- +- .cfi_endproc +- +-#if _CALL_ELF == 2 +- .size safe_syscall_base, .-safe_syscall_base +-#else +- .size safe_syscall_base, .-.L.safe_syscall_base +- .size .L.safe_syscall_base, .-.L.safe_syscall_base +-#endif +``` +(Obviously, it is not made in a portable way – that was not needed at the time.) + +Unfortunately, while build itself worked, the binary crashed on launch. So something is not quite right, maybe with ABI compliance. diff --git a/results/classifier/mode-gemma3:12b/user/261 b/results/classifier/mode-gemma3:12b/user/261 new file mode 100644 index 00000000..ed17690b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/261 @@ -0,0 +1,3 @@ + + +broken signal handling in nios2 user-mode emulation diff --git a/results/classifier/mode-gemma3:12b/user/2614 b/results/classifier/mode-gemma3:12b/user/2614 new file mode 100644 index 00000000..29e7e4ae --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2614 @@ -0,0 +1,3 @@ + + +vhost user documentation for VHOST_USER_ADD_MEM_REG incorrect diff --git a/results/classifier/mode-gemma3:12b/user/262 b/results/classifier/mode-gemma3:12b/user/262 new file mode 100644 index 00000000..3d1f7901 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/262 @@ -0,0 +1,3 @@ + + +Broken scaling with gtk,gl=on on a hidpi display diff --git a/results/classifier/mode-gemma3:12b/user/2628 b/results/classifier/mode-gemma3:12b/user/2628 new file mode 100644 index 00000000..39b6cd1d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2628 @@ -0,0 +1,22 @@ + + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines +Description of problem: +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version + +dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped + +chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version + +dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped +Steps to reproduce: +1. debootstrap --arch=arm64 stable /scratch/debian-stable +2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version +Additional information: +Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU + +chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes diff --git a/results/classifier/mode-gemma3:12b/user/2629 b/results/classifier/mode-gemma3:12b/user/2629 new file mode 100644 index 00000000..bfad903b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2629 @@ -0,0 +1,3 @@ + + +dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines diff --git a/results/classifier/mode-gemma3:12b/user/263 b/results/classifier/mode-gemma3:12b/user/263 new file mode 100644 index 00000000..19ac71a3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/263 @@ -0,0 +1,3 @@ + + +readdir() returns NULL (errno=EOVERFLOW) for 32-bit user-static qemu on 64-bit host diff --git a/results/classifier/mode-gemma3:12b/user/2632 b/results/classifier/mode-gemma3:12b/user/2632 new file mode 100644 index 00000000..98cd709f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2632 @@ -0,0 +1,85 @@ + + +tcg optimization breaking memory access ordering +Description of problem: +The following code creates register dependency between 2 loads, which forces the first load to finish before the second: +``` +movz w0, #0x2 +str w0, [x1] +ldr w2, [x1] +eor w3, w2, w2 +ldr w4, [x5, w3, sxtw] +``` + +While translating it to tcg IR, it keeps this dependency correctly. +But after running tcg optimizations, it optimized the tcg sequence for `eor w3, w2, w2` at `0000000000000144` to `mov_i64 x3,$0x0`. which then removes the dependency between the loads. + +It results in incorrect behavior on the host on a multiple threaded program +Steps to reproduce: +1. +2. +3. +Additional information: +``` +OP: + ld_i32 loc0,env,$0xfffffffffffffff0 + brcond_i32 loc0,$0x0,lt,$L0 + st8_i32 $0x0,env,$0xfffffffffffffff4 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 + + ---- 000000000000013c 0000000000000000 0000000000001c00 + mov_i64 loc3,x1 + mov_i64 loc4,loc3 + qemu_st_a64_i64 x0,loc4,w16+un+leul,2 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + mov_i64 loc5,x1 + mov_i64 loc6,loc5 + qemu_ld_a64_i64 x2,loc6,w16+un+leul,2 + + ---- 0000000000000144 0000000000000000 0000000000000000 + and_i64 loc7,x2,$0xffffffff + xor_i64 x3,x2,loc7 + and_i64 x3,x3,$0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + mov_i64 loc9,x5 + mov_i64 loc10,x3 + ext32s_i64 loc10,loc10 + add_i64 loc9,loc9,loc10 + mov_i64 loc11,loc9 + qemu_ld_a64_i64 x4,loc11,w16+un+leul,2 + st8_i32 $0x1,env,$0xfffffffffffffff4 +``` + + +``` +OP after optimization and liveness analysis: + ld_i32 tmp0,env,$0xfffffffffffffff0 pref=0xffffffff + brcond_i32 tmp0,$0x0,lt,$L0 dead: 0 + st8_i32 $0x0,env,$0xfffffffffffffff4 dead: 0 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 sync: 0 dead: 0 pref=0xffffffff + + ---- 000000000000013c 0000000000000000 0000000000001c00 + qemu_st_a64_i64 $0x2,x1,w16+un+leul,2 dead: 0 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + qemu_ld_a64_i64 x2,x1,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000144 0000000000000000 0000000000000000 + mov_i64 x3,$0x0 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + qemu_ld_a64_i64 x4,x5,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + st8_i32 $0x1,env,$0xfffffffffffffff4 dead: 0 +``` diff --git a/results/classifier/mode-gemma3:12b/user/2641 b/results/classifier/mode-gemma3:12b/user/2641 new file mode 100644 index 00000000..8218c334 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2641 @@ -0,0 +1,3 @@ + + +Possible DEREF_OF_NULL in linux-user/syscall.c diff --git a/results/classifier/mode-gemma3:12b/user/2647 b/results/classifier/mode-gemma3:12b/user/2647 new file mode 100644 index 00000000..ef37f48a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2647 @@ -0,0 +1,49 @@ + + +A code error in accel/tcg/user-exec.c +Description of problem: +accel/tcg/user-exec.c: +``` +static int probe_access_internal(CPUArchState *env, vaddr addr, + int fault_size, MMUAccessType access_type, + bool nonfault, uintptr_t ra) +{ + int acc_flag; + bool maperr; + + switch (access_type) { + case MMU_DATA_STORE: + acc_flag = PAGE_WRITE_ORG; + break; + case MMU_DATA_LOAD: + acc_flag = PAGE_READ; + break; + case MMU_INST_FETCH: + acc_flag = PAGE_EXEC; + break; + default: + g_assert_not_reached(); + } + + if (guest_addr_valid_untagged(addr)) { + int page_flags = page_get_flags(addr); + if (page_flags & acc_flag) { + if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE) + && cpu_plugin_mem_cbs_enabled(env_cpu(env))) { + return TLB_MMIO; + } + return 0; /* success */ + } + maperr = !(page_flags & PAGE_VALID); + } else { + maperr = true; + } + + if (nonfault) { + return TLB_INVALID_MASK; + } + + cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra); +} +``` +The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code. diff --git a/results/classifier/mode-gemma3:12b/user/2652 b/results/classifier/mode-gemma3:12b/user/2652 new file mode 100644 index 00000000..ea55edab --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2652 @@ -0,0 +1,3 @@ + + +qemu-user please allow to emulate aarch64 cpu in 32bits mode diff --git a/results/classifier/mode-gemma3:12b/user/2655 b/results/classifier/mode-gemma3:12b/user/2655 new file mode 100644 index 00000000..ff5490e2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2655 @@ -0,0 +1,41 @@ + + +A problem in target/riscv/vector_helper.c: vext_ldff() +Description of problem: +I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c: +``` +static inline void +vext_ldff(...) +{ +... + for (i = env->vstart; i < env->vl; i++) { +... + if (i == 0) { + probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD); + } else { +... + flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD, + mmu_index, true, &host, 0); +... + if (flags & ~TLB_WATCHPOINT) { + vl = i; + goto ProbeSuccess; + } +... + } + } +ProbeSuccess: +... +} +``` +If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist. + +In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? + +This problem occurred in both linux-user mode and full-system mode. + +Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions. +Steps to reproduce: +1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests. +2. Write a plugin to add memory callbacks. +3. Observe the behavior of the function. diff --git a/results/classifier/mode-gemma3:12b/user/2664 b/results/classifier/mode-gemma3:12b/user/2664 new file mode 100644 index 00000000..e4bf204b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2664 @@ -0,0 +1,11 @@ + + +Building in Windows MSYS2/Mingw64 fails +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2676 b/results/classifier/mode-gemma3:12b/user/2676 new file mode 100644 index 00000000..31f6099d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2676 @@ -0,0 +1,9 @@ + + +GTK+ UI has serious problems on macOS hosts +Description of problem: +The GTK+ UI simply does not work on macOS at this stage. One major reason is that there does not appear to be any regular polling of the (macOS) UI event loop. The Cocoa back-end for GTK [sets a custom event polling function in GLib's event handler](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L1089) but Qemu never actually calls GLib/GTK's event polling. + +Thanks to @bonzini for discovering this as part of a [discussion on a patch generalising runloop event handling on macOS](https://patchew.org/QEMU/20241113142343.40832-1-phil@philjordan.eu/20241113142343.40832-2-phil@philjordan.eu/#CABgObfat1JwiBFNKHK6wwMkW5kgaqZfKJa=rW._5F9VvEdMWJR75A@mail.gmail.com). + +There is also a reasonable chance that QEMU might not reliably call GTK+ functions from the main thread (thread 0), which causes problems when GTK then calls through to the native Cocoa APIs which must be called from thread 0. diff --git a/results/classifier/mode-gemma3:12b/user/2683 b/results/classifier/mode-gemma3:12b/user/2683 new file mode 100644 index 00000000..43fdb0b6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2683 @@ -0,0 +1,41 @@ + + +TCG: probe_access() has inconsistent behavior +Description of problem: +In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO. + +accel/tcg/cputlb.c: probe_access_internal() +``` + if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED)) + || (access_type != MMU_INST_FETCH && force_mmio)) { + *phost = NULL; + return TLB_MMIO; + } +``` +But in linux-user mode, it will return correct address when the flag is TLB_MMIO. + +accel/tcg/user-exec.c: probe_access() +``` + return size ? g2h(env_cpu(env), addr) : NULL; +``` +This will lead to some different behaviors, like cbo.zero in RISC-V. + +target/riscv/op_helper.c: helper_cbo_zero() +``` + mem = probe_write(env, address, cbozlen, mmu_idx, ra); + + if (likely(mem)) { + memset(mem, 0, cbozlen); + } else { + for (int i = 0; i < cbozlen; i++) { + cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra); + } + } +``` +When the current instruction has memory callback by plugin: + +Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly. + +Linux-user mode uses fast-path(memset) and doesn't inject callbacks. + +To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode. diff --git a/results/classifier/mode-gemma3:12b/user/2688 b/results/classifier/mode-gemma3:12b/user/2688 new file mode 100644 index 00000000..5b241d5b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2688 @@ -0,0 +1,3 @@ + + +Add `disable_host_loopback` for network user backend diff --git a/results/classifier/mode-gemma3:12b/user/2696 b/results/classifier/mode-gemma3:12b/user/2696 new file mode 100644 index 00000000..987d26dc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2696 @@ -0,0 +1,14 @@ + + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/mode-gemma3:12b/user/2717 b/results/classifier/mode-gemma3:12b/user/2717 new file mode 100644 index 00000000..ff1b9080 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2717 @@ -0,0 +1,14 @@ + + +semihosting link to risc-v details in document is changed +Description of problem: + +Steps to reproduce: +1. Open https://gitlab.com/qemu-project/qemu/-/blob/master/docs/about/emulation.rst +2. Goto Supported Targets section +3. Click RISC-V link in the table +4. Got 404 + +New url looks like https://github.com/riscv-non-isa/riscv-semihosting/blob/main/riscv-semihosting.adoc +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2730 b/results/classifier/mode-gemma3:12b/user/2730 new file mode 100644 index 00000000..bf2539d2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2730 @@ -0,0 +1,12 @@ + + +riscv Calculation error！ +Steps to reproduce: +The following command will produce an error output + +```asm + lui s0, 0x80000 + lw a1, -48(s0) +``` +The value of a1 becomes 0xffffffff + diff --git a/results/classifier/mode-gemma3:12b/user/2738 b/results/classifier/mode-gemma3:12b/user/2738 new file mode 100644 index 00000000..8d48c4e7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2738 @@ -0,0 +1,12 @@ + + +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/mode-gemma3:12b/user/275 b/results/classifier/mode-gemma3:12b/user/275 new file mode 100644 index 00000000..ca713b7b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/275 @@ -0,0 +1,3 @@ + + +Error in user-mode calculation of ELF aux vector's AT_PHDR diff --git a/results/classifier/mode-gemma3:12b/user/276 b/results/classifier/mode-gemma3:12b/user/276 new file mode 100644 index 00000000..a0d3dfa8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/276 @@ -0,0 +1,3 @@ + + +Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/mode-gemma3:12b/user/2765 b/results/classifier/mode-gemma3:12b/user/2765 new file mode 100644 index 00000000..81e1c097 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2765 @@ -0,0 +1,3 @@ + + +InputMethodKit warnings on macOS Sequoia diff --git a/results/classifier/mode-gemma3:12b/user/2766 b/results/classifier/mode-gemma3:12b/user/2766 new file mode 100644 index 00000000..682a6e68 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2766 @@ -0,0 +1,25 @@ + + +Qemu 9.2: stubs: build issue with --enable-user --disable-system --enable-tools +Description of problem: +Since commit "[stubs: avoid duplicate symbols in libqemuutil.a](https://gitlab.com/qemu-project/qemu/-/commit/388b849fb6c33882b481123568995a749a54f648)", Qemu doesn't build with: + + ./configure --enable-user --disable-system --enable-tools + + /usr/bin/ld: libhwcore.a.p/hw_core_qdev.c.o: in function 'device_finalize': \ + /home/autobuild/autobuild/instance-2/output-1/build/host-qemu-9.2.0/build/../hw/core/qdev.c:689:(.text+0x75c): undefined reference to 'qapi_event_send_device_deleted' + collect2: error: ld returned 1 exit status + +See Buildroot automated build results: +http://autobuild.buildroot.org/?reason=host-qemu-9.2.0 + +Indeed, with have_system = false and have_tools = true, Qemu needs the stubs for QAPI events added by stub_ss.add(files('qdev.c')) to provide qapi_event_send_device_deleted. + +Maybe the change in stubs/meson.build should have been: \ + +if not have_system and have_tools \ +stub_ss.add(files('qdev.c')) \ +endif + +Best regards, +Romain diff --git a/results/classifier/mode-gemma3:12b/user/2799 b/results/classifier/mode-gemma3:12b/user/2799 new file mode 100644 index 00000000..5e9892cf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2799 @@ -0,0 +1,43 @@ + + +compile failure for linux-user when host libc defines "struct sched_attr" in its sched.h +Description of problem: +When I tried to build commit 871af84d the build process stopped in [3306/9698] Compiling C object libqemu...-linux-user.a.p/linux-user_syscall.c.o + +Here is the error log: + +``` +../linux-user/syscall.c:364:8: error: redefinition of 'struct sched_attr' + 364 | struct sched_attr { + | ^~~~~~~~~~ +In file included from /usr/include/bits/sched.h:63, + from /usr/include/sched.h:43, + from /usr/include/pthread.h:22, + from /usr/include/glib-2.0/glib/deprecated/gthread.h:126, + from /usr/include/glib-2.0/glib.h:115, + from /home/fred/qemu-git/src/qemu/include/glib-compat.h:32, + from /home/fred/qemu-git/src/qemu/include/qemu/osdep.h:161, + from ../linux-user/syscall.c:20: +/usr/include/linux/sched/types.h:98:8: note: originally defined here + 98 | struct sched_attr { + | ^~~~~~~~~~ +``` +Steps to reproduce: +1. Grab commit 871af84d +2. Use this configure command line: + +``` +--prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --smbd=/usr/bin/smbd \ + --enable-modules \ + --enable-sdl \ + --disable-werror \ + "${@:2}" +``` + +3. Launch ninja and wait. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/280 b/results/classifier/mode-gemma3:12b/user/280 new file mode 100644 index 00000000..109e1830 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/280 @@ -0,0 +1,3 @@ + + +(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML diff --git a/results/classifier/mode-gemma3:12b/user/2802 b/results/classifier/mode-gemma3:12b/user/2802 new file mode 100644 index 00000000..2b083ac9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2802 @@ -0,0 +1,28 @@ + + +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/mode-gemma3:12b/user/2815 b/results/classifier/mode-gemma3:12b/user/2815 new file mode 100644 index 00000000..9cd32748 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2815 @@ -0,0 +1,3 @@ + + +clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue diff --git a/results/classifier/mode-gemma3:12b/user/2824 b/results/classifier/mode-gemma3:12b/user/2824 new file mode 100644 index 00000000..190b3236 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2824 @@ -0,0 +1,3 @@ + + +compile from source on macOS error: "found no usable tomli, please install it" diff --git a/results/classifier/mode-gemma3:12b/user/2825 b/results/classifier/mode-gemma3:12b/user/2825 new file mode 100644 index 00000000..88b44bf7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2825 @@ -0,0 +1,39 @@ + + +execveat with file descriptor and empty filename returns ENOENT when cross architectures +Description of problem: +On my x86_64 debian host (with binfmt_misc configured), when calling execveat with a fd , and empty pathname "", and flag AT_EMPTY_PATH. Then only x86_64 and x86 can be called normally, while programs of other architectures (arm64, arm, riscv64, etc.) will return ENOENT errors. + +I first encountered this problem when trying to run lxc-attach with qemu-aarch64. Its reference is [lxc/stable-6.0/src/include/fexecve.c#L30](https://github.com/lxc/lxc/blob/stable-6.0/src/include/fexecve.c#L30), which is the implementation of the fexecve function. So I wrote a simple test and compiled it with `x86_64/aarch64-linux-gnu-gcc -static test.c -o test`. execveat works fine when running natively or using qemu-x86_64/qemu-i386. When running versions for other architectures, using AT_EMPTY_PATH will result in ENOENT (No such file or directory); use /proc/self/fd/%d as the pathname and execve, it will work fine (like the rest part of the fexecve function). If binfmt_misc is turned off and run forign architectures ver, both calls will result in ENOEXEC (Exec format error). +Steps to reproduce: +1. Install qemu-user and binfmt_misc. Install gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. +2. Compile test.c with host gcc, then compile forign architectures ver with gcc-aarch64-linux-gnu/gcc-riscv64-linux-gnu etc. like `gcc -static test.c -o test` and `aarch64-linux-gnu-gcc -static test.c -o test-aarch64` +3. Run different versions of test +4. To disable/enable binfmt, you can `echo 0 > /proc/sys/fs/binfmt_misc/qemu-aarch64` or `echo 1 > /proc/sys/fs/binfmt_misc/qemu-aarch64` +5. Sample outputs + +``` +rrex@debian:~/Downloads$ ./test +****Running to prepare execve +fd=3 +File size: 772296 bytes + +execveat with AT_EMPTY_PATH: +**Running in execve + +execveat with fd path: /proc/self/fd/3 +**Running in execve + +rrex@debian:~/Downloads$ qemu-aarch64 ./test-aarch64 +****Running to prepare execve +fd=3 +File size: 706104 bytes + +execveat with AT_EMPTY_PATH: +!!execveat a fd failed with errno: No such file or directory + +execveat with fd path: /proc/self/fd/3 +**Running in execve +``` +Additional information: +# diff --git a/results/classifier/mode-gemma3:12b/user/2827 b/results/classifier/mode-gemma3:12b/user/2827 new file mode 100644 index 00000000..f7f69821 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2827 @@ -0,0 +1,3 @@ + + +Document how to use QEMU user mode networking with passt diff --git a/results/classifier/mode-gemma3:12b/user/283 b/results/classifier/mode-gemma3:12b/user/283 new file mode 100644 index 00000000..1e2e0532 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/283 @@ -0,0 +1,3 @@ + + +TCG memory leak with FreeDOS 'edit' diff --git a/results/classifier/mode-gemma3:12b/user/2846 b/results/classifier/mode-gemma3:12b/user/2846 new file mode 100644 index 00000000..e40afd1f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2846 @@ -0,0 +1,3 @@ + + +linux-user hangs if fd_trans_lock is held during fork diff --git a/results/classifier/mode-gemma3:12b/user/2850 b/results/classifier/mode-gemma3:12b/user/2850 new file mode 100644 index 00000000..cae689ec --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2850 @@ -0,0 +1,5 @@ + + +Available in a version for Windows on arm +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/2865 b/results/classifier/mode-gemma3:12b/user/2865 new file mode 100644 index 00000000..b4605476 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2865 @@ -0,0 +1,54 @@ + + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/mode-gemma3:12b/user/2878 b/results/classifier/mode-gemma3:12b/user/2878 new file mode 100644 index 00000000..e6f0ad12 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2878 @@ -0,0 +1,3 @@ + + +Support for avx512 in qemu user space emulation. diff --git a/results/classifier/mode-gemma3:12b/user/289 b/results/classifier/mode-gemma3:12b/user/289 new file mode 100644 index 00000000..e09e8480 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/289 @@ -0,0 +1,3 @@ + + +Guest freezes until there is a keyboard input on Windows version diff --git a/results/classifier/mode-gemma3:12b/user/2914 b/results/classifier/mode-gemma3:12b/user/2914 new file mode 100644 index 00000000..baa7520f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2914 @@ -0,0 +1,17 @@ + + +JRE fails (SIGSEGV) on x86 Ubuntu 24.04 LTS emulated on Apple Silicon M2 ARM +Description of problem: +JRE (HotSpot Runtime) errors with SIGSEGV on x86 Linux Ubuntu 24.04.2 LTS when it is emulated on Apple Silicon M2. In this case, JRE is being triggered by SBT that is running Scala source code. + +This could be a Qemu issue, an OpenJDK issue, an Apple issue, etc. - Let me know if this is the wrong place/not under the purview of Qemu and I'll post it somewhere else. +Steps to reproduce: +I am attempting to run a Scala project (https://github.com/ucb-bar/chipyard) on a x86 machine emulated on an Apple Silicon device. The project build flow fails on step 5 when Scala sources are compiled and run. You can reproduce the issue by running Chipyard's recommended setup flow here: + +https://chipyard.readthedocs.io/en/stable/Chipyard-Basics/Initial-Repo-Setup.html#default-requirements-installation + +Then instead of running the given build-setup command in the tutorial, run `./build-setup.sh riscv-tools -s 3 -s 8 -s 7 -s 8 -s 9 -s 10 --use-lean-conda` in order to skip the irrelevant setup steps. + +The SBT build config is in the project's base directory under build.sbt. There is a commonSettings sequence that is inherited by each subsequent project. The flow: line 409 of common.mk is triggered by line 257 & 258 of build-setup.sh, which then triggers SBT with some arguments passed into the SBT executable. +Additional information: +Extensive crash logs and attempts to solve the issue has been documented at this issue on UTM's GitHub: https://github.com/utmapp/UTM/issues/7070 diff --git a/results/classifier/mode-gemma3:12b/user/2924 b/results/classifier/mode-gemma3:12b/user/2924 new file mode 100644 index 00000000..3e4387d7 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2924 @@ -0,0 +1,17 @@ + + +qemu-user not responding to Ctrl-C from gdb +Description of problem: +When attached to qemu-x84_64's gdbserver via gdb, it is not possible to interrupt the binary being emulated. Usually, Ctrl-C will interrupt a running binary from gdb and I believe (though have not tested) it works in qemu-system. + +First Ctrl-C will do nothing and second will prompt to stop debugging. +``` +(gdb) c +Continuing. +^C^CThe target is not responding to interrupt requests. +Stop debugging it? (y or n) +``` +Steps to reproduce: +1. Run `./qemu-x86_64 -g 1234 ~/Downloads/base64-x64_64-static` or any static binary that will pause/hang +2. Connect from gdb `(gdb) target remote :1234` +3. Ctrl-C in gdb diff --git a/results/classifier/mode-gemma3:12b/user/2929 b/results/classifier/mode-gemma3:12b/user/2929 new file mode 100644 index 00000000..0f951988 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2929 @@ -0,0 +1,9 @@ + + +Ask to extend vhost-user protocol to carry implementation defined error contexts +Additional information: +I am working on the Google [crosvm](https://chromium.googlesource.com/crosvm/crosvm/) project, which implements some `vhost-user` clients/servers defined by [this QEMU doc](https://qemu-project.gitlab.io/qemu/interop/vhost-user.html). I am wondering if we could add a protocol feature/protocol header flag bit to allow the payload of the reply to carry detailed implementation defined error contexts? + +Specifically, I am working on the `vhost-user-gpu` device, which needs to send some memory mapping request to the frontend(the main process where VCPU lives), so that we can map some GPU memory to the guest. We are trying to diagnose a bug where the frontend can sometimes fail to perform the operation. However, we don't have access to the logs on the main process, so we are left with only very limited information on the `vhost-user-gpu` process. It could be helpful if we could send detailed implementation defined error contexts in the payload of the reply. + +I am wondering in order for the upstream QEMU to accept such "spec" change to the `vhost-user` protocol, what the process should be like? Thanks. diff --git a/results/classifier/mode-gemma3:12b/user/2935 b/results/classifier/mode-gemma3:12b/user/2935 new file mode 100644 index 00000000..d2a09b7e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2935 @@ -0,0 +1,26 @@ + + +strchrnul detection not suitable for macOS +Description of problem: +When qemu is compiled on macOS 15.4, targeting an earlier macOS version (e.g., 15.1), and then run on this earlier macOS version (15.1), it segfaults. This is because: + +- the meson test for strchrnul succeeds (the function is present in the library) +- the strchrnul function is therefore used +- but that function was introduced in the system's libc in 15.4 only + +The root cause for the bug is that the meson test for strchrnul does not include the appropriate header. Indeed, see the documentation for meson on compiler.has_function (https://mesonbuild.com/Compiler-properties.html#does-a-function-exist) + +> Note that, on macOS programs can be compiled targeting older macOS versions than the one that the program is compiled on. It can't be assumed that the OS version that is compiled on matches the OS version that the binary will run on. +> +> Therefore when detecting function availability with compiler.has_function(), it is important to specify the correct header in the prefix argument. + +The correct fix would be, in qemu's meson.build, to change: + +`cc.has_function('strchrnul')` + +into `cc.has_function('strchrnul', prefix : '#include <string>')` + +This is the recommended best practice and would allow correct detection on all platforms, including macOS. +Steps to reproduce: +1. Install qemu from Homebrew, which is built on macOS 15.4 +2. Run it on a machine with macOS < 15.4 diff --git a/results/classifier/mode-gemma3:12b/user/294 b/results/classifier/mode-gemma3:12b/user/294 new file mode 100644 index 00000000..b65d02c5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/294 @@ -0,0 +1,3 @@ + + +Keyboard keys get stuck diff --git a/results/classifier/mode-gemma3:12b/user/2952 b/results/classifier/mode-gemma3:12b/user/2952 new file mode 100644 index 00000000..a3c07a8b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2952 @@ -0,0 +1,16 @@ + + +Truncated bits while writing value to registers of RISC-V +Description of problem: +As mentioned above +Steps to reproduce: +``` +# 1. Compile the `test.S`: +riscv32-unknown-linux-gnu-gcc -g -static -nostartfiles -o test hello.S + +# 2. Execute the binary: +qemu-riscv32 ./test + +# 3. Check exit code +echo $? +``` diff --git a/results/classifier/mode-gemma3:12b/user/2971 b/results/classifier/mode-gemma3:12b/user/2971 new file mode 100644 index 00000000..b26a8b99 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2971 @@ -0,0 +1,46 @@ + + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/2972 b/results/classifier/mode-gemma3:12b/user/2972 new file mode 100644 index 00000000..ebed624b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2972 @@ -0,0 +1,639 @@ + + +loongarch64 inconsistencies between hardware and qemu due too lenient decoding of floating point comparisons +Description of problem: +(Related to #2971 ) + +Lenient instruction decoding of floating point comparisons leads to instructions that do not exist on hardware (Loongson 3A5000). + +The decoding of floating point compare instruction allows for instructions with illegal fcmp modes. + +The following are affected (`target/loongarch/insns.decode`): + +``` +vfcmp_cond_s 0000 11000101 ..... ..... ..... ..... @vvv_fcond +vfcmp_cond_d 0000 11000110 ..... ..... ..... ..... @vvv_fcond +xvfcmp_cond_s 0000 11001001 ..... ..... ..... ..... @vvv_fcond +xvfcmp_cond_d 0000 11001010 ..... ..... ..... ..... @vvv_fcond +fcmp_cond_s 0000 11000001 ..... ..... ..... 00 ... @cff_fcond +fcmp_cond_d 0000 11000010 ..... ..... ..... 00 ... @cff_fcond +``` + +The `get_fcmp_flags` function in `target/loongarch/tcg/insn_trans/trans_fcmp.c.inc` allows decoding all possible 4-bit condition values even though some are invalid on hardware (Loongson 3A5000): + +<details><summary>qemu-loongarch64-static</summary> + +``` + --- fcond = 0b0 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b100 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b101 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b110 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b111 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1000 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1001 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1010 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1011 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1100 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1101 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1110 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1111 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10000 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10001 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10010 (LT | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10011 (LT | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10100 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10101 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10110 (LT | EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10111 (LT | EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11000 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11001 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11010 (LT | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11011 (LT | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11100 (EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11101 (EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True +``` + +</details> + + +<details><summary>Loongson 3A5000</summary> + +``` + --- fcond = 0b0 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1 () --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11 (LT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b100 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b101 (EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b110 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b111 (LT | EQ) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1000 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1001 (UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1010 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1011 (LT | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1100 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1101 (EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1110 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b1111 (LT | EQ | UN) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10000 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10001 (LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10010 (LT | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10011 (LT | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10100 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10101 (EQ | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b10110 (LT | EQ | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b10111 (LT | EQ | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11000 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11001 (UN | LT | GT) --- +vfcmp_cond_s True +vfcmp_cond_d True +xvfcmp_cond_s True +xvfcmp_cond_d True +fcmp_cond_s True +fcmp_cond_d True + + --- fcond = 0b11010 (LT | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11011 (LT | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11100 (EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11101 (EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11110 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False + + --- fcond = 0b11111 (LT | EQ | UN | LT | GT) --- +vfcmp_cond_s False +vfcmp_cond_d False +xvfcmp_cond_s False +xvfcmp_cond_d False +fcmp_cond_s False +fcmp_cond_d False +``` + +</details> +Steps to reproduce: +1. compile the `test_instr_valid` test program for loongarch64 (see additional information). +2. run the `check_defined.py` python script to print out information about defined instructions. +3. All tested fcmp instructions are defined when run using qemu, but some are invalid (SIGILL) on actual hardware. +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_instr_valid` source code: + +```C +#include <signal.h> +#include <errno.h> +#include <stdio.h> +#include <stddef.h> +#include <stdint.h> +#include <stdlib.h> +#include <sys/mman.h> + +#define PAGE_SIZE 0x4000 + +#define ret 0x4c000020 + +typedef void (*instr_fun)(void); + +static __attribute__((aligned(PAGE_SIZE))) uint32_t code[PAGE_SIZE / sizeof(uint32_t)]; + +void handler(int signo, siginfo_t *info, void *context) { + printf("False"); + exit(0); +} + +int main(int argc, char** argv) { + struct sigaction act = { 0 }; + act.sa_flags = SA_SIGINFO | SA_ONSTACK; + act.sa_sigaction = &handler; + sigaction(SIGILL, &act, NULL); + uint32_t instr = (uint32_t)strtoull(argv[1], NULL, 0); + code[0] = instr; + code[1] = ret; + mprotect(code, sizeof(code), PROT_READ | PROT_EXEC); + instr_fun f = (instr_fun)(void*)code; + f(); + printf("True"); + exit(0); +} +``` + +`check_defined.py`: + +```py +import subprocess + +CMD = ["qemu-loongarch64-static", "./test_instr_valid"] # remove "qemu-loongarch64-static" when running without emulation + +def is_defined(instr): + try: + return eval(subprocess.check_output(CMD + [hex(instr)]).decode()) + except: + return False + +bases = [ + ("vfcmp_cond_s ", 0b00001100010100000000000000000000), # vfcmp_cond_s 0000 11000101 ..... ..... ..... ..... @vvv_fcond + ("vfcmp_cond_d ", 0b00001100011000000000000000000000), # vfcmp_cond_d 0000 11000110 ..... ..... ..... ..... @vvv_fcond + ("xvfcmp_cond_s", 0b00001100100100000000000000000000), # xvfcmp_cond_s 0000 11001001 ..... ..... ..... ..... @vvv_fcond + ("xvfcmp_cond_d", 0b00001100101000000000000000000000), # xvfcmp_cond_d 0000 11001010 ..... ..... ..... ..... @vvv_fcond +] + +bases_2 = [ + ("fcmp_cond_s ", 0b00001100000100000000000000000000), # fcmp_cond_s 0000 11000001 ..... ..... ..... 00 ... @cff_fcond + ("fcmp_cond_d ", 0b00001100001000000000000000000000), # fcmp_cond_d 0000 11000010 ..... ..... ..... 00 ... @cff_fcond +] + +def format_fcond(val): + x = ["LT", "EQ", "UN", "LT | GT"] + return " | ".join(x[i] for i in range(4) if (val >> 1) & (1 << i)) + +fcond_shift = 15 + +# use r1, r2, r3 for vector instructions +reg_mask = 0b000110001000001 + +# use c0, r1, r2 for normal instructions +reg_mask_2 = 0b000100000100000 + +for fcond in range(1 << 5): + print(f" --- fcond = {bin(fcond)} ({format_fcond(fcond)}) --- ") + for name, mask in bases: + print(name, is_defined(mask | reg_mask | (fcond << fcond_shift))) + for name, mask in bases_2: + print(name, is_defined(mask | reg_mask_2 | (fcond << fcond_shift))) + print("") +``` diff --git a/results/classifier/mode-gemma3:12b/user/2988 b/results/classifier/mode-gemma3:12b/user/2988 new file mode 100644 index 00000000..31f4f849 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/2988 @@ -0,0 +1,9 @@ + + +Absolute mouse mode is broken in SDL2 +Description of problem: +Absolute mouse mode is broken in SDL2. Bisected at 30aa105640b0a2a541744b6584d57c9a4b86debd. + +Relative mouse mode has never worked in stretched SDL2 Display for display controllers that passed through cursor data and have positions warped by HOST UI backend. It looks like 30aa105640b0a2a541744b6584d57c9a4b86debd tried to fix this but it didn't work out. Scaling **"relative motions"** isn't straight-forward as what the commit had expected. + +Absolute mouse mode mode has always worked in stretched SDL2 Display. 30aa105640b0a2a541744b6584d57c9a4b86debd broke it without fixing anything. diff --git a/results/classifier/mode-gemma3:12b/user/306 b/results/classifier/mode-gemma3:12b/user/306 new file mode 100644 index 00000000..905a1174 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/306 @@ -0,0 +1,3 @@ + + +Option to constrain linux-user exec() to emulated CPU only diff --git a/results/classifier/mode-gemma3:12b/user/311 b/results/classifier/mode-gemma3:12b/user/311 new file mode 100644 index 00000000..c2060c5f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/311 @@ -0,0 +1,3 @@ + + +qemu user mode: rt signals not implemented for sparc guests diff --git a/results/classifier/mode-gemma3:12b/user/312 b/results/classifier/mode-gemma3:12b/user/312 new file mode 100644 index 00000000..2645a76d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/312 @@ -0,0 +1,3 @@ + + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/mode-gemma3:12b/user/313 b/results/classifier/mode-gemma3:12b/user/313 new file mode 100644 index 00000000..3c4fe368 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/313 @@ -0,0 +1,3 @@ + + +-daemonize not working on macOS diff --git a/results/classifier/mode-gemma3:12b/user/314 b/results/classifier/mode-gemma3:12b/user/314 new file mode 100644 index 00000000..ee062b92 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/314 @@ -0,0 +1,3 @@ + + +qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip diff --git a/results/classifier/mode-gemma3:12b/user/318 b/results/classifier/mode-gemma3:12b/user/318 new file mode 100644 index 00000000..952b45d6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/318 @@ -0,0 +1,3 @@ + + +QEMU crash after a QuickBASIC program integer overflow diff --git a/results/classifier/mode-gemma3:12b/user/324 b/results/classifier/mode-gemma3:12b/user/324 new file mode 100644 index 00000000..f5581f02 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/324 @@ -0,0 +1,3 @@ + + +chrome based apps can not be run under qemu user mode diff --git a/results/classifier/mode-gemma3:12b/user/326 b/results/classifier/mode-gemma3:12b/user/326 new file mode 100644 index 00000000..1fb39662 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/326 @@ -0,0 +1,3 @@ + + +QEMU-user ignores MADV_DONTNEED diff --git a/results/classifier/mode-gemma3:12b/user/334 b/results/classifier/mode-gemma3:12b/user/334 new file mode 100644 index 00000000..cab69331 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/334 @@ -0,0 +1,3 @@ + + +macOS App Nap feature gradually freezes QEMU process diff --git a/results/classifier/mode-gemma3:12b/user/340 b/results/classifier/mode-gemma3:12b/user/340 new file mode 100644 index 00000000..37167860 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/340 @@ -0,0 +1,3 @@ + + +qemu: uncaught target signal 6 (Aborted) - core dumped on Apple Silicon M1 arm64 diff --git a/results/classifier/mode-gemma3:12b/user/354 b/results/classifier/mode-gemma3:12b/user/354 new file mode 100644 index 00000000..787699f6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/354 @@ -0,0 +1,3 @@ + + +Emulation error when calling the SIOCGIFNETMASK ioctl through qemu-user diff --git a/results/classifier/mode-gemma3:12b/user/356 b/results/classifier/mode-gemma3:12b/user/356 new file mode 100644 index 00000000..91564020 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/356 @@ -0,0 +1,3 @@ + + +qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/mode-gemma3:12b/user/385 b/results/classifier/mode-gemma3:12b/user/385 new file mode 100644 index 00000000..60c95fe5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/385 @@ -0,0 +1,3 @@ + + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/mode-gemma3:12b/user/408 b/results/classifier/mode-gemma3:12b/user/408 new file mode 100644 index 00000000..e2a30a30 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/408 @@ -0,0 +1,3 @@ + + +DLLs not installing on 32bit version diff --git a/results/classifier/mode-gemma3:12b/user/419 b/results/classifier/mode-gemma3:12b/user/419 new file mode 100644 index 00000000..f19f03fb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/419 @@ -0,0 +1,3 @@ + + +bsd-user dumps core for all binaries emulated diff --git a/results/classifier/mode-gemma3:12b/user/426 b/results/classifier/mode-gemma3:12b/user/426 new file mode 100644 index 00000000..91564020 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/426 @@ -0,0 +1,3 @@ + + +qemu linux-user doesn't translate host/target data for iovec I/O diff --git a/results/classifier/mode-gemma3:12b/user/434 b/results/classifier/mode-gemma3:12b/user/434 new file mode 100644 index 00000000..751b25ec --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/434 @@ -0,0 +1,3 @@ + + +Mouse pointer disappears when it is over console window diff --git a/results/classifier/mode-gemma3:12b/user/442 b/results/classifier/mode-gemma3:12b/user/442 new file mode 100644 index 00000000..2fbd6fdb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/442 @@ -0,0 +1,3 @@ + + +Firebird crashes on qemu-m68k-user with pthread_mutex_init error diff --git a/results/classifier/mode-gemma3:12b/user/449 b/results/classifier/mode-gemma3:12b/user/449 new file mode 100644 index 00000000..0862e9f2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/449 @@ -0,0 +1,70 @@ + + +s390x linux-user assertion fires in vector asm on master +Description of problem: +Seeing a assert being fired when running this go program that executes vector instructions: + +[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go) + +``` +qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed. +SIGABRT: abort +PC=0x5b660 m=0 sigcode=4294967290 + +goroutine 1 [running]: +runtime.sigpanic() + /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660 +crypto/elliptic.p256SqrInternalVMSL() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600 +p256SqrInternal() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8 +crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c +crypto/elliptic.p256Sqr(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81 +crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6 +crypto/elliptic.initTable() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2 +crypto/elliptic.initP256Arch(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57 +crypto/elliptic.initP256() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960 +crypto/elliptic.initAll() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4 +sync.(*Once).doSlow(0x2168e8, 0x122be8) + /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c +sync.(*Once).Do(...) + /home/jalbrecht/s390x/15/go/src/sync/once.go:57 +crypto/elliptic.P256(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433 +main.main() + /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e +runtime.main() + /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4 +runtime.goexit() + /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52 + +r0 0x0 r1 0xc000198bc0 +r2 0xc000198ce0 r3 0xc000198ce0 +r4 0x1401a0 r5 0xc000198be0 +r6 0xc000198bc0 r7 0x1c00f0 +r8 0xda600 r9 0xc0001989a8 +r10 0x217810 r11 0x0 +r12 0x4000800378 r13 0xc000000180 +r14 0xda600 r15 0xc000198998 +pc 0x5b660 link 0xda600 +exit status 2 +``` +Steps to reproduce: +On an amd64 linux host: +1. Download attached ecdsaexample.go file +2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz +3. Build a qemu-s390x-static from current master +4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go +Additional information: +@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues. + +This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs. + +cc: @ruixinbao diff --git a/results/classifier/mode-gemma3:12b/user/455 b/results/classifier/mode-gemma3:12b/user/455 new file mode 100644 index 00000000..c46d2183 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/455 @@ -0,0 +1,36 @@ + + +Pressing special keys (specially ctrl) sticks the key or makes it repeat the next key until ESC or Ctrl is pressed. +Description of problem: +Well, I'm using it in a daily basis, since it is my VM to isolate the environment for work. + +It was compiled from source for _jack_ support, the only thing that I cared about. I'll be honest : I don't remember the special parameters, nothing unusual though. I'm not in the need for _rt_ kernels. + +When I press `Ctrl` and sometimes when I press other special keys, one of the three options occur : +1. It repeats all the keys pressed next, like if I was pressing it for a long time. + - Example : `a` turns into `aaaaaaaaaaaaaaa...`(continues) + - It repeats until I press `Esc` or `Ctrl` again. +1. `Ctrl` continues as pressed and everything I type occurs with `Ctrl`. + - Example : `a` turns into `Ctrl-A` + - Probably caused by the previous option. +1. It does what is expected, like `Ctrl-C` +Steps to reproduce: +1. Run the specified config. +1. Test `Ctrl-C` + `Ctrl-V` using text editors. + - I think that using a graphical one is faster to see it happening. + - Examples + - Atom + - Eclipse + - Kate + - VsCode + - It also occurred using a _pty_ but since I generally use the _middle-mouse-button_ with _ptys_. + - I'm not aware of the frequency that it happens. + - It also occurs with the mouse (`Ctrl-mouseclick`). + - For example: instead of going to a _Firefox_'s tab, it selects it. + +I don't know any other step here, the use case is trivial coding. +Additional information: +- I have already tried to disable "keyboard repeat" in config. + - At first it seems to work but the `Ctrl` key can get stuck like in the description and then I'm unable to get out of it (everything is sent as if it was with `Ctrl`) without pressing `Ctrl`+`ESC`. I have no idea of why. + - The problem seems to occur less frequently. +- It also happened before setting up `qemu-guest-agent`. diff --git a/results/classifier/mode-gemma3:12b/user/456 b/results/classifier/mode-gemma3:12b/user/456 new file mode 100644 index 00000000..d640ba96 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/456 @@ -0,0 +1,31 @@ + + +Qemu User (x86_64) Hangs after futex function not implemented error +Description of problem: +Qemu User hangs on futex call with the following last strace +``` +futex(0x0000004001a01654,FUTEX_PRIVATE_FLAG|FUTEX_UNLOCK_PI,0,NULL,NULL,0) = -1 errno=38 (Function not implemented) +``` +This is the last call until giving a SIGINT with CTRL + C where the following strace is output +``` +futex(0x00000040b0085180,FUTEX_PRIVATE_FLAG|FUTEX_WAIT,2,NULL,NULL,0) = -1 errno=4 (Interrupted system call) +--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL, si_pid=0, si_uid=0} --- + +``` +Steps to reproduce: +1. Install steamcmd https://developer.valvesoftware.com/wiki/SteamCMD +2. In the steamcmd shell install Valheim dedicated server with `app_update 896660` +3. Navigate to the downloaded app `cd ~/Steam/steamapps/common/Valheim\ dedicated\ server/` +4. Run `qemu-x86_64 valheim_server.x86_64` +5. The process hangs as per description. +Additional information: +The issue was originally encountered on a raspberry pi ARM64 host using the ubuntu 5.2.0 version of qemu. Installed cross libararies: +* libc6-amd64-cross +* libgcc-s1-amd64-cross + +It was then replicated on the x86 host fedora with a build of the qemu master branch. +The full qemu -strace output is provided below +[qemu_strace_output.log](/uploads/96e0e31b1e63191a94d73f05023c5173/qemu_strace_output.log) + +The expected output found when running `strace ./valheim_server.x86_64` without qemu on the x86_64 host is attached below +[expected_output.log](/uploads/b3b25618103de8a3b9c0ef227bbffc9c/expected_output.log) diff --git a/results/classifier/mode-gemma3:12b/user/470 b/results/classifier/mode-gemma3:12b/user/470 new file mode 100644 index 00000000..e9ff8cc3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/470 @@ -0,0 +1,3 @@ + + +qemu linux-user requires read permissions on memory passed to syscalls that should only need write access diff --git a/results/classifier/mode-gemma3:12b/user/473 b/results/classifier/mode-gemma3:12b/user/473 new file mode 100644 index 00000000..5d1aefe0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/473 @@ -0,0 +1,3 @@ + + +QEMU 6.0.0 - NSIS installer script issues diff --git a/results/classifier/mode-gemma3:12b/user/48 b/results/classifier/mode-gemma3:12b/user/48 new file mode 100644 index 00000000..55716496 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/48 @@ -0,0 +1,3 @@ + + +Hover effect color for "Full list of releases" button is low contrast diff --git a/results/classifier/mode-gemma3:12b/user/494 b/results/classifier/mode-gemma3:12b/user/494 new file mode 100644 index 00000000..ae688c01 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/494 @@ -0,0 +1,3 @@ + + +cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/mode-gemma3:12b/user/509 b/results/classifier/mode-gemma3:12b/user/509 new file mode 100644 index 00000000..6d499ea3 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/509 @@ -0,0 +1,3 @@ + + +Atomic test-and-set instruction does not work on qemu-user diff --git a/results/classifier/mode-gemma3:12b/user/514 b/results/classifier/mode-gemma3:12b/user/514 new file mode 100644 index 00000000..700cd431 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/514 @@ -0,0 +1,27 @@ + + +MTE reports false positive for "str" instruction with the SP as the base register. +Description of problem: +When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. +Steps to reproduce: +Clang version: clang version 12.0.1. +I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: +``` +0000000000000c14 <test_func>: + c14: a9bc7bfd stp x29, x30, [sp, #-64]! + c18: f9000bf7 str x23, [sp, #16] + ... +``` +Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. +When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": +ESR_EL1=0x96000051. + +According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: +``` +A Tag Unchecked access will be generated for a load or store that uses either of the following: +• A base register only, with the SP as the base register. +• A base register plus immediate offset addressing form, with the SP as the base register. +``` +Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/560 b/results/classifier/mode-gemma3:12b/user/560 new file mode 100644 index 00000000..ffd9b835 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/560 @@ -0,0 +1,3 @@ + + +User-emu documentation mentions inexistent "runtime" downloads diff --git a/results/classifier/mode-gemma3:12b/user/562 b/results/classifier/mode-gemma3:12b/user/562 new file mode 100644 index 00000000..694af37e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/562 @@ -0,0 +1,3 @@ + + +`ShaderTranslator.h` and `ShaderTranslator.cpp` files are missing and are not in ANGLE_ROOT/src/libShaderTranslator diff --git a/results/classifier/mode-gemma3:12b/user/566 b/results/classifier/mode-gemma3:12b/user/566 new file mode 100644 index 00000000..758b2468 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/566 @@ -0,0 +1,3 @@ + + +Fail to build linux-user on Alpine diff --git a/results/classifier/mode-gemma3:12b/user/567376 b/results/classifier/mode-gemma3:12b/user/567376 new file mode 100644 index 00000000..93ba557f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/567376 @@ -0,0 +1,8 @@ + + +qemu-img fails to convert image + +On a Windows XP system and an NTFS drive, using QEMU on Windows Ver 0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU 0.12.3 built locally, when I run the following commands, a dialog is displayed indicating that "qemu-img.exe has encountered a problem and needs to close". + + qemu-img create foo.img 1G + qemu-img convert -O qcow2 foo.img bar.img
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/568053 b/results/classifier/mode-gemma3:12b/user/568053 new file mode 100644 index 00000000..823dd39c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/568053 @@ -0,0 +1,5 @@ + + +requires MSYS coreutils ext sub-package to build on Windows + +When I try to build QEMU on Windows without the MSYS coreutils ext sub-package installed, the build fails because it cannot find dd.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/577 b/results/classifier/mode-gemma3:12b/user/577 new file mode 100644 index 00000000..7d365639 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/577 @@ -0,0 +1,27 @@ + + +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/mode-gemma3:12b/user/578 b/results/classifier/mode-gemma3:12b/user/578 new file mode 100644 index 00000000..615b3708 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/578 @@ -0,0 +1,32 @@ + + +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/mode-gemma3:12b/user/579 b/results/classifier/mode-gemma3:12b/user/579 new file mode 100644 index 00000000..01e18f21 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/579 @@ -0,0 +1,52 @@ + + +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/mode-gemma3:12b/user/582 b/results/classifier/mode-gemma3:12b/user/582 new file mode 100644 index 00000000..d89aa123 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/582 @@ -0,0 +1,3 @@ + + +Possible regression in qemu-user-static v5.7 from Fedora 34 Repo? diff --git a/results/classifier/mode-gemma3:12b/user/590 b/results/classifier/mode-gemma3:12b/user/590 new file mode 100644 index 00000000..5c6cadda --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/590 @@ -0,0 +1,3 @@ + + +NSIS Windows installer generator warnings when cross-building on MinGW diff --git a/results/classifier/mode-gemma3:12b/user/601 b/results/classifier/mode-gemma3:12b/user/601 new file mode 100644 index 00000000..7fafda10 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/601 @@ -0,0 +1,22 @@ + + +import tensorflow causes qemu: uncaught target signal 6 (Aborted) - core dumped +Description of problem: +Crashes when importing tensorflow in Docker container under --platorm linux/amd64 on M1 Mac +``` +2021-09-06 13:35:24.435613: F tensorflow/core/lib/monitoring/sampler.cc:42] Check failed: bucket_limits_[i] > bucket_limits_[i - 1] (0 vs. 10) +qemu: uncaught target signal 6 (Aborted) - core dumped +``` +Steps to reproduce: +See https://gitlab.com/ryan-feather/docker-tensorflow-qemu-bug/ for Dockerfile and description of steps repeating here. +1. Using the dockerfile +``` +FROM python:3.9-buster +RUN pip install tensorflow==2.6.0 + +``` +2. `docker buildx build --iidfile build.id --platform linux/amd64 . --progress=plain` +3. ``` docker run --platform linux/amd64 `cat build.id` python -c "import tensorflow"``` +Additional information: +See +https://github.com/docker/for-mac/issues/5342 where the Docker team suggests this is a qemu bug. I couldn't find where anyone had opened one of these here, so hopefully this isn't a duplicate. diff --git a/results/classifier/mode-gemma3:12b/user/602 b/results/classifier/mode-gemma3:12b/user/602 new file mode 100644 index 00000000..d68ec74e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/602 @@ -0,0 +1,15 @@ + + +Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation +Description of problem: +In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests. E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI. +Steps to reproduce: +1. https://cirrus-ci.com/task/5914289870471168 +Additional information: +The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014). + +The fix is something like: + +``` +__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno); +``` diff --git a/results/classifier/mode-gemma3:12b/user/616 b/results/classifier/mode-gemma3:12b/user/616 new file mode 100644 index 00000000..4bd3bac2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/616 @@ -0,0 +1,109 @@ + + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/mode-gemma3:12b/user/618 b/results/classifier/mode-gemma3:12b/user/618 new file mode 100644 index 00000000..ef3139be --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/618 @@ -0,0 +1,97 @@ + + +overflow condition code determined incorrectly after subtraction on s390x +Description of problem: +Paul Eggert found this bug, just by taking a look at the file `qemu/target/s390x/tcg/cc_helper.c`. + +The following program +[foo.c](/uploads/c1f425684fd661c4437950d7d8ddf31d/foo.c) +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int a1 = 0; +int b1 = -2147483648; +long long a2 = 0L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", ! overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", ! overflow_64 (a, b)); + } +} +``` +should print +``` +a = 0x0, b = 0x80000000 +no_overflow = 0 +a = 0x0, b = 0x8000000000000000 +no_overflow = 0 +``` +However, when compiled as an s390x program and executed through qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the 'o' (overflow / ones) condition code: +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + sgr %r1,%r3 ;; subtract b from a + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +The condition code and the overflow bit are defined in the z/Architecture Principles of Operation (POP) http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf page 7-5 / 7-6 / 7-388 : "In mathematical terms, signed addition and subtraction produce a fixed-point overflow when the result is outside the range of representation for signed binary integers." + +I conclude that the bug is in QEMU: QEMU does not set the overflow condition code correctly. +Steps to reproduce: +[foo.static.s390x](/uploads/e4b79b019db590f3a4b13cac41e57ba6/foo.static.s390x) +(the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +The attached patch fixes it. +[0002-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/8d414f84fe0ed36bf07bd28f5e7836ab/0002-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/mode-gemma3:12b/user/619 b/results/classifier/mode-gemma3:12b/user/619 new file mode 100644 index 00000000..074eefe4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/619 @@ -0,0 +1,3 @@ + + +Move TCGCPUOps::fake_user_exception() to linux-user/i386/cpu_loop.c diff --git a/results/classifier/mode-gemma3:12b/user/625 b/results/classifier/mode-gemma3:12b/user/625 new file mode 100644 index 00000000..fa25ec92 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/625 @@ -0,0 +1,25 @@ + + +qemu-hppa floating point POWER function is incorrect +Description of problem: +The floating point power function produces incorrect values, and possibly stack misshapes as well. +Steps to reproduce: +1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static +2. $ qemu-hppa pow +3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45 +Additional information: +Example C source to reproduce, pow.c: +``` +#include <stdio.h> +#include <math.h> +int main() +{ + double base, expo, res; + base=10.0; + expo=6.0; + // res sould be 1e+6 + res = pow(base, expo); + printf("%.1lf^%.1lf = %.2lf\n", base, expo, res); + return 0; +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/627 b/results/classifier/mode-gemma3:12b/user/627 new file mode 100644 index 00000000..dbf79d50 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/627 @@ -0,0 +1,9 @@ + + +VI.EXE crashes on start under QEMU; works under BOCHS +Description of problem: +vi.exe hangs on startup; can be verified to work in bochs +Steps to reproduce: +1. Run vi.exe from DOS prompt; hang is evident immediately as ~ ~ ~ ~ doesn't show up +Additional information: +Actual [vi.exe](/uploads/d77076b8187489253c6ad8f1ab3ec247/vi.exe) attached; it's ridiculously old; the kind of thing that belongs on archive.org; I think I actually own this copy program by inheritance; but if the copyright holder objects we'll have to take it down again. :( diff --git a/results/classifier/mode-gemma3:12b/user/633 b/results/classifier/mode-gemma3:12b/user/633 new file mode 100644 index 00000000..db470ee0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/633 @@ -0,0 +1,34 @@ + + +i686-arm-user-static - Allocating guest commpage: Operation not permitted +Steps to reproduce: +1. Run the test case linked earlier. +2. You'll see `apt update` failing: + +``` +Get:1 http://archive.raspberrypi.org/debian buster InRelease [32.6 kB] +Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB] +Err:1 http://archive.raspberrypi.org/debian buster InRelease + At least one invalid signature was encountered. +Err:2 http://raspbian.raspberrypi.org/raspbian buster InRelease + At least one invalid signature was encountered. +Reading package lists... Done +W: GPG error: http://archive.raspberrypi.org/debian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://archive.raspberrypi.org/debian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +W: GPG error: http://raspbian.raspberrypi.org/raspbian buster InRelease: At least one invalid signature was encountered. +E: The repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' is not signed. +N: Updating from such a repository can't be done securely, and is therefore disabled by default. +N: See apt-secure(8) manpage for repository creation and user configuration details. +``` +Additional information: +Setting `sysctl vm.mmap_min_addr=53248` makes it work (as opposed to the system default of 65536). + +Bisecting the bug linked earlier also breaks this in a slightly different way. Everything works at 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1. After that, apt update appears to work, but the package lists end up empty, so nothing can be installed. Then after 975ac4559c4c00010e05f7a3e782eeb9497837ea, the output is as provided above. + +apt launches /usr/lib/apt/methods/gpgv and passes it some commands through stdin. gpgv launches /usr/bin/apt-key, which fails with `Allocating guest commpage: Operation not permitted`. Running gpgv directly and sending the same commands works without any issues. The problem only occurs when gpgv is run through apt. (I don't meant the normal system gpgv binary, but the transport method binary that comes with apt) + +Getting any output is tricky because by the time apt-key is launched, gpgv redirects stdout and stderr to /dev/null and communication takes place through fd 3. https://salsa.debian.org/apt-team/apt/-/blob/2.2.4/apt-pkg/contrib/gpgv.cc#L355 https://salsa.debian.org/apt-team/apt/-/blob/main/methods/gpgv.cc#L186 + +I had to do some ugly things with different versions of qemu and wrapper scripts to see the commpage error, but hopefully there's enough information provided here that it won't be necessary. diff --git a/results/classifier/mode-gemma3:12b/user/645662 b/results/classifier/mode-gemma3:12b/user/645662 new file mode 100644 index 00000000..cf023800 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/645662 @@ -0,0 +1,42 @@ + + +QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit + +When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)), +gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu, +3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources +on Debian Lenny with kernel 2.6.34.6 from kernel.org, gcc (Debian 4.3.2-1.1) 4.3. + +Regression testing errors: + +test_cmath +test test_cmath failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in + self.fail(error_message) +AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0)) +Expected: complex(3.141592653589793, -2.1073424255447014e-08) +Received: complex(3.141592653589793, -2.1073424338879928e-08) +Received value insufficiently close to expected value. + + +test_float +test test_float failed -- Traceback (most recent call last): + File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in + self.assertEqual(s, repr(float(s))) +AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25' + + +test_math +test test_math failed -- multiple errors occurred; run in verbose mode for deta + +=> + +runtests.sh -v test_math + +le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math +test_math BAD + 1 BAD + 0 GOOD + 0 SKIPPED + 1 total +le01:~/tools/python3/Python-3.1.2#
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/654 b/results/classifier/mode-gemma3:12b/user/654 new file mode 100644 index 00000000..964a6cbc --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/654 @@ -0,0 +1,25 @@ + + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/mode-gemma3:12b/user/660 b/results/classifier/mode-gemma3:12b/user/660 new file mode 100644 index 00000000..ac7a84bd --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/660 @@ -0,0 +1,11 @@ + + +User emulation does not use host GPU +Description of problem: + +Steps to reproduce: +1. Make a Arch Linux chroot (though any Linux system should work) on Linux +2. run `glxinfo | grep OpenGL +3. It's using llvmpipe, not whatever GPU/driver that the hosts use +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/667791 b/results/classifier/mode-gemma3:12b/user/667791 new file mode 100644 index 00000000..79e33187 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/667791 @@ -0,0 +1,41 @@ + + +Cygwin build fails due to ui/vnc-etc-tight.c + +Configure: +./configure \ +--prefix="./install/bin/" \ +--interp-prefix="./install/bin-%M/" \ +--cc="gcc -mno-cygwin" \ +--host-cc="gcc" \ +--disable-sdl \ +--enable-system \ +--disable-user \ +--disable-linux-user \ +--disable-darwin-user \ +--disable-bsd-user \ +--disable-xen \ +--disable-brlapi \ +--disable-vnc-tls \ +--disable-vnc-sasl \ +--disable-vnc-jpeg \ +--disable-vnc-png \ +--disable-vnc-thread \ +--disable-curses \ +--disable-curl \ +--disable-bluez \ +--disable-kvm \ +--disable-nptl \ +--disable-vde \ +--disable-vhost-net + +Versions of software +Cygwin 1.7 +GNU Make 3.81 +GCC 3.4.4 (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a) +QEMU 0.13.0 + +Result: +Function tight_detect_smooth_image24(...) uses "uint" type, that appears to be not defined in this scope. Prepending this function with +typedef unsigned int uint; +fixes build.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/682326 b/results/classifier/mode-gemma3:12b/user/682326 new file mode 100644 index 00000000..faa83b5a --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/682326 @@ -0,0 +1,13 @@ + + +linux-user/mmap exhaustion + +Currently when executing a linux-user target, mmap.c is in use- the model it uses internally for figuring out what the mmap address actually should be basically is an accumulator, every mmap invocation (regardless of munmap's that cleared the previous usage) is center on the next page. + +The end result of this is that it'll burn it's way through the space soon enough, especially if it's a 64bit host w/ a 32bit target- the host starts giving back 64bit addresses and the emulated mmap falls over after failed attempts at a low MAP_FIXED range. + +Where this becomes problematic is that glibc's FILE internals mmap a *lot*- once per handle. Any long running process can hit this wall- rpmbuild unfortunately is pretty loose in it's FILE creation/usage, so it hits the wall surprisingly fast- at least on an opensuse 11.2 system w/ mmap_min_addr of 65536 (their default), building qt reliably hits that exhaustion during packaging. + +Attached is basically, a hack- but one that works surprisingly well and at least for meego building via qemu-arm, eliminates the failure scenario I've described above. It doesn't remove the exhaustion as much as push it a fair bit back, although there are still a couple of ways to trigger it (http://bugs.meego.com/show_bug.cgi?id=10526 is the only remaining example I'm aware of). + +This patch simply checks to see if upon an actual, host level munmap, if the ending point of the munmap is where we'd allocate from next- if so, it shifts the starting point back to the (now) unmap'd start, reusing the space. Rebuilding meego a couple of times over, thus far I've not managed to flush out any failures that point at this specific patch, so... it looks like it's doing the trick- that said the lack of a g2h/h2g in the calculation still seems questionable to me.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/690 b/results/classifier/mode-gemma3:12b/user/690 new file mode 100644 index 00000000..7ac2ac8f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/690 @@ -0,0 +1,21 @@ + + +32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error) +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago. + +Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters. + +The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value: +``` +[0 ... 53248] - No error at all +[53249 ... 61440] - Cannot allocate memory +[61441 ... 65536 and higher] - Operation not permitted +``` +Steps to reproduce: +1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz) +2. `$ make # will build the docker container` +3. `$ make run # will enter the container` +4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh` +Additional information: +A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748 diff --git a/results/classifier/mode-gemma3:12b/user/695 b/results/classifier/mode-gemma3:12b/user/695 new file mode 100644 index 00000000..c8cff5ce --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/695 @@ -0,0 +1,3 @@ + + +MIPS: nanomips p32 ABI not supported diff --git a/results/classifier/mode-gemma3:12b/user/696834 b/results/classifier/mode-gemma3:12b/user/696834 new file mode 100644 index 00000000..e3306681 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/696834 @@ -0,0 +1,33 @@ + + +FP exception reporting not working on NetBSD host + +I recognize that NetBSD is not one of the officially supported host OS. However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and works quite well. Well, with one exception (pun intended): It seems that Floating Point exceptions don't get reported properly. + +The following code-snippet demonstrates the problem: + + +volatile int flt_signal = 0; + +static sigjmp_buf sigfpe_flt_env; +static void +sigfpe_flt_action(int signo, siginfo_t *info, void *ptr) +{ + flt_signal++; +} + +void trigger(void) +{ + struct sigaction sa; + double d = strtod("0", NULL); + + if (sigsetjmp(sigfpe_flt_env, 0) == 0) { + sa.sa_flags = SA_SIGINFO; + sa.sa_sigaction = sigfpe_flt_action; + sigemptyset(&sa.sa_mask); + sigaction(SIGFPE, &sa, NULL); + fpsetmask(FP_X_INV|FP_X_DZ|FP_X_OFL|FP_X_UFL|FP_X_IMP); + printf("%g\n", 1 / d); + } + printf("FPE signal handler invoked %d times.\n"); +}
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/697 b/results/classifier/mode-gemma3:12b/user/697 new file mode 100644 index 00000000..4d92a88f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/697 @@ -0,0 +1,3 @@ + + +linux-user create default CPU type before parsing the ELF header for specific CPU type diff --git a/results/classifier/mode-gemma3:12b/user/698 b/results/classifier/mode-gemma3:12b/user/698 new file mode 100644 index 00000000..c507480d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/698 @@ -0,0 +1,360 @@ + + +linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map +Description of problem: +QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor. + +The following source file: + +```c +#include <fcntl.h> +#include <inttypes.h> +#include <stdbool.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/wait.h> + +static const char string[] = "Hello, world!\n"; + +static bool copy_to_stdout(const char *path) +{ + bool success = false; + + int fd = open(path, O_RDONLY); + if (fd < 0) { + perror("open"); + return false; + } + + char buf[16 * 1024]; + while (true) { + ssize_t bytes_read = read(fd, buf, sizeof(buf)); + if (bytes_read == 0) { + success = true; + goto out; + } else if (bytes_read < 0) { + perror("read"); + goto out; + } + ssize_t bytes_written = 0; + while (bytes_written < bytes_read) { + ssize_t ret = write(STDOUT_FILENO, buf + bytes_written, + bytes_read - bytes_written); + if (ret < 0) { + perror("write"); + goto out; + } + bytes_written += ret; + } + } + +out: + close(fd); + return success; +} + +static bool dump_maps(void) +{ + printf("Maps read by self:\n"); + fflush(stdout); + if (!copy_to_stdout("/proc/self/maps")) + return false; + + printf("\nMaps read by child process:\n"); + fflush(stdout); + pid_t pid = fork(); + if (pid < 0) { + perror("fork"); + return false; + } + if (pid == 0) { + char parent_maps[32]; + sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid()); + if (copy_to_stdout(parent_maps)) + _exit(EXIT_SUCCESS); + else + _exit(EXIT_FAILURE); + } + int wstatus; + if (waitpid(pid, &wstatus, 0) < 0 || + !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS) + return false; + + printf("\n"); + return true; +} + +int main(void) +{ + if (!dump_maps()) + return EXIT_FAILURE; + + int fd = open("/proc/self/mem", O_RDONLY); + if (fd < 0) { + perror("open: /proc/self/mem"); + return EXIT_FAILURE; + } + + char buf[sizeof(string)]; + printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n", + sizeof(buf), string, (uintptr_t)string, buf, + (unsigned int)getpid()); + fflush(stdout); + + if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) { + perror("pread: /proc/self/mem"); + return EXIT_FAILURE; + } + + if (memcmp(buf, string, sizeof(buf)) != 0) { + fprintf(stderr, "buffer doesn't match\n"); + return EXIT_FAILURE; + } + + return EXIT_SUCCESS; +} +``` + +when compiled for 32-bit ARM produces the following output: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +3ffff000-40000000 r-xp 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00010000-00020000 ---p 00000000 00:00 0 +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +0008c000-0009b000 ---p 00000000 00:00 0 +0009b000-0009c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +0009c000-0009d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +0009d000-000c0000 rw-p 00000000 00:00 0 +000c0000-4000f000 ---p 00000000 00:00 0 +4000f000-40010000 r--p 00000000 00:00 0 +40010000-40011000 ---p 00000000 00:00 0 +40011000-40811000 rw-p 00000000 00:00 0 +40811000-100000000 ---p 00000000 00:00 0 +100000000-100001000 r--p 00000000 00:00 0 +5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028 /home/osandov/repos/qemu/build/qemu-arm +5636ddff3000-5636de010000 rw-p 00000000 00:00 0 +5636df67b000-5636df80c000 rw-p 00000000 00:00 0 [heap] +7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 +7f300ffff000-7f3010000000 ---p 00000000 00:00 0 +7f3010000000-7f3010021000 rw-p 00000000 00:00 0 +7f3010021000-7f3014000000 ---p 00000000 00:00 0 +7f3017119000-7f301719a000 rw-p 00000000 00:00 0 +7f301719a000-7f301719b000 ---p 00000000 00:00 0 +7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 +7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771 /usr/lib/libffi.so.8.1.0 +7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709 /usr/lib/libgmp.so.10.4.1 +7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144 /usr/lib/libhogweed.so.6.4 +7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 +7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147 /usr/lib/libnettle.so.8.4 +7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729 /usr/lib/libtasn1.so.6.6.1 +7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656 /usr/lib/libunistring.so.2.1.0 +7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638 /usr/lib/libidn2.so.0.3.7 +7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986 /usr/lib/libp11-kit.so.0.3.0 +7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813 /usr/lib/libdl-2.33.so +7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 +7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974 /usr/lib/libpcre.so.1.2.13 +7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806 /usr/lib/libc-2.33.so +7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806 /usr/lib/libc-2.33.so +7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806 /usr/lib/libc-2.33.so +7f3018011000-7f301801a000 rw-p 00000000 00:00 0 +7f301801a000-7f3018021000 r--p 00000000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018030000-7f3018034000 r--p 00016000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847 /usr/lib/libpthread-2.33.so +7f3018037000-7f301803b000 rw-p 00000000 00:00 0 +7f301803b000-7f301803e000 r--p 00000000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018050000-7f3018053000 r--p 00015000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018053000-7f3018054000 ---p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018054000-7f3018055000 r--p 00018000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528 /usr/lib/libgcc_s.so.1 +7f3018056000-7f3018065000 r--p 00000000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819 /usr/lib/libm-2.33.so +7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018197000-7f3018198000 ---p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018198000-7f3018199000 r--p 00141000 00:19 2549819 /usr/lib/libm-2.33.so +7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819 /usr/lib/libm-2.33.so +7f301819a000-7f3018233000 r--p 00000000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f3018333000-7f301839f000 r--p 00199000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558 /usr/lib/libstdc++.so.6.0.29 +7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 +7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f3018508000-7f301859d000 r--p 00156000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924 /usr/lib/libgnutls.so.30.30.0 +7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 +7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215 /usr/lib/libgmodule-2.0.so.0.7000.0 +7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212 /usr/lib/libglib-2.0.so.0.7000.0 +7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 +7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204 /usr/lib/liburing.so.2.1.0 +7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855 /usr/lib/librt-2.33.so +7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018700000-7f3018701000 r--p 00008000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855 /usr/lib/librt-2.33.so +7f3018702000-7f3018705000 r--p 00000000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018705000-7f3018713000 r-xp 00003000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018713000-7f3018719000 r--p 00011000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f3018719000-7f301871a000 ---p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871a000-7f301871b000 r--p 00017000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871b000-7f301871c000 rw-p 00018000 00:19 15838 /usr/lib/libz.so.1.2.11 +7f301871c000-7f301871e000 rw-p 00000000 00:00 0 +7f301871e000-7f301871f000 r--p 00000000 00:19 2549795 /usr/lib/ld-2.33.so +7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795 /usr/lib/ld-2.33.so +7f3018743000-7f301874c000 r--p 00025000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795 /usr/lib/ld-2.33.so +7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795 /usr/lib/ld-2.33.so +7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0 [stack] +7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0 [vvar] +7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331 +buffer doesn't match +``` + +The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping: + +``` +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +``` + +but on the host, it's mapped differently: + +``` +00020000-0008c000 r--p 00000000 00:19 8275924 /home/osandov/repro +``` + +When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all: + +``` +Maps read by self: +10000-7c000 r-xp 00000000 00:19 8275924 /home/osandov/repro +7c000-8b000 ---p 00000000 00:00 0 +8b000-8c000 r--p 0006b000 00:19 8275924 /home/osandov/repro +8c000-8d000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +8d000-b0000 rw-p 00000000 00:00 0 +40000000-40001000 ---p 00000000 00:00 0 +40001000-40801000 rw-p 00000000 00:00 0 [stack] + +Maps read by child process: +00400000-00401000 r--p 00000000 00:19 297 /usr/bin/qemu-arm-static +00401000-00769000 r-xp 00001000 00:19 297 /usr/bin/qemu-arm-static +00769000-00abe000 r--p 00369000 00:19 297 /usr/bin/qemu-arm-static +00abe000-00c58000 r--p 006bd000 00:19 297 /usr/bin/qemu-arm-static +00c58000-00cd3000 rw-p 00857000 00:19 297 /usr/bin/qemu-arm-static +00cd3000-00cf7000 rw-p 00000000 00:00 0 +0253c000-0268e000 rw-p 00000000 00:00 0 [heap] +42645000-42655000 ---p 00000000 00:00 0 +42655000-426c1000 r--p 00000000 00:19 8275924 /home/osandov/repro +426c1000-426d0000 ---p 00000000 00:00 0 +426d0000-426d1000 r--p 0006b000 00:19 8275924 /home/osandov/repro +426d1000-426d2000 rw-p 0006c000 00:19 8275924 /home/osandov/repro +426d2000-426f5000 rw-p 00000000 00:00 0 +426f5000-82645000 ---p 00000000 00:00 0 +82645000-82646000 ---p 00000000 00:00 0 +82646000-82e46000 rw-p 00000000 00:00 0 +82e46000-142635000 ---p 00000000 00:00 0 +142635000-142636000 r--p 00000000 00:00 0 +7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 +7f558bfff000-7f558c000000 ---p 00000000 00:00 0 +7f558c000000-7f558c021000 rw-p 00000000 00:00 0 +7f558c021000-7f5590000000 ---p 00000000 00:00 0 +7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 +7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 +7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 +7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0 [stack] +7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0 [vvar] +7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] + +Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443 +pread: /proc/self/mem: Input/output error +``` +Steps to reproduce: +1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro). +2. Run `qemu-arm ./repro`. +Additional information: +I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126. + +This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue. diff --git a/results/classifier/mode-gemma3:12b/user/701 b/results/classifier/mode-gemma3:12b/user/701 new file mode 100644 index 00000000..f7565a87 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/701 @@ -0,0 +1,3 @@ + + +Setup a gitlab shared runner for linux-user testing diff --git a/results/classifier/mode-gemma3:12b/user/704 b/results/classifier/mode-gemma3:12b/user/704 new file mode 100644 index 00000000..a0c5eefe --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/704 @@ -0,0 +1,3 @@ + + +linux-user: misaligned address for type 'struct linux_dirent64' diff --git a/results/classifier/mode-gemma3:12b/user/714 b/results/classifier/mode-gemma3:12b/user/714 new file mode 100644 index 00000000..cad3af50 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/714 @@ -0,0 +1,45 @@ + + +Command line arguments are not passed correctly with user-space semihosting +Description of problem: +The emulated process always receives a value of 1 for `argc`, with `argv[0]` returning seemingly random characters (in Ubuntu packaged qemu 5.2), but correlating with command-line input (output below from master built qemu 6.1): +``` +$ qemu-arm -cpu cortex-m7 ./a.out 123 test +argc: 1 +argv: + - @@@ + +$ qemu-arm -cpu cortex-m7 ./a.out +argc: 1 +argv: + [0] @ +``` +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> + +int main(int argc, char* argv[]) { + std::cout << "argc: " << argc << "\n"; + std::cout << "argv: \n"; + + for (int i = 0; i < argc; i++) + std::cout << " [" << i << "] " << argv[i] << "\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 ./a.out +``` diff --git a/results/classifier/mode-gemma3:12b/user/729 b/results/classifier/mode-gemma3:12b/user/729 new file mode 100644 index 00000000..7cd52992 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/729 @@ -0,0 +1,36 @@ + + +Environment variables are not passed with user-space semihosting +Description of problem: +Environment variables are not passed to the emulated process, either inherited (as I might expect it to work in user-space?) or by specifying the values through the QEMU command-line. Note that setting the environment variable from within the app before calling `getenv` does work, so it isn't just a case of some system no-ops for the platform. +Steps to reproduce: +1. Compile the following program with [ARM embedded toolchain](https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads): +```cpp +#include <iostream> +#include <cstdlib> + +int main(int argc, char* argv[]) { + char* env = std::getenv("TEST"); + if (env) + std::cout << "Env TEST: " << env << "\n"; + else + std::cout << "Env TEST not set.\n"; + return 0; +} +``` + +``` +$ $CXX --version +arm-none-eabi-g++ (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release) +Copyright (C) 2020 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +$ $CXX main.cpp --specs=rdimon.specs -mcpu=cortex-m7 +``` + +2. Run in user-space (semihosted): +``` +$ qemu-arm -cpu cortex-m7 -E TEST=val123 ./a.out +Env TEST not set. +``` diff --git a/results/classifier/mode-gemma3:12b/user/730 b/results/classifier/mode-gemma3:12b/user/730 new file mode 100644 index 00000000..afdcf2d8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/730 @@ -0,0 +1,3 @@ + + +test-thread-breakpoint fails with some gdb version diff --git a/results/classifier/mode-gemma3:12b/user/739785 b/results/classifier/mode-gemma3:12b/user/739785 new file mode 100644 index 00000000..cce130ef --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/739785 @@ -0,0 +1,36 @@ + + +qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Good time of day everybody, + +I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. + +1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ +2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +./configure --static --disable-blobs --disable-system --target-list=i386-linux-user +make + +3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. +uname -a +Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + +4. Added the following options into /etc/rc.local +/sbin/modprobe binfmt_misc +/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + +6.Now i chroot into /i386 and I get this: +[root@Plugbox i386]# chroot . +[II aI hnve ao n@P /]# pacman -Suy +bash: fork: Invalid argument + +7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: +[root@Plugbox linux-user-test-0.3]# make +./qemu-linux-user.sh +[qemu-i386] +../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile +BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +make: *** [test] Error 127
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/754635 b/results/classifier/mode-gemma3:12b/user/754635 new file mode 100644 index 00000000..6d4d0ef5 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/754635 @@ -0,0 +1,57 @@ + + +-d option outs wrong info about sections + +For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file: +$ cat /tmp/qemu.log | grep -A7 guest +Relocating guest address space from 0x08048000 to 0x8048000 +guest_base 0x0 +start end size prot +00048000-0005f000 00017000 r-x +0005f000-00069000 0000a000 rw- +00040000-00041000 00001000 --- +00041000-00041800 00000800 rw- +00041800-0005d800 0001c000 r-x +0005d800-0005f800 00002000 rw- + +But such command in 0.12.5 release outs this: +$ cat /tmp/qemu.log | grep -A7 guest +guest_base 0x0 +start end size prot +00f38000-00f39000 00001000 --- +08048000-0805f000 00017000 r-x +0805f000-08061000 00002000 rw- +40000000-40080000 00080000 rw- +40080000-40081000 00001000 --- +40081000-4009d000 0001c000 r-x + +It looks correct. +I received such differences and with qemu-microblaze. + +After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c: +in 0.12.5: +end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS); + +in 0.14.0: +int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, + +V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22 + +I make this changes: +$ diff -up qemu-0.14.0/exec.c exec.c +--- qemu-0.14.0/exec.c 2011-04-08 17:26:00.524464002 +0400 ++++ exec.c 2011-04-08 17:26:09.800464003 +0400 +@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk + data.prot = 0; + + for (i = 0; i < V_L1_SIZE; i++) { +- int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT, ++ int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS), + V_L1_SHIFT / L2_BITS - 1, l1_map + i); + if (rc != 0) { + return rc; + +After this outputs looks correct. + +I don't know code base good, and think what may to do more general corrections. +Host system: linux i386
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/779151 b/results/classifier/mode-gemma3:12b/user/779151 new file mode 100644 index 00000000..fb055761 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/779151 @@ -0,0 +1,18 @@ + + +qemu-nbd crash during using with chroot + +I use qemu-nbd to mount my image. And after some times, qemu-nbd crashes and so the chroot freeze. + +ps aux | grep qemu : +root 2223 0.0 0.0 9776 548 ? Ss 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2224 0.0 0.0 10800 544 ? D 18:03 0:00 qemu-nbd --connect=/dev/nbd0 /chroots/test/virtual.img +root 2227 0.0 0.0 0 0 ? Z 18:03 0:00 [qemu-nbd] <defunct> +root 2357 0.0 0.0 5212 768 pts/0 D+ 18:07 0:00 grep qemu + +mount : +/dev/nbd0p1 on /chroots/test/amd64 type ext3 (rw,errors=remount-ro,commit=0) +/dev on /chroots/test/amd64/dev type devtmpfs (rw,mode=0755) +/dev/pts on /chroots/test/amd64/dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) +/proc on /chroots/test/amd64/proc type proc (rw) +/sys on /chroots/test/amd64/sys type sysfs (rw,noexec,nosuid,nodev)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/788881 b/results/classifier/mode-gemma3:12b/user/788881 new file mode 100644 index 00000000..14835ce4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/788881 @@ -0,0 +1,18 @@ + + +i386-bsd-user and similar don't build on Mac OS X + +0.14.1 crashes on Mac OS X 64bit with some targets (*-bsd-user): + + CC i386-bsd-user/cpu-exec.o +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c: In function ‘cpu_x86_signal_handler’: +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: ‘REG_RIP’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: (Each undeclared identifier is reported only once +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:895: error: for each function it appears in.) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:897: error: ‘REG_TRAPNO’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: dereferencing pointer to incomplete type +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:898: error: ‘REG_ERR’ undeclared (first use in this function) +/Users/michael/Downloads/qemu-0.14.1/cpu-exec.c:899: error: dereferencing pointer to incomplete type +make[1]: *** [cpu-exec.o] Error 1
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/796480 b/results/classifier/mode-gemma3:12b/user/796480 new file mode 100644 index 00000000..62028ecb --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/796480 @@ -0,0 +1,47 @@ + + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git)
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/805 b/results/classifier/mode-gemma3:12b/user/805 new file mode 100644 index 00000000..2a4e959c --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/805 @@ -0,0 +1,16 @@ + + +qemu-hexagon: [binary]: Error mapping file: Invalid argument +Description of problem: +Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error: +`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument` +Steps to reproduce: +``` +./qemu-hexagon <hexagon-binary> +qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument +``` +Additional information: +A similar problem has been reported on the mailing list: +https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html + +Unfortunately without a solution. diff --git a/results/classifier/mode-gemma3:12b/user/817 b/results/classifier/mode-gemma3:12b/user/817 new file mode 100644 index 00000000..18d8865f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/817 @@ -0,0 +1,3 @@ + + +linux-user: waitid leaves target siginfo uninitialized when info.si_pid is zero diff --git a/results/classifier/mode-gemma3:12b/user/824 b/results/classifier/mode-gemma3:12b/user/824 new file mode 100644 index 00000000..038fdaf6 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/824 @@ -0,0 +1,14 @@ + + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/mode-gemma3:12b/user/829 b/results/classifier/mode-gemma3:12b/user/829 new file mode 100644 index 00000000..4120e1e0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/829 @@ -0,0 +1,16 @@ + + +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/mode-gemma3:12b/user/833 b/results/classifier/mode-gemma3:12b/user/833 new file mode 100644 index 00000000..50d560b8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/833 @@ -0,0 +1,44 @@ + + +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/mode-gemma3:12b/user/834 b/results/classifier/mode-gemma3:12b/user/834 new file mode 100644 index 00000000..4775cb8d --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/834 @@ -0,0 +1,61 @@ + + +linux-user: fails to deliver signals raised during pselect +Description of problem: +When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`. + +Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/) +Steps to reproduce: +A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite). + +```C +#include <stdio.h> +#include <unistd.h> +#include <signal.h> +#include <sys/select.h> + +static void handler(int sig) +{ + puts("SIGNAL"); +} + +int main(int argc, char *argv[]) +{ + struct sigaction sa; + + fd_set rfds; + sigset_t emptyset, blockset; + + sigemptyset (&blockset); + sigemptyset (&emptyset); + sigaddset (&blockset, SIGUSR1); + + sa.sa_handler = handler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + sigaction(SIGUSR1, &sa, NULL); + + sigprocmask (SIG_BLOCK, &blockset, NULL); + + FD_ZERO(&rfds); + + while(1) { + pselect(0, &rfds, NULL, NULL, NULL, &emptyset); + } + + return 0; +} +``` + +Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`: + +``` +$ ./a.out & +[1] 1683587 +$ kill -USR1 %1 +$ SIGNAL +``` + +When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered). + +The pselect call itself _is_ interrupted, but the signal goes missing. diff --git a/results/classifier/mode-gemma3:12b/user/835 b/results/classifier/mode-gemma3:12b/user/835 new file mode 100644 index 00000000..68739122 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/835 @@ -0,0 +1,11 @@ + + +SDL display does not handle ps2 relative packets +Description of problem: +The main problem: while tracing relative events input_event_rel all mouse events are positive and seems to be the absolute x and y mouse position. When that happens ps2 sends a +x -y of a full 127 count. +Steps to reproduce: +1. Trace input_event_rel +2. Observe that when moving the mouse the trace always shows positive values, that doesn't depend on what direction you move the mouse +3. Observe that the xrel and yrel is more like absolute positions +Additional information: +I noticed searching on sdl2 docs and some issues related to SDL2 mouse events that when you do not specify SDL_HINT_MOUSE_RELATIVE_MODE_WARP weird things happens, i tried adding SDL_SetHint(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1"); at the end of the sdl2 init function and the mouse events started to show normal values. I'm not sure if that's the correct way to solve the bug, but it seems to be. diff --git a/results/classifier/mode-gemma3:12b/user/836 b/results/classifier/mode-gemma3:12b/user/836 new file mode 100644 index 00000000..54746b18 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/836 @@ -0,0 +1,87 @@ + + +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/mode-gemma3:12b/user/837 b/results/classifier/mode-gemma3:12b/user/837 new file mode 100644 index 00000000..73249b93 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/837 @@ -0,0 +1,32 @@ + + +x86 user: icebp/int1 raises wrong signal +Description of problem: +This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. + +Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. + +This also happens on an AArch64 host. +``` +$ ./icebp +Trace/breakpoint trap +$ qemu-x86_64 ./icebp +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Steps to reproduce: +1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 +``` + .globl _start +_start: + .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it +#ifdef __x86_64__ + mov $60, %eax + syscall +#else + mov $1, %eax + int $0x80 +#endif +``` +2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message +3. Run on qemu-user. Notice how it raises `SIGILL`. diff --git a/results/classifier/mode-gemma3:12b/user/852 b/results/classifier/mode-gemma3:12b/user/852 new file mode 100644 index 00000000..4776b036 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/852 @@ -0,0 +1,33 @@ + + +ppc64le: possible SIMD issue casting double to int +Description of problem: +Working with numpy in a ppc64le VM, I ran into a strange double -to casting issue, specifically when casting an array of 1.0 values to 1 values. The numpy folks guided me to a small reproducible test case. + +The attached [convert.c](/uploads/2dd7936f4defccf816ffee7c7c002e77/convert.c) creates double and int arrays of length `1 <= n <= 16`. The double array is filled with the value 1.0, and both arrays are passed to a function that converts the value. + +With `-O2`, output is as expected (truncated here): + +``` +i = 1: 1 +i = 2: 1 1 +i = 3: 1 1 1 +i = 4: 1 1 1 1 +i = 5: 1 1 1 1 1 +i = 6: 1 1 1 1 1 1 +``` + +With `-O3`, all values that fit into blocks of four become zero: +``` +i = 1: 1 +i = 2: 1 1 +i = 3: 1 1 1 +i = 4: 0 0 0 0 +i = 5: 0 0 0 0 1 +i = 6: 0 0 0 0 1 1 +``` + +I tested this with executables compiled on a physical ppc64le host, where the issue is not reproducible. +Steps to reproduce: +1. `gcc -O2 -o convert convert.c && ./convert` +2. `gcc -O3 -o convert convert.c && ./convert` diff --git a/results/classifier/mode-gemma3:12b/user/855630 b/results/classifier/mode-gemma3:12b/user/855630 new file mode 100644 index 00000000..f654916b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/855630 @@ -0,0 +1,11 @@ + + +Cant Run Wine (posix not nptl) past 0.14.1 + +when trying to build qemu I can build with ./configure --static --enable-sdl --target-list=i386-linux-user just fine with 0.12.5 + +But when I try to go on 0.13.0 or higher (tested on 0.15.0) it will say it cant find libSDL. + +Tried with arm and x86 versions of Ubuntu 9.10 and 11.04. Same on all 4 tests. + +I found I could run posix wine on 12.5 but I cant go higher for posix wine because of that libSDL.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/856 b/results/classifier/mode-gemma3:12b/user/856 new file mode 100644 index 00000000..3e840f14 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/856 @@ -0,0 +1,63 @@ + + +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/mode-gemma3:12b/user/857 b/results/classifier/mode-gemma3:12b/user/857 new file mode 100644 index 00000000..5ab53735 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/857 @@ -0,0 +1,14 @@ + + +qemu-x86_64 uses host libraries instead of emulated system libraries +Description of problem: +I'm using Buildroot to build a cross-compiled embedded Linux system. During the build process there is a little hack to create some header file using a cross-compiled application. For this hack they use qemu to run this application. Building this embedded system for aarch64 work fine, but for x86_64 I get the following messages: + +bytecode_builtins_list_generator: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by bytecode_builtins_list_generator) +bytecode_builtins_list_generator: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by bytecode_builtins_list_generator) + +The path of the libraries in this error message is from my host system. The embedded system uses /lib64 or /usr/lib64. It seems to me that the linker search for the libraries at first on the host system and later uses the path from the command line. So you have a mixed up of host and embedded system libraries (as you can see in the attached strace log). +Additional information: +[qemu-1.log](/uploads/f53e98b6b15cce7cbf94d14dffa39f90/qemu-1.log) diff --git a/results/classifier/mode-gemma3:12b/user/866 b/results/classifier/mode-gemma3:12b/user/866 new file mode 100644 index 00000000..584ddae4 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/866 @@ -0,0 +1,55 @@ + + +linux-user: substantial memory leak when threads are created and destroyed +Description of problem: +Substantial memory leak when the following simple program is executed on `qemu-arm`, +```c +// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread` + +#include <assert.h> +#include <pthread.h> + +#define MAGIC_RETURN ((void *)42) + +void *thread_main(void *arg) +{ + return MAGIC_RETURN; +} + +int main(int argc, char *argv[]) +{ + size_t i; + for (i = 0;; i++) + { + pthread_t thread; + assert(pthread_create(&thread, NULL, thread_main, NULL) == 0); + void *ret; + assert(pthread_join(thread, &ret) == 0); + assert(ret == MAGIC_RETURN); + } + + return 0; +} +``` +Steps to reproduce: +1. +``` +export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf +export ARMSDK=/${TOOLCHAIN_PREFIX} +export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc +export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc +``` +2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'` +3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1` +4. `$CC test_qemu.c -o test_qemu.out -pthread` +5. `qemu-arm -L $SYSROOT ./test_qemu.out` +6. Observe memory usage keeps ramping up and crashes the process once out of memory. +Additional information: +Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from +```bash +valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out +# Send CTRL-C before the process crashes due to oom +callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100 xtmemory.kcg > annot.log +``` + +# diff --git a/results/classifier/mode-gemma3:12b/user/868 b/results/classifier/mode-gemma3:12b/user/868 new file mode 100644 index 00000000..c012eabf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/868 @@ -0,0 +1,17 @@ + + +Graphic session freezes and logs out +Description of problem: +Graphic session freezes and logs out resetting user session. I've tried with both X and Wayland. +The session does not last longer than 10-15 mins while working with: + VSCode + Firefox browser (no more than 5 open tabs - nothing heavy) + +If only using console, the problem does not seem occur, or maybe it takes longer, but haven't been able to reproduce it. +Steps to reproduce: +No steps. Just using common apps (vscode editor and ffox browser) for 10-15 mins causes the problem. Standard sites: gitlab, stacoverflow. +Additional information: +I used this configuration for +1 year without issues. I guess some updates to either Ubuntu or Lubuntu causes the problem. +I deleted the guest VM and started with a fresh new Lubuntu 20.04 LTS AS IS no exttra software and the problem persists. + +Happy to provide any info you may require. I've looked around in the logs but couldnn't find anything useful. diff --git a/results/classifier/mode-gemma3:12b/user/871 b/results/classifier/mode-gemma3:12b/user/871 new file mode 100644 index 00000000..0da63a7f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/871 @@ -0,0 +1,16 @@ + + +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/mode-gemma3:12b/user/872 b/results/classifier/mode-gemma3:12b/user/872 new file mode 100644 index 00000000..eecbf107 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/872 @@ -0,0 +1,3 @@ + + +linux-user getsockopt(fd, SOL_SOCKET, SO_ERROR) returns host errno to target diff --git a/results/classifier/mode-gemma3:12b/user/876 b/results/classifier/mode-gemma3:12b/user/876 new file mode 100644 index 00000000..6a10b36f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/876 @@ -0,0 +1,36 @@ + + +snek-arm fails on s390x with qemu >6.1 +Description of problem: +snek is a language inspired by python for embedded. The tests run snek code natively (in this case on s390x) as well as in python3 as well as emulated for arm. +The latter is what fails... + +the Ubuntu testing has spotted this in: + +- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220211_065108_2144a@/log.gz +- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220212_050524_3b7ee@/log.gz +- https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/s390x/s/snek/20220214_080226_46968@/log.gz + +In there all work, but one test fails reproducible, that is `test/pass-slice.py` + +When eliminating the automation in makefiles and all that it comes down to: +``` +$ qemu-system-arm -chardev stdio,mux=on,id=stdio0 -serial none -monitor none -semihosting-config enable=on,chardev=stdio0,arg='snek',arg=test/pass-slice.py -machine mps2-an385,accel=tcg -cpu cortex-m3 -kernel /usr/share/snek/snek-qemu-arm-1.7.elf -nographic -bios none +fail: [::-5] (model 'o' impl '') +``` + +To be clear: +- the test for python3 works on all platforms +- the test for snek-native works on all platforms +- the test for snek-arm work on all platforms except s390x +- with qemu 6.0 this worked, but the more recent qemu 6.2 makes it fail +- only some subtests of pass-slice.py fail (see below) + +I've gone into some details for the snek side of things in [the bug report there](https://github.com/keith-packard/snek/issues/58). +Steps to reproduce: +1. get an s390x system +2. get the snek elf file for arm +3. run qemu-system-arm as shown above + +P.S. I tried this on latest head (building qemu in an F35 container) and it fails there as well, hence I'm listing commit 2d88a3a595 as affected as well. +We know 6.0 was ok, so likely 6.0->6.1 brought the issue, I have not yet checked if a bisect is feasible for this. diff --git a/results/classifier/mode-gemma3:12b/user/879 b/results/classifier/mode-gemma3:12b/user/879 new file mode 100644 index 00000000..21223b93 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/879 @@ -0,0 +1,5 @@ + + +Microphone support for Macbooks +Additional information: + diff --git a/results/classifier/mode-gemma3:12b/user/885 b/results/classifier/mode-gemma3:12b/user/885 new file mode 100644 index 00000000..e36f1650 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/885 @@ -0,0 +1,3 @@ + + +linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int` diff --git a/results/classifier/mode-gemma3:12b/user/892 b/results/classifier/mode-gemma3:12b/user/892 new file mode 100644 index 00000000..918465d0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/892 @@ -0,0 +1,7 @@ + + +Ensure qemu-storage-daemon builds, works and is included in win10 setup +Additional information: +- Job run on 20220315 "msys2-64bit build target" seems to have created binary: https://gitlab.com/qemu-project/qemu/-/jobs/2201739711 + - ```2456 [1324/1586] Linking target storage-daemon/qemu-storage-daemon.exe``` + - I hope it will be included in final distributed setup files diff --git a/results/classifier/mode-gemma3:12b/user/893956 b/results/classifier/mode-gemma3:12b/user/893956 new file mode 100644 index 00000000..ab0f921f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/893956 @@ -0,0 +1,17 @@ + + +qemu-img bug with dynamic vhd + +Hye, i found a problem with qemu-img when trying to get info of a dynamic vhd. I made imgae of my 60GB computer hard drive with disk2vhd. The dynamic vhd is 21gb size. + +With 1.0-rc3 version : +running command: qemu-img info 60_GB.VHD +qemu-img: Could not open '60_GB.VHD' : File too large + +0.14.1 version give me wrong information : +image: 60_GB.VHD +file format: vpc +virtual size: 127G (136899993600 bytes) +disk size: 21G + +Thanks for reply.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/902413 b/results/classifier/mode-gemma3:12b/user/902413 new file mode 100644 index 00000000..470dd5ef --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/902413 @@ -0,0 +1,100 @@ + + +qemu-i386-user on ARM host: wine hangs/spins when trying to run anything + +With qemu built from git from 217bfb445b54db618a30f3a39170bebd9fd9dbf2 and configured with './configure --target-list=i386-linux-user --static --interp-prefix=/home/pgriffais/natty-i386/', trying to run wine 1.3.15 from an Ubuntu 11.04 chroot results in hangs. If I run an i386 emulated wineserver, wineserver hangs in: + +0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82 +82 ../sysdeps/unix/syscall-template.S: No such file or directory. + in ../sysdeps/unix/syscall-template.S +(gdb) bt +#0 0x600c7f8c in read () at ../sysdeps/unix/syscall-template.S:82 +#1 0x6004a316 in read (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, + arg3=1, arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0) + at /usr/include/bits/unistd.h:45 +#2 do_syscall (cpu_env=0x622c3ee8, num=3, arg1=6, arg2=1121255519, arg3=1, + arg4=134875664, arg5=1, arg6=1121255528, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:4691 +#3 0x600262f0 in cpu_loop (env=0x622c3ee8) + at /home/ubuntu/src/qemu/linux-user/main.c:321 +#4 0x60026bbc in main (argc=<value optimized out>, + argv=<value optimized out>, envp=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/main.c:3817 + +While wine hangs in: + +0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82 +82 ../sysdeps/unix/syscall-template.S: No such file or directory. + in ../sysdeps/unix/syscall-template.S +(gdb) bt +#0 0x600c84ac in recvmsg () at ../sysdeps/unix/syscall-template.S:82 +#1 0x60041c4e in do_sendrecvmsg (fd=4, target_msg=<value optimized out>, + flags=1073741824, send=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:1834 +#2 0x600497ec in do_socketcall (cpu_env=<value optimized out>, num=102, + arg1=17, arg2=1122504544, arg3=2076831732, arg4=1122504568, + arg5=2076942688, arg6=1122504888, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:2235 +#3 do_syscall (cpu_env=<value optimized out>, num=102, arg1=17, + arg2=1122504544, arg3=2076831732, arg4=1122504568, arg5=2076942688, + arg6=1122504888, arg7=0, arg8=0) + at /home/ubuntu/src/qemu/linux-user/syscall.c:6085 +#4 0x600262f0 in cpu_loop (env=0x622c3f08) + at /home/ubuntu/src/qemu/linux-user/main.c:321 +#5 0x60026bbc in main (argc=<value optimized out>, + argv=<value optimized out>, envp=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/main.c:3817 + +However if I build wineserver 1.3.15 natively for ARM and run it on the host while wine is emulated, I get the following: + +root@tiberiusstation:/home/ubuntu# ./natty-i386/usr/bin/wine notepad +Unsupported ancillary data: 1/2 +Unsupported ancillary data: 1/2 +Unsupported ancillary data: 1/2 +err:process:__wine_kernel_init boot event wait timed out + +I assume the last one is due to wineboot.exe hanging. The main wine process hangs in there: + +cg_temp_new_internal_i32 (temp_local=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg.c:483 +483 } +(gdb) bt +#0 tcg_temp_new_internal_i32 (temp_local=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg.c:483 +#1 0x60052ac6 in tcg_temp_new_i32 (val=6) + at /home/ubuntu/src/qemu/tcg/tcg.h:442 +#2 tcg_const_i32 (val=6) at /home/ubuntu/src/qemu/tcg/tcg.c:530 +#3 0x6005ef0c in tcg_gen_shri_i32 (ot=2, op1=2, op2=7, is_right=1, + is_arith=0, s=<value optimized out>) + at /home/ubuntu/src/qemu/tcg/tcg-op.h:605 +#4 gen_shift_rm_im (ot=2, op1=2, op2=7, is_right=1, is_arith=0, + s=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:1514 +#5 0x6006df90 in gen_shifti (s=0xbefea970, pc_start=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:1946 +#6 disas_insn (s=0xbefea970, pc_start=<value optimized out>) + at /home/ubuntu/src/qemu/target-i386/translate.c:5397 +#7 0x60091758 in gen_intermediate_code_internal (env=0x625656f8, + tb=0x402cdf48) at /home/ubuntu/src/qemu/target-i386/translate.c:7825 +#8 gen_intermediate_code_pc (env=0x625656f8, tb=0x402cdf48) + at /home/ubuntu/src/qemu/target-i386/translate.c:7896 +#9 0x60054bf2 in cpu_restore_state (tb=0x402cdf48, env=0x62565690, + searched_pc=1617393812) at /home/ubuntu/src/qemu/translate-all.c:126 +#10 0x60091d9e in handle_cpu_signal (host_signum=<value optimized out>, + pinfo=<value optimized out>, puc=0xbefeab70) + at /home/ubuntu/src/qemu/user-exec.c:117 +#11 cpu_x86_signal_handler (host_signum=<value optimized out>, + pinfo=<value optimized out>, puc=0xbefeab70) + at /home/ubuntu/src/qemu/user-exec.c:458 +#12 0x6003c764 in host_signal_handler (host_signum=11, info=0xbefeaaf0, + puc=<value optimized out>) + at /home/ubuntu/src/qemu/linux-user/signal.c:492 +#13 <signal handler called> +#14 0x60677894 in static_code_gen_buffer () +#15 0x6000a260 in cpu_x86_exec (env=0x0) + at /home/ubuntu/src/qemu/cpu-exec.c:566 +#16 0x68953200 in ?? () +#17 0x68953200 in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack? + +Running the same version of wine through qemu-user-i386 running on an i386 host works fine with both wineserver and wine being emulated; that's the result I'm trying to achieve.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/909 b/results/classifier/mode-gemma3:12b/user/909 new file mode 100644 index 00000000..764bf02e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/909 @@ -0,0 +1,13 @@ + + +qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries +Description of problem: +**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.** + +Trying to chroot into a mips n32 installation fails with +``` +/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data +``` +however, bash, libc.so.6, and qemu all exist and have the proper abi + +The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware. diff --git a/results/classifier/mode-gemma3:12b/user/911 b/results/classifier/mode-gemma3:12b/user/911 new file mode 100644 index 00000000..f398c463 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/911 @@ -0,0 +1,19 @@ + + +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/mode-gemma3:12b/user/922 b/results/classifier/mode-gemma3:12b/user/922 new file mode 100644 index 00000000..501eaeaf --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/922 @@ -0,0 +1,22 @@ + + +QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static +Description of problem: +I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying. + +This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0 + +I wrote small test to demonstrate this bug. +Steps to reproduce: +1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2) +2. `$ make # To build the docker container` +3. `$ make shell # To run ARM bash` +4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault: +``` +[root@0d81b08f032b /]# /qemu --version +qemu-arm version 6.2.90 +Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers +[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done +Segmentation fault (core dumped) +[root@0d81b08f032b /]# +``` diff --git a/results/classifier/mode-gemma3:12b/user/927 b/results/classifier/mode-gemma3:12b/user/927 new file mode 100644 index 00000000..7f4b8193 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/927 @@ -0,0 +1,34 @@ + + +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/mode-gemma3:12b/user/929 b/results/classifier/mode-gemma3:12b/user/929 new file mode 100644 index 00000000..e3b8af08 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/929 @@ -0,0 +1,35 @@ + + +qemu-user syscall clone fails +Description of problem: +This seems very similar to the issue reported here (https://bugs.launchpad.net/qemu/+bug/1926996). When attempting to perform the clone syscall, an error of -1 is returned where I would expect it to succeed. Running the same executable outside of qemu works as expected. +Steps to reproduce: +1. gcc clone.c +2. qemu-x86_64 a.out +Additional information: +I've tried building with gcc, zig cc, and clang and the output of each works fine when running natively, but running under qemu fails. I originally discovered it when cross compiling to riscv64 but it doesn't seem to be limited to that architecture. + +``` +// clone.c + +#include <linux/sched.h> +#include <sched.h> +#include <sys/syscall.h> +#include <unistd.h> +#include <stdio.h> + +int main(void) { + + long pid = syscall( SYS_clone, 0, 0, 0, 0, 0 ); + + if (pid < 0) { + printf( "error %ld\n", pid ); + } else if (pid == 0) { + printf( "child %ld\n", pid ); + } else { + printf( "parent %ld\n", pid ); + } + + return 0; +} +``` diff --git a/results/classifier/mode-gemma3:12b/user/935945 b/results/classifier/mode-gemma3:12b/user/935945 new file mode 100644 index 00000000..493b05b8 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/935945 @@ -0,0 +1,154 @@ + + +SLIRP still not working for win32 + +SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. + +Here is an example slirp debug log: + +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 84 +icmp_input... +m = 5bd4f0b8 +m_len = 84 +icmp_type = 8 +ip_output... +so = 0 +m0 = 5bd4f0b8 +if_output... +so = 0 +ifm = 5bd4f0b8 +if_start... +arp_table_search... +ip = 0x502000a +found hw addr = 52:54:00:12:34:56 +m_free... +m = 5bd4f0b8 +arp_table_add... +ip = 0x502000a +hw addr = 52:54:00:12:34:56 +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 0 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f728 +ip_input... +m = 5bd4f728 +m_len = 55 +udp_input... +m = 5bd4f728 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f728 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f0b8 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +m_get... +m = 5bd4f0b8 +ip_input... +m = 5bd4f0b8 +m_len = 55 +udp_input... +m = 5bd4f0b8 +iphlen = 20 +sosendto... +so = 5bd104a0 +m = 5bd4f0b8 +sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 +m_free... +m = 5bd4f728 +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +ip_slowtimo... +tcp_slowtimo... +[repeated]
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/938 b/results/classifier/mode-gemma3:12b/user/938 new file mode 100644 index 00000000..ae8bf255 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/938 @@ -0,0 +1,3 @@ + + +Impossible to cross compile from Ubuntu or Debian to Windows with the tutorial diff --git a/results/classifier/mode-gemma3:12b/user/939 b/results/classifier/mode-gemma3:12b/user/939 new file mode 100644 index 00000000..6acfab93 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/939 @@ -0,0 +1,77 @@ + + +qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit +Description of problem: +In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) + +So, I used the following test program, statically linked: +``` +#include <stdlib.h> +#include <stdio.h> +#include <string.h> + +int main() { + + char *pointer; + int i; + + for (i=1; i<301; i++) { + + printf("Allocation %i : ", i); + pointer = malloc(20480000 * sizeof(char)); + + printf(" pointer is %p, ", pointer); + + if (! pointer) { + printf("malloc failed\n"); + exit(0); + }; + + memset(pointer, 0xDB, 20480000); + printf(" filled\n"); + } +}; +``` + +With mips3 n32 I get the following output: +``` +pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest +/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest +Allocation 1 : pointer is 0x40802010, filled +Allocation 2 : pointer is 0x41b8b010, filled +Allocation 3 : pointer is 0x42f14010, filled +[...] +Allocation 51 : pointer is 0x7d8c4010, filled +Allocation 52 : pointer is 0x7ec4d010, filled +qemu: unhandled CPU exception 0x15 - aborting +pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0 +GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200 +GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000 +GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369 +GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010 +GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000 +GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000 +GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000 +GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854 +CP0 Status 0x24800010 Cause 0x00000000 EPC 0x0000000000000000 + Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000 + Config2 0x80000000 Config3 0x00000000 + Config4 0x00000000 Config5 0x00000000 +** +ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu) +``` + +For mips2 o32 I get the more correct looking output +``` +pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest +/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped +pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest +Allocation 1 : pointer is 0x3ec76008, filled +Allocation 2 : pointer is 0x3d8ed008, filled +Allocation 3 : pointer is 0x3c564008, filled +[...] +Allocation 104 : pointer is 0x4082c008, filled +Allocation 105 : pointer is (nil), malloc failed +``` diff --git a/results/classifier/mode-gemma3:12b/user/944 b/results/classifier/mode-gemma3:12b/user/944 new file mode 100644 index 00000000..fba7378e --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/944 @@ -0,0 +1,30 @@ + + +9p virtfs issue under MacOS in 7.0.0-rc1 +Description of problem: +9p virtfs under MacOS has an issue with sed inline replacements (sed -i). +The issue somewhere in xattr I believe +Steps to reproduce: +1. /Users/sid/ is mounted via 9p virtfs from MacOS host +2. +``` +[core@localhost ~]$ sed -i 's/aaa/zzz/g' /Users/sid/q/123 +sed: preserving permissions for ‘/Users/sid/q/sed3MLMjp’: Protocol not supported +``` +Additional information: +strace part with error +``` +openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", O_RDWR|O_CLOEXEC) = 5 +write(5, NULL, 0) = 0 +close(5) = 0 +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +read(3, "qqq\nzzz\nsss\n", 8192) = 12 +newfstatat(4, "", {st_mode=S_IFREG|0600, st_size=0, ...}, AT_EMPTY_PATH) = 0 +read(3, "", 8192) = 0 +fchown(4, 501, 1000) = 0 +fgetxattr(3, "system.posix_acl_access", 0x7ffd6dbd18b0, 132) = -1 ENODATA (No data available) +newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=12, ...}, AT_EMPTY_PATH) = 0 +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EPROTONOSUPPORT (Protocol not supported) +fchmod(4, 0100644) = 0 +``` diff --git a/results/classifier/mode-gemma3:12b/user/95 b/results/classifier/mode-gemma3:12b/user/95 new file mode 100644 index 00000000..90b0320f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/95 @@ -0,0 +1,3 @@ + + +linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code) diff --git a/results/classifier/mode-gemma3:12b/user/952 b/results/classifier/mode-gemma3:12b/user/952 new file mode 100644 index 00000000..ebc3db5b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/952 @@ -0,0 +1,99 @@ + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) +Description of problem: +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 + 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello + +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. + +But it's coredump. + +I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. + +host： +``` +$qemu-arm -g 12345 hello +``` +service: +``` +$gdb-multiarch hello +(gdb) target remote localhost:12345 +Remote debugging using localhost:12345 +0x0000a602 in _start () +(gdb) ni +0x0000a604 in _start () +(gdb) +0x0000a608 in _start () +(gdb) +0x0000a608 in _start () +``` +Another way to check: +``` +$gdb qemu-arm +(gdb) run hello +(gdb) bt +#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 +(gdb) up +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +772 sigsuspend(&act.sa_mask); +(gdb) +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +1099 dump_core_and_abort(sig); +(gdb) +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); +(gdb) +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +472 process_pending_signals(env); +(gdb) l +467 default: +468 error: +469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); +470 abort(); +471 } +472 process_pending_signals(env); +473 } +474 } +475 +476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) +(gdb) p cpu_exec(cs) +$2 = 7 +``` +Here process_pending_signals(env) gives SIGTRAP?? + +Here is my binary: +[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/mode-gemma3:12b/user/955379 b/results/classifier/mode-gemma3:12b/user/955379 new file mode 100644 index 00000000..b12ccb6b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/955379 @@ -0,0 +1,19 @@ + + +cmake hangs with qemu-arm-static + +I'm using git commit 3e7ecd976b06f... configured with --target-list=arm-linux-user --static in a chroot environment to compile some things. I ran into this problem with both pcl and opencv-2.3.1. cmake consistently freezes at some point during its execution, though in a different spot each time, usually during a step when it's searching for some libraries. For instance, pcl most commonly stops after: + +[snip] +-- Boost version: 1.46.1 +-- Found the following Boost libraries: +-- system +-- filesystem +-- thread +-- date_time +-- checking for module 'eigen3' +-- found eigen3, version 3.0.1 + +which is perplexing because it freezes after finding what it wants, not during the search. When it does get past that point, it does so almost immediately but freezes somewhere else. + +I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic with an Intel i5.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/967 b/results/classifier/mode-gemma3:12b/user/967 new file mode 100644 index 00000000..a5dbf42f --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/967 @@ -0,0 +1,226 @@ + + +qemu 6.2 user mode memory leak when mmap + munmap is called +Description of problem: +Launch a program with qemu user mode emulator, +If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. + +Excepted behavior: qemu-x86_64 costs very less memory after munmap is called. +Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap]. +Steps to reproduce: +1.Compile this code with g++. +```shell +g++ -o main.bin main.cpp +``` +```cpp +#include <chrono> +#include <cstdio> +#include <sys/types.h> +#include <unistd.h> +#include <cstdlib> +#include <sys/mman.h> + +#include <thread> + +static constexpr size_t pageSize = 4096; + +int main(){ + constexpr size_t size = 1024*100*pageSize*1000; + + void* data = mmap(nullptr, size, PROT_NONE, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); + + if(data == nullptr){ + perror("mmap failed"); + exit(1); + } + + int error = munmap(data, size); + + if(error !=0){ + perror("munmap failed"); + exit(1); + } + + + printf("mmap munmap test done\n"); + while(true){ + std::this_thread::sleep_for(std::chrono::seconds(10000)); + } + + return 0; +} +``` +2. run main.bin with qemu-x86_64 +```shell +$ qemu-x86_64 ./main.bin +mmap munmap test done +``` +3. check memory usage by top +``` +$ top -p `pgrep "qemu"` +top - 16:00:39 up 6:41, 1 user, load average: 0.08, 0.12, 0.10 +Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie +%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +MiB Mem : 15969.1 total, 8249.3 free, 6048.2 used, 1671.5 buff/cache +MiB Swap: 2048.0 total, 1209.6 free, 838.4 used. 9544.3 avail Mem + + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 38521 jcq 20 0 2634324 2.3g 7840 S 0.0 14.8 0:04.48 qemu-x86_64 +``` + +4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB. +```shell +$ cat /proc/38521/maps +4000000000-4000001000 r--p 00000000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000001000-4000002000 r--p 00001000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000002000-4000003000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000003000-4000004000 r--p 00002000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000004000-4000005000 rw-p 00003000 00:35 49812 /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin +4000005000-4000026000 rw-p 00000000 00:00 0 +4001005000-4001006000 ---p 00000000 00:00 0 +4001006000-4001806000 rw-p 00000000 00:00 0 +4001806000-400183d000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +400183d000-400183e000 ---p 00000000 00:00 0 +400183e000-4001840000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001840000-4001842000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +4001842000-4001844000 rw-p 00000000 00:00 0 +4001863000-4001a78000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a78000-4001a7c000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +4001a7e000-4001a8d000 rw-p 00000000 00:00 0 +5611c96af000-5611c9734000 r--p 00000000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9902000-5611c993c000 r--p 00252000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878 /usr/bin/qemu-x86_64 +5611c9950000-5611c996e000 rw-p 00000000 00:00 0 +5611ca5e0000-56125d125000 rw-p 00000000 00:00 0 [heap] +7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 +7f203ffff000-7f2040000000 ---p 00000000 00:00 0 +7f2040000000-7f2040021000 rw-p 00000000 00:00 0 +7f2040021000-7f2044000000 ---p 00000000 00:00 0 +7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 +7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 +7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 +7f2048676000-7f2048678000 r--p 00000000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f204867f000-7f2048680000 r--p 00009000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538 /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0 +7f2048683000-7f204868d000 r--p 00000000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088 /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1 +7f2048705000-7f204870d000 r--p 00000000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874a000-7f204874b000 ---p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874b000-7f204874c000 r--p 00045000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541 /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4 +7f204874d000-7f2048757000 r--p 00000000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048790000-7f2048792000 r--p 00042000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736 /usr/lib/x86_64-linux-gnu/libnettle.so.8.4 +7f2048793000-7f2048795000 rw-p 00000000 00:00 0 +7f2048795000-7f2048798000 r--p 00000000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2 +7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136 /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0 +7f2048957000-7f2048959000 r--p 00000000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f204895d000-7f2048976000 r--p 00006000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922 /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7 +7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0 +7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747 /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3 +7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541 /usr/lib/x86_64-linux-gnu/libc.so.6 +7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 +7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972 /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 +7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717 /usr/lib/x86_64-linux-gnu/libm.so.6 +7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0 +7f2049043000-7f2049045000 rw-p 00000000 00:00 0 +7f2049045000-7f2049047000 r--p 00000000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f2049049000-7f204904a000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904a000-7f204904b000 r--p 00004000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165 /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0 +7f204904c000-7f2049069000 r--p 00000000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049182000-7f2049183000 ---p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049183000-7f2049184000 r--p 00136000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0 +7f2049185000-7f2049186000 rw-p 00000000 00:00 0 +7f2049186000-7f2049188000 r--p 00000000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918a000-7f204918b000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918b000-7f204918c000 r--p 00004000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546 /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0 +7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 +7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513 /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 +7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0 [stack] +7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0 [vvar] +7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0 [vdso] +ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall] +``` +Additional information: +qemu is installed by ubuntu's apt. + +sudo apt install qemu-user + +compiler version: +``` +g++ --version +g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0 +Copyright (C) 2021 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +``` + +libc version: +``` +ldd --version +ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35 +Copyright (C) 2022 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. +Written by Roland McGrath and Ulrich Drepper. +``` diff --git a/results/classifier/mode-gemma3:12b/user/968 b/results/classifier/mode-gemma3:12b/user/968 new file mode 100644 index 00000000..ce0a65e9 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/968 @@ -0,0 +1,97 @@ + + +QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled +Description of problem: +QEMU guest agent fails to install if COM+ Application: QEMU Guest Agent VSS Provider not properly uninstalled +Steps to reproduce: +1. Install QEMU guest agent +2. Uninstall QEMU guest agent (in rare cases it didn't uninstall the COM+ component) +3. Install QEMU guest agent and get error: `Product: QEMU guest agent -- Error 1722. There is a problem with this Windows Installer package. A program run as part of the setup did not finish as expected. Contact your support personnel or package vendor. Action RegisterCom, location: cmd.exe, command: /c "C:\Program Files\Qemu-ga\qemu-ga.exe" -s vss-install` +Additional information: +1. **Qemu GA is already uninstalled:** + +``` +gwmi Win32_Product + + +IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37} +Name : Spice Agent 0.10.0-5 (64-bit) +Vendor : Red Hat, Inc. +Version : 0.10.5 +Caption : Spice Agent 0.10.0-5 (64-bit) + +IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869} +Name : Virtio-win-driver-installer +Vendor : Red Hat, Inc. +Version : 0.1.189 +Caption : Virtio-win-driver-installer + +IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D} +Name : Orca +Vendor : Microsoft Corporation +Version : 3.1.5299.0000 +Caption : Orca + +IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00} +Name : Microsoft Silverlight +Vendor : Microsoft Corporation +Version : 5.1.50918.0 +Caption : Microsoft Silverlight + +IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE} +Name : Icinga 2 +Vendor : Icinga GmbH +Version : 2.11.0 +Caption : Icinga 2 +``` + +2. **Extract files from installer and run `qemu-ga.exe -s vss-install`** + +It fails with: `QGA VSS Provider is already installed. (Error: 80004004) Vorgang abgebrochen` + +3. **Uninstall COM+ component: `qemu-ga.exe -s vss-uninstall`** + +`Removing COM+ Application: QEMU Guest Agent VSS Provider` + +4. **Now you can install GA** + +``` +gwmi Win32_Product + + +IdentifyingNumber : {EE3877E4-07B0-41F2-ADB8-B45133DDCE37} +Name : Spice Agent 0.10.0-5 (64-bit) +Vendor : Red Hat, Inc. +Version : 0.10.5 +Caption : Spice Agent 0.10.0-5 (64-bit) + +IdentifyingNumber : {4C49C419-DE39-421B-B0F8-5F0DE1486869} +Name : Virtio-win-driver-installer +Vendor : Red Hat, Inc. +Version : 0.1.189 +Caption : Virtio-win-driver-installer + +IdentifyingNumber : {85F4CBCB-9BBC-4B50-A7D8-E1106771498D} +Name : Orca +Vendor : Microsoft Corporation +Version : 3.1.5299.0000 +Caption : Orca + +IdentifyingNumber : {99AD6A3C-F854-4E6E-865F-11D4A5E46172} +Name : QEMU guest agent +Vendor : RedHat +Version : 101.1.0 +Caption : QEMU guest agent + +IdentifyingNumber : {89F4137D-6C26-4A84-BDB8-2E5A4BB71E00} +Name : Microsoft Silverlight +Vendor : Microsoft Corporation +Version : 5.1.50918.0 +Caption : Microsoft Silverlight + +IdentifyingNumber : {AB392F9F-0C0C-4098-B5BA-B1E84E62D6CE} +Name : Icinga 2 +Vendor : Icinga GmbH +Version : 2.11.0 +Caption : Icinga 2 +``` diff --git a/results/classifier/mode-gemma3:12b/user/98 b/results/classifier/mode-gemma3:12b/user/98 new file mode 100644 index 00000000..fd6a2378 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/98 @@ -0,0 +1,3 @@ + + +Curses Keyboard Broken On OS X diff --git a/results/classifier/mode-gemma3:12b/user/980 b/results/classifier/mode-gemma3:12b/user/980 new file mode 100644 index 00000000..fab38bb2 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/980 @@ -0,0 +1,18 @@ + + +Binary emulation of a Solaris-8-compiled dynamically linked C program gives a bus error immediately on startup when running with qemu-sparc +Description of problem: +I am currently trying to use binary emulation to run a dynamically-linked executable C program that was written and compiled on a Solaris 8 VM. However, when I do so, I immediately get a bus error, and I'm not sure what the cause is. Below I'll delineate all of the steps I took to recreate this. +Steps to reproduce: +1. Start Solaris 8 VM (this was done via QEMU, actually, and there are no issues here) +2. Write a simple `.c` program. +3. Compile that program with `/usr/local/bin/gcc`. The name of the program is `binary_emulation`. +4. Test program on the VM to ensure functionality. +5. Stop VM. +6. Mount `.qcow2` on the Linux host so I can easily extract files from it. +7. Copy the entire `/` directory off to `~/binary_emulation/target` +8. Copy `binary_emulation` to a separate directory. +9. `cd` to `.../qemu/build` +10. Run `./qemu-sparc -L ~/binary_emulation/target ~/binary_emulation/binary_emulation` +Additional information: +# diff --git a/results/classifier/mode-gemma3:12b/user/982 b/results/classifier/mode-gemma3:12b/user/982 new file mode 100644 index 00000000..ec8627d0 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/982 @@ -0,0 +1,39 @@ + + +linux-user: --strace incorrectly decodes writev arguments for 64-bit binaries on 32-bit machine +Description of problem: +With `--strace`, the arguments to `writev` appear to be decoded incorrectly. +The syscall still succeeds and has the expected effects. +Steps to reproduce: +``` +$ cat main.c +#include <sys/uio.h> + +int main(void) { + struct iovec iov; + iov.iov_base = "hello, world!\n"; + iov.iov_len = 14; + return writev(1, &iov, 1); +} + +$ aarch64-unknown-linux-gnu-gcc -static -o aarch64-main main.c + +$ x86_64-pc-linux-gnu-gcc -static -o x86_64-main main.c + +$ i686-pc-linux-gnu-gcc -static -o i686-main main.c + +$ ./i686-main +hello, world! + +$ strace ./i686-main |& grep writev +writev(1, [{iov_base="hello, world!\n", iov_len=14}], 1hello, world! + +$ qemu-i386 --strace ./i686-main |& grep writev +21953 writev(1,0x407ffe54,0x1) = 14 + +$ qemu-x86_64 --strace ./x86_64-main |& grep writev +22218 writev(1,(nil),0x407ffcc0) = 14 + +$ qemu-aarch64 --strace ./aarch64-main |& grep writev +22523 writev(1,(nil),0x407ffcc8) = 14 +``` diff --git a/results/classifier/mode-gemma3:12b/user/984 b/results/classifier/mode-gemma3:12b/user/984 new file mode 100644 index 00000000..930d20ba --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/984 @@ -0,0 +1,25 @@ + + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/mode-gemma3:12b/user/987 b/results/classifier/mode-gemma3:12b/user/987 new file mode 100644 index 00000000..4992ef5b --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/987 @@ -0,0 +1,51 @@ + + +compiling issue +Description of problem: +compilation error issue while building for qemu-riscv32-static +Steps to reproduce: +1.git clone https://github.com/qemu/qemu.git + +2. ./configure --static --disable-system --target-list=riscv32-linux-user + + +issue output: +``` +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[954/960] Compiling C object tests/unit/test-string-output-visitor.p/test-string-output-visitor.c.o +[955/960] Linking target tests/unit/test-string-output-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[956/960] Compiling C object tests/unit/test-string-input-visitor.p/test-string-input-visitor.c.o +[957/960] Linking target tests/unit/test-string-input-visitor +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[958/960] Linking target tests/unit/test-x86-cpuid +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +[959/960] Compiling C object tests/unit/test-visitor-serialization.p/test-visitor-serialization.c.o +[960/960] Linking target tests/unit/test-visitor-serialization +/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libglib-2.0.a(libglib_2_0_la-gutils.o): In function `g_get_user_database_entry': +(.text+0x267): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0xdd): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +(.text+0x11b): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +changing dir to build for make ""... +make[1]: Entering directory '/home/sadiq/work/qemu/build' + GIT ui/keycodemapdb meson tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp +[1/3] Generating qemu-version.h with a custom command (wrapped by meson to capture output) +make[1]: Leaving directory '/home/sadiq/work/qemu/build' +``` + +Any suggestions to resolve the issue would be helpful + +Thanks diff --git a/results/classifier/mode-gemma3:12b/user/989 b/results/classifier/mode-gemma3:12b/user/989 new file mode 100644 index 00000000..31356d04 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/989 @@ -0,0 +1,102 @@ + + +Segmentation fault on Apple M1 inside a docker container +Description of problem: +I cannot build a Rust dependency (`regex-syntax`) in a docker container for the platform linux/amd64 using Rancher Desktop (v1.2.1; Kubernetes v1.22.7) on Apple M1 hardware. +I suppose it is a QEMU issue because I didn't observe it on x86_64 hardware where the exact same docker container was built and executed natively without emulation. +Moreover, valgrind does not detect an invalid memory access either. +Steps to reproduce: +1. `nerdctl build --platform linux/amd64 -t rust-x86_64 .` +2. `nerdctl run --platform linux/amd64 -it rust-x86_64` +3. `cargo new hello` +4. `cd hello` +5. `echo 'regex-syntax = "0.6.25"' >> Cargo.toml` +6. `cargo build --release -v` +Additional information: +Dockerfile: +``` +FROM ubuntu:21.10 + +# Install a basic environment needed for our build tools +ARG DEBIAN_FRONTEND=noninteractive +RUN apt -yq update && \ + apt -yqq install --no-install-recommends curl ca-certificates \ + build-essential pkg-config libssl-dev llvm-dev liblmdb-dev clang cmake + +# Install Rust and Cargo in /opt +ARG rust_version=1.60.0 +ARG platform=x86_64 +ENV RUSTUP_HOME=/opt/rustup \ + CARGO_HOME=/opt/cargo \ + PATH=/opt/cargo/bin:$PATH +RUN curl --fail https://sh.rustup.rs -sSf \ + | sh -s -- -y --default-toolchain ${rust_version}-${platform}-unknown-linux-gnu --no-modify-path && \ + rustup default ${rust_version}-${platform}-unknown-linux-gnu +``` + + + +Output inside the docker container: + +``` +# cargo build --release -v + Updating crates.io index + Downloaded regex-syntax v0.6.25 + Downloaded 1 crate (293.3 KB) in 0.84s + Compiling regex-syntax v0.6.25 + Running `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow` +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23] +/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x14d)[0x40033d532d] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03] +/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44] +error: could not compile `regex-syntax` + +Caused by: + process didn't exit successfully: `rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow` (signal: 11, SIGSEGV: invalid memory reference) + +# valgrind rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg 'feature="default"' --cfg 'feature="unicode"' --cfg 'feature="unicode-age"' --cfg 'feature="unicode-bool"' --cfg 'feature="unicode-case"' --cfg 'feature="unicode-gencat"' --cfg 'feature="unicode-perl"' --cfg 'feature="unicode-script"' --cfg 'feature="unicode-segment"' -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow +==977== Memcheck, a memory error detector +==977== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. +==977== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info +==977== Command: rustc --crate-name regex_syntax --edition=2018 /opt/cargo/registry/src/github.com-1ecc6299db9ec823/regex-syntax-0.6.25/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no --cfg feature="default" --cfg feature="unicode" --cfg feature="unicode-age" --cfg feature="unicode-bool" --cfg feature="unicode-case" --cfg feature="unicode-gencat" --cfg feature="unicode-perl" --cfg feature="unicode-script" --cfg feature="unicode-segment" -C metadata=fc954162c3ed8ec3 -C extra-filename=-fc954162c3ed8ec3 --out-dir /hello/target/release/deps -L dependency=/hello/target/release/deps --cap-lints allow +==977== +{"artifact":"/hello/target/release/deps/regex_syntax-fc954162c3ed8ec3.d","emit":"dep-info"} +{"artifact":"/hello/target/release/deps/libregex_syntax-fc954162c3ed8ec3.rmeta","emit":"metadata"} +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x4b3d23)[0x400215fd23] +/lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x4005cab520] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZNK4llvm13AttributeList19addAttributeAtIndexERNS_11LLVMContextEjNS_9AttributeE+0x834)[0x40088d3484] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM-14-rust-1.60.0-stable.so(_ZN4llvm8Function19addAttributeAtIndexEjNS_9AttributeE+0x18)[0x40088d2c48] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs4_NtCsfrnhObXyzQM_18rustc_codegen_llvm3abiINtNtNtCsaEkRwEFRwNk_12rustc_target3abi4call5FnAbiNtNtCs12ixbLjc5mB_12rustc_middle2ty2TyENtB5_12FnAbiLlvmExt16apply_attrs_llfn+0x101)[0x40033d52e1] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXNtCsfrnhObXyzQM_18rustc_codegen_llvm9mono_itemNtNtB4_7context9CodegenCxNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7declare16PreDefineMethods12predefine_fn+0x56a)[0x40033bba5a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x17007c0)[0x40033ac7c0] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23761e6)[0x40040221e6] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2373a6f)[0x400401fa6f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23a1e45)[0x400404de45] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvXs5_CsfrnhObXyzQM_18rustc_codegen_llvmNtB5_18LlvmCodegenBackendNtNtNtCsegTyfRY58Oj_17rustc_codegen_ssa6traits7backend14CodegenBackend13codegen_crate+0xda)[0x400400e70a] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23544e7)[0x40040004e7] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x233ac88)[0x4003fe6c88] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(_RNvMs0_NtCsf5CM6ndXTHU_15rustc_interface7queriesNtB5_7Queries15ongoing_codegen+0xaf)[0x4003fdd02f] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x2308b04)[0x4003fb4b04] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x22ee134)[0x4003f9a134] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-75e5f32fc3580f6c.so(+0x23213e9)[0x4003fcd3e9] +/opt/rustup/toolchains/1.60.0-x86_64-unknown-linux-gnu/bin/../lib/libstd-8d61b92a0a02f53a.so(rust_metadata_std_cd3cf6af28dff6de+0xa7d03)[0x400598fd03] +/lib/x86_64-linux-gnu/libc.so.6(+0x94947)[0x4005cfd947] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x44)[0x4005d8da44] +Segmentation fault (core dumped) +``` diff --git a/results/classifier/mode-gemma3:12b/user/994412 b/results/classifier/mode-gemma3:12b/user/994412 new file mode 100644 index 00000000..b5a5a824 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/994412 @@ -0,0 +1,10 @@ + + +reverse vnc to unix domain sockets does not work + +I tried to connect to a unix domain socket, but failed. + +$ qemu -vnc unix:/tmp/my.sock,reverse +connect(unix:/tmp/my.sock,reverse): No such file or directory + +I guess it is because unix_connect does not remove characters after first comma.
\ No newline at end of file diff --git a/results/classifier/mode-gemma3:12b/user/998 b/results/classifier/mode-gemma3:12b/user/998 new file mode 100644 index 00000000..3660ab92 --- /dev/null +++ b/results/classifier/mode-gemma3:12b/user/998 @@ -0,0 +1,62 @@ + + +AArch64: SCTLR_EL1.BT0 set incorrectly in user mode +Description of problem: +PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV. + + #include <stdint.h> + #include <stdlib.h> + #include <unistd.h> + #include <string.h> + #include <stdio.h> + #include <sys/mman.h> + + // PACIASP is a valid BTI landing pad, but there are some conditions + // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch + // onto a PACIASP landing pad is only valid if it originates from + // x16 or x17 (i.e. br x17 is OK, br x3 is not). + // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a). + + // Sample function which starts with a paciasp instruction + // (comes from -mbranch-protection=pac-ret+leaf) + void indirect_fn(int i) { + // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK. + i = i+1; + // Can't access this function from the copied location, so will segfault. + fprintf(stderr, "reachable\n"); + } + + int main(int argc, char **argv) { + // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc + // so instead map a page and copy the sample function there. + void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (e == MAP_FAILED) { + return 1; + } + memcpy(e, (void*)indirect_fn, 64); + mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // paciasp is a valid landing pad if the branch comes from an unprotected area, + // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI. + void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (f == MAP_FAILED) { + return 1; + } + uint32_t *x = (uint32_t*)f; + x[0] = 0xd503245fuL; // bti c + x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR + mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // Jump to the shim + asm volatile ( + "mov x3, %0\n" + "mov x2, %1\n" + "blr x2\n" + : : "p"(e), "p"(f) : "x2", "x3"); + + // Execution should not reach here + return 1; + } +Steps to reproduce: +1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar. +2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample` |