add results

231 files changed, 10405 insertions, 0 deletions

diff --git a/results/classifier/gemma3:27b/runtime/1010484 b/results/classifier/gemma3:27b/runtime/1010484
new file mode 100644
index 00000000..d0df2531
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1010484
@@ -0,0 +1,9 @@
+
+
+
+slirp to accept non-local dns server
+
+current version of slirp doesn't allow feeded dns address to be outside of given network.
+in many scenarios you need to provide dns server that isn't local.
+
+this simple patch removes checking for if dns server isn't in local subnet.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1027 b/results/classifier/gemma3:27b/runtime/1027
new file mode 100644
index 00000000..cad3d64f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1027
@@ -0,0 +1,18 @@
+
+
+
+Executables should have embedded plist on macOS
+Description of problem:
+QEMU binaries on macOS should have an embedded property list (`plist`).
+
+The bundle identifier of an application, as well as many other settings, are usually not set programmatically but through an `Info.plist` file found within the application bundle (`.app`) which is a property list (basically a settings file in XML format). 
+
+When liking a command line binary, you can tell the linker to embed such a property list inside the binary and the system will respect that when loading the binary. Having an embedded `Info.plist` is highly recommended for all macOS applications, even command line tools, as many system features will not work correctly (or are not even possible) unless they have one (not in all places the binary name will work instead of a bundle identifier).
+
+All you need to do is writing a [plist file by hand](https://docs.transifex.com/formats/apple-plist) (for a list of available keys, see [Apple's documentation](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Introduction/Introduction.html)) and then tell the liker to embed it into the binary:
+
+```
+-sectcreate __TEXT __info_plist YourPlistFile.plist
+```
+
+This makes it far easier to set app specific settings correctly, as in #334 for example. Also things like sudden termination can be disabled completely that way without a single line of code.
diff --git a/results/classifier/gemma3:27b/runtime/1031920 b/results/classifier/gemma3:27b/runtime/1031920
new file mode 100644
index 00000000..18445cd5
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1031920
@@ -0,0 +1,40 @@
+
+
+
+Linux user gdbserver does not respond to remote  `Ctrl-C' interrupts
+
+The bug was reproduce in a recent mainline build for ARM Linux by starting emulation with a gdbserver:
+
+$ qemu-arm -g 1234 a.out
+
+and then connecting from gdb:
+
+(gdb) target remote :1234
+Remote debugging using :1234
+[New Remote target]
+[Switching to Remote target]
+0x00008ba8 in _start ()
+(gdb) b main
+Breakpoint 1 at 0x8cb0: file hello.c, line 5.
+(gdb) cont
+Continuing.
+
+Breakpoint 1, main (argc=1, argv=0xf6fff24c) at hello.c:5
+5	  int n = 0;
+(gdb) l
+1	#include <stdio.h>
+2	
+3	int main (int argc, char **argv)
+4	{
+5	  int n = 0;
+6	
+7	  for (;;) {
+8	     printf ("Hello, World!\n");
+9	     sleep (5);
+10	  }
+(gdb) cont
+Continuing.
+^C^CInterrupted while waiting for the program.
+Give up (and stop debugging it)? (y or n) y
+
+Notice that the `Ctrl-C' interrupts are ignored.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1034 b/results/classifier/gemma3:27b/runtime/1034
new file mode 100644
index 00000000..151e0ef8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1034
@@ -0,0 +1,20 @@
+
+
+
+Erlang/OTP 25 JIT on AArch64 fails in user mode emulation
+Description of problem:
+Compiling Erlang/OTP 25 fails with segfault when using user mode (but works in system mode), the Erlang devs have tracked it down in [ErlangForums](https://erlangforums.com/t/otp-25-0-rc3-release-candidate-3-is-released/1317/24) and give this explanation:
+
+> Thanks, I’ve found a bug in QEMU that explains this. The gist of it is:
+> 
+> Instead of interpreting guest code, QEMU dynamically translates it to the host architecture. When the guest overwrites code for one reason or another, the translation is invalidated and redone if needed.
+> 
+> Our JIT:ed code is mapped in two regions to work in the face of W^X restrictions: one executable but not writable, and one writable but not executable. Both of these regions point to the same physical memory and writes to the writable region are “magically” reflected in the executable one.
+> 
+> I would’ve expected QEMU to honor the IC IVAU / ISB instructions we use to tell the processor that we’ve altered code at a particular address, but for some reason QEMU just ignores them 3 and relies entirely on trapping writes to previously translated code.
+> 
+> In system mode QEMU emulates the MMU and sees that these two regions point at the same memory, and has no problem invalidating the executable region after writing to the writable region.
+> 
+> In user mode it instead calls mprotect(..., PROT_READ) on all code regions it has translated, and invalidates translations in the signal handler. The problem is that we never write to the executable region – just the writable one – so the code doesn’t get invalidated.
+
+There doesn't seem to a open or closed QEMU bug that actually describes this problem.
diff --git a/results/classifier/gemma3:27b/runtime/1041 b/results/classifier/gemma3:27b/runtime/1041
new file mode 100644
index 00000000..e12e90d4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1041
@@ -0,0 +1,34 @@
+
+
+
+x86_64 Auxillary vector reports platform as i686 which doesn't match the linux kernel
+Description of problem:
+Based on the kernel source in the auxiliary vector AT_PLATFORM should be `x86_64` (confirmed by running outside qemu). However qemu sets it to `i686`.
+
+This was originally reported with docker-for-mac, but was reduced on `x86_64` which is why it is pointless
+Steps to reproduce:
+1. Compile the following for x86_64 (statically if you don't want have an x86_64 dynamic linker) (code originally from https://stackoverflow.com/questions/26520163/accessing-auxiliary-vectors-c)
+
+```
+#include <stdio.h>
+#include <elf.h>
+
+int main(int argc, char** argv, char* envp[]) {
+  Elf64_auxv_t *auxv;
+  while(*envp++ != NULL);
+
+  /*from stack diagram above: *envp = NULL marks end of envp*/
+  int i = 0 ;
+  for (auxv = (Elf64_auxv_t *)envp; auxv->a_type != AT_NULL; auxv++)
+    /* auxv->a_type = AT_NULL marks the end of auxv */
+  {
+    if( auxv->a_type == AT_PLATFORM)
+      printf("AT_PLATFORM is: %s\n", ((char*)auxv->a_un.a_val));
+  }
+}
+```
+2. Run with `qemu-x86_64-static`
+3. See `AT_PLATFORM is: i686`
+4. Compare to "real" x86_64 bit system which gives `AT_PLATFORM is: x86_64`
+Additional information:
+I think that adding `#define ELF_PLATFORM "x86_64"` [here](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L134) should work (but I don't fully understand the code). Otherwise we just end up getting the 32-bit case.
diff --git a/results/classifier/gemma3:27b/runtime/1044 b/results/classifier/gemma3:27b/runtime/1044
new file mode 100644
index 00000000..68394603
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1044
@@ -0,0 +1,4 @@
+
+
+
+Warning: libevent-loop-base.a the table of contents is empty
diff --git a/results/classifier/gemma3:27b/runtime/1052857 b/results/classifier/gemma3:27b/runtime/1052857
new file mode 100644
index 00000000..6cf3a439
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1052857
@@ -0,0 +1,18 @@
+
+
+
+qemu-user compiled static for ppc fails on 64bit hosts
+
+On debian I used debootstrap to set up a powerpc chroot. If I then copy in a statically linked qemu-user ppc binary it will work for some commands in the chroot and fail for others. Steps to reproduce:
+
+host$ mkdir powerpc
+host$ sudo debootstrap --arch=powerpc --foreign wheezy powerpc http://ftp.debian.org/debian
+host$ sudo cp /usr/bin/qemu-ppc-static powerpc/usr/bin/
+host$  LANG=C sudo chroot powerpc /usr/bin/qemu-ppc-static /bin/bash
+I have no name!@guest:/# pwd
+/
+I have no name!@guest:/# cd home/
+I have no name!@guest:/home# ls
+qemu-ppc-static: /tmp/buildd/qemu-1.1.2+dfsg/linux-user/signal.c:4341: setup_frame: Assertion `({ unsigned long __guest = (unsigned long)(ka->_sa_handler) - guest_base; (__guest < (1ul << 32)) && (!reserved_va || (__guest < reserved_va)); })' failed.
+
+I have also built this from the git HEAD sources (hash 6b80f7db8a7f84d21e46d01e30c8497733bb23a0) and I get the same result.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1054812 b/results/classifier/gemma3:27b/runtime/1054812
new file mode 100644
index 00000000..8b1d033c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1054812
@@ -0,0 +1,8 @@
+
+
+
+Configure uses wrong libtool on Darwin
+
+On Darwin/OS X, there are two versions of libtool: the GNU libtool, and Apple's libtool. Both are installed, but Apple's libtool (libtool) won't build libcacard that Qemu uses, but Gnu's libtool (glibtool) does. I get around using Apple's libtool by passing LIBTOOL=glibtool when configuring; unfortunately this variable isn't preserved so when Qemu's configure changes it's not passed. A simple switch in the configure script could check for Darwin, then if present, use glibtool. Or configure could check the features of libtool, see if they can build libcacard, then look for alternatives like glibtool. 
+
+This bug was probably introduced when libcacard was added to Qemu, and is present in commit 93b6599734f81328ee3d608f57667742cafeea72.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1059 b/results/classifier/gemma3:27b/runtime/1059
new file mode 100644
index 00000000..e8a07378
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1059
@@ -0,0 +1,13 @@
+
+
+
+qemu: uncaught target signal 6 (Aborted) - core dumped Issue
+Description of problem:
+When we are trying to use the docker images which is using Qemu internally in mac Os then we are getting the qemu: uncaught target signal 6 (Aborted) - core dumped Issue
+Steps to reproduce:
+1. https://botfront.io/docs/installation/local-machine install in local machine
+2. run bot front run
+3. Go to the docker dashboard and open the botfront-rasa. 
+4. ![Screenshot_2022-06-03_at_12.34.54_PM](/uploads/db4f0ba030cac850e1ae90189d1f8a55/Screenshot_2022-06-03_at_12.34.54_PM.png)
+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/gemma3:27b/runtime/1068900 b/results/classifier/gemma3:27b/runtime/1068900
new file mode 100644
index 00000000..8c4f0457
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1068900
@@ -0,0 +1,8 @@
+
+
+
+Thread cancellation broken in app-level emulation
+
+Thread cancellation (and certain other implementation-internal things such as set*id() and timers) are implemented in userspace on Linux by stealing a couple of the realtime signals for internal use by the implementation, leaving them unavailable to applications. Unfortunately, this bites qemu application-level emulation when the application being run uses thread cancellation or other features that need such signals. The signal handler is unable to be set (because sigaction on the host rejects the signal numbers) and attempts to send the signals result in it being received not by the emulated application code, but by the libc/libpthread code on which qemu is running; this in turn seems to cause qemu to crash.
+
+The best solution I can think of is for qemu to steal one of the realtime signals for its own use, and multiplex signal numbers outside the range SIGRTMIN..SIGRTMAX, as well as the stolen signal itself, on top of this stolen signal. This would both allow cancellation to work, and would allow applications the full range of realtime signals when the guest has more signals than the host (e.g. MIPS running on x86 host).
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1070 b/results/classifier/gemma3:27b/runtime/1070
new file mode 100644
index 00000000..7f24dfa9
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1070
@@ -0,0 +1,13 @@
+
+
+
+gdbstub XML generation for ARM is done for every CPU
+Description of problem:
+- As arm_cpu_register_gdb_regs_for_features is called from the device
+   realize stage for each vCPU in user mode we end up uselessly
+   regenerating the XML for every new thread. Once you get up to 100
+   threads this starts exceeding the large maps done for QHT and PageDesc
+Steps to reproduce:
+See above command line, valgrind picks it up
+Additional information:
+See also #866, #967
diff --git a/results/classifier/gemma3:27b/runtime/1072 b/results/classifier/gemma3:27b/runtime/1072
new file mode 100644
index 00000000..be8fef07
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1072
@@ -0,0 +1,27 @@
+
+
+
+different behavior when remote debugger is used
+Description of problem:
+I found Qemu shows different behavior when I run Qemu with hello-world (statically linked binary enclosed) directly or run it through remote debugger. I need help to understand the following: 
+
+1. Is this intended behavior?
+1. Any way to make the two approaches have consistent behavior (I prefer the behavior shown in the 2nd approach described below)
+1. If it is intended behavior, any explanation why or suggestions how to dig further to root cause the difference.
+
+The corresponding source code is the line 86 in [filedoalloc.c](https://code.woboq.org/userspace/glibc/libio/filedoalloc.c.html#86). It tests if the file (stdout) is char special device (S_ISCHR)
+The preprocessed code is as follows:
+   if (((((st.st_mode)) & 0170000) == (0020000))) 
+
+I then compared two different approaches to run Qemu:
+
+1. I used the following command line to collect the trace:  qemu_aarch64 -strace  -plugin $QEMU_ROOT/build/contrib/plugins/libexeclog.so -d plugin hello.a64. This one tests False for S_ISCHR
+1. when I used gdb to connect to Qemu and single-step the instructions, S_ISCHR tests True, which is different from running qemu directly (approach 1). 
+
+Thanks!
+Steps to reproduce:
+1.[hello.a64](/uploads/4b4ccae8c1e4b045c39ceae6a094d55a/hello.a64)
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1075 b/results/classifier/gemma3:27b/runtime/1075
new file mode 100644
index 00000000..1c45079a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1075
@@ -0,0 +1,19 @@
+
+
+
+Unable to create a cluster using ppc64le specific kind binary on x86 host architecture
+Description of problem:
+
+Steps to reproduce:
+1. docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+2. wget https://github.com/kubernetes-sigs/kind/releases/download/v0.14.0/kind-linux-ppc64le
+3. chmod u+x kind-linux-ppc64le
+4. curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/ppc64le/kubectl
+5. chmod +x kubectl
+6. sudo cp kubectl /usr/local/bin/
+7. KUBECONFIG="${HOME}/kind-test-config"
+8. export KUBECONFIG
+9. ./kind-linux-ppc64le create cluster --image quay.io/mayurwaghmode111/node-ppc64le:ppc64le -v=3 --wait 1m --retain
+10. ./kind-linux-ppc64le export logs
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1086 b/results/classifier/gemma3:27b/runtime/1086
new file mode 100644
index 00000000..56d70a3b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1086
@@ -0,0 +1,72 @@
+
+
+
+Numpy/scipy test suites fails in QEMU on ppc64le (but not on aarch64)
+Description of problem:
+I'm not really qualified to report this problem, but after being affected by it for ~2 years (and QEMU 7 not fixing things), I decided to give it a shot. Please excuse reporting deficiencies, I'll endeavour to fix them as best I can once pointed out.
+
+In my spare time, I help out for the packaging effort in the [conda-forge](https://conda-forge.org/) ecosystem, which is mostly associated/attached to the python world, but - in contrast to the vanilla python tools - also deals with non-python dependencies, and in particular has strong enough abstractions to deal with ABI-issues and generally provides much better integration than the packages on PyPI.
+
+This strength of abstraction has also allowed conda-forge to publish artefacts for many more architectures than most projects are commonly able to provide precompiled binaries for. Due to the lack of (reliable) public CI for aarch64 & ppc64le, these packages are mostly cross-compiled from linux-x86. Where cross compilation is not possible, the packages are compiled in emulation through QEMU, coming through https://github.com/multiarch/qemu-user-static (this is the part of the infrastructure I don't fully understand myself...). The full infrastructure is somewhat involved, but should not be relevant (hopefully) to the issue at hand (see instructions below) - and even if that turns out to be the case, that would be a great information gain as well.
+
+In either case, the tests for the package (ideally comprising the entire upstream test suite) are then run in emulation.
+
+Two of the so-called "feedstocks" I co-maintain are for [numpy](https://github.com/conda-forge/numpy-feedstock) and [scipy](https://github.com/conda-forge/scipy-feedstock), and there have been persistent issues with running the test suite in emulation on PPC (interestingly, the same setup on a different architecture - aarch64 - has no problems). However, the compiled artefacts on PPC run fine on native hardware.
+
+Said otherwise, it appears numpy/scipy are exercising QEMU enough to uncover some bugs. I've seen similar problems also in other packages (e.g. the cvxpy-stack), reinforcing the impression that this is a QEMU issue, and not one on the level of the individual packages.
+
+Depending on the exact combination of python version, the result of the numpy test suite might be as follows:
+```
+320 failed, 18900 passed, 361 skipped, 36 xfailed, 9 xpassed, 144 warnings in 2516.49s (0:41:56)
+```
+
+Looking at the test failures, sometimes the results are garbage
+```
+>       assert_array_max_ulp(x, x+eps, maxulp=20)
+E       AssertionError: Arrays are not almost equal up to 20 ULP (max difference is 8.55554e+08 ULP)
+
+eps        = 1.1920929e-07
+self       = <numpy.testing.tests.test_utils.TestULP object at 0x401ec8beb0>
+x          = array([ 2.3744986e-38,            nan,  2.2482052e-15,  7.5780330e+28,
+                  nan,            nan,  5.8310814e+29, -5.6511531e+24,
+        1.0010809e+00,  1.0101526e+00], dtype=float32)
+```
+sometimes the values are permuted
+```
+>           assert_array_equal(actual, desired)
+E           AssertionError: 
+E           Arrays are not equal
+E           
+E           x and y nan location mismatch:
+E            x: array([0.000000e+00, 6.704092e-39, 9.000000e+00, 2.350989e-38,
+E                  0.000000e+00, 0.000000e+00, 0.000000e+00, 0.000000e+00,
+E                  6.772341e-39,          nan], dtype=float32)
+E            y: array([6.704092e-39, 6.772341e-39, 0.000000e+00, 0.000000e+00,
+E                  0.000000e+00, 0.000000e+00,          nan, 2.350989e-38,
+E                  2.000000e+00, 7.000000e+00], dtype=float32)
+```
+sometimes the results are fundamentally different (zero vs. non-zero)
+```
+>               raise AssertionError(msg)
+E               AssertionError: 
+E               Arrays are not almost equal to 6 decimals
+E               
+E               Mismatched elements: 72 / 216 (33.3%)
+E               Max absolute difference: 1.
+E               Max relative difference: 1.
+E                x: array([[[[[0., 0., 0.],
+E                         [0., 0., 0.],
+E                         [0., 0., 0.]],...
+E                y: array([[[[[1., 0., 0.],
+E                         [0., 1., 0.],
+E                         [0., 0., 1.]],...
+```
+
+I don't know where it goes wrong, but it's not just a little tolerance violation. One PR that illustrates this is [here](https://github.com/conda-forge/numpy-feedstock/pull/274) and the respective CI run is [here](https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=526218&view=results) (ignore the errors for osx-arm64, those are unrelated).
+Steps to reproduce:
+1. In an emulated ppc64 machine, install miniforge from [here](https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-Linux-ppc64le.sh)
+2. Run `conda create -n test_env numpy pytest cython hypothesis typing_extensions` and then `conda activate test_env`
+3. Run `python -c "import numpy; numpy.test()"`
+4. Pick any test that fails and run it as `python -c "import numpy; numpy.test(tests='x.y.z')"`
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1093 b/results/classifier/gemma3:27b/runtime/1093
new file mode 100644
index 00000000..a8de95a8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1093
@@ -0,0 +1,36 @@
+
+
+
+RISC-V: signal frame is misaligned in signal handlers
+Description of problem:
+`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan.
+Steps to reproduce:
+1. Create a C file with the following contents:
+```c
+#include <signal.h>
+#include <stdio.h>
+
+void handler(int sig, siginfo_t *info, void *context) {
+	printf("signal occurred, info: %p, context: %p\n", info, context);
+}
+
+int main() {
+	struct sigaction act;
+	act.sa_flags = SA_SIGINFO;
+	act.sa_sigaction = handler;
+	sigaction(SIGINT, &act, NULL);
+
+	// Deliberately misalign the stack
+	asm volatile ("addi sp, sp, -4");
+
+	while(1);
+	// Unreachable
+}
+```
+2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`.
+3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned:
+```
+signal occurred, info: 0x400080025c, context: 0x40008002dc
+```
+Additional information:
+This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15.
diff --git a/results/classifier/gemma3:27b/runtime/1098729 b/results/classifier/gemma3:27b/runtime/1098729
new file mode 100644
index 00000000..4bae42db
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1098729
@@ -0,0 +1,46 @@
+
+
+
+qemu-user-static for armhf: segfault in threaded code
+
+
+Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian.
+
+The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot.
+
+Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs.
+
+As an example, I've grabbed the threads demo program here:
+
+    https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c
+
+and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest):
+
+    gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex
+
+When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever.
+
+However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output:
+
+
+    (armhf) $ ./dotprod_mutex
+    Thread 1 did 100000 to 200000:  mysum=100000.000000 global sum=100000.000000
+    Thread 0 did 0 to 100000:  mysum=100000.000000 global sum=200000.000000
+    TCG temporary leak before f6731ca0
+    qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371:
+    tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed.
+
+
+    (armhf) $ ./dotprod_mutex
+    qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+    Segmentation fault
+
+    (armhf) $ ./dotprod_mutex
+    qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519:
+    tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed.
+
+
+    (armhf) $ ./dotprod_mutex
+    Thread 1 did 100000 to 200000:  mysum=100000.000000 global sum=100000.000000
+    qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+    Segmentation fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1102 b/results/classifier/gemma3:27b/runtime/1102
new file mode 100644
index 00000000..7399874b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1102
@@ -0,0 +1,41 @@
+
+
+
+qemu-user: zero_bss might raise segfault when segment is not writable
+Description of problem:
+When a PT_LOAD segment with the following attributes presented in the user program,
+* MemSiz > FileSiz
+* NOT Writable
+
+qemu-aarch64 will crash with segment fault running it.
+
+
+
+
+in [linux-user/elfload.c: bss_zero](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c#L2097), the exceeded part is zero'ed without checking if it is writable
+```
+    if (host_start < host_map_start) {
+        memset((void *)host_start, 0, host_map_start - host_start);
+    }
+```
+Steps to reproduce:
+1. ./qemu-aarch64 ./X.so
+Additional information:
+readelf output of X.so
+```
+Program Headers:
+  Type           Offset             VirtAddr           PhysAddr                 FileSiz            MemSiz              Flags  Align
+  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040       0x0000000000000230 0x0000000000000230  R E    0x8
+  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000       0x0000000000110270 0x00000000001c94e0  R E    0x10000
+  LOAD           0x0000000000129bd0 0x00000000001d9bd0 0x00000000001d9bd0       0x0000000000000438 0x00000000000004c0  RW     0x10000
+  LOAD           0x000000000013a008 0x00000000001ea008 0x00000000001ea008       0x0000000000017bd0 0x0000000000017bd0  RW     0x10000
+  LOAD           0x0000000000161bd8 0x0000000000211bd8 0x0000000000211bd8       0x000000000000f740 0x000000000000f740  RW     0x10000
+  DYNAMIC        0x0000000000161e60 0x0000000000211e60 0x0000000000211e60       0x00000000000001e0 0x00000000000001e0  RW     0x8
+  INTERP         0x0000000000089410 0x0000000000089410 0x0000000000089410       0x0000000000000015 0x0000000000000015  R      0x1
+      [Requesting program interpreter: /system/bin/linker64]
+  NOTE           0x000000000013dbc8 0x00000000001edbc8 0x00000000001edbc8       0x0000000000000011 0x0000000000000011  R      0x1
+  GNU_EH_FRAME   0x00000000001c86a4 0x00000000001c86a4 0x00000000001c86a4       0x00000000000002dc 0x00000000000002dc  R      0x4
+  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000       0x0000000000000000 0x0000000000000000  RW     0x10
+```
+
+X.so: https://drive.google.com/file/d/1A7mkWRcK2BKkpeevt8T6FVLg-t6mWdgi/view?usp=sharing
diff --git a/results/classifier/gemma3:27b/runtime/1147 b/results/classifier/gemma3:27b/runtime/1147
new file mode 100644
index 00000000..b4e7fe14
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1147
@@ -0,0 +1,12 @@
+
+
+
+x86_64 emu on aarch64 host: cpu_exec: assertion failed: (cpu == current_cpu)
+Description of problem:
+Execution of some binaries crashes with `Bail out! ERROR:../qemu-7.0.0/accel/tcg/cpu-exec.c:933:cpu_exec: assertion failed: (cpu == current_cpu)`. Looking at the code, that code is wrapped in a gcc/clang ifdef. Recompiling with clang produces this crash instead: `... include/qemu/rcu.h:102: void rcu_read_unlock(void): Assertion 'p_rcu_reader->depth != 0' failed.`
+
+No easier steps to reproduce (yet) than `systemd-nspawn`ing into an x86_64 Ubuntu container invoking qemu-x86_64-static through binfmt. Commands such as `ls` work fine, while `apt-get` will immediately crash with the error listed above.
+
+Note that this happens running Asahi Linux on the bare metal of an M1-based Macbook Pro. This same issue does *not* occur running the *same* binaries with the *same* x86_64 Ubuntu image on an Arch or Ubuntu VM under macOS on the same machine - regardless of if the QEMU binaries were built in a VM or in Asahi.
+
+These are big.LITTLE chips. Using taskset/affinity to limit the target process to a single specific core does not help. The Asahi kernel has a 16K page-size, which is known to cause trouble for some programs. qemu-arm(-static) however works without any issues (the M1 cannot run 32-bit ARM code natively, only 64-bit).
diff --git a/results/classifier/gemma3:27b/runtime/1165383 b/results/classifier/gemma3:27b/runtime/1165383
new file mode 100644
index 00000000..8571e394
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1165383
@@ -0,0 +1,6 @@
+
+
+
+executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault
+
+executable qemu-1.4.0/i386-linux-user/./qemu-i386 gives a segmentation fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1172613 b/results/classifier/gemma3:27b/runtime/1172613
new file mode 100644
index 00000000..fb402641
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1172613
@@ -0,0 +1,66 @@
+
+
+
+[qemu 1.4.1] inconsistent behavior on different architecture
+
+Running with qemu 1.4.1 and eglibc 2.17 on Debian Linux 7.0 for amd64
+
+---------------- armhf ----------------
+$ arm-linux-gnueabihf-gcc hello.c
+$ qemu-arm ./a.out
+/lib/ld-linux-armhf.so.3: No such file or directory
+
+$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so ./a.out
+./a.out: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
+
+$ qemu-arm arm-linux-gnueabihf/lib/ld-2.17.so --library-path  arm-linux-gnueabihf/lib ./a.out
+Hello, world !
+
+---------------- powerpc64 ----------------
+$ powerpc64-linux-gcc hello.c
+
+$ qemu-ppc64 ./a.out
+/lib64/ld64.so.1: No such file or directory
+
+[BAD BEHAVIOR !!!]
+$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so ./a.out
+Invalid data memory access: 0x00000041988fd008
+NIP 000000400001cb2c   LR 000000400001cc30 CTR 0000000000000000 XER 0000000000000000
+MSR 8000000002006000 HID0 0000000060000000  HF 8000000002006000 idx 0
+TB 00000000 00000000
+GPR00 0000000000000000 000000400083a220 0000004000041230 00000043309bd010
+GPR04 0000004000026f12 000000000000000b 000000000000002e 000000000000002e
+GPR08 0000000000000030 000000008803fffc 00000041988fcff4 0000000000000037
+GPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+GPR16 0000000000000000 000000400003a4d8 000000400083a6d0 000000400083a6d8
+GPR20 000000400003a898 000000000000000a 0000000000000000 00000043309bd010
+GPR24 0000004000037b60 00000000cfe8ced7 000000400003a430 0000000010000261
+GPR28 00000001980bfff4 0000000000000000 000000004401ffff 000000002200ffff
+CR 22242224  [ E  E  E  G  E  E  E  G  ]             RES ffffffffffffffff
+FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000
+FPSCR 0000000000000000
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+$ qemu-ppc64 powerpc64-linux/lib64/ld-2.17.so --library-path powerpc64-linux/lib64 ./a.out
+Hello, world !
+
+---------------- sparc64 ----------------
+$ sparc64-linux-gcc hello.c
+
+$ qemu-sparc64 ./a.out
+/lib64/ld-linux.so.2: No such file or directory
+
+[BAD BEHAVIOR !!!]
+$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so ./a.out
+Segmentation fault
+
+$ qemu-sparc64 sparc64-linux/lib64/ld-2.17.so --library-path sparc64-linux/lib64 ./a.out
+Hello, world !
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1182490 b/results/classifier/gemma3:27b/runtime/1182490
new file mode 100644
index 00000000..2fb9375e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1182490
@@ -0,0 +1,79 @@
+
+
+
+[qemu-1.5] coroutine-win32.c broken on NULL pointer
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 4340.0x163c]
+qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80)
+    at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47
+(gdb) bt
+#0  qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0,
+    from_=0x3ba1c80) at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47
+#1  coroutine_trampoline (co_=0x3ba1c80)
+    at /home/cauchy/vcs/git/qemu/coroutine-win32.c:58
+#2  0x0000000077098fed in ?? ()
+#3  0x0000000000000000 in ?? ()
+(gdb)
+(gdb) info registers
+rax            0x0      0
+rbx            0x3ba1c80        62528640
+rcx            0x0      0
+rdx            0x0      0
+rsi            0x770b28d0       1997220048
+rdi            0x3ba1b38        62528312
+rbp            0x0      0x0
+rsp            0xc0bff60        0xc0bff60
+r8             0x3184c0 3245248
+r9             0x43e31a 4449050
+r10            0x0      0
+r11            0x206    518
+r12            0x0      0
+r13            0x0      0
+r14            0x0      0
+r15            0x0      0
+rip            0x43e2cd 0x43e2cd <coroutine_trampoline+61>
+eflags         0x10206  [ PF IF RF ]
+cs             0x33     51
+ss             0x2b     43
+ds             0x0      0
+es             0x0      0
+fs             0x0      0
+gs             0x0      0
+(gdb) disassemble
+Dump of assembler code for function coroutine_trampoline:
+   0x000000000043e290 <+0>:     push   %rdi
+   0x000000000043e291 <+1>:     push   %rsi
+   0x000000000043e292 <+2>:     push   %rbx
+   0x000000000043e293 <+3>:     sub    $0x30,%rsp
+   0x000000000043e297 <+7>:     mov    %rcx,%rbx
+   0x000000000043e29a <+10>:    lea    0x26dc1f(%rip),%rcx        #
+0x6abec0 <__emutls_v.current>
+   0x000000000043e2a1 <+17>:    mov    0x6868dd68(%rip),%rax        # 0x68acc010
+   0x000000000043e2a8 <+24>:    mov    %rax,0x28(%rsp)
+   0x000000000043e2ad <+29>:    xor    %eax,%eax
+   0x000000000043e2af <+31>:    callq  0x695808 <__emutls_get_address>
+   0x000000000043e2b4 <+36>:    mov    0x9090d9(%rip),%rsi        #
+0xd47394 <__imp_SwitchToFiber>
+   0x000000000043e2bb <+43>:    mov    %rax,%rdi
+   0x000000000043e2be <+46>:    xchg   %ax,%ax
+   0x000000000043e2c0 <+48>:    mov    0x8(%rbx),%rcx
+   0x000000000043e2c4 <+52>:    callq  *(%rbx)
+   0x000000000043e2c6 <+54>:    mov    0x10(%rbx),%rdx
+   0x000000000043e2ca <+58>:    mov    %rdx,(%rdi)
+=> 0x000000000043e2cd <+61>:    movl   $0x2,0x38(%rdx)
+   0x000000000043e2d4 <+68>:    mov    0x30(%rdx),%rcx
+   0x000000000043e2d8 <+72>:    callq  *%rsi
+   0x000000000043e2da <+74>:    jmp    0x43e2c0 <coroutine_trampoline+48>
+End of assembler dump.
+(gdb)
+
+
+From:
+
+qemu_coroutine_switch (action=COROUTINE_TERMINATE, to_=0x0, from_=0x3ba1c80)
+    at /home/cauchy/vcs/git/qemu/coroutine-win32.c:47
+
+We can see qemu_coroutine_switch was call with to_=NULL, then crashed at line 47:
+
+to->action = action;
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1187319 b/results/classifier/gemma3:27b/runtime/1187319
new file mode 100644
index 00000000..7216dc4d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1187319
@@ -0,0 +1,11 @@
+
+
+
+Ctrl-Alt-- and Ctrl-Alt-+ have no effect in SDL
+
+The manual page mentions Ctrl-Alt-- for shrinking a window and Ctrl-Alt-+ for enlarging it. Pressing these keys do not seem to have any effect.
+
+I tried -/= with and without holding shift and the numpad. By the way, the numpad plus and min do not have any effect in GTK either.
+
+Keyboard layout: US int with AltGr dead keys
+version: 1.5.0
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1207896 b/results/classifier/gemma3:27b/runtime/1207896
new file mode 100644
index 00000000..03d4dc72
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1207896
@@ -0,0 +1,6 @@
+
+
+
+binfmt wrapper for argv[0] handling
+
+Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1209 b/results/classifier/gemma3:27b/runtime/1209
new file mode 100644
index 00000000..c7792870
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1209
@@ -0,0 +1,8 @@
+
+
+
+Optionally do not clear the screen when starting a VM
+Additional information:
+```
+QEMU emulator version 6.2.0 (qemu-6.2.0-14.fc36)
+```
diff --git a/results/classifier/gemma3:27b/runtime/121 b/results/classifier/gemma3:27b/runtime/121
new file mode 100644
index 00000000..74768dcb
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/121
@@ -0,0 +1,4 @@
+
+
+
+multiprocess program gets incorrect results with qemu arm-linux-user
diff --git a/results/classifier/gemma3:27b/runtime/1211 b/results/classifier/gemma3:27b/runtime/1211
new file mode 100644
index 00000000..496c499a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1211
@@ -0,0 +1,10 @@
+
+
+
+Bad fonts in "cirrus" VGA card.
+Description of problem:
+Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file.
+Steps to reproduce:
+Similar to #988.
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/122 b/results/classifier/gemma3:27b/runtime/122
new file mode 100644
index 00000000..24cc126d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/122
@@ -0,0 +1,4 @@
+
+
+
+linux-user does not check PROT_EXEC
diff --git a/results/classifier/gemma3:27b/runtime/1221966 b/results/classifier/gemma3:27b/runtime/1221966
new file mode 100644
index 00000000..0da40dbc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1221966
@@ -0,0 +1,37 @@
+
+
+
+SIGSEGV in static_code_gen_buffer
+
+Trying to run 'ls' (or, anything else as far as I can tell) from a SunOS 5.8 box under RHEL 6.4 linux, I get a segfault.  I've tried qemu-1.5.3, qemu-1.6.0, and I fetched git://git.qemu-project.org/qemu.git.  I've also tried a statically linked sh from /sbin/ and it also segfaulted.
+
+wcolburn@anotheruvula</home/anotheruvula/qemu>$ gdb bin/qemu-sparc
+GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
+Copyright (C) 2010 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "x86_64-redhat-linux-gnu".
+For bug reporting instructions, please see:
+<http://www.gnu.org/software/gdb/bugs/>...
+Reading symbols from /home/anotheruvula/qemu/bin/qemu-sparc...done.
+(gdb) run ../sparc/ls
+Starting program: /home/anotheruvula/qemu/bin/qemu-sparc ../sparc/ls
+[Thread debugging using libthread_db enabled]
+
+Program received signal SIGSEGV, Segmentation fault.
+0x00007ffff8259116 in static_code_gen_buffer ()
+Missing separate debuginfos, use: debuginfo-install glib2-2.22.5-7.el6.x86_64 glibc-2.12-1.107.el6_4.4.x86_64
+(gdb) where
+#0  0x00007ffff8259116 in static_code_gen_buffer ()
+#1  0x00007ffff7f570cd in cpu_tb_exec (cpu=0x7ffffa2b1210, tb_ptr=
+    0x7ffff82590d0 "A\213n \205í\017\205Í")
+    at /home/anotheruvula/qemu-devel/cpu-exec.c:56
+#2  0x00007ffff7f57b2d in cpu_sparc_exec (env=0x7ffffa2b1348)
+    at /home/anotheruvula/qemu-devel/cpu-exec.c:631
+#3  0x00007ffff7f77f36 in cpu_loop (env=0x7ffffa2b1348)
+    at /home/anotheruvula/qemu-devel/linux-user/main.c:1089
+#4  0x00007ffff7f798ff in main (argc=2, argv=0x7fffffffdfc8, envp=
+    0x7fffffffdfe0) at /home/anotheruvula/qemu-devel/linux-user/main.c:4083
+(gdb)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1228 b/results/classifier/gemma3:27b/runtime/1228
new file mode 100644
index 00000000..e3d920fa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1228
@@ -0,0 +1,46 @@
+
+
+
+-display curses only recognizes escape characters if pressed very quickly
+Description of problem:
+The system start and runs perfectly fine, but when I try to exit the escape commands does not seem to work.
+
+I have tried all the ones from here:
+https://www.qemu.org/docs/master/system/keys.html
+https://www.qemu.org/docs/master/system/mux-chardev.html
+
+When using the graphical display, the escape characters works as expected but when using -display curses, they do not.
+Steps to reproduce:
+1. Start qemu with the command provided 
+2. Try to exit using ctrl + x a - Not working
+3. Try to exit using alt + 2 - Not working
+
+The same issues occurs when running qemu on a Linux machine (Ubunt) via Visual Studio Code / ssh. 
+
+I'm guessing this is a macOS specific issue or maybe something to do with my Locale (sv-SE).
+Additional information:
+Linux 0.01 build:
+https://github.com/mariuz/linux-0.01
+
+**Tests using showkey**
+
+Alt + 2 from mobile ssh client (Terminus) -> Ubuntu machine
+```
+^[2      27 0033 0x1b
+         50 0062 0x32
+```
+
+Option + 2 from macOS Terminal + ssh -> Ubuntu machine
+```
+@ 	 64 0100 0x40
+```
+
+Esc + 2 from macOS Terminal + ssh -> Ubuntu machine
+```
+^[ 	 27 0033 0x1b
+2 	 50 0062 0x32
+```
+
+**Update**
+
+It seems to work if I press ESC + 2 at exactly the same time.
diff --git a/results/classifier/gemma3:27b/runtime/1233225 b/results/classifier/gemma3:27b/runtime/1233225
new file mode 100644
index 00000000..0a7a2516
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1233225
@@ -0,0 +1,27 @@
+
+
+
+mips/mipsel linux user float division problem
+
+Hi,
+
+I tested the following with the qemu git HEAD as of 2013-09-30 on Debian stable and testing. My host runs amd64 but I also tried this out inside a i386 chroot with the same result. The problem occurs for mips and mipsel. Given the following program:
+
+#include <stdio.h>
+int main(int argc, char **argv)
+{
+    int a = 1;
+    double d = a/2.0;
+    printf("%f\n", d);
+    return 0;
+}
+
+Instead of printing 0.5, it will print 2.0 if executed in qemu user mode.
+
+$ mipsel-linux-gnu-gcc mipstest.c
+$ ~/qemu/mipsel-linux-user/qemu-mipsel ./a.out
+2.0
+
+Expecting this to be a problem with my cross compiler (gcc-4.4 from emdebian) I ran a fully emulated debian squeeze environment inside qemu. There, I compiled the same program natively with gcc and as expected got 0.5 as the output. I also copied the cross compiled binary inside the emulated environment and also got 0.5 when I ran it. So the same mips/mipsel binary produces different output depending on whether it is run in a fully emulated environment or qemu user mode.
+
+Can anybody else reproduce this problem?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1245703 b/results/classifier/gemma3:27b/runtime/1245703
new file mode 100644
index 00000000..29fde687
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1245703
@@ -0,0 +1,12 @@
+
+
+
+LD_PREFIX option reads directories recursively in an endless loop
+
+If I run qemu user emulation with -L /path/to/my/sysroot/ in which also the proc and dev filesystem is mounted QEMU eats my memory until it gets killed by the kernel.
+
+According to the strace output it follows the symbolic links in the proc filesystem running forever in a recursive loop.
+
+The easiest solution would be to add in the function "add_dir_maybe" in the file util/path.c an additional check for symbolic links that it don't follow them. 
+
+Also I don't really understand the need of doing this. A lot of ressources are wasted everytime QEMU-user is started just by having the directory structure in memory. In my case this are more than 20000 entries which QEMU is loading every time.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1246990 b/results/classifier/gemma3:27b/runtime/1246990
new file mode 100644
index 00000000..9b2c6b07
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1246990
@@ -0,0 +1,41 @@
+
+
+
+[qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+Rjsupplicant is an authentication client of Campus Network in most universities in China. Its Linux version has only x86 and amd64 version.
+
+On linux:
+
+./qemu-x86_64 is compiled from latest qemu 1.6.1, with ./configure options: --enable-debug --target-list=x86_64-linux-user . Compiler is gcc version 4.7.3 (Debian 4.7.3-4) 
+
+$ sudo ./qemu-x86_64  ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet 
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+$ sudo gdb ./qemu-x86_64
+(gdb) r ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet
+(gdb) where
+#0  0x00005555559c21bd in static_code_gen_buffer ()
+#1  0x00005555555b74d5 in cpu_tb_exec (cpu=0x555557972580, tb_ptr=0x5555559c2190 <static_code_gen_buffer+819792> "A\213n\250\205\355\017\205\257")
+    at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:56
+#2  0x00005555555b817d in cpu_x86_exec (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/cpu-exec.c:631
+#3  0x00005555555d997a in cpu_loop (env=0x5555579726b0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/main.c:283
+#4  0x00005555555eca6b in clone_func (arg=0x7fffffffc1d0) at /home/USER/x/rjsupplicant/x64/qemu-1.6.1/linux-user/syscall.c:4266
+#5  0x00007ffff71bfe0e in start_thread (arg=0x7ffff7f04700) at pthread_create.c:311
+#6  0x00007ffff6ef493d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
+
+$ file rjsupplicant 
+rjsupplicant: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
+
+$ uname -r
+3.10-2-amd64
+
+
+And it can be run on Linux amd64 successfully.
+
+Though I don't have the source code of rjsupplicant, so I don't have further information.
+
+`qemu-x86_64 -strace ./rjsupplicant -n eth0 -u USER -p PASS -d 1 -s internet` is attached as strace_qemu.log
+
+
+The binary is available to download at http://ge.tt/6pgG1tw/v/0
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1254672 b/results/classifier/gemma3:27b/runtime/1254672
new file mode 100644
index 00000000..bfb059d9
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1254672
@@ -0,0 +1,44 @@
+
+
+
+ps segfaults with qemu-{arm,armel,mips,powerpc}-static
+
+Host: Ubuntu Precise AMD64
+Guest: Debian Testing armhf
+
+After running a debootstrap for Debian testing/armhf and entering the chroot, simply running "ps" causes a segmentation fault.
+
+$ sudo qemu-debootstrap --arch=armhf testing armhf http://ftp.uk.debian.org/debian/
+[...]
+$ sudo chroot armhf
+# ps
+Signal 11 (SEGV) caught by ps (procps-ng version 3.3.4).
+/bin/ps:display.c:59: please report this bug
+
+I couldn't find a bug report for procps, which would be unusual if such a bug existed, so I'm assuming the bug is in qemu.
+
+Unfortunately trying to run debootstrap for an Ubuntu variant fails to find the release file.
+
+ps is used a lot, as you can imagine, but specifically it fails when trying to install some packages via "apt-get install" and no attempt is made to recover.
+
+ProblemType: Bug
+DistroRelease: Ubuntu 12.04
+Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1
+ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11
+Uname: Linux 3.8.0-33-generic x86_64
+NonfreeKernelModules: wl
+ApportVersion: 2.0.1-0ubuntu17.6
+Architecture: amd64
+Date: Mon Nov 25 10:43:12 2013
+Dependencies:
+ 
+InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1)
+MarkForUpload: True
+ProcEnviron:
+ LANGUAGE=en_GB:en
+ TERM=xterm
+ PATH=(custom, no user)
+ LANG=en_GB.UTF-8
+ SHELL=/bin/bash
+SourcePackage: qemu-linaro
+UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1254828 b/results/classifier/gemma3:27b/runtime/1254828
new file mode 100644
index 00000000..b8ef1885
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1254828
@@ -0,0 +1,40 @@
+
+
+
+qemu-sparc64-static: Segmentation Fault during debootstrap second stage
+
+Host: Ubuntu Precise amd64
+Guest: Debian Sid (ports) sparc64
+
+When attempting the second stage of a debootstrap for a sparc64 Debian Sid guest, a segmentation fault occurs.
+
+$ sudo qemu-debootstrap --no-check-gpg --arch=sparc64 sid sparc64 http://ftp.debian-ports.org/debian
+I: Running command: debootstrap --arch sparc64 --foreign --no-check-gpg sid sparc64 http://ftp.debian-ports.org/debian
+[...]
+I: Running command: chroot sparc64 /debootstrap/debootstrap --second-stage
+/debootstrap/debootstrap: 22: .: Can't open /usr/share/debootstrap/functions
+Segmentation fault (core dumped)
+
+Running a simple "sudo chroot sparc64" exits silently on amd64, and reports a segfault on i386.
+
+ProblemType: Bug
+DistroRelease: Ubuntu 12.04
+Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1
+ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11
+Uname: Linux 3.8.0-33-generic x86_64
+NonfreeKernelModules: wl
+ApportVersion: 2.0.1-0ubuntu17.6
+Architecture: amd64
+Date: Mon Nov 25 17:49:34 2013
+Dependencies:
+ 
+InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1)
+MarkForUpload: True
+ProcEnviron:
+ LANGUAGE=en_GB:en
+ TERM=xterm
+ PATH=(custom, no user)
+ LANG=en_GB.UTF-8
+ SHELL=/bin/bash
+SourcePackage: qemu-linaro
+UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1255 b/results/classifier/gemma3:27b/runtime/1255
new file mode 100644
index 00000000..bf1cc937
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1255
@@ -0,0 +1,14 @@
+
+
+
+32bit qemu-arm fails to run systemctl "Allocating guest commpage: Cannot allocate memory"
+Description of problem:
+I am using a bare minimal install of the latest 32 bit version of debian with only ssh installed. I have compiled qemu from the latest git with "./configure --target-list=arm-linux-user --static --disable-pie". When I try to run systemctl from the latest version of raspbian, I experience the error: "Allocating guest commpage: Cannot allocate memory".
+Steps to reproduce:
+1. Download and extract the included systemctl and required libs. [systemctl+libs.tgz](/uploads/a2834ed651a981fded4bcc19ea9ca31b/systemctl+libs.tgz)
+2. run "qemu-arm -L ./ systemctl --version"
+Additional information:
+- I think this is related to [Issue 690](https://gitlab.com/qemu-project/qemu/-/issues/690).
+- When I run "qemu-arm -L ./ -B 0x20000 systemctl --version" there is no error.
+- The error still happens when setting vm.mmap_min_addr to 0.
+- The error does not occur on v5.0.0, but does occur on v5.1.0 and v6.1.0.
diff --git a/results/classifier/gemma3:27b/runtime/1261743 b/results/classifier/gemma3:27b/runtime/1261743
new file mode 100644
index 00000000..63b65d98
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1261743
@@ -0,0 +1,8 @@
+
+
+
+trace-backend "simple" doesn't support "disable" property of event
+
+trace-backend "simple" generates wrong eventid in trace/generated-tracers.c after "disable" property occured in trace-events record.
+
+Result: missing or mixing logs in trace file.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1263747 b/results/classifier/gemma3:27b/runtime/1263747
new file mode 100644
index 00000000..3dfdf616
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1263747
@@ -0,0 +1,32 @@
+
+
+
+Arm64 fails to run a binary which runs OK on real hardware
+
+This binary:
+
+http://oirase.annexia.org/tmp/test.gz
+
+runs OK on real aarch64 hardware.  It is a statically linked Linux binary which (if successful) will print "hello, world" and exit cleanly.
+
+On qemu-arm64 userspace emulator it doesn't print anything and loops forever using 100% CPU.
+
+----
+The following section is only if you wish to compile this binary from source, otherwise you can ignore it.
+
+First compile OCaml from:
+
+https://github.com/ocaml/ocaml
+
+(note you have to compile it on aarch64 or in qemu, it's not possible to cross-compile).  You will have to apply the one-line patch from:
+
+https://sympa.inria.fr/sympa/arc/caml-list/2013-12/msg00179.html
+
+    ./configure
+    make -j1 world.opt
+
+Then do:
+
+    echo 'print_endline "hello, world"' > test.ml
+    ./boot/ocamlrun ./ocamlopt -I stdlib stdlib.cmxa test.ml -o test
+    ./test
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1285363 b/results/classifier/gemma3:27b/runtime/1285363
new file mode 100644
index 00000000..c16a45f3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1285363
@@ -0,0 +1,48 @@
+
+
+
+qemu-aarch64-static segfaults
+
+I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine.
+
+Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree.
+
+ 1) dh_fixperms is a script that commonly runs at the end of a package build.
+     Its basically doing a `find | xargs chmod`.
+ 2) debootstrap --second-stage
+     This is used to configure an arm64 chroot that was built using
+     debootstrap on a non-native host. It is basically invoking a bunch of
+     shell scripts (postinst, etc). When it blows up, the stack consistently
+     looks like this:
+
+Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e
+/debootstrap/debootstrap --second-stage'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
+__dest=0x400082c330) at
+/usr/include/x86_64-linux-gnu/bits/string3.h:51
+51  return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
+(gdb) bt
+#0  0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0,
+__dest=0x400082c330) at
+/usr/include/x86_64-linux-gnu/bits/string3.h:51
+#1  stq_p (v=274886476624, ptr=0x400082c330) at
+/mnt/qemu.upstream/include/qemu/bswap.h:280
+#2  stq_le_p (v=274886476624, ptr=0x400082c330) at
+/mnt/qemu.upstream/include/qemu/bswap.h:315
+#3  target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678,
+sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167
+#4  target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0
+<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530,
+env=env@entry=0x62d9c678)
+    at /mnt/qemu.upstream/linux-user/signal.c:1286
+#5  0x0000000060059f46 in setup_frame (env=0x62d9c678,
+set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at
+/mnt/qemu.upstream/linux-user/signal.c:1322
+#6  process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at
+/mnt/qemu.upstream/linux-user/signal.c:5747
+#7  0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at
+/mnt/qemu.upstream/linux-user/main.c:1082
+#8  0x0000000060005079 in main (argc=<optimized out>, argv=<optimized
+out>, envp=<optimized out>) at
+/mnt/qemu.upstream/linux-user/main.c:4374
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1287195 b/results/classifier/gemma3:27b/runtime/1287195
new file mode 100644
index 00000000..c16f930d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1287195
@@ -0,0 +1,6 @@
+
+
+
+validate_guest_space incorrectly enabled on AArch64
+
+When running linux-user targetting AArch64, validate_guest_space() in elfload.c reserves space in the guest address space for the ARM commpage. Since there is no commpage on AArch64, this function should be disable on that target.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1294898 b/results/classifier/gemma3:27b/runtime/1294898
new file mode 100644
index 00000000..ac8e8197
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1294898
@@ -0,0 +1,81 @@
+
+
+
+gtk: menubar visible in fullscreen mode with gtk3
+
+Using the gtk UI, compiled with gtk3, the menu bar is fully visible in full screen mode. On gtk2 it's hidden. The set_size_request call isn't abided on gtk3 it seems.
+
+Simple fix is:
+
+diff --git a/ui/gtk.c b/ui/gtk.c
+index 66e886f..7b3bd3d 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -805,7 +805,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
+ 
+     if (!s->full_screen) {
+         gtk_notebook_set_show_tabs(GTK_NOTEBOOK(s->notebook), FALSE);
+-        gtk_widget_set_size_request(s->menu_bar, 0, 0);
++        gtk_widget_hide(s->menu_bar);
+         gtk_widget_set_size_request(s->drawing_area, -1, -1);
+         gtk_window_fullscreen(GTK_WINDOW(s->window));
+         if (gd_on_vga(s)) {
+@@ -815,7 +815,7 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
+     } else {
+         gtk_window_unfullscreen(GTK_WINDOW(s->window));
+         gd_menu_show_tabs(GTK_MENU_ITEM(s->show_tabs_item), s);
+-        gtk_widget_set_size_request(s->menu_bar, -1, -1);
++        gtk_widget_show(s->menu_bar);
+         gtk_widget_set_size_request(s->drawing_area,
+                                     surface_width(s->ds),
+                                     surface_height(s->ds));
+
+
+The problem with that is that hiding the menu bar means all its associated accelerators are no longer usable, so there's way to exit fullscreen mode. That's kind of a problem :)
+
+We can install the accelerators on the window, but make sure the menu item still shows the accelerator short cut. Example with the fullscreen accelerator:
+
+diff --git a/ui/gtk.c b/ui/gtk.c
+index 66e886f..fbce2b0 100644
+--- a/ui/gtk.c
++++ b/ui/gtk.c
+@@ -799,7 +799,7 @@ static void gd_menu_show_tabs(GtkMenuItem *item, void *opaque)
+     }
+ }
+ 
+-static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
++static void gd_do_full_screen(void *opaque)
+ {
+     GtkDisplayState *s = opaque;
+ 
+@@ -828,6 +828,11 @@ static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
+     gd_update_cursor(s, FALSE);
+ }
+ 
++static void gd_menu_full_screen(GtkMenuItem *item, void *opaque)
++{
++    gd_do_full_screen(opaque);
++}
++
+ static void gd_menu_zoom_in(GtkMenuItem *item, void *opaque)
+ {
+     GtkDisplayState *s = opaque;
+@@ -1304,10 +1309,11 @@ static GtkWidget *gd_create_menu_view(GtkDisplayState *s, GtkAccelGroup *accel_g
+     gtk_menu_set_accel_group(GTK_MENU(view_menu), accel_group);
+ 
+     s->full_screen_item = gtk_menu_item_new_with_mnemonic(_("_Fullscreen"));
+-    gtk_menu_item_set_accel_path(GTK_MENU_ITEM(s->full_screen_item),
+-                                 "<QEMU>/View/Full Screen");
+-    gtk_accel_map_add_entry("<QEMU>/View/Full Screen", GDK_KEY_f,
+-                            HOTKEY_MODIFIERS);
++    gtk_accel_group_connect(accel_group, GDK_KEY_f, HOTKEY_MODIFIERS, 0,
++         g_cclosure_new_swap(G_CALLBACK(gd_do_full_screen), s, NULL));
++    gtk_accel_label_set_accel(
++        GTK_ACCEL_LABEL(gtk_bin_get_child(GTK_BIN(s->full_screen_item))),
++        GDK_KEY_f, HOTKEY_MODIFIERS);
+     gtk_menu_shell_append(GTK_MENU_SHELL(view_menu), s->full_screen_item);
+ 
+     separator = gtk_separator_menu_item_new();
+
+
+However gtk_accel_label_set_accel, which shows the accel key sequence in the menu, is gtk 3.8+ :/ So older versions wouldn't have any visual indication of the shortcuts. Maybe that's not a problem, SDL didn't have any indication of shortcuts either.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1311614 b/results/classifier/gemma3:27b/runtime/1311614
new file mode 100644
index 00000000..35739fc7
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1311614
@@ -0,0 +1,50 @@
+
+
+
+qemu-arm segfaults with gcc 4.9.0
+
+I have an ARM chroot that working with qemu-arm emulation
+
+[root@filzbach fedya]# cat /proc/sys/fs/binfmt_misc/arm
+enabled
+interpreter /usr/bin/qemu-arm-binfmt
+flags: P
+offset 0
+magic 7f454c4601010100000000000000000002002800
+mask ffffffffffffff00fffffffffffffffffeffffff
+
+
+In chroot installed gcc dependencies with 4.9.0 version
+
+sudo rpm --root /home/fedya/root/ -qa | grep 4.9.0
+
+libgcc1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libgomp1-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++6-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-cpp-4.9.0_2014.04-1-omv2013.0.armv7hl
+libstdc++-devel-4.9.0_2014.04-1-omv2013.0.armv7hl
+gcc-c++-4.9.0_2014.04-1-omv2013.0.armv7hl
+
+
+When i try to run "rpm" , "rpmbuild", "rpm2cpio"command i always see qemu segfault message
+
+
+example:
+
+[root@filzbach /]# uname -a
+Linux filzbach.lindev.ch 3.13.6-nrjQL-desktop-70omv #1 SMP PREEMPT Wed Mar 12 21:40:00 UTC 2014 armv7l armv7l armv7l GNU/Linux
+
+[root@filzbach /]# rpm
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+
+Segfault became apparent only after gcc upgrade from 4.8.3 to 4.9.0.
+
+When i downgrade it to 4.8.3 all working fine again.
+It looks like a qemu bug with gcc.
+
+
+P.S.
+I tried to rebuild qemu with gcc 4.9.0
+I tried to build qemu from git sources, from fedora sources, from suse sources etc.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1346784 b/results/classifier/gemma3:27b/runtime/1346784
new file mode 100644
index 00000000..2395c80f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1346784
@@ -0,0 +1,70 @@
+
+
+
+qemu internal memory areas visible to a guest via /proc/self/maps
+
+
+Qemu internal memory areas are not suppressed in the output and are  visible to a guest via /proc/self/maps.
+
+$ echo "int main() { return 0; }" > /tmp/test.c
+$ gcc -m32 -fsanitize=address -fno-common -Wall -g -fPIC -o /tmp/test /tmp/test.c
+$ qemu-i386-static -R 0 /tmp/test
+
+We use -R option because the binary can't be executed under stock version of Qemu with address sanitizer instrumentations (Asan).
+
+Qemu memory map looks the following way where GUEST valid addresses are marked with ***** and invalid with @@@:
+
+***** 08048000-08049000 r-xp 00000000 08:01 28835889          /tmp/test
+***** 08049000-0804a000 rw-p 00000000 08:01 28835889          /tmp/test
+***** 1ffff000-24000000 rw-p 00000000 00:00 0 
+***** 24000000-28000000 ---p 00000000 00:00 0 
+***** 28000000-40000000 rw-p 00000000 00:00 0 
+***** 40000000-40001000 ---p 00000000 00:00 0 
+***** 40001000-40801000 rw-p 00000000 00:00 0                         [stack]
+***** 40801000-40821000 r-xp 00000000 08:01 26738694          /lib32/ld-2.19.so
+***** 40821000-40822000 r--p 0001f000 08:01 26738694          /lib32/ld-2.19.so
+***** 40822000-40823000 rw-p 00020000 08:01 26738694          /lib32/ld-2.19.so
+***** 40823000-40827000 rw-p 00000000 00:00 0 
+***** 40827000-408ca000 r-xp 00000000 08:01 49424994          /home/michail/build/lib32/libasan.so.1.0.0
+***** 408ca000-408cc000 rw-p 000a3000 08:01 49424994          /home/michail/build/lib32/libasan.so.1.0.0
+***** 408cc000-40d24000 rw-p 00000000 00:00 0 
+***** 40d3c000-40ee2000 r-xp 00000000 08:01 26738695          /lib32/libc-2.19.so
+***** 40ee2000-40ee4000 r--p 001a6000 08:01 26738695          /lib32/libc-2.19.so
+***** 40ee4000-40ee5000 rw-p 001a8000 08:01 26738695          /lib32/libc-2.19.so
+***** 40ee5000-40ee8000 rw-p 00000000 00:00 0 
+***** 40ee8000-40f00000 r-xp 00000000 08:01 26738711          /lib32/libpthread-2.19.so
+***** 40f00000-40f01000 r--p 00017000 08:01 26738711          /lib32/libpthread-2.19.so
+***** 40f01000-40f02000 rw-p 00018000 08:01 26738711          /lib32/libpthread-2.19.so
+***** 40f02000-40f04000 rw-p 00000000 00:00 0 
+***** 40f04000-40f07000 r-xp 00000000 08:01 26738708          /lib32/libdl-2.19.so
+***** 40f07000-40f08000 r--p 00002000 08:01 26738708          /lib32/libdl-2.19.so
+***** 40f08000-40f09000 rw-p 00003000 08:01 26738708          /lib32/libdl-2.19.so
+***** 40f09000-40fee000 r-xp 00000000 08:01 49424965          /home/michail/build/lib32/libstdc++.so.6.0.20
+***** 40fee000-40ff2000 r--p 000e5000 08:01 49424965          /home/michail/build/lib32/libstdc++.so.6.0.20
+***** 40ff2000-40ff3000 rw-p 000e9000 08:01 49424965          /home/michail/build/lib32/libstdc++.so.6.0.20
+***** 40ff3000-40ffa000 rw-p 00000000 00:00 0 
+***** 40ffa000-4103e000 r-xp 00000000 08:01 26738698          /lib32/libm-2.19.so
+***** 4103e000-4103f000 r--p 00043000 08:01 26738698          /lib32/libm-2.19.so
+***** 4103f000-41040000 rw-p 00044000 08:01 26738698          /lib32/libm-2.19.so
+***** 41040000-41041000 rw-p 00000000 00:00 0 
+***** 41041000-4105b000 r-xp 00000000 08:01 49424637          /home/michail/build/lib32/libgcc_s.so.1
+***** 4105b000-4105c000 rw-p 00019000 08:01 49424637          /home/michail/build/lib32/libgcc_s.so.1
+***** 4105c000-4105e000 rw-p 00000000 00:00 0 
+***** 4105f000-41061000 rw-p 00000000 00:00 0 
+***** 41065000-421ed000 rw-p 00000000 00:00 0 
+***** 421ee000-421f1000 rw-p 00000000 00:00 0 
+***** 60000000-6033b000 r-xp 00000000 08:01 48760980          /home/michail/build/bin/qemu-i386-static
+***** 6053b000-60546000 rw-p 0033b000 08:01 48760980          /home/michail/build/bin/qemu-i386-static
+***** 60546000-6059a000 rw-p 00000000 00:00 0 
+***** 6059a000-6259b000 rwxp 00000000 00:00 0 
+***** 6259b000-625ae000 rw-p 00000000 00:00 0 
+***** 62dce000-62e12000 rw-p 00000000 00:00 0                          [heap]
+@@@ 7f3f5e6a9000 - 7f3f61f28000 rw-p 00000000 00:00 0 
+@@@ 7fffad130000 - 7fffad132000 r-xp 00000000 00:00 0          [vdso]
+@@@ ffffffffff600000 - ffffffffff601000 r-xp 00000000 00:00 0          [vsyscall]
+
+qemu-i386-static and its heap are in ranges which are valid and be reported to guest in case of maps file reading.
+
+The issue is related to early reported bugs:
+http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg02793.html
+http://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg03085.html
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1357206 b/results/classifier/gemma3:27b/runtime/1357206
new file mode 100644
index 00000000..d9675457
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1357206
@@ -0,0 +1,62 @@
+
+
+
+QEMU user mode still crashes in multi-thread code.
+
+I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode.
+
+I did a little search and found LP:668799 but it is far from now and it is probably not the problem here.
+
+I used program below as the test program:
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <pthread.h>
+
+void *print_message_function( void *ptr );
+
+main()
+{
+     pthread_t thread1, thread2;
+     const char *message1 = "Thread 1";
+     const char *message2 = "Thread 2";
+     int  iret1, iret2;
+
+    /* Create independent threads each of which will execute function */
+
+     iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1);
+     if(iret1)
+     {
+         fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1);
+         exit(EXIT_FAILURE);
+     }
+
+     iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2);
+     if(iret2)
+     {
+         fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2);
+         exit(EXIT_FAILURE);
+     }
+
+     printf("pthread_create() for thread 1 returns: %d\n",iret1);
+     printf("pthread_create() for thread 2 returns: %d\n",iret2);
+
+     /* Wait till threads are complete before main continues. Unless we  */
+     /* wait we run the risk of executing an exit which will terminate   */
+     /* the process and all threads before the threads have completed.   */
+
+     pthread_join( thread1, NULL);
+     pthread_join( thread2, NULL); 
+
+     exit(EXIT_SUCCESS);
+}
+
+void *print_message_function( void *ptr )
+{
+     char *message;
+     message = (char *) ptr;
+     printf("%s \n", message);
+}
+
+Compiled to i386 and aarch64 object, 
+and both qemu-i386 and qemu-aarch64 had segmentation faults.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1357226 b/results/classifier/gemma3:27b/runtime/1357226
new file mode 100644
index 00000000..be6c99f1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1357226
@@ -0,0 +1,14 @@
+
+
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+steps to reproduce:
+pbuilder-dist utopic armhf create
+pbuilder-dist utopic armhf login
+apt-get install imagemagick
+convert foo.xpm foo.png
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+(doesn't matter if images are actually there or not)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1361912 b/results/classifier/gemma3:27b/runtime/1361912
new file mode 100644
index 00000000..c5b00197
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1361912
@@ -0,0 +1,12 @@
+
+
+
+qemu-mips64 Segmentation fault
+
+When I ran qemu-mips64 for any mips 64 executable , I got this error:
+
+$ ./qemu-mips64  ../lang
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault (core dumped)
+
+Is this a known issue?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1362635 b/results/classifier/gemma3:27b/runtime/1362635
new file mode 100644
index 00000000..9536b6de
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1362635
@@ -0,0 +1,45 @@
+
+
+
+bdrv_read co-routine re-entered recursively
+
+calling bdrv_read in a loop leads to the follwing situation:
+
+bs->drv->bdrv_aio_readv is called, and finally calls bdrv_co_io_em_complete in other thread context.
+there is a possibility of calling bdrv_co_io_em_complete before calling qemu_coroutine_yield in bdrv_co_io_em. And qemu fails with "co-routine re-entered recursively".
+
+static void bdrv_co_io_em_complete(void *opaque, int ret)
+{
+    CoroutineIOCompletion *co = opaque;
+
+    co->ret = ret;
+    qemu_coroutine_enter(co->coroutine, NULL);
+}
+
+static int coroutine_fn bdrv_co_io_em(BlockDriverState *bs, int64_t sector_num,
+                                      int nb_sectors, QEMUIOVector *iov,
+                                      bool is_write)
+{
+    CoroutineIOCompletion co = {
+        .coroutine = qemu_coroutine_self(),
+    };
+    BlockDriverAIOCB *acb;
+
+    if (is_write) {
+        acb = bs->drv->bdrv_aio_writev(bs, sector_num, iov, nb_sectors,
+                                       bdrv_co_io_em_complete, &co);
+    } else {
+        acb = bs->drv->bdrv_aio_readv(bs, sector_num, iov, nb_sectors,
+                                      bdrv_co_io_em_complete, &co);
+    }
+
+    trace_bdrv_co_io_em(bs, sector_num, nb_sectors, is_write, acb);
+    if (!acb) {
+        return -EIO;
+    }
+    qemu_coroutine_yield();
+
+    return co.ret;
+}
+
+is it a bug, or may be I don't understand something?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1388 b/results/classifier/gemma3:27b/runtime/1388
new file mode 100644
index 00000000..ef331b07
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1388
@@ -0,0 +1,17 @@
+
+
+
+QEMU 7.2.0 - Update file repository with x86/x64 Windows installer
+Description of problem:
+In file repository
+
+https://qemu.weilnetz.de/w32/
+https://qemu.weilnetz.de/w64/
+
+are not availble Windows installer for x86 and x64 platform and QEMU final 7.2.0.
+
+The latest version is 7.2.0.RC4 (08.12.2022).
+
+Thanks.
+Steps to reproduce:
+
diff --git a/results/classifier/gemma3:27b/runtime/1429313 b/results/classifier/gemma3:27b/runtime/1429313
new file mode 100644
index 00000000..8313542a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1429313
@@ -0,0 +1,12 @@
+
+
+
+qemu-user doesn't block target signals on entry to signal hanlder.
+
+Upon entry to a target signal handler the function process_pending_signals in linux-user/signal.c block the appropriate host signals, but signals already received and queued by Qemu are not blocked. If multiple signals arrive in quick succession this results incorrect recursion in the target signal handler.
+
+The attached test case my be run as:
+
+$ (sleep 2 ; echo) | qemu-i386 ./a.out
+.................. Recursion in signal handler!
+qemu: uncaught target signal 6 (Aborted) - core dumped
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1471 b/results/classifier/gemma3:27b/runtime/1471
new file mode 100644
index 00000000..670b1af3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1471
@@ -0,0 +1,19 @@
+
+
+
+16fc5726a6 breaks curl SSL connections
+Description of problem:
+`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`).
+Steps to reproduce:
+1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4
+2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0
+3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk`
+4. Observe the following error message:
+
+```
+curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature
+```
+
+Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. 
+
+Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a).
diff --git a/results/classifier/gemma3:27b/runtime/1478 b/results/classifier/gemma3:27b/runtime/1478
new file mode 100644
index 00000000..bdd8513e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1478
@@ -0,0 +1,69 @@
+
+
+
+Qemu 7.2.0 i386: core2: init crash (glibc)
+Description of problem:
+The toolchain-builder project (a side project of Buildroot to build pre-built toolchains) reported an issue with Qemu 7.2.0 for  x86-core2--glibc--bleeding-edge toolchain, see:
+
+https://gitlab.com/buildroot.org/toolchains-builder/-/jobs/3731683337
+
+Reverting back to Qemu 7.1.0, the system boot correctly with the same system image.
+I reproduced the issue with the current Qemu master (6b433719eabf0abc74cff0cfd5687f0137c4198a)
+
+Here is the boot log obtained with Qemu 7.2.0:
+   ```
+Run /sbin/init as init process
+random: fast init done
+EXT4-fs (vda): warning: mounting unchecked fs, running e2fsck is recommended
+EXT4-fs (vda): re-mounted. Opts: (null). Quota mode: disabled.
+Starting syslogd: OK
+traps: syslogd[52] general protection fault ip:b7e21465 sp:bfe59e6c error:0 in libc.so.6[b7d9b000+123000]
+Starting klogd: OK
+traps: klogd[56] general protection fault ip:b7e94465 sp:bf8f069c error:0 in libc.so.6[b7e0e000+123000]
+Running sysctl: traps: logger[62] general protection fault ip:b7e48b6c sp:bfd7d194 error:0 in libc.so.6[b7e05000+123000]
+Segmentation fault
+traps: logger[64] general protection fault ip:b7dd3b6c sp:bf9b8604 error:0 in libc.so.6[b7d90000+123000]
+Segmentation fault
+
+traps: init[100] general protection fault ip:b7dda465 sp:bfd5f42c error:0 in libc.so.6[b7d54000+123000]
+Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
+CPU: 0 PID: 1 Comm: init Not tainted 5.15.18 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
+Call Trace:
+ dump_stack_lvl+0x32/0x41
+ dump_stack+0xd/0x10
+ panic+0x90/0x206
+ do_exit.cold+0xa9/0xa9
+ do_group_exit+0x2a/0x90
+ get_signal+0x115/0x7e0
+ arch_do_signal_or_restart+0x90/0x5a0
+ ? put_pid+0xc/0x20
+ ? kernel_clone+0x10b/0x3d0
+ exit_to_user_mode_prepare+0xf8/0x1c0
+ syscall_exit_to_user_mode+0x1b/0x40
+ do_int80_syscall_32+0x41/0x90
+ entry_INT80_32+0xf0/0xf0
+EIP: 0xb7de5d88
+Code: 37 01 00 00 65 ff 15 10 00 00 00 89 d0 5a 5b 5e 5f 5d c3 66 90 66 90 66 90 66 90 66 90 66 90 66 90 90 59 b8 be 00 00 00 cd 80 <51> 3d 01 f0 ff ff 0f 83 06 e9 f6 ff c3 e8 81 a0 06 00 05 9a a0 0e
+EAX: 00000064 EBX: 0059aa1c ECX: 00561f5b EDX: 00000008
+ESI: 0059cc20 EDI: bfd5fa64 EBP: 0059b138 ESP: bfd5fa20
+DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
+Kernel Offset: disabled
+---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
+   ```
+I did a git bisect on qemu sources up to this commit:
+
+https://gitlab.com/qemu-project/qemu/-/commit/958e1dd1300f37f18b2161dfb4eb806fc8c19b44
+Steps to reproduce:
+Build the Buildroot qemu_x86_defconfig with BR2_x86_core2 target architecture variant added manually
+1. git clone https://gitlab.com/buildroot.org/buildroot.git
+2. git switch --detach c419ef62d84b5be65599452ab84f7ed719bbe470
+3. make qemu_x86_defconfig
+4. make menuconfig (enable BR2_x86_core2)
+5. make
+6. ./output/images/start-qemu.sh
+Additional information:
+System built with gcc options:
+   ```
+i686-buildroot-linux-gnu-gcc.br_real' '--sysroot' 'output/host/i686-buildroot-linux-gnu/sysroot' '-fstack-protector-strong' '-fPIE' '-pie' '-Wl,-z,now' '-Wl,-z,relro'
+   ```
diff --git a/results/classifier/gemma3:27b/runtime/1494 b/results/classifier/gemma3:27b/runtime/1494
new file mode 100644
index 00000000..38369c1a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1494
@@ -0,0 +1,935 @@
+
+
+
+[regression] [bisected] [coredump] qemu-x86_64 segfaults on ppc64le (4K page size) when downloading go dependencies: unexpected fault address 0x0
+Description of problem:
+qemu-x86_64 segfaults when trying to compile yay inside an Arch Linux x86_64 chroot from a Gentoo Linux ppc64le (4K page size) host. Hardware is a Raptor CS Talos 2 Power 9.
+
+It works with qemu-7.2 so this is a regression in git master (or less likely with the patch).
+
+```
+[niko@talos2 yay]$ makepkg -s
+==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:03:01 PM CET)
+==> Checking runtime dependencies...
+==> Checking buildtime dependencies...
+==> Retrieving sources...
+  -> Found yay-11.3.2.tar.gz
+==> Validating source files with sha256sums...
+    yay-11.3.2.tar.gz ... Passed
+==> Extracting sources...
+  -> Extracting yay-11.3.2.tar.gz with bsdtar
+==> Removing existing $pkgdir/ directory...
+==> Starting build()...
+go build -trimpath -mod=readonly -modcacherw  -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+go: downloading github.com/Jguer/votar v1.0.0
+go: downloading github.com/Jguer/aur v1.0.1
+go: downloading github.com/Jguer/go-alpm/v2 v2.1.2
+go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5
+go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab
+go: downloading github.com/Morganamilo/go-srcinfo v1.0.0
+go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035
+go: downloading github.com/leonelquinteros/gotext v1.5.0
+go: downloading github.com/adrg/strutil v0.3.0
+go: downloading golang.org/x/text v0.3.7
+make: *** [Makefile:113: yay] Illegal instruction (core dumped)
+```
+
+```
+[niko@talos2 yay]$ makepkg -s
+==> Making package: yay 11.3.2-1 (Wed 15 Feb 2023 05:10:01 PM CET)
+==> Checking runtime dependencies...
+==> Checking buildtime dependencies...
+==> Retrieving sources...
+  -> Found yay-11.3.2.tar.gz
+==> Validating source files with sha256sums...
+    yay-11.3.2.tar.gz ... Passed
+==> Extracting sources...
+  -> Extracting yay-11.3.2.tar.gz with bsdtar
+==> Starting build()...
+go build -trimpath -mod=readonly -modcacherw  -ldflags '-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+go: downloading github.com/Jguer/votar v1.0.0
+go: downloading github.com/Jguer/go-alpm/v2 v2.1.2
+go: downloading github.com/Morganamilo/go-srcinfo v1.0.0
+go: downloading github.com/Jguer/aur v1.0.1
+go: downloading github.com/leonelquinteros/gotext v1.5.0
+go: downloading github.com/Morganamilo/go-pacmanconf v0.0.0-20210502114700-cff030e927a5
+go: downloading golang.org/x/term v0.0.0-20220722155259-a9ba230a4035
+go: downloading github.com/adrg/strutil v0.3.0
+go: downloading golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab
+go: downloading golang.org/x/text v0.3.7
+# math/bits
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xabb70a]
+
+goroutine 4 [running]:
+runtime.throw({0xdbf491?, 0x1?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0001d7750 sp=0xc0001d7720 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0001d77b0 sp=0xc0001d7750 pc=0x44f4ea
+cmd/compile/internal/ssa.ValHeap.Less({{0xc0001ae1c0, 0x4, 0x8}, {0xc0001de700, 0x28, 0x100}}, 0x8?, 0xc0001de700?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:59 +0xaa fp=0xc0001d77e0 sp=0xc0001d77b0 pc=0xabb70a
+cmd/compile/internal/ssa.(*ValHeap).Less(0x4?, 0x8?, 0xc0001de700?)
+	<autogenerated>:1 +0x77 fp=0xc0001d7860 sp=0xc0001d77e0 pc=0xad7677
+container/heap.up({0xf24240, 0xc00019eb40}, 0xc00081b370?)
+	/usr/lib/go/src/container/heap/heap.go:92 +0x7e fp=0xc0001d7898 sp=0xc0001d7860 pc=0x7024de
+container/heap.Push({0xf24240, 0xc00019eb40}, {0xdb1f80?, 0xc00081b370?})
+	/usr/lib/go/src/container/heap/heap.go:53 +0x5a fp=0xc0001d78c0 sp=0xc0001d7898 pc=0x7022da
+cmd/compile/internal/ssa.schedule(0xc0004ea000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/schedule.go:349 +0x151c fp=0xc0001d7eb0 sp=0xc0001d78c0 pc=0xabcd9c
+cmd/compile/internal/ssa.Compile(0xc0004ea000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0001dbb68 sp=0xc0001d7eb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071b540, 0x2)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0001dbea8 sp=0xc0001dbb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071b540, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0001dbf70 sp=0xc0001dbea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001dbfb0 sp=0xc0001dbf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001dbfe0 sp=0xc0001dbfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001dbfe8 sp=0xc0001dbfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [semacquire]:
+runtime.gopark(0xc0000062e8?, 0xc00019a050?, 0x0?, 0xa0?, 0x4027dba128?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005ad968 sp=0xc0005ad948 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.semacquire1(0xc0008c4768, 0x20?, 0x1, 0x0, 0x0?)
+	/usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005ad9d0 sp=0xc0005ad968 pc=0x44c9af
+sync.runtime_Semacquire(0xc0008b8000?)
+	/usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005ada08 sp=0xc0005ad9d0 pc=0x46a6e7
+sync.(*WaitGroup).Wait(0xc000659800?)
+	/usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005ada30 sp=0xc0005ada08 pc=0x487deb
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005ada88 sp=0xc0005ada30 pc=0xcc6675
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005adf20 sp=0xc0005ada88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005adf80 sp=0xc0005adf20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005adfe0 sp=0xc0005adf80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005adfe8 sp=0xc0005adfe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009afb0 sp=0xc00009af90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009afe0 sp=0xc00009afb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009afe8 sp=0xc00009afe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 17 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096780 sp=0xc000096760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc0000967c8 sp=0xc000096780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc0000967e0 sp=0xc0000967c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000967e8 sp=0xc0000967e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 18 [GC scavenge wait]:
+runtime.gopark(0xc000194000?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000096f70 sp=0xc000096f50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc000096fa0 sp=0xc000096f70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc000096fc8 sp=0xc000096fa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc000096fe0 sp=0xc000096fc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000096fe8 sp=0xc000096fe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 33 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027cf9f48?, 0x0?, 0x0?, 0xc00009a770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009a628 sp=0xc00009a608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009a7e0 sp=0xc00009a628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009a7e8 sp=0xc00009a7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 49 [select]:
+runtime.gopark(0xc0004e6fb0?, 0x2?, 0xf0?, 0x6d?, 0xc0004e6f6c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0004e6da0 sp=0xc0004e6d80 pc=0x43b716
+runtime.selectgo(0xc0004e6fb0, 0xc0004e6f68, 0xc000504000?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0004e6ee0 sp=0xc0004e6da0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0004e6fe0 sp=0xc0004e6ee0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004e6fe8 sp=0xc0004e6fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 3 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0004f7858 sp=0xc0004f7838 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0004f79e0 sp=0xc0004f7858 pc=0x46f85b
+cmd/compile/internal/ssa.is64BitInt(0xc000141480)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:218 +0xa fp=0xc0004f79e8 sp=0xc0004f79e0 pc=0x7e2e8a
+cmd/compile/internal/ssa.rewriteValueAMD64_OpLoad(0xc00086a458)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:29312 +0x51 fp=0xc0004f7a28 sp=0xc0004f79e8 pc=0x884911
+cmd/compile/internal/ssa.rewriteValueAMD64(0xc00089f678?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewriteAMD64.go:838 +0x31be fp=0xc0004f7a48 sp=0xc0004f7a28 pc=0x819bbe
+cmd/compile/internal/ssa.applyRewrite(0xc0001b2000, 0xdf92a8, 0xdf9348, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssa/rewrite.go:133 +0x1016 fp=0xc0004f7e80 sp=0xc0004f7a48 pc=0x7e27d6
+cmd/compile/internal/ssa.lower(0xc0001b2000?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/lower.go:10 +0x2f fp=0xc0004f7eb0 sp=0xc0004f7e80 pc=0x7b4c4f
+cmd/compile/internal/ssa.Compile(0xc0001b2000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0004fbb68 sp=0xc0004f7eb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071b900, 0x3)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0004fbea8 sp=0xc0004fbb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071b900, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0004fbf70 sp=0xc0004fbea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004fbfb0 sp=0xc0004fbf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004fbfe0 sp=0xc0004fbfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004fbfe8 sp=0xc0004fbfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 50 [runnable]:
+cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc0007ce6d8?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc0000dbbf0 sp=0xc0000dbbe8 pc=0x79c375
+cmd/compile/internal/ssa.flagalloc(0xc0000ca000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc0000dbeb0 sp=0xc0000dbbf0 pc=0x79c0ca
+cmd/compile/internal/ssa.Compile(0xc0000ca000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc0000dfb68 sp=0xc0000dbeb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc00071ba40, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc0000dfea8 sp=0xc0000dfb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc00071ba40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dff70 sp=0xc0000dfea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dffb0 sp=0xc0000dff70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dffe0 sp=0xc0000dffb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dffe8 sp=0xc0000dffe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 51 [runnable]:
+cmd/compile/internal/ssa.(*Value).clobbersFlags(0xc000780d90?)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:243 +0xd5 fp=0xc00091bbf0 sp=0xc00091bbe8 pc=0x79c375
+cmd/compile/internal/ssa.flagalloc(0xc000774540)
+	/usr/lib/go/src/cmd/compile/internal/ssa/flagalloc.go:39 +0x172a fp=0xc00091beb0 sp=0xc00091bbf0 pc=0x79c0ca
+cmd/compile/internal/ssa.Compile(0xc000774540)
+	/usr/lib/go/src/cmd/compile/internal/ssa/compile.go:97 +0x963 fp=0xc00091fb68 sp=0xc00091beb0 pc=0x76bc43
+cmd/compile/internal/ssagen.buildssa(0xc000703900, 0x0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:572 +0x2027 fp=0xc00091fea8 sp=0xc00091fb68 pc=0xaf0527
+cmd/compile/internal/ssagen.Compile(0xc000703900, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc00091ff70 sp=0xc00091fea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc00091ffb0 sp=0xc00091ff70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc00091ffe0 sp=0xc00091ffb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00091ffe8 sp=0xc00091ffe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+# unicode/utf8
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x411410]
+
+goroutine 19 [running]:
+runtime.throw({0xdbf491?, 0x4000804d28?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0004f1830 sp=0xc0004f1800 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0004f1890 sp=0xc0004f1830 pc=0x44f4ea
+runtime.mapaccess2_fast32(0xc0009b3c00, 0xc000562000, 0x6be729)
+	/usr/lib/go/src/runtime/map_fast32.go:53 +0x170 fp=0xc0004f1898 sp=0xc0004f1890 pc=0x411410
+cmd/compile/internal/ssagen.genssa(0xc000562000, 0xc000988ee0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:6964 +0x965 fp=0xc0004f1ea8 sp=0xc0004f1898 pc=0xb27345
+cmd/compile/internal/ssagen.Compile(0xc0000fcb40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0004f1f70 sp=0xc0004f1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0004f1fb0 sp=0xc0004f1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0004f1fe0 sp=0xc0004f1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0004f1fe8 sp=0xc0004f1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [semacquire]:
+runtime.gopark(0x20?, 0xd7ca20?, 0x0?, 0x60?, 0xc00003a600?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0005a9968 sp=0xc0005a9948 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.semacquire1(0xc0006d5a88, 0x20?, 0x1, 0x0, 0x0?)
+	/usr/lib/go/src/runtime/sema.go:160 +0x20f fp=0xc0005a99d0 sp=0xc0005a9968 pc=0x44c9af
+sync.runtime_Semacquire(0xc0000fdb80?)
+	/usr/lib/go/src/runtime/sema.go:62 +0x27 fp=0xc0005a9a08 sp=0xc0005a99d0 pc=0x46a6e7
+sync.(*WaitGroup).Wait(0xc0008ca400?)
+	/usr/lib/go/src/sync/waitgroup.go:116 +0x4b fp=0xc0005a9a30 sp=0xc0005a9a08 pc=0x487deb
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:183 +0x235 fp=0xc0005a9a88 sp=0xc0005a9a30 pc=0xcc6675
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc0005a9f20 sp=0xc0005a9a88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc0005a9f80 sp=0xc0005a9f20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc0005a9fe0 sp=0xc0005a9f80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0005a9fe8 sp=0xc0005a9fe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027cf9fe8?, 0x0?, 0x0?, 0xc00009c770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 49 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0009c1308 sp=0xc0009c12e8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0009c1490 sp=0xc0009c1308 pc=0x46f85b
+cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000754700)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0009c16f0 sp=0xc0009c1490 pc=0x779bb7
+cmd/compile/internal/ssa.BuildFuncDebug(0xc00041e5a0?, 0xc000754700, 0xc000000049?, 0xa?, 0xc00098c000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0009c1898 sp=0xc0009c16f0 pc=0x77adb6
+cmd/compile/internal/ssagen.genssa(0xc000754700, 0xc0004bfce0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0009c1ea8 sp=0xc0009c1898 pc=0xb2790b
+cmd/compile/internal/ssagen.Compile(0xc0000fc8c0, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0009c1f70 sp=0xc0009c1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0009c1fb0 sp=0xc0009c1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0009c1fe0 sp=0xc0009c1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0009c1fe8 sp=0xc0009c1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 5 [select]:
+runtime.gopark(0xc00009e7b0?, 0x2?, 0xf0?, 0xe5?, 0xc00009e76c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009e5a0 sp=0xc00009e580 pc=0x43b716
+runtime.selectgo(0xc00009e7b0, 0xc00009e768, 0x0?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc00009e6e0 sp=0xc00009e5a0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc00009e7e0 sp=0xc00009e6e0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009e7e8 sp=0xc00009e7e0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 50 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0001cd308 sp=0xc0001cd2e8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001cd490 sp=0xc0001cd308 pc=0x46f85b
+cmd/compile/internal/ssa.PopulateABIInRegArgOps(0xc000192000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:436 +0x57 fp=0xc0001cd6f0 sp=0xc0001cd490 pc=0x779bb7
+cmd/compile/internal/ssa.BuildFuncDebug(0xc0001a65a0?, 0xc000192000, 0xc000000049?, 0x12?, 0xc0001a4000)
+	/usr/lib/go/src/cmd/compile/internal/ssa/debug.go:578 +0x1d6 fp=0xc0001cd898 sp=0xc0001cd6f0 pc=0x77adb6
+cmd/compile/internal/ssagen.genssa(0xc000192000, 0xc00019f260)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7157 +0xf2b fp=0xc0001cdea8 sp=0xc0001cd898 pc=0xb2790b
+cmd/compile/internal/ssagen.Compile(0xc0000fca00, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0001cdf70 sp=0xc0001cdea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0001cdfb0 sp=0xc0001cdf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0001cdfe0 sp=0xc0001cdfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0001cdfe8 sp=0xc0001cdfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 20 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0008e10f8 sp=0xc0008e10d8 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0008e1280 sp=0xc0008e10f8 pc=0x46f85b
+cmd/compile/internal/ssagen.AddrAuto(0xc000201ed0, 0x81308171a15?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7649 +0x94 fp=0xc0008e12a8 sp=0xc0008e1280 pc=0xb2d9d4
+cmd/compile/internal/amd64.ssaGenValue(0xc0008bec60, 0xc000781ab0)
+	/usr/lib/go/src/cmd/compile/internal/amd64/ssa.go:1037 +0x13dc fp=0xc0008e1898 sp=0xc0008e12a8 pc=0xb3d6bc
+cmd/compile/internal/ssagen.genssa(0xc0004e4000, 0xc0008e8070)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:7024 +0x3ff8 fp=0xc0008e1ea8 sp=0xc0008e1898 pc=0xb2a9d8
+cmd/compile/internal/ssagen.Compile(0xc0000fcc80, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:195 +0x26f fp=0xc0008e1f70 sp=0xc0008e1ea8 pc=0xae7b8f
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0008e1fb0 sp=0xc0008e1f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0008e1fe0 sp=0xc0008e1fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0008e1fe8 sp=0xc0008e1fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+# internal/reflectlite
+unexpected fault address 0x0
+fatal error: fault
+[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0x66b360]
+
+goroutine 6 [running]:
+runtime.throw({0xdbf491?, 0x8?})
+	/usr/lib/go/src/runtime/panic.go:1047 +0x5d fp=0xc0000dc720 sp=0xc0000dc6f0 pc=0x4389fd
+runtime.sigpanic()
+	/usr/lib/go/src/runtime/signal_unix.go:851 +0x28a fp=0xc0000dc780 sp=0xc0000dc720 pc=0x44f4ea
+cmd/compile/internal/abi.(*assignState).regAllocate(0xc0000dc7a0, 0x41b2b1, {0x14cdd40, 0xc0000dc808}, 0xa8)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:607 fp=0xc0000dc788 sp=0xc0000dc780 pc=0x66b360
+cmd/compile/internal/abi.(*assignState).assignParamOrReturn(0xc0000dc8a8, 0xc0008977a0, {0xf23198, 0xc000a0b080}, 0x20?)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:777 +0x165 fp=0xc0000dc840 sp=0xc0000dc788 pc=0x66bae5
+cmd/compile/internal/abi.(*ABIConfig).ABIAnalyzeFuncType(0xc0000bca60, 0xc00089b710)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:404 +0x3d7 fp=0xc0000dc9f8 sp=0xc0000dc840 pc=0x669a17
+cmd/compile/internal/abi.(*ABIConfig).ABIAnalyze(0xd41a80?, 0xc0000d0600?, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/abi/abiutils.go:432 +0x5d fp=0xc0000dcb68 sp=0xc0000dc9f8 pc=0x669e7d
+cmd/compile/internal/ssagen.buildssa(0xc0008cc500, 0x1)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:455 +0x1209 fp=0xc0000dcea8 sp=0xc0000dcb68 pc=0xaef709
+cmd/compile/internal/ssagen.Compile(0xc0008cc500, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000dcf70 sp=0xc0000dcea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000dcfb0 sp=0xc0000dcf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000dcfe0 sp=0xc0000dcfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000dcfe8 sp=0xc0000dcfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 1 [runnable]:
+runtime.gopark(0xc0000be000?, 0xc0004edec0?, 0xb0?, 0x99?, 0xc000739978?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc000739910 sp=0xc0007398f0 pc=0x43b716
+runtime.chansend(0xc000d540c0, 0xc0007399e8, 0x1, 0xc0007399d8?)
+	/usr/lib/go/src/runtime/chan.go:259 +0x42e fp=0xc000739998 sp=0xc000739910 pc=0x40602e
+runtime.chansend1(0xd7ca20?, 0x4000803501?)
+	/usr/lib/go/src/runtime/chan.go:145 +0x1d fp=0xc0007399c8 sp=0xc000739998 pc=0x405bdd
+cmd/compile/internal/gc.compileFunctions.func4(0xc00180cc40)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:160 +0x27 fp=0xc0007399e8 sp=0xc0007399c8 pc=0xcc68a7
+cmd/compile/internal/gc.compileFunctions.func5({0xc001099500, 0x222, 0x350?})
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:170 +0x53 fp=0xc000739a30 sp=0xc0007399e8 pc=0xcc6713
+cmd/compile/internal/gc.compileFunctions()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:181 +0x1ff fp=0xc000739a88 sp=0xc000739a30 pc=0xcc663f
+cmd/compile/internal/gc.Main(0xdf8e28)
+	/usr/lib/go/src/cmd/compile/internal/gc/main.go:332 +0x13aa fp=0xc000739f20 sp=0xc000739a88 pc=0xcc86aa
+main.main()
+	/usr/lib/go/src/cmd/compile/main.go:57 +0xdd fp=0xc000739f80 sp=0xc000739f20 pc=0xcf00bd
+runtime.main()
+	/usr/lib/go/src/runtime/proc.go:250 +0x207 fp=0xc000739fe0 sp=0xc000739f80 pc=0x43b2e7
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000739fe8 sp=0xc000739fe0 pc=0x46e201
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009cfb0 sp=0xc00009cf90 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.forcegchelper()
+	/usr/lib/go/src/runtime/proc.go:305 +0xb0 fp=0xc00009cfe0 sp=0xc00009cfb0 pc=0x43b550
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009cfe8 sp=0xc00009cfe0 pc=0x46e201
+created by runtime.init.6
+	/usr/lib/go/src/runtime/proc.go:293 +0x25
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009d780 sp=0xc00009d760 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.bgsweep(0x0?)
+	/usr/lib/go/src/runtime/mgcsweep.go:278 +0x8e fp=0xc00009d7c8 sp=0xc00009d780 pc=0x425cce
+runtime.gcenable.func1()
+	/usr/lib/go/src/runtime/mgc.go:178 +0x26 fp=0xc00009d7e0 sp=0xc00009d7c8 pc=0x41aee6
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009d7e8 sp=0xc00009d7e0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:178 +0x6b
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc0000380e0?, 0xf1ad58?, 0x1?, 0x0?, 0x0?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009df70 sp=0xc00009df50 pc=0x43b716
+runtime.goparkunlock(...)
+	/usr/lib/go/src/runtime/proc.go:387
+runtime.(*scavengerState).park(0x1487ce0)
+	/usr/lib/go/src/runtime/mgcscavenge.go:400 +0x53 fp=0xc00009dfa0 sp=0xc00009df70 pc=0x423c13
+runtime.bgscavenge(0x0?)
+	/usr/lib/go/src/runtime/mgcscavenge.go:628 +0x45 fp=0xc00009dfc8 sp=0xc00009dfa0 pc=0x4241e5
+runtime.gcenable.func2()
+	/usr/lib/go/src/runtime/mgc.go:179 +0x26 fp=0xc00009dfe0 sp=0xc00009dfc8 pc=0x41ae86
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009dfe8 sp=0xc00009dfe0 pc=0x46e201
+created by runtime.gcenable
+	/usr/lib/go/src/runtime/mgc.go:179 +0xaa
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x43ba92?, 0x4027d38828?, 0x0?, 0x0?, 0xc00009c770?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc00009c628 sp=0xc00009c608 pc=0x43b716
+runtime.runfinq()
+	/usr/lib/go/src/runtime/mfinal.go:193 +0x107 fp=0xc00009c7e0 sp=0xc00009c628 pc=0x419f27
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc00009c7e8 sp=0xc00009c7e0 pc=0x46e201
+created by runtime.createfing
+	/usr/lib/go/src/runtime/mfinal.go:163 +0x45
+
+goroutine 5 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc000194658 sp=0xc000194638 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0001947e0 sp=0xc000194658 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc0001fe500, {0xf2a400, 0xc000a990a0?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1432 +0xbb fp=0xc000194b68 sp=0xc0001947e0 pc=0xaf509b
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d9540, 0x2)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc000194ea8 sp=0xc000194b68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d9540, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc000194f70 sp=0xc000194ea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc000194fb0 sp=0xc000194f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc000194fe0 sp=0xc000194fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc000194fe8 sp=0xc000194fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 33 [select]:
+runtime.gopark(0xc0000997b0?, 0x2?, 0xf0?, 0x95?, 0xc00009976c?)
+	/usr/lib/go/src/runtime/proc.go:381 +0xd6 fp=0xc0000995a0 sp=0xc000099580 pc=0x43b716
+runtime.selectgo(0xc0000997b0, 0xc000099768, 0xc000110000?, 0x0, 0xd26040?, 0x1)
+	/usr/lib/go/src/runtime/select.go:327 +0x7be fp=0xc0000996e0 sp=0xc0000995a0 pc=0x44b8be
+cmd/compile/internal/gc.compileFunctions.func3()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:141 +0x132 fp=0xc0000997e0 sp=0xc0000996e0 pc=0xcc6a12
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000997e8 sp=0xc0000997e0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:134 +0xf8
+
+goroutine 22 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0000ad2d0 sp=0xc0000ad2b0 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc0000ad458 sp=0xc0000ad2d0 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf295c0, 0xc00134d450?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0000ad7e0 sp=0xc0000ad458 pc=0xaf517a
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.(*state).stmt(0xc0016ada00, {0xf29800, 0xc0013eebc0?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1441 +0x45e5 fp=0xc0000adb68 sp=0xc0000ad7e0 pc=0xaf95c5
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d8b40, 0x3)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc0000adea8 sp=0xc0000adb68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d8b40, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc0000adf70 sp=0xc0000adea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc0000adfb0 sp=0xc0000adf70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc0000adfe0 sp=0xc0000adfb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc0000adfe8 sp=0xc0000adfe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+
+goroutine 49 [runnable]:
+runtime.asyncPreempt2()
+	/usr/lib/go/src/runtime/preempt.go:307 +0x3f fp=0xc0017932d0 sp=0xc0017932b0 pc=0x439e1f
+runtime.asyncPreempt()
+	/usr/lib/go/src/runtime/preempt_amd64.s:53 +0xdb fp=0xc001793458 sp=0xc0017932d0 pc=0x46f85b
+cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf295c0, 0xc00140a960?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1455 +0x19a fp=0xc0017937e0 sp=0xc001793458 pc=0xaf517a
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.(*state).stmt(0xc001794000, {0xf2a400, 0xc000a92a10?})
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1436 +0x150 fp=0xc001793b68 sp=0xc0017937e0 pc=0xaf5130
+cmd/compile/internal/ssagen.(*state).stmtList(...)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:1421
+cmd/compile/internal/ssagen.buildssa(0xc0005d9680, 0x0)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/ssa.go:552 +0x1ee6 fp=0xc001793ea8 sp=0xc001793b68 pc=0xaf03e6
+cmd/compile/internal/ssagen.Compile(0xc0005d9680, 0x0?)
+	/usr/lib/go/src/cmd/compile/internal/ssagen/pgen.go:185 +0x4c fp=0xc001793f70 sp=0xc001793ea8 pc=0xae796c
+cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:171 +0x3a fp=0xc001793fb0 sp=0xc001793f70 pc=0xcc681a
+cmd/compile/internal/gc.compileFunctions.func3.1()
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:153 +0x32 fp=0xc001793fe0 sp=0xc001793fb0 pc=0xcc6c52
+runtime.goexit()
+	/usr/lib/go/src/runtime/asm_amd64.s:1598 +0x1 fp=0xc001793fe8 sp=0xc001793fe0 pc=0x46e201
+created by cmd/compile/internal/gc.compileFunctions.func3
+	/usr/lib/go/src/cmd/compile/internal/gc/compile.go:152 +0x245
+```
+Steps to reproduce:
+1. Create an Arch Linux chroot from a bootstrap tarball: https://wiki.archlinux.org/title/Install_Arch_Linux_from_existing_Linux#Method_A:_Using_the_bootstrap_tarball_(recommended)
+2. Chroot into it using the following script:
+```
+#!/bin/bash
+
+basedir="/home/niko/chroots/arch-x86_64"
+cp /etc/resolv.conf ${basedir}/etc/
+cp /usr/bin/qemu-x86_64 ${basedir}/usr/bin/
+sed -i 's!#Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$arch!Server = http://archlinux.mirror.garr.it/archlinux/$repo/os/$a>
+mount --make-slave --bind  ${basedir} ${basedir}
+mount -t proc none ${basedir}/proc
+mount -t sysfs none ${basedir}/sys/
+mount --make-rslave --rbind /dev ${basedir}/dev
+mount --make-rslave --rbind /run ${basedir}/run
+chroot ${basedir} /bin/bash
+sleep 3
+umount -R ${basedir}/run
+umount -R ${basedir}/dev
+umount ${basedir}/sys
+umount ${basedir}/proc
+umount ${basedir}
+mount | grep chroots | grep arch-x86_64 | grep -v snap
+```
+3. Initialize pacaman keyring and update system:
+```
+# pacman-key --init
+# pacman-key --populate
+# pacman -Syu
+```
+4. Download the yay `PKGBUILD` from the AUR (https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=yay) and run `makepkg -s`
+5. Wait for the crash.
+Additional information:
+```
+Wed 2023-02-15 17:03:22 CET   495600 1000 1000 SIGILL  present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
+Wed 2023-02-15 17:11:25 CET   509058 1000 1000 SIGSEGV present  /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64                         >
+talos2 ~ # coredumpctl gdb 495600
+           PID: 495600 (go)
+           UID: 1000 (niko)
+           GID: 1000 (niko)
+        Signal: 4 (ILL)
+     Timestamp: Wed 2023-02-15 17:03:21 CET (13min ago)
+  Command Line: /usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldflags $'-X "main.yayVersion=11.3.2" -X "main.localePath=/usr/share/locale/" -linkmode=external' -buildmode=pie -o yay
+    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+          Unit: user@1000.service
+     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (niko)
+       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
+    Machine ID: b3e834569b8ff461391f5ac061feb773
+      Hostname: talos2
+       Storage: /var/lib/systemd/coredump/core.go.1000.33cad872d21043ebbe3dd6581bdd28c6.495600.1676477001000000.zst (present)
+  Size on Disk: 7.4M
+       Message: Process 495600 (go) of user 1000 dumped core.
+
+GNU gdb (Gentoo 12.1 vanilla) 12.1
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "powerpc64le-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.gentoo.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
+BFD: warning: /var/tmp/coredump-8CHpqc: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
+
+warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libresolv.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/f2/f2133743f1bb49d82c152c57fea6c71755a865029a19ff845dd27e420f5fa0be-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/89/89e115246dee235465b64002c5ab8a7df3a3f1b776d78dab9cd937c4892860a0-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/79/791d1887c70eed91dc52577c14310590649cb307ef557d46d8cc10df4704a957-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/86/86d5a3a0121a98ed0805aa57bc14d0bd85178c04054816d99495336d86c5bf5f-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/31/31d19f3051c8985f29f85ea43d9445e4b848c58a17a79d4e726280a9bced5743-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/79/79d75d9215f18cbef6b6a66468f78efd92edc13f7093f600b1552032732410aa-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/bc/bcdca8f344789eb190a1124fe919aa975d08f07250bfc6d780b0ae0cc28092fe-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/86/86e73e7b053ab6e1e1d149b5d1bbba621bfc3d0bbc66ec6310c072c82a7221e7-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/b1/b12eb8399331175352cb92b971280ba5c0c501c6ffa5c330921c3c0667c5f199-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/32/3264d3f95a5e2e731c952060b0cd4cb3bc37ff884513397336d40c935d098e5b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/19/1977592d2d60e1dd1025609428d04f6cc17283759aae0c97bd8f35e8a341679b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/a9/a9b261a012c19401c1fd78154a20f58bb7778e731e17f903eb3fe8ed3a5ddd59-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/96/9697f94a563c1bd04db2a82ac1770821f97548911f616dd1149bb87d0f48d65b-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/56/56e54c1dc0b6bee517915ce0bdf694a3b94f4de88b2cabb987b645e1255594fb-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/7e/7e9d9d14f25fe76951999c17680e09a181c5f14c9c4f30fe6bff8d0d669590c3-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/f4/f431652315a861a2a85b47ae12cfc99734b3db4754aa35c9158254e4ba3507c0-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/1c/1c51052ad1af6b1a1575f9bbc3f4616ed673578a285ae9a29f5548eed68c05dd-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/be/be3037525f021f1d7e2e8499d3dcc0f44be39adf70eb91979c96db3e5645bcf1-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/55/557fa6c4030abc2d7b6407ce3093ae5772939f1a2595be09dd670ecd1c5ec8f2-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/69/69a73f1b9f395cf4a1666dde8d7971a0bd9313fbfa55a5109eb02e59b301be09-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/ab/abc0750a5bd45b2346aa5bc87092f67207e9436307e3e32cb470952f87d13fb6-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/da/dadc71547f56ab68eccefd0d571599f99739a3d75acc444d97829d6ab62a6922-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/91/915619420aacc3b5964e7537365661258ab52ec44fb7ab29790258822c793de5-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/68/6834d594cb4ffe53979a0c4611bb5200e6e0c580acb42f4383ed2fb6a93d758d-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/c6/c6ccbc76ef432925fc1a5ea22ab750ac591f3e8983d2f33f54b01c799e3a274d-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/89/893c62418d079bf692b5ff17db226ae3d0fefdc87cbd0c64f30c437677a288ec-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d8/d8666c5d7807c5a08b30f2278a1efd691c188804b3090704bd0b3f8ef06c40d9-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d4/d401ca16783c19ff776f35305023173b63e2610e313b9a793734af80afda4e83-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/d0/d0593989dbf79e26b8bf6705325c6b44044e560a22c3ab81d320c67dcd97f1eb-d during file-backed mapping note processing
+
+warning: Can't open file /home/niko/.cache/go-build/57/572953ae015634b922f88b0191804a949206100adb6bd2454db615e2774dbe30-d during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_mymachines.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libcap.so.2.67 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgcc_s.so.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_resolve.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libnss_myhostname.so.2 during file-backed mapping note processing
+
+warning: core file may not match specified executable file.
+[New LWP 495627]
+[New LWP 495604]
+[New LWP 495603]
+[New LWP 495614]
+[New LWP 495602]
+[New LWP 495610]
+[New LWP 495618]
+[New LWP 495606]
+[New LWP 495621]
+[New LWP 495608]
+[New LWP 495612]
+[New LWP 495629]
+[New LWP 495615]
+[New LWP 495622]
+[New LWP 495600]
+[New LWP 495605]
+[New LWP 495623]
+[New LWP 495630]
+[New LWP 495616]
+[New LWP 495633]
+[New LWP 495634]
+[New LWP 495635]
+[New LWP 495636]
+[New LWP 495637]
+[New LWP 495632]
+[New LWP 495609]
+[New LWP 495620]
+[New LWP 495617]
+[New LWP 495624]
+[New LWP 495628]
+[New LWP 495625]
+[New LWP 495607]
+[New LWP 495613]
+[New LWP 495626]
+[New LWP 495619]
+[New LWP 495611]
+[New LWP 495631]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/usr/lib64/libthread_db.so.1".
+Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/go build -trimpath -mod=readonly -modcacherw -ldf'.
+Program terminated with signal SIGILL, Illegal instruction.
+#0  0x00003fff9d5d7284 in code_gen_buffer ()
+[Current thread is 1 (Thread 0x3fff4bf3c380 (LWP 495627))]
+(gdb) info threads
+  Id   Target Id                          Frame 
+* 1    Thread 0x3fff4bf3c380 (LWP 495627) 0x00003fff9d5d7284 in code_gen_buffer ()
+  2    Thread 0x3fffa85ec380 (LWP 495604) 0x000000001029ba2c in __lll_lock_wait ()
+  3    Thread 0x3fffa862d380 (LWP 495603) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  4    Thread 0x3fffa8362380 (LWP 495614) 0x00000000100ef210 in tb_jmp_cache_get_tb (hash=3271, jc=0x3fff6c00c5c0)
+    at ../accel/tcg/tb-jmp-cache.h:38
+  5    Thread 0x3fffa8eaf380 (LWP 495602) 0x00000000102cf6ec in syscall ()
+  6    Thread 0x3fffa8466380 (LWP 495610) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  7    Thread 0x3fffa815d380 (LWP 495618) 0x00000000101e07c8 in g_hash_table_lookup ()
+  8    Thread 0x3fffa856a380 (LWP 495606) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  9    Thread 0x3fffa809a380 (LWP 495621) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  10   Thread 0x3fffa84e8380 (LWP 495608) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  11   Thread 0x3fffa83e4380 (LWP 495612) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  12   Thread 0x3fff4beba380 (LWP 495629) 0x00003fff9c1c84b8 in code_gen_buffer ()
+  13   Thread 0x3fffa8321380 (LWP 495615) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  14   Thread 0x3fffa86ae380 (LWP 495622) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  15   Thread 0x200f4000 (LWP 495600)     safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  16   Thread 0x3fffa85ab380 (LWP 495605) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  17   Thread 0x3fffa8059380 (LWP 495623) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  18   Thread 0x3fff4be79380 (LWP 495630) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  19   Thread 0x3fffa82e0380 (LWP 495616) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  20   Thread 0x3fff4bdb6380 (LWP 495633) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  21   Thread 0x3fff4bd75380 (LWP 495634) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  22   Thread 0x3fff4bd34380 (LWP 495635) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  23   Thread 0x3fff4bcf3380 (LWP 495636) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  24   Thread 0x3fff4bcb2380 (LWP 495637) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  25   Thread 0x3fff4bdf7380 (LWP 495632) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  26   Thread 0x3fffa84a7380 (LWP 495609) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  27   Thread 0x3fffa80db380 (LWP 495620) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  28   Thread 0x3fffa829f380 (LWP 495617) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  29   Thread 0x3fff4bfff380 (LWP 495624) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  30   Thread 0x3fff4befb380 (LWP 495628) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  31   Thread 0x3fff4bfbe380 (LWP 495625) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  32   Thread 0x3fffa8529380 (LWP 495607) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  33   Thread 0x3fffa83a3380 (LWP 495613) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  34   Thread 0x3fff4bf7d380 (LWP 495626) 0x00003fff9d5d7284 in code_gen_buffer ()
+  35   Thread 0x3fffa811c380 (LWP 495619) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  36   Thread 0x3fffa8425380 (LWP 495611) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+  37   Thread 0x3fff4be38380 (LWP 495631) safe_syscall_base () at ../common-user/host/ppc64/safe-syscall.inc.S:75
+(gdb) quit
+talos2 ~ # coredumpctl gdb 509058
+           PID: 509058 (make)
+           UID: 1000 (niko)
+           GID: 1000 (niko)
+        Signal: 11 (SEGV)
+     Timestamp: Wed 2023-02-15 17:11:24 CET (6min ago)
+  Command Line: /usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/pkg/yay PREFIX=/usr build
+    Executable: /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64
+ Control Group: /user.slice/user-1000.slice/user@1000.service/session.slice/vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+          Unit: user@1000.service
+     User Unit: vte-spawn-a3a4897b-7df3-4b3e-a8fc-91898d4e7b51.scope
+         Slice: user-1000.slice
+     Owner UID: 1000 (niko)
+       Boot ID: 33cad872d21043ebbe3dd6581bdd28c6
+    Machine ID: b3e834569b8ff461391f5ac061feb773
+      Hostname: talos2
+       Storage: /var/lib/systemd/coredump/core.make.1000.33cad872d21043ebbe3dd6581bdd28c6.509058.1676477484000000.zst (present)
+  Size on Disk: 1.0M
+       Message: Process 509058 (make) of user 1000 dumped core.
+
+GNU gdb (Gentoo 12.1 vanilla) 12.1
+Copyright (C) 2022 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "powerpc64le-unknown-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://bugs.gentoo.org/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from /home/niko/chroots/arch-x86_64/usr/bin/qemu-x86_64...
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000002
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001
+BFD: warning: /var/tmp/coredump-jyYs2x: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002
+
+warning: Can't open file /usr/lib/ld-linux-x86-64.so.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libguile-3.0.so.1.6.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libc.so.6 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgc.so.1.5.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libffi.so.8.1.2 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libunistring.so.5.0.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libgmp.so.10.4.1 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libcrypt.so.2.0.0 during file-backed mapping note processing
+
+warning: Can't open file /usr/lib/libm.so.6 during file-backed mapping note processing
+
+warning: core file may not match specified executable file.
+[New LWP 509058]
+[New LWP 509060]
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/usr/lib64/libthread_db.so.1".
+Core was generated by `/usr/bin/qemu-x86_64 /usr/bin/make VERSION=11.3.2 DESTDIR=/home/niko/devel/yay/'.
+Program terminated with signal SIGSEGV, Segmentation fault.
+#0  0x0000000010278798 in sigsuspend ()
+[Current thread is 1 (Thread 0x1bde9000 (LWP 509058))]
+(gdb) info threads
+  Id   Target Id                          Frame 
+* 1    Thread 0x1bde9000 (LWP 509058)     0x0000000010278798 in sigsuspend ()
+  2    Thread 0x3fffae0ef380 (LWP 509060) 0x00000000102cf6ec in syscall ()
+(gdb) quit
+```
+
+Download coredumps:
+
+https://drive.google.com/file/d/1GosaobKvmuRg-olaA1-aZcp7zAZcWmcF/view?usp=share_link
+
+https://drive.google.com/file/d/1N0BmlBIYY-qT5lHqlrKXvPL_FdYl3GfI/view?usp=share_link
diff --git a/results/classifier/gemma3:27b/runtime/1495 b/results/classifier/gemma3:27b/runtime/1495
new file mode 100644
index 00000000..705279de
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1495
@@ -0,0 +1,9 @@
+
+
+
+MacOS fails check-unit for test-io-channel-command for some reason
+Description of problem:
+While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709
+Steps to reproduce:
+1. install socat
+2. make check-unit
diff --git a/results/classifier/gemma3:27b/runtime/1512 b/results/classifier/gemma3:27b/runtime/1512
new file mode 100644
index 00000000..ff48c090
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1512
@@ -0,0 +1,4 @@
+
+
+
+AVX/AVX2 not correcly detected in user mode
diff --git a/results/classifier/gemma3:27b/runtime/1519037 b/results/classifier/gemma3:27b/runtime/1519037
new file mode 100644
index 00000000..73971ba4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1519037
@@ -0,0 +1,10 @@
+
+
+
+qemu-i386 32-bit segfault
+
+I'm getting segfaults on 32-bit linux trying to run binaries using qemu-i386 from git. These segfaults go away when run in gdb or strace - could it be about the environment somehow?
+
+In contrast qemu-x86_64 works fine. How can I pinpoint the cause of this? 
+
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1527765 b/results/classifier/gemma3:27b/runtime/1527765
new file mode 100644
index 00000000..4fce454c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1527765
@@ -0,0 +1,75 @@
+
+
+
+sh4: ghc randomly segfaults on qemu-sh4-static
+
+Hello!
+
+I am currently in the process of bootstrapping ghc for the Debian sh4 port and ran into a strange problem with qemu-sh4-static which randomly segfaults when running ghc to compile a Haskell source:
+
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ls
+Main.hi  Main.hs  Setup.hs  ghc-pwd.cabal  ghc.mk
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+[1 of 1] Compiling Main             ( Main.hs, Main.o )
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+[1 of 1] Compiling Main             ( Main.hs, Main.o )
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+[1 of 1] Compiling Main             ( Main.hs, Main.o )
+Bad interface file: /usr/local/lib/sh4-unknown-linux-gnu-ghc-7.10.3/time/dist-install/build/Data/Time/Format/Parse.hi
+    ghc: panic! (the 'impossible' happened)
+  (GHC version 7.10.3 for sh4-unknown-linux):
+	getSymtabName:unknown known-key unique
+<<details unavailable>>
+
+Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
+
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd# ghc Main.hs
+/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+[1 of 1] Compiling Main             ( Main.hs, Main.o )
+Linking Main ...
+root@jessie32:~/ghc-7.8.4/utils/ghc-pwd#
+
+As seen above, compiling a Haskell source code often results in a segfault but simply by retrying to run ghc over and over again, the compile process will eventually succeed and no segfault occurs.
+
+I have created a tarball which contains the sh4 chroot from the example above which also includes ghc, gcc and the source code in question (in /root/ghc-7.8.4/utils/ghc-pwd). To test, it's probably a good idea to replace the qemu-sh4-static binary in /usr/bin with a current git snapshot (which I tried but didn't help).
+
+> http://users.physik.fu-berlin.de/~glaubitz/sid-sh4-sbuild-ghc.tgz
+
+In case anyone wants to try ghc with their own sh4 chroot, here's my version of ghc:
+
+> https://people.debian.org/~glaubitz/sh4-unknown-linux-gnu-ghc-7.10.3.tar.gz
+
+Just extract in the chroot of the sh4 chroot.
+
+Please note, that it might be advisable on sh4 to apply the patches from these two bug reports as otherwise qemu-sh4-static won't work properly on sh4 and misses syscall 186:
+
+> https://bugs.launchpad.net/ubuntu/+source/qemu-linaro/+bug/1254824
+> https://bugs.launchpad.net/qemu/+bug/1516408
+
+The above issue is reproducible with the two patches applied and without. It's also reproducible with both libc6 2.19 and 2.21 in the chroot. Thus, I am currently out of ideas what else to test.
+
+Cheers,
+Adrian
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1528 b/results/classifier/gemma3:27b/runtime/1528
new file mode 100644
index 00000000..83543fca
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1528
@@ -0,0 +1,12 @@
+
+
+
+ppc64le: qemu-arm: basic hello world fails with "user-exec.c:492: page_set_flags: Assertion `start < end' failed."
+Description of problem:
+Trying to utilize a RH8 enterprise POWER9 based server to build OpenBMC which utilizes qemu under the covers to validate cross compiles. After some debug, I found that a basic hello-world cross compiled application does not work on POWER9 hardware.
+Steps to reproduce:
+1. Create basic hello world .c file, cross compile it for arm (arm-linux-gnueabi-gcc hello.c -o hello)
+2. Build latest qemu-arm from master
+3. Run qemu-arm against hello world binary
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1528239 b/results/classifier/gemma3:27b/runtime/1528239
new file mode 100644
index 00000000..77560ec1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1528239
@@ -0,0 +1,48 @@
+
+
+
+Unable to debug PIE binaries with QEMU gdb stub.
+
+The issue occurs on current trunk:
+
+max@max:~/build/qemu$ cat test.c
+#include <stdio.h>
+
+int main() {
+  printf("Hello, world!\n");
+  return 0;
+}
+
+max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x
+max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x 
+.............................
+
+
+max@max:~/build/qemu$ gdb
+GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
+........................................................................................
+(gdb) file bad.x
+Reading symbols from bad.x...(no debugging symbols found)...done.
+(gdb) b main
+Breakpoint 1 at 0x779
+(gdb) target remote localhost:1234
+Remote debugging using localhost:1234
+Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
+
+Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
+done.
+Loaded symbols for /lib64/ld-linux-x86-64.so.2
+Error in re-setting breakpoint 1: Cannot access memory at address 0x775
+Error in re-setting breakpoint 1: Cannot access memory at address 0x775
+0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2
+(gdb) c
+Continuing.
+[Inferior 1 (Remote target) exited normally]
+(gdb) 
+
+
+max@max:~/build/qemu$ cat config.log
+# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static'
+
+
+W/O QEMU or -pie flag breakpoint on main works fine.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1541 b/results/classifier/gemma3:27b/runtime/1541
new file mode 100644
index 00000000..a677253a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1541
@@ -0,0 +1,35 @@
+
+
+
+Invalid position of G_NORETURN in clang v15
+Description of problem:
+Order of `G_NORETURN` used in https://gitlab.com/qemu-project/qemu/-/blob/0f3de970febd2c9b29dccecb63ca928c6802a101/include/qemu/osdep.h#L240-242 is not valid in clang++ 15.0.7.
+
+Switching `extern` with `G_NORETURN` seems to fix the issue.
+Steps to reproduce:
+1. Build qemu system for MIPSEL or use minimal reproducer:
+
+`example.cpp`:
+```
+#include "/path/to/qemu/include/glib-compat.h"
+
+extern G_NORETURN
+void // QEMU_ERROR("code path is reachable")
+    qemu_build_not_reached_always(void);
+```
+
+```
+$ clang++ --version
+clang version 15.0.7
+Target: x86_64-pc-linux-gnu
+Thread model: posix
+InstalledDir: /usr/bin
+$ clang++ -m64 -mcx16 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu++11 -O0 -g example.cpp
+example.cpp:3:8: error: an attribute list cannot appear here
+extern G_NORETURN
+       ^~~~~~~~~~
+/usr/include/glib-2.0/glib/gmacros.h:1075:21: note: expanded from macro 'G_NORETURN'
+# define G_NORETURN [[noreturn]]
+                    ^~~~~~~~~~~~
+1 error generated.
+```
diff --git a/results/classifier/gemma3:27b/runtime/1547 b/results/classifier/gemma3:27b/runtime/1547
new file mode 100644
index 00000000..87973015
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1547
@@ -0,0 +1,15 @@
+
+
+
+POWER9 emulation is broken when compiler optimizations are on (for gcc 11.3 and later)
+Description of problem:
+Comparing two floating point memory operands produces incorrect result
+Steps to reproduce:
+1. Unpack attached archive and change to test_p64 directory
+2. Build the source file with: powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64
+3. Run with QEMU: qemu-ppc64le -cpu POWER9 test_p64 > output.txt
+4. Check the output text file output.txt (with pluma or any other text editor) to see the printouts
+Additional information:
+The pre-built binary and its output file are attached as test_p64.tar.gz[test_p64.tar.gz](/uploads/0e9dbc22e6841496efc15775e6aa624a/test_p64.tar.gz)
+
+The purpose of this report is to motivate the creation of a point release QEMU 6.2.1 for Ubuntu 22.04 LTS (which will be supported for years to come). Also cross-linking similar bug report for MIPS with exact same goal: https://gitlab.com/qemu-project/qemu/-/issues/1531
diff --git a/results/classifier/gemma3:27b/runtime/1550503 b/results/classifier/gemma3:27b/runtime/1550503
new file mode 100644
index 00000000..2471785e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1550503
@@ -0,0 +1,16 @@
+
+
+
+target-arm/helper.c:5493: bad test ?
+
+[qemu/target-arm/helper.c:5493]: (style) Expression '(X & 0x1f) != 0xf80f0000' is always true.
+
+Source code is
+
+        (env->uncached_cpsr & CPSR_M) != CPSR_USER &&
+
+but
+
+./qemu/target-arm/cpu.h:#define CPSR_M (0x1fU)
+
+./qemu/target-arm/cpu.h:#define CPSR_USER (CPSR_NZCV | CPSR_Q | CPSR_GE)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1553 b/results/classifier/gemma3:27b/runtime/1553
new file mode 100644
index 00000000..89fab3c5
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1553
@@ -0,0 +1,15 @@
+
+
+
+Build error: implicit declaration of function 'qemu_close_to_socket'
+Description of problem:
+When build the latest master code with MSYS2 on Windows 10, GCC reports:
+../ui/spice-core.c: In function 'watch_remove':
+../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration]
+  152 |     qemu_close_to_socket(watch->fd);
+      |     ^~~~~~~~~~~~~~~~~~~~
+../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs]
+Steps to reproduce:
+1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu
+2. cd build
+3. make
diff --git a/results/classifier/gemma3:27b/runtime/1568107 b/results/classifier/gemma3:27b/runtime/1568107
new file mode 100644
index 00000000..7518d6f0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1568107
@@ -0,0 +1,12 @@
+
+
+
+x86_64 linux-user: setup_rt_frame: not implemented
+
+Trying to run this binary (https://github.com/ethcore/parity/releases/download/v1.0.1/parity_linux_1.0.1-0_amd64.deb) under qemu-x86_64 on ARM, ends like this:
+
+$ qemu-x86_64 parity --pruning fast 
+
+setup_rt_frame: not implemented
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1585840 b/results/classifier/gemma3:27b/runtime/1585840
new file mode 100644
index 00000000..71d86971
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1585840
@@ -0,0 +1,12 @@
+
+
+
+multiprocess program gets incorrect results with qemu arm-linux-user
+
+The attached program can run either in a threaded mode or a multiprocess mode.  It defaults to threaded mode, and switches to multiprocess mode if the first positional argument is "process".  "success" of the test is defined as the final count being seen as 2000000 by both tasks.
+
+In standard linux x86_64 userspace (i7, 4 cores) and in standard armhf userspace (4 cores), the test program consistently completes successfully in both modes.  But with qemu arm-linux-user, the test consistently succeeds in threaded mode and generally fails in multiprocess mode.
+
+The test reflects an essential aspect of how the Free and Open Source project linuxcnc's IPC system works: shared memory regions (created by shmat, but mmap would probably behave the same) contain data and mutexes.  I observed that our testsuite encounters numerous deadlocks and failures when running in an schroot with qemu-user (x86_64 host), and I believe the underlying cause is improper support for atomic operations in a multiprocess model. (the testsuite consistently passes on real hardware)
+
+I observed the same failure at v1.6.0 and master (v2.6.0-424-g287db79), as well as in the outdated Debian version 1:2.1+dfsg-12+deb8u5a.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1591611 b/results/classifier/gemma3:27b/runtime/1591611
new file mode 100644
index 00000000..6d7918b8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1591611
@@ -0,0 +1,26 @@
+
+
+
+chroot using qemu-x86_64-static fails on ppc64el
+
+When attempting to use qemu-x86_64-static from qemu 2.5.0 on a ppc64el host to chroot into an amd64 environment, all commands fail with an assertion error.  /usr/bin/qemu-x86_64-static from the host was copied into the chroot /usr/bin, and the host has multiformat support in the kernel.
+
+Sample output illustrating the problem, as well as bash builtins working:
+
+# chroot /virtualbox/scratchdisks_local_001/amd64_chroot qemu-x86_64-static /bin/bash
+# ls
+bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed.
+setup_frame: not implemented
+setup_frame: not implemented
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+setup_frame: not implemented
+setup_frame: not implemented
+# echo TEST
+TEST
+# cat test
+bash: ../sysdeps/nptl/fork.c:136: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (__builtin_offsetof (struct pthread, tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (__builtin_offsetof (struct pthread, tid))); } __value; }) != ppid' failed.
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+It is currently unknown if other host architectures (e.g. aarch64) are also affected.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1593 b/results/classifier/gemma3:27b/runtime/1593
new file mode 100644
index 00000000..6ad5a6ae
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1593
@@ -0,0 +1,10 @@
+
+
+
+SLIRP hostfwd ignores bind address and uses `INADDR_ANY`
+Description of problem:
+When using `-netdev hostfwd=`..., qemu SLIRP uses `INADDR_ANY` instead of any bind address provided by the user. As a result, even if the user specifies to listen only on localhost (e.g. `-netdev user,hostfwd=tcp:127.0.0.1:22-:22`), qemu will listen on `*.*`. This is a potential security issue (as it may unexpectedly expose the guest to internet or local network traffic).
+Additional information:
+The bug is here: https://gitlab.com/qemu-project/qemu/-/blob/master/net/slirp.c#L777
+
+Rather than hardcoding `INADDR_ANY`, qemu should respect the user-defined bind address.
diff --git a/results/classifier/gemma3:27b/runtime/1603734 b/results/classifier/gemma3:27b/runtime/1603734
new file mode 100644
index 00000000..e542bd20
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1603734
@@ -0,0 +1,10 @@
+
+
+
+Hang in fsqrt
+
+At least qemu-i368 and qemu-x86_64 hang in floatx80_sqrt in versions 2.6.0 and git (2.6.50) for some input values, likely due to an infinite loop at fpu/softfloat.c:6569.
+
+Steps to reproduce:
+1) Compile attached code: gcc -o test test.c -lm
+2) `qemu-i368 test` and `qemu-x86_64 test` will hang at 100% cpu
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1623020 b/results/classifier/gemma3:27b/runtime/1623020
new file mode 100644
index 00000000..f33d7ee9
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1623020
@@ -0,0 +1,58 @@
+
+
+
+emulate amd64 binary on arm7 host
+
+I'm trying to run a Go program compiled for amd64 on a Raspberry Pi. Here is an example :
+
+===
+// main.go
+package main
+
+func main() {
+	println("hello world")
+}
+===
+
+Then here is the output I'm getting :
+
+===
+> GOARCH=amd64 go build main.go
+> ../qemu/build/x86_64-linux-user/qemu-x86_64 -strace ./main
+29213 arch_prctl(4098,4823880,0,0,0,0) = 0
+29213 write(2,0,4622922)fatal error:  = 13
+29213 write(2,0,4622132)bad timediv = 11
+29213 write(2,0,4620094)
+ = 1
+29213 write(2,0,4635135)runtime: panic before malloc heap initialized
+ = 46
+29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address)
+29213 select(0,0,0,0,1082131776,0) = -1 errno=14 (Bad address)
+29213 write(2,0,4623731)
+runtime stack:
+ = 16
+29213 write(2,0,4622922)fatal error:  = 13
+29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43
+29213 write(2,0,4620094)
+ = 1
+29213 write(2,0,4635135)runtime: panic before malloc heap initialized
+ = 46
+29213 write(2,0,4624923)panic during panic
+ = 19
+29213 write(2,0,4623731)
+runtime stack:
+ = 16
+29213 write(2,0,4622922)fatal error:  = 13
+29213 write(2,0,4634607)gentraceback before goexitPC initialization = 43
+29213 write(2,0,4620094)
+ = 1
+29213 write(2,0,4635135)runtime: panic before malloc heap initialized
+ = 46
+29213 write(2,0,4627441)stack trace unavailable
+ = 24
+29213 exit_group(4)
+===
+
+I'm running the latest qemu (commit 7263da78045dc91cc207f350911efe4259e99b3c), which was compiled with "../configure --target-list=x86_64-linux-user --static".
+
+The go version is 1.7.1, and the system "Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux".
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1641861 b/results/classifier/gemma3:27b/runtime/1641861
new file mode 100644
index 00000000..b1e75a03
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1641861
@@ -0,0 +1,39 @@
+
+
+
+ARM QEMU doesn't enforce that RES0 bits in FPSCR are non-writeable
+
+Hi all, we systematically tested the QEMU implementation for emulating arm user mode programs. We found that QEMU incorrectly emulate the FPSCR register. The following the proof of code:
+
+/*********** Beginning of the bug: arm.c **********/
+
+int printf(const char *format, ...);
+unsigned char i0[0x10];
+unsigned char o[0x10];
+int main() {
+    int k = 0;
+    asm("mov r2, %0\n"
+        "ldr r0, [r2]\n"::"r"((char *)(i0)));;
+    asm("vmsr fpscr, r0");
+    asm("mov r2, %0\n"
+        "vmrs r4, fpscr\n"
+        "str r4, [r2]\n"::"r"((char *)(o)));;
+    for (k = 0; k < 0x10; k++)
+        printf("%02x", o[0x10 - 1 - k]);
+    printf("\n");
+}
+unsigned char i0[0x10] = {0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x28, 0x1c, 0xc7, 0x01, 0x00, 0x00, 0x00, 0x00};
+
+/*********** End fo the bug **********/
+
+When the program is compiled into arm binary code and running on a real arm machine, and running in qemu, we have the following result
+
+$ arm-linux-gnueabihf-gcc arm.c -o arm -static
+$ ./arm
+000000000000000000000000fff7009f
+$ qemu-arm arm
+000000000000000000000000ffffffff
+
+According to the ARM manual, bits[19, 14:13, 6:5] of FPSCR should be reserved as zero. However, arm qemu fails to keep these bits to be zero: these bits can be actually modified in QEMU.
+
+Thanks!
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1648 b/results/classifier/gemma3:27b/runtime/1648
new file mode 100644
index 00000000..e69c4038
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1648
@@ -0,0 +1,61 @@
+
+
+
+linux-user: incorrect alignment of sigframe::pretcode & rt_sigframe::pretcode cause crash
+Description of problem:
+Corrent Print Result:
+
+sp: cdd3b4e8
+
+SUCCEEDED!
+
+qemu-x86_64 Print Result:
+
+sp: 2804170
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+Segmentation fault
+
+Reason of Bug:
+
+sigframe::pretcode & rt_sigframe::pretcode must align of 16n-sizeof(void*) instead of 16n, Because rsp align of 16n before instruction "call" in caller, After "call", push address of "call" in caller. sp of begin in callee is 16n-sizeof(void*)
+
+For example on x86_64:
+
+reference to "qemu/linux-user/i386/signal.c"
+
+```
+# define TARGET_FPSTATE_FXSAVE_OFFSET 0
+
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    struct target_fpstate fpstate QEMU_ALIGNED(16);
+};
+#define TARGET_RT_SIGFRAME_FXSAVE_OFFSET (                                 \
+    offsetof(struct rt_sigframe, fpstate) + TARGET_FPSTATE_FXSAVE_OFFSET)
+```
+
+offsetof(struct rt_sigframe, fpstate) align of 16
+
+TARGET_FPSTATE_FXSAVE_OFFSET is 0
+
+TARGET_RT_SIGFRAME_FXSAVE_OFFSET is 16n, also alignment of fxsave is 64
+
+so address of rt_sigframe::pretcode is 16n instead of 16n - sizeof(void*), It is incorect!
+
+Fix the bug:
+
+```
+struct rt_sigframe {
+    abi_ulong pretcode;
+    struct target_ucontext uc;
+    struct target_siginfo info;
+    abi_ulong unused QEMU_ALIGNED(16);
+    struct target_fpstate fpstate;
+};
+```
+
+offsetof(struct rt_sigframe, fpstate) is 16n+8, so address of rt_sigframe::pretcode is 16n-8 on x86_64.
diff --git a/results/classifier/gemma3:27b/runtime/1654137 b/results/classifier/gemma3:27b/runtime/1654137
new file mode 100644
index 00000000..d5672caa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1654137
@@ -0,0 +1,10 @@
+
+
+
+Ctrl-A b not working in 2.8.0
+
+With a recent update from 2.7.0 to 2.8.0 I have discovered that I can no longer send a "break" to the VM.  Ctrl-A b is simply ignored.  Other Ctrl-A sequences seem to work correctly.
+
+This is on a NetBSD amd64 system, version 7.99.53, and qemu was installed on this system from source.
+
+Reverting to the previous install restores "break" capability.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1659901 b/results/classifier/gemma3:27b/runtime/1659901
new file mode 100644
index 00000000..00e73f65
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1659901
@@ -0,0 +1,12 @@
+
+
+
+Regression: SIGSEGV running Java
+
+I have a build script that bootstraps a Debian armhf image. Part of the process involves running a Java program while inside a chroot. I am using Debian's qemu-user-static package to run the armhf Java binary on an amd64 system.
+
+qemu-user-static version 1:2.7+dfsg-3~bpo8+2 works fine. Version 1:2.8+dfsg-1~bpo8+1 always causes Java to crash with a SIGSEGV. The location of the crash appears to be random and hasn't been the same twice.
+
+I am using the Azul Systems Zulu Embedded Java runtime, rather than the regular OpenJDK runtime, because the Zulu runtime has an arm32 JIT whereas OpenJDK is interpreter-only on arm32.
+
+I can reproduce the problem easily by mounting the image created by my build script and executing "java -XshowSettings -version" in a chroot. I can give you the image if that would help debug the problem.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1661815 b/results/classifier/gemma3:27b/runtime/1661815
new file mode 100644
index 00000000..9f7701f6
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1661815
@@ -0,0 +1,29 @@
+
+
+
+Stack address is returned from function translate_one
+
+The vulnerable version is qemu-2.8.0, and the vulnerable function is in "target-s390x/translate.c".
+
+The code snippet is as following.
+
+static ExitStatus translate_one(CPUS390XState *env, DisasContext *s)
+{
+    const DisasInsn *insn;
+    ExitStatus ret = NO_EXIT;
+    DisasFields f;
+    ...
+    s->fields = &f;
+    ...
+    s->pc = s->next_pc;
+    return ret;
+}
+
+A stack address, i.e. the address of local variable "f" is returned from current function through the output parameter "s->fields" as a side effect.
+
+This issue is one kind of undefined behaviors, according the C Standard, 6.2.4 [ISO/IEC 9899:2011] (https://www.securecoding.cert.org/confluence/display/c/DCL30-C.+Declare+objects+with+appropriate+storage+durations)
+
+This dangerous defect may lead to an exploitable vulnerability.
+We suggest sanitizing "s->fields" as null before return.
+
+Note that this issue is reported by shqking and Zhenwei Zou together.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1671 b/results/classifier/gemma3:27b/runtime/1671
new file mode 100644
index 00000000..12f4d7b2
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1671
@@ -0,0 +1,1360 @@
+
+
+
+segfault/errors in gdbstub with linux userspace emulator (qemu-riscv64), from racy behavior with singal handler?
+Description of problem:
+Often, qemu segfaults, sometimes GDB just spits out a wall of "Ignoring packet error, continuing..." and ~hangs: I don't get a GDB command prompt quickly, if at all, and when I ctrl-c I see "The target is not responding to GDB commands. Stop debugging it? (y or n)".
+Steps to reproduce:
+1. Run the `testb3` binary from below as described
+2. Connect via GDB and `continue`
+3. Multiple threads (independently) SIGABRT themselves when they fail their test(s), which happens quickly on my machine (which has 16 physical cores)
+Additional information:
+From the coredump, it looks like there's a lot of cooks in the gdbstub kitchen:
+
+```
+  Id   Target Id                           Frame 
+* 1    Thread 0x7febc02ef6c0 (LWP 3922802) gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+  2    Thread 0x7febc06db6c0 (LWP 3922792) safe_syscall_base ()
+    at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+  3    Thread 0x7febc03b26c0 (LWP 3922799) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  4    Thread 0x7febc0f5d6c0 (LWP 3922751) 0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+  5    Thread 0x7febc0f5ebc0 (LWP 3922750) safe_syscall_base ()
+    at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+  6    Thread 0x7febc01696c0 (LWP 3922808) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  7    Thread 0x7febc04f76c0 (LWP 3922794) 0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+  8    Thread 0x7febc026d6c0 (LWP 3922804) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  9    Thread 0x7febc01aa6c0 (LWP 3922807) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  10   Thread 0x7febc075c6c0 (LWP 3922793) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  11   Thread 0x7febc04756c0 (LWP 3922796) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  12   Thread 0x7febc01eb6c0 (LWP 3922806) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  13   Thread 0x7febc022c6c0 (LWP 3922805) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  14   Thread 0x7febc03f36c0 (LWP 3922798) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  15   Thread 0x7febc04346c0 (LWP 3922797) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  16   Thread 0x7febc03716c0 (LWP 3922800) 0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+  17   Thread 0x7febc04b66c0 (LWP 3922795) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  18   Thread 0x7febc02ae6c0 (LWP 3922803) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+  19   Thread 0x7febc03306c0 (LWP 3922801) 0x00007febc16de96c in read () from /usr/lib/libc.so.6
+```
+
+Each of those `read` and `send` threads look something similar to this one:
+
+```
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+```
+
+Which, at a guess, seems like there's maybe 20 different concurrent processes fighting over the singular [gdbstub state](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L57)? Specifically, they're all stomping on each other by writing to the same [buffer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/user.c#L136) and advancing the [current CPU list pointer](https://gitlab.com/qemu-project/qemu/-/blob/master/gdbstub/gdbstub.c#L1422), which causes the "bad packet" cross-talk and the segfault respectively.
+
+<details><summary>full backtrace</summary>
+
+```
+(gdb) thread apply all bt full
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+No locals.
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+No locals.
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+No locals.
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+No locals.
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+No locals.
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+No locals.
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+No locals.
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+No locals.
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+No locals.
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+(gdb) thread apply all bt 
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+(gdb) thread apply all bt full
+
+Thread 19 (Thread 0x7febc03306c0 (LWP 3922801)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 18 (Thread 0x7febc02ae6c0 (LWP 3922803)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 17 (Thread 0x7febc04b66c0 (LWP 3922795)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 16 (Thread 0x7febc03716c0 (LWP 3922800)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 15 (Thread 0x7febc04346c0 (LWP 3922797)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 14 (Thread 0x7febc03f36c0 (LWP 3922798)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 13 (Thread 0x7febc022c6c0 (LWP 3922805)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 12 (Thread 0x7febc01eb6c0 (LWP 3922806)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 11 (Thread 0x7febc04756c0 (LWP 3922796)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 10 (Thread 0x7febc075c6c0 (LWP 3922793)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 9 (Thread 0x7febc01aa6c0 (LWP 3922807)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 8 (Thread 0x7febc026d6c0 (LWP 3922804)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 7 (Thread 0x7febc04f76c0 (LWP 3922794)):
+#0  0x00007febc16f1d4c in send () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a994a in gdb_put_buffer () at ../qemu-8.0.0/gdbstub/user.c:82
+No locals.
+#2  0x00005582273aad23 in gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:161
+No locals.
+#3  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#4  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#5  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#7  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#8  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#9  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#10 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#11 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#12 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#13 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#14 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#15 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#16 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#17 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#18 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 6 (Thread 0x7febc01696c0 (LWP 3922808)):
+#0  0x00007febc16de96c in read () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273ae6ce in read () at /usr/include/bits/unistd.h:38
+No locals.
+#2  gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:148
+No locals.
+#3  0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#4  0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#5  0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#6  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#7  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#8  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 5 (Thread 0x7febc0f5ebc0 (LWP 3922750)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x000055822728bfa1 in main () at ../qemu-8.0.0/linux-user/main.c:962
+No locals.
+
+Thread 4 (Thread 0x7febc0f5d6c0 (LWP 3922751)):
+#0  0x00007febc16e80dd in syscall () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273cdcb3 in qemu_futex_wait () at /usr/src/debug/qemu/qemu-8.0.0/include/qemu/futex.h:29
+No locals.
+#2  qemu_event_wait () at ../qemu-8.0.0/util/qemu-thread-posix.c:464
+No locals.
+#3  0x00005582273d83ad in call_rcu_thread () at ../qemu-8.0.0/util/rcu.c:261
+No locals.
+#4  0x00005582273cde58 in qemu_thread_start () at ../qemu-8.0.0/util/qemu-thread-posix.c:541
+No locals.
+#5  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#6  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 3 (Thread 0x7febc03b26c0 (LWP 3922799)):
+#0  0x00007febc16f1b1c in recv () from /usr/lib/libc.so.6
+No symbol table info available.
+#1  0x00005582273a9882 in recv () at /usr/include/bits/socket2.h:38
+No locals.
+#2  gdb_get_char () at ../qemu-8.0.0/gdbstub/user.c:39
+No locals.
+#3  0x00005582273aad28 in gdb_got_immediate_ack () at ../qemu-8.0.0/gdbstub/user.c:62
+No locals.
+#4  gdb_put_packet_binary () at ../qemu-8.0.0/gdbstub/gdbstub.c:164
+No locals.
+#5  0x00005582273ab768 in gdb_put_strbuf () at ../qemu-8.0.0/gdbstub/gdbstub.c:181
+No locals.
+#6  handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1410
+No locals.
+#7  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#8  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#9  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#10 0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#11 0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#12 gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#13 gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#14 0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#15 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#16 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#17 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#18 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#19 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#20 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 2 (Thread 0x7febc06db6c0 (LWP 3922792)):
+#0  safe_syscall_base () at ../qemu-8.0.0/common-user/host/x86_64/safe-syscall.inc.S:75
+No locals.
+#1  0x00005582274134c2 in safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:678
+No locals.
+#2  do_safe_futex () at ../qemu-8.0.0/linux-user/syscall.c:7804
+No locals.
+#3  do_futex () at ../qemu-8.0.0/linux-user/syscall.c:7891
+No locals.
+#4  0x00005582274191fa in do_syscall1.constprop.0 () at ../qemu-8.0.0/linux-user/syscall.c:12476
+No locals.
+#5  0x00005582273a2a22 in do_syscall () at ../qemu-8.0.0/linux-user/syscall.c:13375
+No locals.
+#6  0x000055822729644c in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:55
+No locals.
+#7  0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#8  0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#9  0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+Thread 1 (Thread 0x7febc02ef6c0 (LWP 3922802)):
+#0  gdb_next_attached_cpu () at ../qemu-8.0.0/gdbstub/gdbstub.c:282
+No locals.
+#1  0x00005582273ab774 in handle_query_threads () at ../qemu-8.0.0/gdbstub/gdbstub.c:1411
+No locals.
+#2  0x000055822741cb78 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#3  0x00005582273abad6 in handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1673
+No locals.
+#4  handle_gen_query () at ../qemu-8.0.0/gdbstub/gdbstub.c:1661
+No locals.
+#5  0x000055822741cbb3 in process_string_cmd.constprop.0 () at ../qemu-8.0.0/gdbstub/gdbstub.c:838
+No locals.
+#6  0x00005582273ae272 in run_cmd_parser () at ../qemu-8.0.0/gdbstub/gdbstub.c:856
+No locals.
+#7  gdb_handle_packet () at ../qemu-8.0.0/gdbstub/gdbstub.c:1953
+No locals.
+#8  gdb_read_byte () at ../qemu-8.0.0/gdbstub/gdbstub.c:2113
+No locals.
+#9  0x00005582273ae6ec in gdb_handlesig () at ../qemu-8.0.0/gdbstub/user.c:153
+No locals.
+#10 0x00005582273919fb in handle_pending_signal () at ../qemu-8.0.0/linux-user/signal.c:1042
+No locals.
+#11 0x0000558227391dd2 in process_pending_signals () at ../qemu-8.0.0/linux-user/signal.c:1153
+No locals.
+#12 0x00005582272964b8 in cpu_loop () at ../qemu-8.0.0/linux-user/riscv/cpu_loop.c:93
+No locals.
+#13 0x00005582273a1d15 in clone_func () at ../qemu-8.0.0/linux-user/syscall.c:6621
+No locals.
+#14 0x00007febc166dbb5 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+#15 0x00007febc16efd90 in ?? () from /usr/lib/libc.so.6
+No symbol table info available.
+
+```
+
+</details>
+
+
+
+- coredump
+    - [core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst](/uploads/071fc96520ca4008941044802c176d6a/core.qemu-riscv64.1000.efb558e6104b4cc5bfa37605fc9af294.3922750.1685497956000000.zst)
+    - [qemu-riscv64](/uploads/f203d5aed8559d80c2d66e439bb4dddf/qemu-riscv64) (the binary the coredump was generated from)
+    - download both, extract corefile, use `DEBUGINFOD_URLS=https://debuginfod.archlinux.org gdb /path/to/qemu-riscv64 -c /tmp/coredump` to debug
+- reproducer
+    - [testb3.tar.xz](/uploads/84bdbb547e01527c3d804e0d88c6c9fe/testb3.tar.xz) (includes testb3 + sysroot to work with command line above)
+    - This binary is a cross-compiled `testb3` from [WebKit](https://github.com/WebKit/WebKit/blob/9755847ab1d40841374b2467b3036d943b723183/Source/JavaScriptCore/b3/testb3_1.cpp#L927) ; sorry, that's about all I know about it so far
+    - A GDB you might use to connect is [SiFive's](https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.1.0-2019.01.0-x86_64-linux-ubuntu14.tar.gz). I got more consistent segfaults with a more recent gdb (12.1), but I'm not sure how to tell you how to get that `gdb` besides "creating a riscv64 poky distribution" (what I did), which is likely not helpful.
diff --git a/results/classifier/gemma3:27b/runtime/1696353 b/results/classifier/gemma3:27b/runtime/1696353
new file mode 100644
index 00000000..355c83de
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1696353
@@ -0,0 +1,38 @@
+
+
+
+golang binaries fail to start under linux-user
+
+With current master golang binaries fail when run under linux-user, for example:
+
+[will@localhost qemu]$ ./arm-linux-user/qemu-arm glide 
+runtime: failed to create new OS thread (have 2 already; errno=22)
+fatal error: newosproc
+
+runtime stack:
+runtime.throw(0x45f879, 0x9)
+	/usr/lib/golang/src/runtime/panic.go:566 +0x78
+runtime.newosproc(0x1092c000, 0x1093bfe0)
+	/usr/lib/golang/src/runtime/os_linux.go:160 +0x1b0
+runtime.newm(0x4ae1e8, 0x0)
+	/usr/lib/golang/src/runtime/proc.go:1572 +0x12c
+runtime.main.func1()
+	/usr/lib/golang/src/runtime/proc.go:126 +0x24
+runtime.systemstack(0x5ef900)
+	/usr/lib/golang/src/runtime/asm_arm.s:247 +0x80
+runtime.mstart()
+	/usr/lib/golang/src/runtime/proc.go:1079
+
+goroutine 1 [running]:
+runtime.systemstack_switch()
+	/usr/lib/golang/src/runtime/asm_arm.s:192 +0x4 fp=0x109287ac sp=0x109287a8
+runtime.main()
+	/usr/lib/golang/src/runtime/proc.go:127 +0x5c fp=0x109287d4 sp=0x109287ac
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_arm.s:998 +0x4 fp=0x109287d4 sp=0x109287d4
+
+The reason for this is that the golang runtime does not pass the CLONE_SYSVMEM flag to clone so the clone flags checks fail:
+
+https://github.com/golang/go/blob/master/src/runtime/os_linux.go#L155
+
+The attached patch allows golang binaries to start under linux-user.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1696773 b/results/classifier/gemma3:27b/runtime/1696773
new file mode 100644
index 00000000..9eea4be1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1696773
@@ -0,0 +1,10 @@
+
+
+
+golang calls to exec crash user emulation
+
+An example program can be found here:
+
+https://github.com/willnewton/qemucrash
+
+This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures).
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1697 b/results/classifier/gemma3:27b/runtime/1697
new file mode 100644
index 00000000..eb55b093
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1697
@@ -0,0 +1,22 @@
+
+
+
+qemu-arm -cpu cortex-m55 dummy_test qemu-arm: ../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= GUEST_ADDR_MAX' failed.
+Description of problem:
+Basic testing failed for cortex m55
+Steps to reproduce:
+1.Pulled the newest qemu 8.0.50
+
+2.Create a Dummy test with only return 0 in main function
+
+3.run  ` arm-none-eabi-gcc -o dummy_test -O2 -g -mcpu=cortex-m55 dummy_test.cc --specs=rdimon.specs` and then `qemu-arm -cpu cortex-m55 dummy_test`
+
+`arm-none-eabi-gcc (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 12.2.1 20230214
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.`
+
+`qemu-arm version 8.0.50 (v8.0.0-1739-g5f9dd6a8ce)
+Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers`
+Additional information:
+It is a known problem in another issues: https://gitlab.com/qemu-project/qemu/-/issues/1528#note_1389268261.
diff --git a/results/classifier/gemma3:27b/runtime/1704638 b/results/classifier/gemma3:27b/runtime/1704638
new file mode 100644
index 00000000..97f7a9eb
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1704638
@@ -0,0 +1,68 @@
+
+
+
+weak symbol access makes qemu in user mode hang for mips, mips64
+
+A program that is statically linked and invokes a weak pointer should crash (because the weak pointer evaluates to NULL).
+
+With qemu in user mode, for mips and mips64, it hangs. The process needs to be killed with "kill -9".
+
+How to reproduce for mips:
+- Compile the program: mips-linux-gnu-gcc-5 -O -Wall -static -o testpthsigmask-mips testpthsigmask.c -pthread
+- Set environment variables for running qemu-mips.
+- ~/inst-qemu/2.9.0/bin/qemu-mips testpthsigmask-mips
+
+How to reproduce for mips64:
+- Compile the program: mips64-linux-gnuabi64-gcc-5 -O -Wall -static -o testpthsigmask-mips64 testpthsigmask.c -lpthread
+- Set environment variables for running qemu-mips64.
+- ~/inst-qemu/2.9.0/bin/qemu-mips64 testpthsigmask-mips64
+
+When I attach gdb to the process, I see that it is hanging inside 'gen_intermediate_code':
+
+$ gdb /home/bruno/inst-qemu/2.9.0/bin/qemu-mips 9726
+...
+Reading symbols from /home/bruno/inst-qemu/2.9.0/bin/qemu-mips...done.
+Attaching to program: /home/bruno/inst-qemu/2.9.0/bin/qemu-mips, process 9726
+...
+(gdb) info threads
+  Id   Target Id         Frame 
+* 1    Thread 0x7f1e7e535740 (LWP 9726) "qemu-mips" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
+  2    Thread 0x7f1e7d0ad700 (LWP 9727) "qemu-mips" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+(gdb) where
+#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
+#1  0x00007f1e7d6f1dbd in __GI___pthread_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>) at ../nptl/pthread_mutex_lock.c:80
+#2  0x000055de1c527199 in qemu_mutex_lock (mutex=mutex@entry=0x55de1c7ff830 <tcg_ctx+272>)
+    at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:60
+#3  0x000055de1c435083 in tb_lock () at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:167
+#4  cpu_restore_state (cpu=cpu@entry=0x55de1e915cb0, retaddr=retaddr@entry=94412445741769) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:350
+#5  0x000055de1c4658d0 in handle_cpu_signal (old_set=0x7ffe5ffd8ea8, is_write=0, address=0, pc=94412445741767)
+    at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:124
+#6  cpu_mips_signal_handler (host_signum=host_signum@entry=11, pinfo=pinfo@entry=0x7ffe5ffd8eb0, puc=puc@entry=0x7ffe5ffd8d80)
+    at /media/develdata/devel/build/qemu-2.9.0/user-exec.c:229
+#7  0x000055de1c4803be in host_signal_handler (host_signum=11, info=0x7ffe5ffd8eb0, puc=0x7ffe5ffd8d80)
+    at /media/develdata/devel/build/qemu-2.9.0/linux-user/signal.c:646
+#8  <signal handler called>
+#9  __bswap_32 (__bsx=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/byteswap.h:47
+#10 bswap32 (x=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:21
+#11 ldl_be_p (ptr=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/bswap.h:434
+#12 cpu_ldl_code (env=0x55de1e91df48, ptr=0) at /media/develdata/devel/build/qemu-2.9.0/include/exec/cpu_ldst_useronly_template.h:68
+#13 gen_intermediate_code (env=env@entry=0x55de1e91df48, tb=tb@entry=0x7f1e7b288e58)
+    at /media/develdata/devel/build/qemu-2.9.0/target/mips/translate.c:19962
+#14 0x000055de1c4352e6 in tb_gen_code (cpu=cpu@entry=0x55de1e915cb0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=162, cflags=<optimized out>, 
+    cflags@entry=0) at /media/develdata/devel/build/qemu-2.9.0/translate-all.c:1295
+#15 0x000055de1c436a7a in tb_find (tb_exit=0, last_tb=0x0, cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:365
+#16 cpu_exec (cpu=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/cpu-exec.c:673
+#17 0x000055de1c466278 in cpu_loop (env=0x55de1e91df48) at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:2236
+#18 0x000055de1c433103 in main (argc=<optimized out>, argv=0x7ffe5ffd9de8, envp=<optimized out>)
+    at /media/develdata/devel/build/qemu-2.9.0/linux-user/main.c:4860
+(gdb) thread 2
+[Switching to thread 2 (Thread 0x7f1e7d0ad700 (LWP 9727))]
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: Datei oder Verzeichnis nicht gefunden.
+(gdb) where
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+#1  0x000055de1c527605 in qemu_futex_wait (val=<optimized out>, f=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/include/qemu/futex.h:26
+#2  qemu_event_wait (ev=ev@entry=0x55de1e82c124 <rcu_call_ready_event>) at /media/develdata/devel/build/qemu-2.9.0/util/qemu-thread-posix.c:399
+#3  0x000055de1c52d41e in call_rcu_thread (opaque=<optimized out>) at /media/develdata/devel/build/qemu-2.9.0/util/rcu.c:249
+#4  0x00007f1e7d6ef6ba in start_thread (arg=0x7f1e7d0ad700) at pthread_create.c:333
+#5  0x00007f1e7d4253dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1715162 b/results/classifier/gemma3:27b/runtime/1715162
new file mode 100644
index 00000000..9dbb3446
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1715162
@@ -0,0 +1,75 @@
+
+
+
+qemu-user crashing when writing core dump
+
+I've a binary I'm running in qemux86-64 but it is segfaulting.  Whilst qemu writes the core dump for that, qemu itself is segfaulting.
+
+(gdb) bt full
+#0  0x00007efdd962e32e in sigsuspend () from /data/poky-tmp/master/build/sysroots-uninative/x86_64-linux/lib/libc.so.6
+No symbol table info available.
+#1  0x0000559176d74da4 in dump_core_and_abort (target_sig=target_sig@entry=11)
+    at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:598
+        cpu = <optimized out>
+        env = <optimized out>
+        ts = 0x55917a42d160
+        core_dumped = <optimized out>
+        act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {18446744067267099647,
+              18446744073709551615 <repeats 15 times>}}, sa_flags = 0, sa_restorer = 0x559100004010}
+#2  0x0000559176d75a38 in handle_pending_signal (cpu_env=cpu_env@entry=0x55917a41c2a0, sig=sig@entry=11,
+    k=k@entry=0x55917a42d190)
+    at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6596
+        handler = <optimized out>
+        set = {__val = {4294967297, 4294967297, 94083256460867, 14, 128, 0, 8, 3, 0, 1, 0, 4243635, 139628765215104,
+            94083255852784, 94083309703424, 3351315493}}
+        target_old_set = {sig = {0}}
+        sa = <optimized out>
+        ts = 0x55917a42d160
+#3  0x0000559176d765ac in process_pending_signals (cpu_env=<optimized out>)
+    at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/signal.c:6674
+        sig = 11
+        ts = 0x55917a42d160
+        set = {__val = {18446744067267100671, 18446744073709551615 <repeats 15 times>}}
+        blocked_set = <optimized out>
+#4  0x0000559176d5e0d8 in cpu_loop (env=0x55917a41c2a0)
+    at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:369
+        trapnr = 14
+        pc = <optimized out>
+        ret = <optimized out>
+        info = {si_signo = 11, si_errno = 0, si_code = 196609, _sifields = {_pad = {101897450, 192, -647518572, 32509,
+              842, 0, 1993519912, 21905, 2051194736, 21905, 1997320506, 21905, 2051195440, 21905, 1993546713, 0,
+              12767276, 64, 1997233696, 21905, 42, 0, 1997233824, 21905, 1997320464, 21905, 350755584, -1438022877},
+            _kill = {_pid = 101897450, _uid = 192}, _timer = {_timer1 = 101897450, _timer2 = 192}, _rt = {
+              _pid = 101897450, _uid = 192, _sigval = {sival_int = -647518572, sival_ptr = 139628739274388}},
+            _sigchld = {_pid = 101897450, _uid = 192, _status = -647518572, _utime = 842, _stime = 94083252138792},
+            _sigfault = {_addr = 824735618282}, _sigpoll = {_band = 101897450, _fd = 192}}}
+#5  0x0000559176d2a4b8 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
+    at /data/poky-tmp/master/build/work/x86_64-linux/qemu-native/2.10.0-r0/qemu-2.10.0/linux-user/main.c:4862
+        regs1 = {r15 = 0, r14 = 0, r13 = 0, r12 = 0, rbp = 0, rbx = 0, r11 = 0, r10 = 0, r9 = 0, r8 = 0, rax = 0,
+          rcx = 0, rdx = 0, rsi = 0, rdi = 0, orig_rax = 0, rip = 274888416832, cs = 0, eflags = 0,
+          rsp = 274888401360, ss = 0}
+        regs = 0x7ffda5b29fc0
+        info1 = {load_bias = 274888413184, load_addr = 274877906944, start_code = 274877906944,
+          end_code = 274877917360, start_data = 274880015120, end_data = 274880016400, start_brk = 0,
+          brk = 274880016472, start_mmap = 183251939328, start_stack = 274888401360, stack_limit = 274880024576,
+          entry = 274888416832, code_offset = 0, data_offset = 0, saved_auxv = 274888402256,
+          auxv_len = 18446744073709550728, arg_start = 274888401368, arg_end = 274888401408,
+          arg_strings = 274888402550, env_strings = 274888402788, file_string = 274888413067, elf_flags = 0,
+          personality = 0}
+        info = 0x7ffda5b2a070
+        bprm = {
+          buf = "\177ELF\002\001\001\000\000\000\000\000\000\000\000\000\003\000>\000\001\000\000\000@\016\000\000\000\000\000\000@\000\000\000\000\000\000\000\230`\002\000\000\000\000\000\000\000\000\000@\000\070\000\006\000@\000\027\000\026\000\001\000\000\000\005", '\000' <repeats 27 times>, "\264C\002\000\000\000\000\000\264C\002\000\000\000\000\000\000\000 \000\000\000\000\000\001\000\000\000\006\000\000\000\240G\002\000\000\000\000\000\240G\"\000\000\000\000\000\240G\"\000\000\000\000\000\330\027\000\000\000\000\000\000p\031\000\000\000\000\000\000\000\000 \000\000\000\000\000\002\000\000\000\006\000\000\000\030N\002\000\000\000\000\000\030N\"\000\000\000\000\000"..., p = 274888401360, fd = 3,
+          e_uid = 1000, e_gid = 1000, argc = 5, envc = 104, argv = 0x55917a42d120, envp = 0x55917a42a8f0,
+          filename = 0x7ffda5b2c683 "/data/poky-tmp/master/build/work/intel_corei7_64-poky-linux/core-image-weston/1.0-r0/rootfs/usr/bin/fc-cache", core_dump = 0x559176d76ed0 <elf_core_dump>}
+        ts = <optimized out>
+        env = 0x55917a41c2a0
+        cpu = 0x55917a414010
+        target_environ = 0x55917a42a8f0
+        wrk = 0x55917a42ac30
+        target_argv = 0x55917a42d120
+        target_argc = 5
+        i = <optimized out>
+        ret = <optimized out>
+        execfd = <optimized out>
+
+(I'll reproduce this with glibc debug symbols shortly)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1716767 b/results/classifier/gemma3:27b/runtime/1716767
new file mode 100644
index 00000000..8ae1b92c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1716767
@@ -0,0 +1,37 @@
+
+
+
+file(1) fails with "Invalid argument" on qemu-sh4-user
+
+We recently discovered that file(1) fails on qemu-sh4-user when running on an ELF file:
+
+(sid_sh4)root@vs94:/# file /bin/bash
+/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument)
+(sid_sh4)root@vs94:/#
+
+Running with "-d" yields more output:
+
+(sid_sh4)root@vs94:/# file -d /bin/bash 2>&1 | tail
+322: >> 7 byte&,=97,"(ARM)"]
+0 == 97 = 0
+mget(type=1, flag=0, offset=7, o=0, nbytes=863324, il=0, nc=1)
+mget/96 @7: \000\000\000\000\000\000\000\000\000\002\000*\000\001\000\000\000\250\317A\0004\000\000\000L(\r\000\027\000\000\0004\000 \000\n\000(\000\032\000\031\000\006\000\000\0004\000\000\0004\000@\0004\000@\000@\001\000\000@\001\000\000\005\000\000\000\004\000\000\000\003\000\000\000t\001\000\000t\001@\000t\001@\000\023\000\000
+
+323: >> 7 byte&,=-1,"(embedded)"]
+0 == 18446744073709551615 = 0
+[try softmagic 1]
+[try elf -1]
+/bin/bash: ERROR: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV) error reading (Invalid argument)
+(sid_sh4)root@vs94:/#
+
+It seems that the comparison above has a bogus (overflown?) value.
+
+On actual hardware, it works:
+
+root@tirpitz:~> file /bin/bash
+/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=4dd0e4281755827d8bb6686fd481f8c80ea73e9a, for GNU/Linux 3.2.0, stripped
+root@tirpitz:~>
+
+I have uploaded a chroot with Debian unstable which allows to reproduce the issue:
+
+> https://people.debian.org/~glaubitz/sid-sh4-sbuild.tar.gz
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1725267 b/results/classifier/gemma3:27b/runtime/1725267
new file mode 100644
index 00000000..544060fe
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1725267
@@ -0,0 +1,34 @@
+
+
+
+armeb regression since qemu version 2.8
+
+Hi,
+
+I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1.
+
+I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe.
+
+# with 2.7:
+$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
+$ echo $?
+0
+# with 2.8, 2.10.1:
+$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
+qemu: uncaught target signal 6 (Aborted) - core dumped
+Aborted (core dumped)
+$ echo $?
+134
+
+The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c
+
+Running with -d in_asm shows a difference early in the startup code:
+IN: _dl_sysdep_start
+[...]
+0x40a17790:  908ff103      addls	pc, pc, r3, lsl #2
+
+and then the next address is not the same with qemu 2.7 and 2.10.1
+
+I hope you have enough data/information to reproduce and confirm/fix the problem.
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1735384 b/results/classifier/gemma3:27b/runtime/1735384
new file mode 100644
index 00000000..69d4ee82
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1735384
@@ -0,0 +1,23 @@
+
+
+
+OpenJDK JVM segfaults on qemu-sh4 (regression)
+
+Some of the recent changes introduced a regression which makes the OpenJDK JVM crash on qemu-sh4:
+
+(sid-sh4-sbuild)root@nofan:/# java -version
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+(sid-sh4-sbuild)root@nofan:/#
+
+An older version works fine:
+
+(sid-sh4-sbuild)root@nofan:/# java -version
+openjdk version "9.0.1"
+OpenJDK Runtime Environment (build 9.0.1+11-Debian-1)
+OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode)
+(sid-sh4-sbuild)root@nofan:/#
+
+Haven't had time for bisecting this yet.
+
+Adrian
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1737444 b/results/classifier/gemma3:27b/runtime/1737444
new file mode 100644
index 00000000..dd7ef2fd
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1737444
@@ -0,0 +1,96 @@
+
+
+
+gccgo setcontext conftest crashes qemu-sh4
+
+While testing gccgo on sh4 to add SH platform definitions to libgo, I discovered that the following conftest program which is part of the libgo configure script crashes on qemu-sh4:
+
+(sid-sh4-sbuild)root@z6:/# cat setcontext.c
+#include <pthread.h>                                                                                                                                                                                                                                                           
+#include <stdlib.h>                                                                                                                                                                                                                                                            
+#include <ucontext.h>                                                                                                                                                                                                                                                          
+#include <unistd.h>                                                                                                                                                                                                                                                            
+
+__thread int tls;
+
+static char stack[10 * 1024 * 1024];
+static ucontext_t c;
+
+/* Called via makecontext/setcontext.  */
+
+static void
+cfn (void)
+{
+  exit (tls);
+}
+
+/* Called via pthread_create.  */
+
+static void *
+tfn (void *dummy)
+{
+  /* The thread should still see this value after calling
+     setcontext.  */
+  tls = 0;
+
+  setcontext (&c);
+
+  /* The call to setcontext should not return.  */
+  abort ();
+}
+
+int
+main ()
+{
+  pthread_t tid;
+
+  /* The thread should not see this value.  */
+  tls = 1;
+
+  if (getcontext (&c) < 0)
+    abort ();
+
+  c.uc_stack.ss_sp = stack;
+#ifdef MAKECONTEXT_STACK_TOP                                                                                                                                                                                                                                                   
+  c.uc_stack.ss_sp += sizeof stack;
+#endif                                                                                                                                                                                                                                                                         
+  c.uc_stack.ss_flags = 0;
+  c.uc_stack.ss_size = sizeof stack;
+  c.uc_link = NULL;
+  makecontext (&c, cfn, 0);
+
+  if (pthread_create (&tid, NULL, tfn, NULL) != 0)
+    abort ();
+
+  if (pthread_join (tid, NULL) != 0)
+    abort ();
+
+  /* The thread should have called exit.  */
+  abort ();
+}
+
+(sid-sh4-sbuild)root@z6:/# gcc -o setcontext -lpthread setcontext.c
+(sid-sh4-sbuild)root@z6:/# ./setcontext 
+Unhandled trap: 0x180
+pc=0x7f69235e sr=0x00000000 pr=0x00400710 fpscr=0x00080000
+spc=0x00000000 ssr=0x00000000 gbr=0x7f658478 vbr=0x00000000
+sgr=0x00000000 dbr=0x00000000 delayed_pc=0x7f692320 fpul=0x00000000
+r0=0x00e11158 r1=0x00000000 r2=0x00000001 r3=0x7ffff2e0
+r4=0x00e11068 r5=0x7ffff314 r6=0x7ffff31c r7=0x00000000
+r8=0x004007b0 r9=0x00000000 r10=0x00000000 r11=0x00000000
+r12=0x7f79ac54 r13=0x00000000 r14=0x7ffff288 r15=0x7ffff288
+r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000
+r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000
+(sid-sh4-sbuild)root@z6:/#
+
+The same code works fine on my Renesas SH7785LCR evaluation board:
+
+root@tirpitz:~> uname -a
+Linux tirpitz 3.16.7-ckt7 #8 PREEMPT Fri Oct 21 18:47:41 CEST 2016 sh4a GNU/Linux
+root@tirpitz:~> gcc -o setcontext setcontext.c  -lpthread
+root@tirpitz:~> ./setcontext 
+root@tirpitz:~> echo $?
+0
+root@tirpitz:~>
+
+Due to this bug, it is not possible to compile gcc-7 with the Go frontend enabled on qemu-sh4.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1740219 b/results/classifier/gemma3:27b/runtime/1740219
new file mode 100644
index 00000000..9517dedf
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1740219
@@ -0,0 +1,62 @@
+
+
+
+static linux-user ARM emulation has several-second startup time
+
+static linux-user emulation has several-second startup time
+
+My problem: I'm a Parabola packager, and I'm updating our
+qemu-user-static package from 2.8 to 2.11.  With my new
+statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true`
+went from taking 0.006s to 3s!  This does not happen with the normal
+dynamically linked 2.11, or the old static 2.8.
+
+What happens is it gets stuck in
+`linux-user/elfload.c:init_guest_space()`.  What `init_guest_space`
+does is map 2 parts of the address space: `[base, base+guest_size]`
+and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find
+an acceptable `base`.  Its strategy is to `mmap(NULL, guest_size,
+...)` decide where the first range is, and then check if that
++0xffff0000 is also available.  If it isn't, then it starts trying
+`mmap(base, ...)` for the entire address space from low-address to
+high-address.
+
+"Normally," it finds an accaptable `base` within the first 2 tries.
+With a static 2.11, it's taking thousands of tries.
+
+----
+
+Now, from my understanding, there are 2 factors working together to
+cause that in static 2.11 but not the other builds:
+
+ - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000
+ - PIE (and thus ASLR) is disabled for static builds
+
+For some reason that I don't understand, with the smaller
+`guest_size` the initial `mmap(NULL, guest_size, ...)` usually
+returns an acceptable address range; but larger `guest_size` makes it
+consistently return a block of memory that butts right up against
+another already mapped chunk of memory.  This isn't just true on the
+older builds, it's true with the 2.11 builds if I use the `-R` flag to
+shrink the `guest_size` back down to 0xf7000000.  That is with
+linux-hardened 4.13.13 on x86-64.
+
+So then, it it falls back to crawling the entire address space; so it
+tries base=0x00001000.  With ASLR, that probably succeeds.  But with
+ASLR being disabled on static builds, the text segment is at
+0x60000000; which is does not leave room for the needed
+0xffff1000-size block before it.  So then it tries base=0x00002000.
+And so on, more than 6000 times until it finally gets to and passes
+the text segment; calling mmap more than 12000 times.
+
+----
+
+I'm not sure what the fix is.  Perhaps try to mmap a continuous chunk
+of size 0xffff1000, then munmap it and then mmap the 2 chunks that we
+actually need.  The disadvantage to that is that it does not support
+the sparse address space that the current algorithm supports for
+`guest_size < 0xffff0000`.  If `guest_size < 0xffff0000` *and* the big
+mmap fails, then it could fall back to a sparse search; though I'm not
+sure the current algorithm is a good choice for it, as we see in this
+bug.  Perhaps it should inspect /proc/self/maps to try to find a
+suitable range before ever calling mmap?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1741 b/results/classifier/gemma3:27b/runtime/1741
new file mode 100644
index 00000000..64d3f1c1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1741
@@ -0,0 +1,4 @@
+
+
+
+95059f9c313a7fbd7f22e4cdc1977c0393addc7b breaks some 32bit architectures in linux-user on amd64
diff --git a/results/classifier/gemma3:27b/runtime/1748612 b/results/classifier/gemma3:27b/runtime/1748612
new file mode 100644
index 00000000..3b01e016
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1748612
@@ -0,0 +1,18 @@
+
+
+
+qemu-user option -strace -D <file> doesn't work
+
+I have been trying to access qemu -strace output from a script
+The main problem was it was on stderr, the strace output was merged with my program's stderr output.
+Then I tried to use the -D option, to log the output to a file.
+This didn't work even if the log file was created, but it was empty.
+
+I have looked at the source code and found the print function was not qemu_log with -strace but gemu_log (to be clear it was GEMU NOT QEMU)
+
+
+I have then replaced all gemu_log by qemu_log removed declaration of gemu_log and recompiled, it seems to works just fine right now.
+
+removed declaration here and here:
+https://github.com/qemu/qemu/blob/master/linux-user/main.c#L108
+https://github.com/qemu/qemu/blob/master/linux-user/qemu.h#L203
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1755 b/results/classifier/gemma3:27b/runtime/1755
new file mode 100644
index 00000000..09f12d8e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1755
@@ -0,0 +1,23 @@
+
+
+
+qemu-arm fails to execute a cortex-M binary (page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.)
+Description of problem:
+I've noticed that qemu-arm (so linux-user mode) fails to execute a binary targeting cortex-M. This used to work until commit
+"Make the commpage executable".
+Steps to reproduce:
+1. Compile a simple hello.c for arm-eabi. If you don't have such a toolchain, you can download one from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads    For instance https://developer.arm.com/-/media/Files/downloads/gnu/12.2.rel1/binrel/arm-gnu-toolchain-12.2.rel1-x86_64-arm-none-eabi.tar.xz (for an x86_64 linux host)
+
+2.# compile for cortex-m3:
+
+3. arm-none-eabi-gcc hello.c -o hello.exe.m3 -mcpu=cortex-m3 -specs=rdimon.specs
+
+4.qemu-arm -cpu cortex-m3 hello.exe.m3
+.....user-exec.c:492: page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed.
+
+5. # compile for cortex-a9:
+
+6. arm-none-eabi-gcc hello.c -o hello.exe.a9 -mcpu=cortex-a9 -specs=rdimon.specs
+
+7. qemu-arm -cpu cortex-a9 hello.exe.a9
+Hello
diff --git a/results/classifier/gemma3:27b/runtime/1756519 b/results/classifier/gemma3:27b/runtime/1756519
new file mode 100644
index 00000000..d6a31f73
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1756519
@@ -0,0 +1,49 @@
+
+
+
+qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create
+
+qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a)  crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message:
+
+(process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
+**
+ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16
+
+
+Backtrace obtained via gdb:
+
+#0  raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
+#1  0x0000000060139b21 in abort () at abort.c:79
+#2  0x0000000060100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, 
+    func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached")
+    at gtestutils.c:2430
+#3  0x0000000060100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, 
+    func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=<optimized out>) at gtestutils.c:2453
+#4  0x0000000060098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665
+#5  0x0000000060098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675
+#6  0x000000006008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7ffff762fe68) at hw/core/qdev.c:874
+#7  0x0000000060098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7ffff762fe68)
+    at qom/object.c:1926
+#8  0x0000000060096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1122
+#9  0x0000000060099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7ffff762fe68)
+    at qom/qom-qobject.c:27
+#10 0x0000000060097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7ffff762fe68) at qom/object.c:1191
+#11 0x0000000060092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61
+#12 0x000000006009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98
+#13 0x000000006004cb61 in cpu_copy (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3881
+#14 0x000000006005b79a in do_fork (env=0x7ffff008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, 
+    child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348
+#15 0x0000000060063e56 in do_syscall (cpu_env=0x7ffff008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, 
+    arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001
+#16 0x000000006004c89f in cpu_loop (env=0x7ffff008cd60) at /opt/qemu/linux-user/main.c:3600
+#17 0x000000006005b68f in clone_func (arg=0x7ffff7775050) at /opt/qemu/linux-user/syscall.c:6311
+#18 0x0000000060121797 in start_thread (arg=0x7ffff7632700) at pthread_create.c:463
+#19 0x000000006019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+
+Attached is a test case source code extracted from libgomp test suite.
+
+Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads.   Changing constants in the test case makes it fail with different numbers of threads.
+
+I will attach statically linked riscv64 binary executable if size limits permit.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1756807 b/results/classifier/gemma3:27b/runtime/1756807
new file mode 100644
index 00000000..3ab52016
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1756807
@@ -0,0 +1,70 @@
+
+
+
+performance regression in qemu-user + proot
+
+To reproduce:
+
+1. Install qemu-user-static and proot
+2. Enter some arm chroot using them:
+
+    proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash
+
+3. Run a command which normally takes a short but measurable amount of time:
+
+    cd /usr/share/doc && time grep -R hello
+
+Result:
+
+This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04.
+
+Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected.
+
+If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though.
+
+Logs:
+
+
+
+System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04
+qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0)
+proot 5.1.0
+
+al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash
+root@al-desktop:/# cd /usr/share/doc
+root@al-desktop:/usr/share/doc# time grep -R hello
+dash/copyright:Debian GNU/Linux hello source package as the file COPYING.  If not,
+
+real	0m0.066s
+user	0m0.040s
+sys	0m0.008s
+
+
+
+
+
+System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04
+qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4)
+proot 5.1.0
+
+al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash
+root@al-thinkpad:/# cd /usr/share/doc
+root@al-thinkpad:/usr/share/doc# time grep -R hello
+dash/copyright:Debian GNU/Linux hello source package as the file COPYING.  If not,
+
+real	0m24.176s
+user	0m0.366s
+sys	0m11.352s
+
+ProblemType: Bug
+DistroRelease: Ubuntu 18.04
+Package: qemu (not installed)
+ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
+Uname: Linux 4.15.0-12-generic x86_64
+ApportVersion: 2.20.8-0ubuntu10
+Architecture: amd64
+Date: Mon Mar 19 07:13:25 2018
+InstallationDate: Installed on 2018-03-18 (0 days ago)
+InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318)
+SourcePackage: qemu
+UpgradeStatus: No upgrade log present (probably fresh install)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1761535 b/results/classifier/gemma3:27b/runtime/1761535
new file mode 100644
index 00000000..38a8d1bb
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1761535
@@ -0,0 +1,39 @@
+
+
+
+qemu-aarch64-static docker arm64v8/openjdk coredump
+
+I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place.
+
+To reproduce (and get to the core dump):
+
+$ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version
+qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+$ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash
+root@bf75cf45d311:/# javac
+Usage: javac <options> <source files>
+where possible options include:
+  -g                         Generate all debugging info
+<...snip...>
+  @<filename>                Read options and filenames from file
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+...TERMINAL HANGS...
+
+
+To get the core dump, In a separate terminal:
+
+# snapshot the file system of the hung image
+$ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump
+
+# connect with known working qemu
+$ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static  -i qemu_coredump /bin/bash
+
+$$ ls -lat
+total 10608
+<snip>
+-rw-r--r--   1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core
+drwxrwxrwt   5 root root     4096 Mar 29 18:02 tmp
+<snip>
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1763 b/results/classifier/gemma3:27b/runtime/1763
new file mode 100644
index 00000000..ed6bf63e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1763
@@ -0,0 +1,15 @@
+
+
+
+ldd fails with qemu-aarch64
+Description of problem:
+see the original issue for full details https://github.com/multiarch/qemu-user-static/issues/172
+Steps to reproduce:
+1. docker run --rm -it arm64v8/ubuntu:16.04 ldd /bin/ls
+
+Also possible on other newer OSs (eg: Ubuntu:18.04) with different compiled binaries.
+Additional information:
+```
+WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64) and no specific platform was requested
+ldd: exited with unknown exit code (139)
+```
diff --git a/results/classifier/gemma3:27b/runtime/1763536 b/results/classifier/gemma3:27b/runtime/1763536
new file mode 100644
index 00000000..d18dcbcc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1763536
@@ -0,0 +1,86 @@
+
+
+
+go build fails under qemu-ppc64le-static (qemu-user)
+
+I am using qemu-user (built static) in a docker container environment.  When running multi-threaded go commands in the container (go build for example) the process may hang, report segfaults or other errors.  I built qemu-ppc64le from the upstream git (master).
+
+I see the problem running on a multi core system with Intel i7 processors.
+# cat /proc/cpuinfo | grep "model name"
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+model name	: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
+
+Steps to reproduce:
+1) Build qemu-ppc64le as static and copy into docker build directory named it qemu-ppc64le-static.
+
+2) Add hello.go to docker build dir.
+
+package main
+import "fmt"
+func main() {
+	fmt.Println("hello world")
+}
+
+3) Create the Dockerfile from below:
+
+FROM ppc64le/golang:1.10.1-alpine3.
+COPY qemu-ppc64le-static /usr/bin/
+COPY hello.go /go
+
+4) Build container
+$ docker build -t qemutest -f Dockerfile ./go 
+
+5) Run test
+$ docker run -it qemutest
+
+/go # /usr/bin/qemu-ppc64le-static --version
+qemu-ppc64le version 2.11.93 (v2.12.0-rc3-dirty)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+/go # go version
+go version go1.10.1 linux/ppc64le
+
+/go # go build hello.go
+fatal error: fatal error: stopm holding locksunexpected signal during runtime execution
+
+panic during panic
+[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1003528c]
+
+runtime stack:
+runtime: unexpected return pc for syscall.Syscall6 called from 0xc42007f500
+stack: frame={sp:0xc4203be840, fp:0xc4203be860} stack=[0x4000b7ecf0,0x4000b928f0)
+
+syscall.Syscall6(0x100744e8, 0x3d, 0xc42050c140, 0x20, 0x18, 0x10422b80, 0xc4203be968[signal , 0x10012d88SIGSEGV: segmentation violation, 0xc420594000 code=, 0x00x1 addr=0x0 pc=0x1003528c)
+]
+
+runtime stack:
+	/usr/local/go/src/syscall/asm_linux_ppc64x.s:61runtime.throw(0x10472d19, 0x13)
+ +	/usr/local/go/src/runtime/panic.go:0x6c616 +0x68
+
+
+runtime.stopm()
+	/usr/local/go/src/runtime/proc.go:1939goroutine  +10x158
+ [runtime.exitsyscall0semacquire(0xc42007f500)
+	/usr/local/go/src/runtime/proc.go:3129 +]:
+0x130
+runtime.mcall(0xc42007f500)
+	/usr/local/go/src/runtime/asm_ppc64x.s:183 +0x58sync.runtime_Semacquire
+(0xc4201fab1c)
+	/usr/local/go/src/runtime/sema.go:56 +0x38
+
+----
+Note the results may differ between attempts,  hangs and other faults sometimes happen.
+----
+If I run "go: single threaded I don't see the problem, for example:
+
+/go # GOMAXPROCS=1 go build -p 1 hello.go 
+/go # ./hello
+hello world
+
+I see the same issue with arm64.  I don't think this is a go issue, but don't have a real evidence to prove that.  This problem looks similar to other problem I have seen reported against qemu running multi-threaded applications.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1765970 b/results/classifier/gemma3:27b/runtime/1765970
new file mode 100644
index 00000000..627353f1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1765970
@@ -0,0 +1,64 @@
+
+
+
+qemu-arm (user mode) segfaults in uclibc-ng chroot after upgrade to 2.11.x
+
+I use a qemu-user chroot + binfmt to build software targetting a raspberry pi.  After upgrading from qemu-2.10.1 to 2.11.1 (Gentoo host), I noticed that on my uclibc-ng chroot qemu-arm will segfault when running python and importing the portage module.
+
+I have bisected qemu down to this commit:
+
+https://github.com/qemu/qemu/commit/18e80c55bb6ec17c05ec0ba717ec83933c2bfc07
+
+If I recompile and change MAX_RESERVED_VA (from the above commit) back to 0x77000000 the problem goes away.  NB I have no idea what that does, I just thought I'd see.
+
+
+Other arm chroots (glibc, musl) do not segfault with qemu-2.11, only the uclibc-ng one.  Not sure why.
+
+
+The following backtrace was generated from running qemu-arm in gdb and recreating the segfault:
+
+(gdb) where
+#0  0x0000000060726046 in static_code_gen_buffer ()
+#1  0x0000000060048789 in cpu_tb_exec (cpu=0x6278e310, 
+    itb=0x60725f80 <static_code_gen_buffer+314624>)
+    at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:167
+#2  0x000000006004937f in cpu_loop_exec_tb (cpu=0x6278e310, 
+    tb=0x60725f80 <static_code_gen_buffer+314624>, last_tb=0x7fffffffd138, 
+    tb_exit=0x7fffffffd130)
+    at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:627
+#3  0x0000000060049600 in cpu_exec (cpu=0x6278e310)
+    at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/accel/tcg/cpu-exec.c:736
+#4  0x00000000600511c3 in cpu_loop (env=0x627965b0)
+    at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:585
+#5  0x00000000600534eb in main (argc=4, argv=0x7fffffffd9b8, 
+    envp=0x7fffffffd9e0)
+    at /usr/src/debug/app-emulation/qemu-2.11.1-r2/qemu-2.11.1/linux-user/main.c:4882
+
+
+
+(gdb) info reg
+rax            0x627965b0       1652123056
+rbx            0x62717870       1651603568
+rcx            0x606da000       1617797120
+rdx            0x60726000       1618108416
+rsi            0x60726000       1618108416
+rdi            0x627965b0       1652123056
+rbp            0x7fffffffd0c0   0x7fffffffd0c0
+rsp            0x7fffffffd080   0x7fffffffd080
+r8             0x0      0
+r9             0x2      2
+r10            0x0      0
+r11            0x629280a0       1653768352
+r12            0x60260e40       1613106752
+r13            0x0      0
+r14            0x606a5018       1617580056
+r15            0x0      0
+rip            0x60048789       0x60048789 <cpu_tb_exec+266>
+eflags         0x10282  [ SF IF RF ]
+cs             0x33     51
+ss             0x2b     43
+ds             0x0      0
+es             0x0      0
+fs             0x0      0
+gs             0x0      0
+(gdb)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1768 b/results/classifier/gemma3:27b/runtime/1768
new file mode 100644
index 00000000..3b1bd619
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1768
@@ -0,0 +1,35 @@
+
+
+
+Could not allocate more than ~2GB with qemu-user
+Description of problem:
+On qemu-user, failed to allocate more than about 2GB on 32bit platform supporting up to 4GB (arm, ppc, etc.)
+Steps to reproduce:
+1. Try to allocate more than 2GB [e.g. for(i=0;i<64;i++) if(malloc(64*1024*1024)==NULL) perror("Failed to allocate 64MB");]
+2. Only 1 64MB chunck is allocated in the upper 2GB memory space
+3. Failed to allocate after about 2GB.
+Additional information:
+The problem is in **pageflags_find** and **pageflags_next** functions (found in _accel/tcg/user-exec.c_) 3rd parameters, that should be **target_ulong** instead of incorrect _target_long_ (the parameter will be converted signed extended to uint64_t).
+The testing program is the following:
+```
+#include <stdio.h>
+#include <stdlib.h>
+
+int main(int argc,char *argv[]) {
+  unsigned int a;
+  unsigned int i;
+  char *al;
+  unsigned int sss=1U*1024*1024*64;
+  for(a=0;a<128;a++) {
+    al=malloc(sss);
+    if(al!=NULL) {
+      printf("ALLOC OK %u (%08lX)!\n",sss*(a+1),al);
+    }
+    else {
+      printf("Cannot alloc %d\n",(a+1)*sss);
+      perror("Cannot alloc");
+      exit(1);
+    }
+  }
+}
+```
diff --git a/results/classifier/gemma3:27b/runtime/1768246 b/results/classifier/gemma3:27b/runtime/1768246
new file mode 100644
index 00000000..70b9b923
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1768246
@@ -0,0 +1,16 @@
+
+
+
+cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
+
+OpenJDK no longer works on qemu-sh4, it previously did after #1735384 was fixed.
+
+Crash indicates an assertion failure:
+
+(sid-sh4-sbuild)root@nofan:/# java --version
+qemu-sh4-static: /root/qemu/accel/tcg/cpu-exec.c:648: cpu_loop_exec_tb: Assertion `use_icount' failed.
+qemu: uncaught target signal 6 (Aborted) - core dumped
+Aborted
+(sid-sh4-sbuild)root@nofan:/#
+
+Haven't bi-sected the issue yet, but will do so later.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1773743 b/results/classifier/gemma3:27b/runtime/1773743
new file mode 100644
index 00000000..d98167cc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1773743
@@ -0,0 +1,24 @@
+
+
+
+qemu-user -g xxx -E LD_PROFILE=xxx segfault
+
+Here is two simple steps to reproduce the bug:
+
+$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls
+
+(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library)
+
+In a other window launch:
+
+$ gdb
+(gdb) target remote :12345
+(gdb) c
+
+At this point qemu will segfault.
+
+It seems this problem is appends when sigprof passed to gdb.
+One way I have found to bypass this:
+patch gdbstub.c gdb_handlesig and ignore sig if
+sig == TARGET_SIGPROF
+(which means now I can't catch sigprof on gdb anymore)
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1774149 b/results/classifier/gemma3:27b/runtime/1774149
new file mode 100644
index 00000000..55ffb334
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1774149
@@ -0,0 +1,79 @@
+
+
+
+qemu-user x86_64 x86 gdb call function from gdb doesn't work
+
+While running qemu user x86_64 x86 with gdb server, calling functions are not working.
+
+Here is how to reproduce it:
+
+run in a terminal:
+$ qemu-x86_64 -g 12345 -L / /bin/ls
+
+In another terminal run gdb:
+(gdb) file /bin/ls
+(gdb) target remote :12345
+(gdb) b _init
+(gdb) c
+(gdb) call malloc(1)
+Could not fetch register "fs_base"; remote failure reply 'E14'
+
+In other cases we also got the error:
+Could not fetch register "orig_rax"; remote failure reply 'E14'
+
+Here is how I patched it (it is only a workaround):
+
+diff --git a/gdbstub.c b/gdbstub.c
+index 2a94030..5749efe 100644
+--- a/gdbstub.c
++++ b/gdbstub.c
+@@ -668,6 +668,11 @@ static int gdb_read_register(CPUState *cpu, uint8_t *mem_buf, int reg)
+             return r->get_reg(env, mem_buf, reg - r->base_reg);
+         }
+     }
++#ifdef TARGET_X86_64
++    return 8;
++#elif TARGET_I386
++    return 4;
++#endif
+     return 0;
+ }
+
+(Our guess for this issue was, gdb is requesting for 'fake' registers to know register size)
+
+Once we patched that, we got another problem while calling functions from gdb: We could call functions, but only once.
+
+Here is how to reproduce it:
+run in a terminal:
+$ qemu-x86_64 -g 12345 -L / /bin/ls
+
+In another terminal run gdb:
+(gdb) file /bin/ls
+(gdb) target remote :12345
+(gdb) b _init
+(gdb) c
+(gdb) call malloc(1)
+$1 = (void *) 0x620010
+(gdb) call malloc(1)
+Cannot access memory at address 0x40007ffb8f
+
+Here is how we patched it to make it work:
+
+diff --git a/exec.c b/exec.c
+index 03238a3..d303922 100644
+--- a/exec.c
++++ b/exec.c
+@@ -2833,7 +2833,7 @@ int cpu_memory_rw_debug(CPUState *cpu, target_ulong addr,
+         if (!(flags & PAGE_VALID))
+             return -1;
+         if (is_write) {
+-            if (!(flags & PAGE_WRITE))
++            if (!(flags & (PAGE_WRITE | PAGE_WRITE_ORG)))
+                 return -1;
+             /* XXX: this code should not depend on lock_user */
+             if (!(p = lock_user(VERIFY_WRITE, addr, l, 0)))
+
+From what we saw, there is a page which is passed to read-only after first execution, and gdb need to write on that page to put a breakpoint. (on the stack)
+
+We suspect this is linked to this:
+https://qemu.weilnetz.de/w64/2012/2012-06-28/qemu-tech.html#Self_002dmodifying-code-and-translated-code-invalidation
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1776478 b/results/classifier/gemma3:27b/runtime/1776478
new file mode 100644
index 00000000..ea670a05
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1776478
@@ -0,0 +1,49 @@
+
+
+
+Getting qemu: uncaught target signal 6 when running  lv2 plugin cross-compilation
+
+Hey,
+I am part of the Zynthian team and we use qemu-arm-static to cross compile lv2 audio plugins.
+
+When running a compilation of DISTRHO-Ports we get:
+
+lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
+qemu: uncaught target signal 6 (Aborted) - core dumped
+./scripts/generate-ttl.sh: line 27: 16524 Aborted                 $GEN ./$FILE
+Makefile:62: recipe for target 'gen_lv2' failed
+make[1]: *** [gen_lv2] Error 134
+make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports'
+Makefile:104: recipe for target 'lv2' failed
+make: *** [lv2] Error 2
+
+
+lv2_ttl_generator source is here:
+https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator
+
+The command that is ruining is
+lv2_ttl_generator ./TAL-Filter-2.so 
+
+And ./TAL-Filter-2.so source is here:
+https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source
+
+
+
+Is there a way to debug what is going on?
+This runs fine on a Raspberrypi which is armv7
+
+A workaround would also help.
+
+
+Bug in Zynthian:
+https://github.com/zynthian/zynthian-sys/issues/59
+Bug in DISTRHO-Ports:
+https://github.com/DISTRHO/DISTRHO-Ports/issues/29
+
+Using qemu-arm-static version from master from two days ago:
+qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: a7a7309ca52c327c6603d60db90ae4feeae719f7
+
+Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3)
+
+Thanks,
+Guy
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1779634 b/results/classifier/gemma3:27b/runtime/1779634
new file mode 100644
index 00000000..c2c447e8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1779634
@@ -0,0 +1,38 @@
+
+
+
+qemu-x86_64 on aarch64 reports "Synchronous External Abort"
+
+Purpose: to run x86_64 utilities on aarch64 platform (Intel/Dell network adapters' firmware upgrade tools)
+System: aarch64 server platform, with ubuntu 16.04 (xenial) Linux 4.13.0-45-generic #50~16.04.1-Ubuntu SMP Wed May 30 11:14:25 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
+
+Reproduce:
+1) build linux-user qemu-x86_64 static from source (tried both version 1.12.0 & 1.11.02)
+   ./configure --target-list=x86_64-linux-user --disable-system --static --enable-linux-user
+
+2) install the interpreter into binfmt_misc filesystem
+   $ cat /proc/sys/fs/binfmt_misc/qemu-x86_64
+     enabled
+     interpreter /usr/local/bin/qemu-x86_64
+     flags:
+     offset 0
+     magic 7f454c4602010100000000000000000002003e00
+     mask fffffffffffefefcfffffffffffffffffeffffff
+
+3) packaging Intel/Dell upgrade utilities into docker images, I've published two on docker hub:
+   REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
+   heyi/dellupdate     latest              8e013f5511cd        6 hours ago         210MB
+   heyi/nvmupdate64e   latest              9d2de9d0edaa        3 days ago          451MB
+
+4) run the docker container on aarch64 server platform:
+   docker run -it --privileged --network host --volume /usr/local/bin/qemu-x86_64:/usr/local/bin/qemu-x86_64 heyi/dellupdate:latest
+
+5) finally, within docker container run the upgrade tool:
+   # ./Network_Firmware_T6VN9_LN_18.5.17_A00.BIN
+
+Errors: in dmesg it reports excessive 'Synchronous External Abort':
+
+kernel: [242850.159893] Synchronous External Abort: synchronous external abort (0x92000610) at 0x0000000000429958
+kernel: [242850.169199] Unhandled fault: synchronous external abort (0x92000610) at 0x0000000000429958
+
+thanks and best regards, Yi
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1793539 b/results/classifier/gemma3:27b/runtime/1793539
new file mode 100644
index 00000000..9b541f40
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1793539
@@ -0,0 +1,12 @@
+
+
+
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5
+
+During the build of gedit for RISC-V this error occurs:
+
+$ qemu-riscv64 -E LD_LIBRARY_PATH=gedit/.libs ./gedit/.libs/gedit
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6003ddc5
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x600009e4
+
+https://build.opensuse.org/package/live_build_log/openSUSE:Factory:RISCV/gedit/standard/riscv64
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1798 b/results/classifier/gemma3:27b/runtime/1798
new file mode 100644
index 00000000..4d67e493
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1798
@@ -0,0 +1,4 @@
+
+
+
+conversions of malloc/calloc/free to g_malloc/g_new/g_free etc
diff --git a/results/classifier/gemma3:27b/runtime/1799200 b/results/classifier/gemma3:27b/runtime/1799200
new file mode 100644
index 00000000..4048274d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1799200
@@ -0,0 +1,43 @@
+
+
+
+null pointer dereference in tcg_emit_op
+
+I am insert a custom  tcg helper function in i386_tr_insn_start for trace the instructions.
+
+most of time the qemu runed ok ,but when execute some special software  will lead to crash.
+
+
+the below is the insert code:
+=======================================================================================
+
+ 8514 static void i386_tr_insn_start(DisasContextBase *dcbase, CPUState *cpu)
+ 8515 {
+ 8516     DisasContext *dc = container_of(dcbase, DisasContext, base);
+ 8517     TCGv_ptr ptr= tcg_const_ptr((void*)cpu); // inserted hepler code
+ 8518     gen_helper_mad_exec(ptr);// insert helper code
+ 8519     tcg_gen_insn_start(dc->base.pc_next, dc->cc_op);
+ 8520 }
+======================================================================================
+
+below is the callstack 
+
+#0  0x000055555581df5e in tcg_emit_op (opc=opc@entry=INDEX_op_movi_i64) at /root/qemu/tcg/tcg.c:2205
+#1  0x0000555555825911 in tcg_gen_op2 (opc=opc@entry=INDEX_op_movi_i64, a1=140734736923704, a2=a2@entry=792) at /root/qemu/tcg/tcg-op.c:53
+#2  0x000055555581d713 in tcg_const_i64 (opc=INDEX_op_movi_i64, a2=792, a1=0x7378) at /root/qemu/tcg/tcg-op.h:109
+#3  0x000055555581d713 in tcg_const_i64 (arg=792, ret=<optimized out>) at /root/qemu/tcg/tcg-op.h:579
+#4  0x000055555581d713 in tcg_const_i64 (val=val@entry=792) at /root/qemu/tcg/tcg.c:1314
+#5  0x000055555582732d in tcg_gen_addi_i64 (ret=0xd18, arg1=0x378, arg2=arg2@entry=792) at /root/qemu/tcg/tcg-op.c:1200
+#6  0x000055555590ffaf in gen_sse (b=792, a=<optimized out>, r=<optimized out>) at /root/qemu/tcg/tcg-op.h:1258
+#7  0x000055555590ffaf in gen_sse (env=env@entry=0x5555567424d0, s=s@entry=0x7fffea99a610, b=b@entry=366, pc_start=pc_start@entry=4513509698, rex_r=rex_r@entry=0) at /root/qemu/target/i386/translate.c:3150
+#8  0x0000555555911d7f in disas_insn (s=s@entry=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8336
+#9  0x00005555559207a0 in i386_tr_translate_insn (dcbase=0x7fffea99a610, cpu=<optimized out>) at /root/qemu/target/i386/translate.c:8543
+#10 0x0000555555892649 in translator_loop (ops=0x55555622dee0 <i386_tr_ops>, db=0x7fffea99a610, cpu=0x55555673a220, tb=<optimized out>) at /root/qemu/accel/tcg/translator.c:110
+#11 0x00005555559209ef in gen_intermediate_code (cpu=cpu@entry=0x55555673a220, tb=tb@entry=0x7fff70682040 <code_gen_buffer+208150547>) at /root/qemu/target/i386/translate.c:8605
+#12 0x0000555555891437 in tb_gen_code (cpu=cpu@entry=0x55555673a220, pc=pc@entry=4513506448, cs_base=cs_base@entry=0, flags=flags@entry=4244147, cflags=cflags@entry=0) at /root/qemu/accel/tcg/translate-all.c:1728
+#13 0x000055555588f97b in cpu_exec (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0x0) at /root/qemu/accel/tcg/cpu-exec.c:410
+#14 0x000055555588f97b in cpu_exec (cpu=cpu@entry=0x55555673a220) at /root/qemu/accel/tcg/cpu-exec.c:734
+#15 0x000055555584b152 in tcg_cpu_exec (cpu=0x55555673a220) at /root/qemu/cpus.c:1405
+#16 0x000055555584d1b8 in qemu_tcg_rr_cpu_thread_fn (arg=<optimized out>) at /root/qemu/cpus.c:1505
+#17 0x00007ffff2585e25 in start_thread () at /lib64/libpthread.so.0
+#18 0x00007ffff22afbad in clone () at /lib64/libc.so.6
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1805 b/results/classifier/gemma3:27b/runtime/1805
new file mode 100644
index 00000000..970804b2
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1805
@@ -0,0 +1,69 @@
+
+
+
+build-user-hexagon  CI job is not actually testing hexagon
+Description of problem:
+Look at the output from the `build-user-hexagon` CI job and see what compiler meson reports it is using:
+
+  https://gitlab.com/qemu-project/qemu/-/jobs/4790457871
+
+```
+Project name: qemu
+Project version: 8.0.91
+C compiler for the host machine: cc -m64 -mcx16 (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
+C linker for the host machine: cc -m64 -mcx16 ld.bfd 2.35.2
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+```
+
+What is 'cc' resolving to ?
+
+```
+$ podman run -it registry.gitlab.com/qemu-project/qemu/qemu/debian-hexagon-cross cc -v | grep Target
+Target: x86_64-linux-gnu
+```
+
+That is a x86_64 target native compiler, not a hexagon target cross compiler.
+
+The ``tests/docker/dockerfiles/debian-hexagon-cross.docker`` file installs the hexagon toolchain under ``/opt`` and adds the dir to ``$PATH`` with: 
+
+```
+ENV PATH $PATH:${TOOLCHAIN_INSTALL}/${TOOLCHAIN_BASENAME}/x86_64-linux-gnu/bin
+```
+
+This toolchain just installs a `clang` binary, not ``cc``
+
+So when ``configure`` runs it looks for ``cc`` first and finds the naitve x86_64 GCC install from the container, not the clang cross compiler
+
+It is also not possible to merely set ``CC=clang`` because meson will assume it is a native compiler and crash and burn when unable to run binaries
+
+```
+# CC=clang ./configure --target-list=x86_64-softmmu
+Using './build' as the directory for build output
+...snip...
+Sphinx not found/usable, disabling docs.
+Disabling PIE due to missing toolchain support
+The Meson build system
+Version: 1.2.0
+Source dir: /qemu
+Build dir: /qemu/build
+Build type: native build
+Project name: qemu
+Project version: 8.0.92
+
+../meson.build:1:0: ERROR: Executables created by c compiler clang -m64 -mcx16 are not runnable.
+```
+
+AFAICT, the root problem here is that the hexagon container is not setup in the same way as the other cross compiler containers.
+
+We need the toolchain binaries to be named after the target triplet - ie not ``clang`` but ``hexagon-unknown-linux-musl-clang``
+
+This used to be done but was thrown away when switching to a pre-built toolchain in b9052d36342c947b36447558ed0a0dd3fb3fb8f4
+
+Then the container also needs to set the configure args for the cross target
+
+```
+ENV QEMU_CONFIGURE_OPTS --cross-prefix=hexagon-unknown-linux-musl-
+```
+
+AFAICT, this was never done, so even before switching to the pre-built toolchain, I think the `build-user-hexagon` CI job was running a native built not hexagon build.
diff --git a/results/classifier/gemma3:27b/runtime/1807 b/results/classifier/gemma3:27b/runtime/1807
new file mode 100644
index 00000000..aee76b46
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1807
@@ -0,0 +1,27 @@
+
+
+
+sparc64 always segfaults doesn't work on Ubuntu 23.04
+Description of problem:
+It segfaults when it tries to use 'printf' or 'puts' to print to the screen.
+Steps to reproduce:
+Do the following at the command line
+
+```
+$ sparc64-linux-gnu-g++ --version
+sparc64-linux-gnu-g++ (Ubuntu 12.2.0-14ubuntu2) 12.2.0
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+$ echo -e "#include <stdio.h> \n int main(void) { puts(\"Hello World\"); }" > test.cpp
+$ sparc64-linux-gnu-g++ -o test test.cpp -static
+$ qemu-sparc64-static --version
+qemu-sparc64 version 7.2.0 (Debian 1:7.2+dfsg-5ubuntu2)
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+$ qemu-sparc64-static ./test
+Segmentation fault (core dumped)
+$ qemu-sparc-static ./test
+qemu-sparc-static: ./test: Invalid ELF image for this architecture
+$ qemu-sparc32plus-static ./test
+qemu-sparc32plus-static: ./test: Invalid ELF image for this architecture
+```
diff --git a/results/classifier/gemma3:27b/runtime/1808565 b/results/classifier/gemma3:27b/runtime/1808565
new file mode 100644
index 00000000..e7558e3b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1808565
@@ -0,0 +1,10 @@
+
+
+
+Reading /proc/self/task/<pid>/maps is not remapped to the target
+
+Seeing this in qemu-user 3.1.0
+
+The code in is_proc_myself which supports remapping of /proc/self/maps and /proc/<pid>/maps does not support remapping of /proc/self/task/<pid>/maps or /proc/<pid>/task/<pid>/maps. Extending is_proc_myself to cover these cases causes the maps to be rewritten correctly.
+
+These are useful in multithreaded programs to avoid freezing the entire program to capture the maps for a single tid.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1812 b/results/classifier/gemma3:27b/runtime/1812
new file mode 100644
index 00000000..014e2dbf
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1812
@@ -0,0 +1,28 @@
+
+
+
+older programs running under qemu-aarch64 segfaults
+Description of problem:
+Numerous aarch64 programs segfaults when run under qemu-aarch64.
+Steps to reproduce:
+1. Install an arm64 chroot (with working qemu-aarch64 binfmt_misc setup):
+```
+debootstrap --variant=minbase --arch=arm64 jessie /tmp/jessie-arm64/ http://archive.debian.org/debian
+or
+debootstrap --variant=minbase --arch=arm64 xenial /tmp/xenial-arm64/ http://ports.ubuntu.com/
+```
+2. build qemu-aarch64; cp qemu-aarch64 /tmp/jessie-arm64/
+3. chroot /tmp/jessie-arm64/
+4. ./qemu-aarch64 /bin/ls
+```
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault 
+```
+Additional information:
+Old userspace (eg Debian jessie, Ubuntu xenial) does not work within qemu 8.1-rc2 aarch64 linux-user emulation, since commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 .  My guess is that old userspace isn't prepared for recent CPU features, but it still smells strange.
+
+Not all programs segfaults. dash works, ls or bash does not.
+
+A chroot is easier in this case, since many old programs don't run inside current environment, like asserting while reading locale-specific information.  To run debootstrap and to enter the resulting chroot, a working qemu-aarch64 binfmt_misc setup is needed.
+
+Reverting the mentioned commit makes everything work again.
diff --git a/results/classifier/gemma3:27b/runtime/1812451 b/results/classifier/gemma3:27b/runtime/1812451
new file mode 100644
index 00000000..208d03c3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1812451
@@ -0,0 +1,17 @@
+
+
+
+In windows host, tftp arbitrary file read vulnerability
+
+https://github.com/qemu/qemu/blob/master/slirp/tftp.c#L343
+
+  if (!strncmp(req_fname, "../", 3) ||
+      req_fname[strlen(req_fname) - 1] == '/' ||
+      strstr(req_fname, "/../")) {
+      tftp_send_error(spt, 2, "Access violation", tp);
+      return;
+  }
+
+There are file path check for not allowing escape tftp directory.
+But, in windows, file path is separated by "\" backslash.
+So, guest can read arbitrary file in Windows host.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1812861 b/results/classifier/gemma3:27b/runtime/1812861
new file mode 100644
index 00000000..6acdc2c3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1812861
@@ -0,0 +1,25 @@
+
+
+
+QEMU in user-mode emulation mode crashes when the user program jumps to an invalid address
+
+Running this code:
+
+void (*func)() = 0x12345678;
+
+int main()
+{
+    func();
+    return 0;
+}
+
+Produces the following output:
+
+qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
+qemu-arm-static: /build/qemu-DqynNa/qemu-2.8+dfsg/translate-all.c:175: tb_lock: Assertion `!have_tb_lock' failed.
+Segmentation fault
+
+The expected result is as follows:
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1813307 b/results/classifier/gemma3:27b/runtime/1813307
new file mode 100644
index 00000000..f2902e8b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1813307
@@ -0,0 +1,24 @@
+
+
+
+util/path.c/follow_path() does not handle "/" well
+
+Hello,
+
+I noticed that qemu does not handle "/" very well in follow_path().
+
+Specifically, I was trying to run gdbserver under qemu, and it failed inside its implementation of __getcwd.
+
+Indeed it does something like
+  if (__lstat ("/", &st) < 0)
+.....
+and then loops from current dir toward the top using lstat("..")
+
+On qemu side, lstat forwards the request to follow_path() in util/path.c, and when passed "/", it returns the path in QEMU_LD_PREFIX (which was the top of my sysroot).
+OTHT, the series of lstat("..") finally reaches the real device root because it's not recognized as "/" in follow_path(), so this is inconsistent and __getcwd fails.
+
+I suppose there's a good reason for returning QEMU_LD_PREFIX when asking for "/", but why is it so?
+
+If there's no good reason, maybe the behaviour could be changed to map "/" to "/" ?
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1813398 b/results/classifier/gemma3:27b/runtime/1813398
new file mode 100644
index 00000000..cf95330d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1813398
@@ -0,0 +1,44 @@
+
+
+
+qemu user calls malloc after fork in multi-threaded process
+
+qemu user may hang in malloc on a musl based system because
+it calls malloc after fork (in a pthread_atfork handler)
+in the child process.
+
+this is undefined behaviour since the parent process is
+multi-threaded and only as-safe functions may be called
+in the child then. (if malloc/free is called concurrently
+with fork the malloc state will be corrupted in the child,
+it works on glibc because glibc takes the malloc locks
+before the fork syscall, but that breaks the as-safety of
+fork and thus non-conforming to posix)
+
+discussed at
+https://www.openwall.com/lists/musl/2019/01/26/1
+
+the bug is hard to reproduce (requires the call_rcu thread
+to call free concurrently with do_fork in the main thread),
+this one is observed with qemu-arm 3.1.0 running on x86_64
+executing an arm busybox sh:
+
+(gdb) bt
+#0  malloc (n=<optimized out>, n@entry=9) at src/malloc/malloc.c:306
+#1  0x0000000060184ad3 in g_malloc (n_bytes=n_bytes@entry=9) at gmem.c:99
+#2  0x000000006018bcab in g_strdup (str=<optimized out>, str@entry=0x60200abf "call_rcu") at gstrfuncs.c:363
+#3  0x000000006016e31d in qemu_thread_create (thread=thread@entry=0x7ffe367d1870, name=name@entry=0x60200abf "call_rcu", 
+    start_routine=start_routine@entry=0x60174c00 <call_rcu_thread>, arg=arg@entry=0x0, mode=mode@entry=1)
+    at /home/pmos/build/src/qemu-3.1.0/util/qemu-thread-posix.c:526
+#4  0x0000000060174b99 in rcu_init_complete () at /home/pmos/build/src/qemu-3.1.0/util/rcu.c:327
+#5  0x00000000601c4fac in __fork_handler (who=1) at src/thread/pthread_atfork.c:26
+#6  0x00000000601be8db in fork () at src/process/fork.c:33
+#7  0x000000006009d191 in do_fork (env=0x627aaed0, flags=flags@entry=17, newsp=newsp@entry=0, parent_tidptr=parent_tidptr@entry=0, 
+    newtls=newtls@entry=0, child_tidptr=child_tidptr@entry=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:5528
+#8  0x00000000600af894 in do_syscall1 (cpu_env=cpu_env@entry=0x627aaed0, num=num@entry=2, arg1=arg1@entry=0, arg2=arg2@entry=-8700192, 
+    arg3=<optimized out>, arg4=8, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:7042
+#9  0x00000000600a835c in do_syscall (cpu_env=cpu_env@entry=0x627aaed0, num=2, arg1=0, arg2=-8700192, arg3=<optimized out>, 
+    arg4=<optimized out>, arg5=1015744, arg6=-74144, arg7=0, arg8=0) at /home/pmos/build/src/qemu-3.1.0/linux-user/syscall.c:11533
+#10 0x00000000600c265f in cpu_loop (env=env@entry=0x627aaed0) at /home/pmos/build/src/qemu-3.1.0/linux-user/arm/cpu_loop.c:360
+#11 0x00000000600417a2 in main (argc=<optimized out>, argv=0x7ffe367d57b8, envp=<optimized out>)
+    at /home/pmos/build/src/qemu-3.1.0/linux-user/main.c:819
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1814128 b/results/classifier/gemma3:27b/runtime/1814128
new file mode 100644
index 00000000..7b23ecb0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1814128
@@ -0,0 +1,158 @@
+
+
+
+qemu-user fails to set up a reasonable brk for static-pie
+
+static pie binaries may not get a reasonable brk,
+with glibc this means they crash in early tls setup code:
+https://sourceware.org/bugzilla/show_bug.cgi?id=24152
+
+qemu seems to put brk at the end of the data segment,
+but if the stack starts (ends) right next to it then
+allocation with brk fails.
+
+in such situation i think qemu should arrange the
+stack or brk to be elsewhere so there is plenty
+space to grow (in case of glibc it's enough if tls
+setup works: later allocations can fall back to mmap).
+
+(ubuntu bionic x86_64 ldconfig.real from libc-bin package)
+$ qemu-x86_64 -strace -d page /sbin/ldconfig.real
+host mmap_min_addr=0x8000
+guest_base  0x0
+start            end              size             prot
+0000004000000000-00000040000f2000 00000000000f2000 r-x
+00000040000f2000-00000040002f2000 0000000000200000 ---
+00000040002f2000-00000040002fa000 0000000000008000 rw-
+00000040002fa000-00000040002fb000 0000000000001000 ---
+00000040002fb000-0000004000afb000 0000000000800000 rw-
+start_brk   0x0000000000000000
+end_code    0x00000040000f1ee8
+start_code  0x0000004000000000
+start_data  0x00000040002f2838
+end_data    0x00000040002f8518
+start_stack 0x0000004000afa130
+brk         0x00000040002f9dd8
+entry       0x0000004000009bc0
+argv_start  0x0000004000afa138
+env_start   0x0000004000afa148
+auxv_start  0x0000004000afa280
+28561 brk(NULL) = 0x00000040002fa000
+28561 brk(0x00000040002fb1c0) = 0x00000040002fa000
+--- SIGSEGV {si_signo=SIGSEGV, si_code=1, si_addr=0xffffffffffffffc0} ---
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+$ readelf -hldSW /tmp/ldconfig.real
+ELF Header:
+  Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
+  Class:                             ELF64
+  Data:                              2's complement, little endian
+  Version:                           1 (current)
+  OS/ABI:                            UNIX - GNU
+  ABI Version:                       0
+  Type:                              DYN (Shared object file)
+  Machine:                           Advanced Micro Devices X86-64
+  Version:                           0x1
+  Entry point address:               0x9bc0
+  Start of program headers:          64 (bytes into file)
+  Start of section headers:          1022920 (bytes into file)
+  Flags:                             0x0
+  Size of this header:               64 (bytes)
+  Size of program headers:           56 (bytes)
+  Number of program headers:         8
+  Size of section headers:           64 (bytes)
+  Number of section headers:         38
+  Section header string table index: 37
+
+Section Headers:
+  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
+  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
+  [ 1] .note.ABI-tag     NOTE            0000000000000200 000200 000020 00   A  0   0  4
+  [ 2] .note.gnu.build-id NOTE            0000000000000220 000220 000024 00   A  0   0  4
+  [ 3] .gnu.hash         GNU_HASH        0000000000000248 000248 00001c 00   A  4   0  8
+  [ 4] .dynsym           DYNSYM          0000000000000268 000268 000018 18   A  5   1  8
+  [ 5] .dynstr           STRTAB          0000000000000280 000280 000001 00   A  0   0  1
+  [ 6] .rela.dyn         RELA            0000000000000288 000288 008748 18   A  4   0  8
+  [ 7] .rela.plt         RELA            00000000000089d0 0089d0 000318 18  AI  4  27  8
+  [ 8] .init             PROGBITS        0000000000008ce8 008ce8 000017 00  AX  0   0  4
+  [ 9] .plt              PROGBITS        0000000000008d00 008d00 000270 10  AX  0   0 16
+  [10] .plt.got          PROGBITS        0000000000008f70 008f70 000060 08  AX  0   0  8
+  [11] .text             PROGBITS        0000000000008fd0 008fd0 0bd29c 00  AX  0   0 16
+  [12] __libc_freeres_fn PROGBITS        00000000000c6270 0c6270 0016b3 00  AX  0   0 16
+  [13] __libc_thread_freeres_fn PROGBITS        00000000000c7930 0c7930 00108f 00  AX  0   0 16
+  [14] .fini             PROGBITS        00000000000c89c0 0c89c0 000009 00  AX  0   0  4
+  [15] .rodata           PROGBITS        00000000000c89e0 0c89e0 01af08 00   A  0   0 32
+  [16] .stapsdt.base     PROGBITS        00000000000e38e8 0e38e8 000001 00   A  0   0  1
+  [17] .eh_frame_hdr     PROGBITS        00000000000e38ec 0e38ec 001f94 00   A  0   0  4
+  [18] .eh_frame         PROGBITS        00000000000e5880 0e5880 00c5b8 00   A  0   0  8
+  [19] .gcc_except_table PROGBITS        00000000000f1e38 0f1e38 0000b0 00   A  0   0  1
+  [20] .tdata            PROGBITS        00000000002f2838 0f2838 000028 00 WAT  0   0  8
+  [21] .tbss             NOBITS          00000000002f2860 0f2860 000040 00 WAT  0   0  8
+  [22] .init_array       INIT_ARRAY      00000000002f2860 0f2860 000010 08  WA  0   0  8
+  [23] .fini_array       FINI_ARRAY      00000000002f2870 0f2870 000010 08  WA  0   0  8
+  [24] .data.rel.ro      PROGBITS        00000000002f2880 0f2880 0034c4 00  WA  0   0 32
+  [25] .dynamic          DYNAMIC         00000000002f5d48 0f5d48 0001a0 10  WA  5   0  8
+  [26] .got              PROGBITS        00000000002f5ee8 0f5ee8 000110 08  WA  0   0  8
+  [27] .got.plt          PROGBITS        00000000002f6000 0f6000 000148 08  WA  0   0  8
+  [28] .data             PROGBITS        00000000002f6160 0f6160 001bd4 00  WA  0   0 32
+  [29] __libc_subfreeres PROGBITS        00000000002f7d38 0f7d38 000060 00  WA  0   0  8
+  [30] __libc_IO_vtables PROGBITS        00000000002f7da0 0f7da0 000768 00  WA  0   0 32
+  [31] __libc_atexit     PROGBITS        00000000002f8508 0f8508 000008 00  WA  0   0  8
+  [32] __libc_thread_subfreeres PROGBITS        00000000002f8510 0f8510 000008 00  WA  0   0  8
+  [33] .bss              NOBITS          00000000002f8520 0f8518 001890 00  WA  0   0 32
+  [34] __libc_freeres_ptrs NOBITS          00000000002f9db0 0f8518 000028 00  WA  0   0  8
+  [35] .note.stapsdt     NOTE            0000000000000000 0f8518 0014cc 00      0   0  4
+  [36] .gnu_debuglink    PROGBITS        0000000000000000 0f99e4 000034 00      0   0  4
+  [37] .shstrtab         STRTAB          0000000000000000 0f9a18 0001ab 00      0   0  1
+Key to Flags:
+  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
+  L (link order), O (extra OS processing required), G (group), T (TLS),
+  C (compressed), x (unknown), o (OS specific), E (exclude),
+  l (large), p (processor specific)
+
+Program Headers:
+  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
+  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0f1ee8 0x0f1ee8 R E 0x200000
+  LOAD           0x0f2838 0x00000000002f2838 0x00000000002f2838 0x005ce0 0x0075a0 RW  0x200000
+  DYNAMIC        0x0f5d48 0x00000000002f5d48 0x00000000002f5d48 0x0001a0 0x0001a0 RW  0x8
+  NOTE           0x000200 0x0000000000000200 0x0000000000000200 0x000044 0x000044 R   0x4
+  TLS            0x0f2838 0x00000000002f2838 0x00000000002f2838 0x000028 0x000068 R   0x8
+  GNU_EH_FRAME   0x0e38ec 0x00000000000e38ec 0x00000000000e38ec 0x001f94 0x001f94 R   0x4
+  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
+  GNU_RELRO      0x0f2838 0x00000000002f2838 0x00000000002f2838 0x0037c8 0x0037c8 R   0x1
+
+ Section to Segment mapping:
+  Segment Sections...
+   00     .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.dyn .rela.plt .init .plt .plt.got .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base .eh_frame_hdr .eh_frame .gcc_except_table 
+   01     .tdata .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .bss __libc_freeres_ptrs 
+   02     .dynamic 
+   03     .note.ABI-tag .note.gnu.build-id 
+   04     .tdata .tbss 
+   05     .eh_frame_hdr 
+   06     
+   07     .tdata .init_array .fini_array .data.rel.ro .dynamic .got 
+
+Dynamic section at offset 0xf5d48 contains 22 entries:
+  Tag        Type                         Name/Value
+ 0x000000000000000c (INIT)               0x8ce8
+ 0x000000000000000d (FINI)               0xc89c0
+ 0x0000000000000019 (INIT_ARRAY)         0x2f2860
+ 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
+ 0x000000000000001a (FINI_ARRAY)         0x2f2870
+ 0x000000000000001c (FINI_ARRAYSZ)       16 (bytes)
+ 0x000000006ffffef5 (GNU_HASH)           0x248
+ 0x0000000000000005 (STRTAB)             0x280
+ 0x0000000000000006 (SYMTAB)             0x268
+ 0x000000000000000a (STRSZ)              1 (bytes)
+ 0x000000000000000b (SYMENT)             24 (bytes)
+ 0x0000000000000015 (DEBUG)              0x0
+ 0x0000000000000003 (PLTGOT)             0x2f6000
+ 0x0000000000000002 (PLTRELSZ)           792 (bytes)
+ 0x0000000000000014 (PLTREL)             RELA
+ 0x0000000000000017 (JMPREL)             0x89d0
+ 0x0000000000000007 (RELA)               0x288
+ 0x0000000000000008 (RELASZ)             34632 (bytes)
+ 0x0000000000000009 (RELAENT)            24 (bytes)
+ 0x000000006ffffffb (FLAGS_1)            Flags: PIE
+ 0x000000006ffffff9 (RELACOUNT)          1443
+ 0x0000000000000000 (NULL)               0x0
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1818483 b/results/classifier/gemma3:27b/runtime/1818483
new file mode 100644
index 00000000..a05053f1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1818483
@@ -0,0 +1,45 @@
+
+
+
+qemu user mode does not support binfmt_misc config with flags include "P"
+
+Hi Sir:
+During our test in chroot environment with qemu-user-static, we got some test cases failed because of program output warning with unexpected full path name.
+For example in test module "Devscripts"
+the test item for broken tarball expected the warning info:
+<tar: This does not look like a tar archive
+tar: ******* >
+but the output was:
+</bin/tar: This does not look like a tar archive
+/bin/tar: ******>
+the cause is the config file of binfmt_misc was set not to send argv0, for example:
+type command "tar" after chroot:
+==========================
+lpeng@lpeng-VirtualBox:~/projects_lpeng/qemu/mips_2/sid$ sudo chroot .
+[sudo] password for lpeng: 
+root@lpeng-VirtualBox:/# tar
+/bin/tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options
+Try '/bin/tar --help' or '/bin/tar --usage' for more information.
+root@lpeng-VirtualBox:/# 
+===========================
+
+by adding output log in main()@qemu/Linux-user/main.c
+we found the original input command was changed, and qemu do not know that, we got the input args:
+argv_0----/usr/bin/qemu-mips64el-static---
+argv_1----/bin/tar---
+argv_2----NULL---
+
+Next step we modified the flags=P in the corresponding config under folder /proc/sys/fs/binfmt_misc, then binfmt_misc sent argv[0] to qemu.
+But chroot could not start bash because in current qemu dose not consider about this unexpected one more"argv[0]"
+
+
+After modified qemu code temporary to handle the new argv list we got the input args, and from argv[2] is the original input command
+argv_0----/usr/bin/qemu-mips64el-static---
+argv_1----/bin/tar---
+argv_2----tar---
+
+We need the original input from command line, so is it possible that let binfmt_misc to pass one more additional args or env to qemu as a token of the binfmt_misc flag, then qemu can judge how to parse the input args by it?
+looking forward your suggestions.
+
+Thanks
+luyou
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1819 b/results/classifier/gemma3:27b/runtime/1819
new file mode 100644
index 00000000..a1740d8e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1819
@@ -0,0 +1,13 @@
+
+
+
+segmentation fault for rpm -qa command on centos:centos7 linux/arm/v7 architecture for docker container in shell.
+Description of problem:
+
+Steps to reproduce:
+1. docker pull centos:centos7@sha256:6887440ab977f751d6675157b73e42428d8ac05cf244c5d09ba036cc22d40d13 //pull an image centos:centos7 linux/arm/v7 tag
+2. docker run -it b22fdcc90005 //docker run in interactive mode just pulled image
+3. on shell run command -\> rpm -qa.
+4. docker run -it b22fdcc90005
+
+   WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/amd64) and no specific platform was requested \[root@e23bc92686e8 /\]# rpm -qa Segmentation fault (core dumped)
diff --git a/results/classifier/gemma3:27b/runtime/1821515 b/results/classifier/gemma3:27b/runtime/1821515
new file mode 100644
index 00000000..9392e639
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1821515
@@ -0,0 +1,41 @@
+
+
+
+qemu-ppc (user) incorrectly converts float(nan)->double(non-nan)
+
+Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs.
+Here is the minimal reproducer:
+
+```c
+// cat a.c
+#include <stdio.h>
+#include <math.h>
+#include <stdint.h>
+
+int main() {
+    volatile float f1 = NAN;
+    volatile float f2 = NAN;
+    printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n",
+        f1, *(volatile uint32_t*)&f1,
+        f2, *(volatile uint32_t*)&f2,
+        (f1 >= f2) ? "True"
+                   : "False");
+    volatile double d = f1;
+    printf ("d (%e, %#llx)\n",
+        d, *(volatile uint64_t*)&d);
+}
+```
+
+```
+# incorrect execution:
+$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a 
+f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True
+d (5.104236e+38, 0x47f8000000000000)
+
+# correct execution
+$ scp a timberdoodle.ppc64.dev.gentoo.org:~/;  ssh timberdoodle.ppc64.dev.gentoo.org ./a
+f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False
+d (nan, 0x7ff8000000000000)
+```
+
+Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1830 b/results/classifier/gemma3:27b/runtime/1830
new file mode 100644
index 00000000..27322faa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1830
@@ -0,0 +1,29 @@
+
+
+
+command hangs in CentOS 7 arm64 container with Ubuntu 22 amd64 host
+Description of problem:
+The command hangs in the container, taking over the CPU:
+
+```
+$ docker run -it centos:7
+[root@42e655bf3d60 /]# LD_DEBUG=all /lib64/ld-2.17.so --list /usr/bin/true &
+[1] 74
+[root@42e655bf3d60 /]#         74:      file=/usr/bin/true [0];  generating link map
+
+[root@42e655bf3d60 /]# ps -e -o pid,ppid,etime,time,state,args
+    PID    PPID     ELAPSED     TIME S COMMAND
+      1       0       34:59 00:00:00 S /usr/libexec/qemu-binfmt/aarch64-binfmt-P /bin/bash /bin/bash
+     74       1       03:16 00:03:13 R /usr/libexec/qemu-binfmt/aarch64-binfmt-P /lib64/ld-2.17.so /lib64/ld-2.17.so
+     80       1  4-19:34:01 00:00:00 R ps -e -o pid,ppid,etime,time,state,args
+[root@42e655bf3d60 /]#
+```
+Steps to reproduce:
+1. Start container
+2. Run `/lib64/ld-2.17.so --list /usr/bin/true`
+Additional information:
+1. The problem is not observed in an Ubuntu 20.04 host system performing the same scenario.
+2. My team build environment has amd64 native architecture hardware.  I ran a similar scenario on an AWS arm64 native machine (QEMU is not needed) and the command works fine in the container.
+3. My team builds several Linux images daily - about a dozen amd64 and eight arm64.  This is the only image that's causing us this problem.
+4. I built trace-cmd but when I tried to start a trace it told me `No events enabled with kvm`.
+5. I built qemu-8.1.0-rc3 and saw the same behavior but I don't think `/usr/libexec/qemu-binfmt/aarch64-binfmt-P` was replaced with a new version so I don't think the old version was used for my container.
diff --git a/results/classifier/gemma3:27b/runtime/1832353 b/results/classifier/gemma3:27b/runtime/1832353
new file mode 100644
index 00000000..8840513f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1832353
@@ -0,0 +1,23 @@
+
+
+
+cpu_exec: Assertion !have_mmap_lock() failed
+
+Hi,
+
+I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of:
+
+qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed.
+
+including with master qemu as of today.
+
+I'm attaching a tarball containing:
+qemu-assert:
+cmd  lib  proc_ptr_51.exe
+
+qemu-assert/lib:
+ld-linux-armhf.so.3  libc.so.6  libgcc_s.so.1  libgfortran.so.5  libm.so.6
+
+where cmd is the basic command used to launch the test & reproduce the failure.
+
+Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1832916 b/results/classifier/gemma3:27b/runtime/1832916
new file mode 100644
index 00000000..fd8f7301
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1832916
@@ -0,0 +1,8 @@
+
+
+
+linux-user does not check PROT_EXEC
+
+At no point do we actually verify that a page is PROT_EXEC before translating.  All we end up verifying is that the page is readable.  Not the same thing, obviously.
+
+The following test case should work for any architecture, though I've only validated it for x86_64 and aarch64.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1833668 b/results/classifier/gemma3:27b/runtime/1833668
new file mode 100644
index 00000000..c6a88da6
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1833668
@@ -0,0 +1,30 @@
+
+
+
+linux-user: Unable to run ARM binaries on Aarch64
+
+Download a ARM package from https://packages.debian.org/sid/busybox-static
+
+Here tested with: busybox-static_1.30.1-4_armel.deb
+
+$ file busybox.armel
+busybox.armel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=12cf572e016bafa240e113b57b3641e94b837f37, stripped
+
+$ qemu-aarch64 --version
+qemu-aarch64 version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.14)
+
+$ qemu-aarch64 busybox.armel
+busybox.armel: Invalid ELF image for this architecture
+
+$ qemu-aarch64 -cpu cortex-a7 busybox.armel
+unable to find CPU model 'cortex-a7'
+
+Also reproduced with commit 33d609990621dea6c7d056c86f707b8811320ac1,
+while the aarch64_cpus[] array contains Aarch64 CPUs, the arm_cpus[] array is empty:
+
+$ gdb -q aarch64-linux-user/qemu-aarch64
+(gdb) p aarch64_cpus
+$1 = {{name = 0x1fe4e8 "cortex-a57", initfn = 0x109bc0 <aarch64_a57_initfn>, class_init = 0x0}, {name = 0x1fe508 "cortex-a53", initfn = 0x109a10 <aarch64_a53_initfn>, class_init = 0x0}, {name = 0x1fe518 "cortex-a72", 
+    initfn = 0x109868 <aarch64_a72_initfn>, class_init = 0x0}, {name = 0x218020 "max", initfn = 0x109d70 <aarch64_max_initfn>, class_init = 0x0}, {name = 0x0, initfn = 0x0, class_init = 0x0}}
+(gdb) p arm_cpus
+$2 = {{name = 0x0, initfn = 0x0, class_init = 0x0}}
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1834496 b/results/classifier/gemma3:27b/runtime/1834496
new file mode 100644
index 00000000..5d976716
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1834496
@@ -0,0 +1,30 @@
+
+
+
+Regressions on arm target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date:   Fri Jun 21 15:40:50 2019 +0100
+
+I found several regressions compared to qemu-3.1 when running the GCC testsuite.
+I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.
+
+All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash:
+
+qemu: uncaught target signal 6 (Aborted) - core dumped
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabi
+--with-mode arm
+--with-cpu cortex-a9
+
+and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference).
+
+I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later.
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1835693 b/results/classifier/gemma3:27b/runtime/1835693
new file mode 100644
index 00000000..1ccfe970
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1835693
@@ -0,0 +1,20 @@
+
+
+
+s390x binaries segfault
+
+Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host.
+
+$ cat hello.cpp 
+#include <iostream>
+using std::cout;
+
+int main() {
+    cout << "Hello World!\n";
+    return 0;
+}
+
+$ s390x-linux-gnu-g++ -o hello hello.cpp
+
+$ qemu-s390x-static hello
+Segmentation fault
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1835839 b/results/classifier/gemma3:27b/runtime/1835839
new file mode 100644
index 00000000..c863d3fa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1835839
@@ -0,0 +1,24 @@
+
+
+
+qemu-user: $0 incorrectly always reports absolute path
+
+We just ran into an issue with the Perl package on Debian/m68k when being built with qemu-user [1].
+
+The problem can be boiled down to qemu-user always reporting absolute paths for the shell variable $0 no matter on how the command was invoked.
+
+A simple reproducer is this:
+
+On normal system (no emulation):
+
+root@nofan:~> sh -c 'echo $0'
+sh
+root@nofan:~>
+
+On qemu-user:
+
+(sid-m68k-sbuild)root@nofan:/# sh -c 'echo $0'
+/bin/sh
+(sid-m68k-sbuild)root@nofan:/#
+
+> [1] https://lists.debian.org/debian-68k/2019/07/msg00007.html
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1836078 b/results/classifier/gemma3:27b/runtime/1836078
new file mode 100644
index 00000000..506e6e58
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1836078
@@ -0,0 +1,25 @@
+
+
+
+Regressions on arm-linux-gnueabihf target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date: Fri Jun 21 15:40:50 2019 +0100
+
+even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
+I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite.
+I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests.
+
+All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash.
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabihf
+--with-cpu cortex-a57
+--with-fpu crypto-neon-fp-armv8
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1836192 b/results/classifier/gemma3:27b/runtime/1836192
new file mode 100644
index 00000000..935aefbc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1836192
@@ -0,0 +1,24 @@
+
+
+
+Regressions on arm926 target with some GCC tests
+
+Hi,
+
+After trying qemu master:
+commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde
+Merge: 68d7ff0 14f5d87
+Author: Peter Maydell <email address hidden>
+Date: Fri Jun 21 15:40:50 2019 +0100
+
+even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496,
+I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926.
+
+I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test.
+
+This was noticed with GCC master configured with
+--target arm-none-linux-gnueabi
+--with-cpu arm10tdmi
+--with-fpu vfp
+
+Thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1836558 b/results/classifier/gemma3:27b/runtime/1836558
new file mode 100644
index 00000000..3fc7acaf
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1836558
@@ -0,0 +1,51 @@
+
+
+
+Qemu-ppc Memory leak creating threads
+
+When creating c++ threads (with c++ std::thread), the resulting binary has memory leaks when running with qemu-ppc.
+
+Eg the following c++ program, when compiled with gcc, consumes more and more memory while running at qemu-ppc. (does not have memory leaks when compiling for Intel, when running same binary on real powerpc CPU hardware also no memory leaks).
+
+(Note I used function getCurrentRSS to show available memory, see https://stackoverflow.com/questions/669438/how-to-get-memory-usage-at-runtime-using-c; calls commented out here)
+
+Compiler: powerpc-linux-gnu-g++ (Debian 8.3.0-2) 8.3.0 (but same problem with older g++ compilers even 4.9)
+Os: Debian 10.0 ( Buster) (but same problem seen on Debian 9/stetch)
+qemu: qemu-ppc version 3.1.50
+
+
+
+---
+
+#include <iostream>
+#include <thread>
+#include <chrono>
+
+
+using namespace std::chrono_literals;
+
+// Create/run and join a 100 threads.
+void Fun100()
+{
+//    auto b4 = getCurrentRSS();
+//    std::cout << getCurrentRSS() << std::endl;
+    for(int n = 0; n < 100; n++)
+    {
+        std::thread t([]
+        {
+            std::this_thread::sleep_for( 10ms );
+        });
+//        std::cout << n << ' ' << getCurrentRSS() << std::endl;
+        t.join();
+    }
+    std::this_thread::sleep_for( 500ms ); // to give OS some time to wipe memory...
+//    auto after = getCurrentRSS();
+    std::cout << b4 << ' ' << after << std::endl;
+}
+
+
+int main(int, char **)
+{
+    Fun100();
+    Fun100();  // memory used keeps increasing
+}
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1840922 b/results/classifier/gemma3:27b/runtime/1840922
new file mode 100644
index 00000000..79a8d0f3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1840922
@@ -0,0 +1,24 @@
+
+
+
+qemu-arm for cortex-m33 aborts with unhandled CPU exception 0x8
+
+Hi,
+
+While experimenting with running the GCC testsuite with cortex-m33 as target (to exercise v8-m code), I came across this failure:
+qemu: unhandled CPU exception 0x8 - aborting
+R00=fffeaf58 R01=fffeaf58 R02=00000000 R03=fffeaf5d
+R04=fffeaf5c R05=fffeaf9c R06=00000000 R07=fffeaf80
+R08=00000000 R09=00000000 R10=00019dbc R11=00000000
+R12=000000f0 R13=fffeaf58 R14=000081f3 R15=fffeaf5c
+XPSR=61000000 -ZC- T NS priv-thread
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6033c908
+
+I'm using arm-eabi-gcc, so it targets bare-metal, not linux.
+
+The testcase is GCC's gcc/testsuite/gcc.c-torture/execute/20000822-1.c; it works when compiled at -O2, but crashes when compiled at -Os. The test uses nested functions, so it creates a trampoline on the stack, whose address may be a problem. But since the stack address seems to be in the same range in the O2 and Os cases, it's not that clear.
+
+I'm attaching the C source, asm, binary executables and qemu traces with in_asm,cpu.
+
+I execute the binaries with:
+qemu-arm --cpu cortex-m33  ./20000822-1.exe.Os
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1854 b/results/classifier/gemma3:27b/runtime/1854
new file mode 100644
index 00000000..fd165c9e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1854
@@ -0,0 +1,21 @@
+
+
+
+s390x: qemu-user: ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Description of problem:
+The nolibc-test program from the Linux kernel crashes since 5f4e5b34092556ab1577e25d1262bd5975b26980 .
+Reverting that commit fixes the issue.
+Steps to reproduce:
+1. Build `nolibc-test` for s390x from Linux kernel tree. (from `tools/testing/selftests/nolibc/`). EDIT: compiled binary is uploaded below.
+2. Run it under qemu-s390x.
+
+```
+ ./qemu-s390x nolibc-test
+**
+ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Bail out! ERROR:../linux-user/elfload.c:2239:zero_bss: code should not be reached
+Aborted (core dumped)
+
+```
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1857 b/results/classifier/gemma3:27b/runtime/1857
new file mode 100644
index 00000000..64840da4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1857
@@ -0,0 +1,55 @@
+
+
+
+Major qemu-aarch64 performance slowdown since commit 59b6b42cd3
+Description of problem:
+I have observed a major performance slowdown between qemu 8.0.0 and 8.1.0:
+
+
+qemu 8.0.0: 0.8s
+
+qemu 8.1.0: 6.8s
+
+
+After bisecting the commits between 8.0.0 and 8.1.0, the offending commit is 59b6b42cd3:
+
+
+commit 59b6b42cd3446862567637f3a7ab31d69c9bef51
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jun 6 10:19:39 2023 +0100
+
+    target/arm: Enable FEAT_LSE2 for -cpu max
+
+    Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+    Message-id: 20230530191438.411344-21-richard.henderson@linaro.org
+    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
+
+
+Reverting the commit in latest master fixes the problem:
+
+qemu 8.0.0: 0.8s
+
+qemu 8.1.0: 6.8s
+
+qemu master + revert 59b6b42cd3: 0.8s
+
+Alternatively, specify `-cpu cortex-a35` to disable LSE2:
+
+`time ./qemu-aarch64 -cpu cortex-a35`: 0.8s
+
+`time ./qemu-aarch64`: 6.77s
+
+The slowdown is also observed when running qemu-aarch64 on aarch64 machine:
+
+`time ./qemu-aarch64 /usr/bin/node -e 1`: 2.91s
+
+`time ./qemu-aarch64 -cpu cortex-a35 /usr/bin/node -e 1`: 1.77s
+
+The slowdown on x86_64 machine is small: 362ms -> 378ms.
+Steps to reproduce:
+1. Run `time ./qemu-aarch64 node-aarch64 -e 1` (node-aarch64 is NodeJS v16 built for AArch64)
+2. Using qemu master, the output says `0.8s`
+3. Using qemu master with commit 59b6b42cd3 reverted, the output says `6.77s`
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/1858415 b/results/classifier/gemma3:27b/runtime/1858415
new file mode 100644
index 00000000..9a66d641
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1858415
@@ -0,0 +1,27 @@
+
+
+
+in tcp_emu function has OOB bug
+
+qemu version: 4.1.0 
+
+```c
+int tcp_emu(struct socket *so, struct mbuf *m){
+............
+case EMU_REALAUDIO:
+............
+    while (bptr < m->m_data + m->m_len) {
+        case 6:
+............
+            lport = (((uint8_t *)bptr)[0] << 8) + ((uint8_t *)bptr)[1];
+............               
+            *(uint8_t *)bptr++ = (p >> 8) & 0xff;
+            *(uint8_t *)bptr = p & 0xff;
+............
+    }
+............
+............
+}
+```
+
+bptr)[1] and  bptr++ ,may make bptr ==  m->m_data + m->m_len,and cause OOB（out of bounds.）
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1860056 b/results/classifier/gemma3:27b/runtime/1860056
new file mode 100644
index 00000000..441b6f4a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1860056
@@ -0,0 +1,23 @@
+
+
+
+mips binaries segfault
+
+Hello World appears to segfault with qemu mips, on a Debian 10.0.0 Buster amd64 host.
+
+Example:
+
+
+$ cat mips/test/hello.cpp 
+#include <iostream>
+using std::cout;
+
+int main() {
+    cout << "Hello World!\n";
+    return 0;
+}
+
+$ mips-linux-gnu-g++ -o hello hello.cpp && ./hello
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+Note that 64-bit MIPS and little endian 32-bit MIPS qemu work fine. The problem is limited to big endian 32-bit MIPS.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1860610 b/results/classifier/gemma3:27b/runtime/1860610
new file mode 100644
index 00000000..aafd772c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1860610
@@ -0,0 +1,10 @@
+
+
+
+cap_disas_plugin leaks memory
+
+Looking at origin/master head, the function cap_disas_plugin leaks memory.
+
+per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close.
+
+I discovered this running qemu under valgrind.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1862986 b/results/classifier/gemma3:27b/runtime/1862986
new file mode 100644
index 00000000..354df31c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1862986
@@ -0,0 +1,67 @@
+
+
+
+qemu-s390x segfaults
+
+All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault when run on an aarch64 odroid Ubuntu.
+
+Steps to reproduce:
+
+root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
+Segmentation fault (core dumped)
+root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version
+qemu-s390x version 4.2.0
+Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
+root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig"
+Segmentation fault (core dumped)
+root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version
+qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+
+qemu-arm does work on the same machine:
+
+root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
+Running 4 test cases...
+
+*** No errors detected
+root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests
+Running 4 test cases...
+
+*** No errors detected
+
+
+What kind of debug information would be helpful for this issue report?
+
+
+GDB for the self-compiled latest release is not particularly helpful:
+
+(gdb) run
+Starting program: /usr/local/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
+[New Thread 0x7fb7a2a140 (LWP 28264)]
+
+Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
+0x000000555596b218 in __bss_start__ ()
+(gdb) bt
+#0  0x000000555596b218 in __bss_start__ ()
+#1  0x00000055556120a8 in ?? ()
+#2  0x00000055579904b0 in ?? ()
+Backtrace stopped: previous frame inner to this frame (corrupt stack?)
+
+A bit more information is available in the version shipped by Ubuntu:
+
+(gdb) run
+Starting program: /usr/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
+[New Thread 0x7fb7a01180 (LWP 28271)]
+
+Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault.
+0x0000005555738f98 in code_gen_buffer ()
+(gdb) bt
+#0  0x0000005555738f98 in code_gen_buffer ()
+#1  0x00000055555e96c8 in cpu_exec ()
+#2  0x00000055555ee430 in cpu_loop ()
+#3  0x00000055555c3328 in main ()
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1863445 b/results/classifier/gemma3:27b/runtime/1863445
new file mode 100644
index 00000000..699fc350
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1863445
@@ -0,0 +1,19 @@
+
+
+
+assertion failed at translate-all.c:2523 with version 3.1.1 
+
+I was trying to debug a userspace binary with radare2 and met the following assertion in qemu:
+
+```
+qemu-mipsel: /builddir/build/BUILD/qemu-3.1.1/accel/tcg/translate-all.c:2523: page_check_range: Assertion `start < ((target_ulong)1 << L1_MAP_ADDR_SPACE_BITS)' failed.
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7fd1c11c5987
+```
+
+```
+# qemu-mipsel --version                                                                                   
+qemu-mipsel version 3.1.1 (qemu-3.1.1-2.fc30)
+Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers
+```
+
+not much to add. seems like qemu is not properly checking for valid addresses
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1869073 b/results/classifier/gemma3:27b/runtime/1869073
new file mode 100644
index 00000000..37f73332
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1869073
@@ -0,0 +1,10 @@
+
+
+
+qemu-arm-static crashes "segmentation fault" when running "git clone -s"
+
+I want to use qemu-arm-static to cross-compile software. The compiler itself is a native cross-compiler connected via "distcc".
+
+The problem is that a script tries to do some stuff with "git" and with a "git clone -s" command the whole story reproducibly stops with a "segmentation fault".
+
+I don't know how to properly debug the issue but it happens 100% of the time that I get the "crash" or git just hangs forever with 100% CPU usage.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1869241 b/results/classifier/gemma3:27b/runtime/1869241
new file mode 100644
index 00000000..6b7faaa9
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1869241
@@ -0,0 +1,22 @@
+
+
+
+svn checkout fails with E000075 "Value too large for defined data type"
+
+I try to autobuild for ARM7 with qemu-arm-static. Part of this is downloading source via SVN.
+
+Whenever I try to download a SVN repository I get the following output:
+
+    svn: E000075: Can't read directory '...': Value too large for defined data type
+
+qemu-arm-static version is 4.2.0
+
+I've also tried older versions without change.
+
+Platform I try to emulate is armv7h (Arch Linux ARM for Raspberry Pi 2)
+
+Host system is AMD64
+
+This can be reproduced 100% of the time. Here I have the issue happening on Travis CI:
+
+https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/304839747#L7228
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1869782 b/results/classifier/gemma3:27b/runtime/1869782
new file mode 100644
index 00000000..4128c960
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1869782
@@ -0,0 +1,16 @@
+
+
+
+qemu-arm-static crashes "segmentation fault" when running "svn checkout"
+
+I'm not actually sure how far I can help as I so far failed to reproduce the issue on my local VM but I get it on Travis CI every time. I even went through the hassle of hacking a Debian repository into their Ubuntu Bionic VM to get qemu 4.2 as I hoped a new version could fix this.
+
+Here is where the error occured: https://travis-ci.com/github/VDR4Arch/vdr4arch/jobs/309106220#L5420
+
+I don't get this error with an armv7h chroot.
+
+Maybe now I'll just try to remove all uses of svn in my build scripts...
+
+Is it actually a viable solution to cross-build with qemu? I'm starting to doubt it...
+
+Would it help if I manage to get this core dump out of Travis somehow (maybe make Travis push it to some GIT or upload it to my webserver)?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1870477 b/results/classifier/gemma3:27b/runtime/1870477
new file mode 100644
index 00000000..bc0c353b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1870477
@@ -0,0 +1,36 @@
+
+
+
+qemu-arm hangs when golang running test
+
+
+1. Environment:
+Ubuntu 16.04.5 X86_64
+qemu-arm version 4.2.0
+go version go 1.14.1 linux/arm
+
+2. Summary:
+Sometimes "go run test.go" command hang
+
+
+3. Reproduction Method (Attempts: 500 Occurred: 1 ): Frequency: 1/500
+
+
+test.go
+======================================
+package main
+import "fmt"
+func main(){
+        for i:=0; i<1000; i++ {
+                fmt.Printf("[%d] Hello world\n", i)
+        }
+}
+======================================
+
+i tested "go run test.go" command called  500 times at qemu arm env.
+qemu hangs about 200~300.
+
+attached strace log.
+
+please check.
+thanks
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1878501 b/results/classifier/gemma3:27b/runtime/1878501
new file mode 100644
index 00000000..960a0916
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1878501
@@ -0,0 +1,34 @@
+
+
+
+qemu-i386 does not define AT_SYSINFO
+
+qemu-i386 does not define the AT_SYSINFO auxval when running i386 Linux binaries.
+
+On most libcs, this is properly handled, but this is mandatory for the i686 Bionic (Android) libc or it will segfault.
+
+This is due to a blind assumption that getauxval(AT_SYSINFO) will return a valid function pointer:
+
+The code varies from version to version, but it looks like this:
+
+void *__libc_sysinfo;
+// mangled as _Z19__libc_init_sysinfov
+void __libc_init_sysinfo() {
+  bool dummy;
+  // __bionic_getauxval = getauxval
+  __libc_sysinfo = reinterpret_cast<void *>(__bionic_getauxval(AT_SYSINFO, dummy));
+}
+
+A simple way to reproduce is to compile a basic C program against the NDK:
+
+int main(void) { return 0; }
+
+$ i686-linux-android-clang -static empty.c -o empty
+$ qemu-i386 -cpu max ./empty
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+The place where it segfaults is misleading: It will, at least on the current NDK, crash on __set_thread_area, this is due to it calling a function pointer to __libc_sysinfo returned by __kernel_syscall.
+
+QEMU 4.1.1 (aarch64)
+Pixel 2 XL via Termux
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1880225 b/results/classifier/gemma3:27b/runtime/1880225
new file mode 100644
index 00000000..8223b607
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1880225
@@ -0,0 +1,140 @@
+
+
+
+Emulation of some arm programs fail with "Assertion `have_guest_base' failed."
+
+This issue is observer with QEMU ToT, checked out around May 15th (but I believe it is present in current master too), and wasn't present in QEMU v5.0.0.
+
+I am using 32-bit Intel(R) Pentium(R) M processor 1.73GHz host.
+
+Arm cross-compiler is a standard cross-compiler that comes with Debian-based distributions, and gcc version is:
+
+$ arm-linux-gnueabi-gcc --version
+arm-linux-gnueabi-gcc (Debian 8.3.0-2) 8.3.0
+
+Compile this program with cross compiler:
+
+$ arm-linux-gnueabi-gcc -O2 -static toupper_string.c -o toupper_string-arm
+
+Emulation with QEMU v5.0.0 is correct, and gives expected output:
+
+$ ~/Build/qemu-5.0.0/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm
+CONTROL RESULT: (toupper_string)
+ nwlrbbmqbhcdarz owkkyhiddqscdxr jmowfrxsjybldbe fsarcbynecdyggx xpklorellnmpapq
+ NWLRBBMQBHCDARZ OWKKYHIDDQSCDXR JMOWFRXSJYBLDBE FSARCBYNECDYGGX XPKLORELLNMPAPQ
+
+While, in case of QEMU master it fails:
+
+$ ~/Build/qemu-master/build-gcc/arm-linux-user/qemu-arm ./toupper_string-arm
+qemu-arm: /home/rtrk/Build/qemu-master/linux-user/elfload.c:2294: probe_guest_base: Assertion `have_guest_base' failed.
+Aborted
+
+There are many other programs that exibit the same behavior. The failure is arm-sprecific.
+
+
+-----------------------------------------------------
+
+source code: (let's call this file toupper_string.c) (similar file is also in attachment)
+
+
+#include <stdlib.h>
+#include <string.h>
+#include <stdio.h>
+#include <unistd.h>
+
+
+#define MAX_STRING_LENGHT              15
+#define NUMBER_OF_RANDOM_STRINGS       100
+#define DEFAULT_NUMBER_OF_REPETITIONS  30000
+#define MAX_NUMBER_OF_REPETITIONS      1000000000
+#define NUMBER_OF_CONTROL_PRINT_ITEMS  5
+
+/* Structure for keeping an array of strings */
+struct StringStruct {
+    char chars[MAX_STRING_LENGHT + 1];
+};
+
+/**
+ * Sets characters of the given string to random small letters a-z.
+ * @param s String to get random characters.
+ * @len Length of the input string.
+ */
+static void gen_random_string(char *chars, const int len)
+{
+    static const char letters[] = "abcdefghijklmnopqrstuvwxyz";
+
+    for (size_t i = 0; i < len; i++) {
+        chars[i] = letters[rand() % (sizeof(letters) - 1)];
+    }
+    chars[len] = 0;
+}
+
+void main (int argc, char* argv[])
+{
+    struct StringStruct random_strings[NUMBER_OF_RANDOM_STRINGS];
+    struct StringStruct strings_to_be_uppercased[NUMBER_OF_RANDOM_STRINGS];
+    int32_t number_of_repetitions = DEFAULT_NUMBER_OF_REPETITIONS;
+    int32_t option;
+
+    /* Parse command line options */
+    while ((option = getopt(argc, argv, "n:")) != -1) {
+        if (option == 'n') {
+            int32_t user_number_of_repetitions = atoi(optarg);
+            /* Check if the value is a negative number */
+            if (user_number_of_repetitions < 1) {
+                fprintf(stderr, "Error ... Value for option '-n' cannot be a "
+                                "negative number.\n");
+                exit(EXIT_FAILURE);
+            }
+            /* Check if the value is a string or zero */
+            if (user_number_of_repetitions == 0) {
+                fprintf(stderr, "Error ... Invalid value for option '-n'.\n");
+                exit(EXIT_FAILURE);
+            }
+            /* Check if the value is too large */
+            if (user_number_of_repetitions > MAX_NUMBER_OF_REPETITIONS) {
+                fprintf(stderr, "Error ... Value for option '-n' cannot be "
+                                "more than %d.\n", MAX_NUMBER_OF_REPETITIONS);
+                exit(EXIT_FAILURE);
+            }
+            number_of_repetitions = user_number_of_repetitions;
+        } else {
+            exit(EXIT_FAILURE);
+        }
+    }
+
+    /* Create an array of strings with random content */
+    srand(1);
+    for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) {
+        gen_random_string(random_strings[i].chars, MAX_STRING_LENGHT);
+    }
+
+    /* Perform uppercasing of a set of random strings multiple times */
+    for (size_t j = 0; j < number_of_repetitions; j++) {
+        /* Copy initial set of random strings to the set to be uppercased */
+        memcpy(strings_to_be_uppercased, random_strings,
+               NUMBER_OF_RANDOM_STRINGS * (MAX_STRING_LENGHT + 1));
+        /* Do actual changing case to uppercase */
+        for (size_t i = 0; i < NUMBER_OF_RANDOM_STRINGS; i++) {
+            int k = 0;
+  
+            while (strings_to_be_uppercased[i].chars[k]) { 
+                char ch = strings_to_be_uppercased[i].chars[k] - 32; 
+                memcpy((void *)strings_to_be_uppercased[i].chars + k,
+                       &ch, 1);
+                k++; 
+            } 
+        }
+    }
+
+    /* Control printing */
+    printf("CONTROL RESULT: (toupper_string)\n");
+    for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) {
+        printf(" %s", random_strings[i].chars);
+    }
+    printf("\n");
+    for (size_t i = 0; i < NUMBER_OF_CONTROL_PRINT_ITEMS; i++) {
+        printf(" %s", strings_to_be_uppercased[i].chars);
+    }
+    printf("\n");
+}
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1880332 b/results/classifier/gemma3:27b/runtime/1880332
new file mode 100644
index 00000000..7bbdf974
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1880332
@@ -0,0 +1,10 @@
+
+
+
+Possible regression in QEMU 5.0.0 after CVE-2020-10702 (segmentation fault)
+
+I've come across a very specific situation, but I'm sure it could be replicated in other cases.
+
+In QEMU 5.0.0 when I use user emulation with a cURL binary for aarch64 and connect to a server using TLS 1.2 and ECDHE-ECDSA-CHACHA20-POLY1305 cypher a segmentation fault occurs.
+
+I attach a Dockerfile that reproduces this crash and the strace output with and without the de0b1bae6461f67243282555475f88b2384a1eb9 commit reverted.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1880722 b/results/classifier/gemma3:27b/runtime/1880722
new file mode 100644
index 00000000..c4c29c70
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1880722
@@ -0,0 +1,17 @@
+
+
+
+Problems related to checking page crossing in use_goto_tb()
+
+The discussion that led to this bug discovery can be found in this 
+mailing list thread:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-05/msg05426.html
+
+A workaround for this problem would be to check for page crossings for 
+both the user and system modes in the use_goto_tb() function across 
+targets. Some targets like "hppa" already implement this fix but others
+don't.
+
+To solve the root cause of this problem, the linux-user/mmap.c should 
+be fixed to do all the invalidations required. By doing so, up to 6.93% 
+performance improvements will be achieved.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1883268 b/results/classifier/gemma3:27b/runtime/1883268
new file mode 100644
index 00000000..97be215b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1883268
@@ -0,0 +1,40 @@
+
+
+
+random errors on aarch64 when executing __aarch64_cas8_acq_rel
+
+Hello,
+
+Since I upgraded to qemu-5.0 when executing the GCC testsuite,
+I've noticed random failures of g++.dg/ext/sync-4.C.
+
+I'm attaching the source of the testcase, the binary executable and the qemu traces (huge, 111MB!) starting at main (with qemu-aarch64 -cpu cortex-a57 -R 0 -d in_asm,int,exec,cpu,unimp,guest_errors,nochain)
+
+The traces where generated by a CI build, I built the executable manually but I expect it to be the same as the one executed by CI.
+
+In seems the problem occurs in f13, which leads to a call to abort()
+
+The preprocessed version of f13/t13 are as follows:
+static bool f13 (void *p) __attribute__ ((noinline));
+static bool f13 (void *p)
+{
+  return (__sync_bool_compare_and_swap((ditype*)p, 1, 2));
+}
+static void t13 ()
+{
+  try {
+    f13(0);
+  }
+  catch (...) {
+    return;
+  }
+  abort();
+}
+
+
+When looking at the execution traces at address 0x00400c9c, main calls f13, which in turn calls __aarch64_cas8_acq_rel (at 0x00401084)
+__aarch64_cas8_acq_rel returns to f13 (address 0x0040113c), then f13 returns to main (0x0040108c) which then calls abort (0x00400ca0)
+
+I'm not quite sure what's wrong :-(
+
+I've not noticed such random problems with native aarch64 hardware.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1883784 b/results/classifier/gemma3:27b/runtime/1883784
new file mode 100644
index 00000000..1f5853f8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1883784
@@ -0,0 +1,12 @@
+
+
+
+[ppc64le] qemu behavior differs from ppc64le hardware
+
+I have some code which passes my test suite on PPC64LE hardware when compiled with GCC 10, but the saem binary fails with both qemu-ppc64le 4.2 (on Fedora 32) and qemu-ppc64le-static 5.0.0 (Debian testing).
+
+I'm not getting any errors about illegal instructions or anything, like that; the results are just silently different on qemu.
+
+I've generated a reduced test case, which is attached along with the binaries (both are the same code, one is just statically linked).  They should execute successufully on PPC64LE hardware, but on qemu they hit a __builtin_abort (because the computed value doesn't match the expected value).
+
+Without being familiar with PPC assembly I'm not sure what else I can do, but if there is anything please let me know.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1888303 b/results/classifier/gemma3:27b/runtime/1888303
new file mode 100644
index 00000000..a6c3d6e8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1888303
@@ -0,0 +1,23 @@
+
+
+
+Intermittent buggines with user mode emulation of x86-64 on aarch64
+
+QEMU Version: 5.0.0
+./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static
+
+Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm
+
+aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages.
+
+On aarch64 machine, invoke:
+
+./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile
+
+Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data.
+
+But, about once every 10 times, it will not sefault and will continue working just fine forever.
+
+The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault.
+
+This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1888728 b/results/classifier/gemma3:27b/runtime/1888728
new file mode 100644
index 00000000..68b6cce8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1888728
@@ -0,0 +1,22 @@
+
+
+
+Bare chroot in linux-user fails with pgb_reserved_va: Assertion `guest_base != 0' failed.
+
+Trying to run a bare chroot with no additional bind mounts fails on git master (8ffa52c20d5693d454f65f2024a1494edfea65d4) with:
+
+root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/
+qemu-m68k-static: /root/qemu/linux-user/elfload.c:2315: pgb_reserved_va: Assertion `guest_base != 0' failed.
+Aborted
+root@nofan:~/qemu>
+
+The problem can be worked around by bind-mounting /proc from the host system into the target chroot:
+
+root@nofan:~/qemu> mount -o bind /proc/ /local_scratch/sid-m68k-sbuild/proc/
+root@nofan:~/qemu> chroot /local_scratch/sid-m68k-sbuild/
+bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
+(sid-m68k-sbuild)root@nofan:/#
+
+Host system is an up-to-date Debian unstable (2020-07-23).
+
+I have not been able to bisect the issue yet since there is another annoying linux-user bug (virtual memory exhaustion) that was somewhere introduced and fixed between v5.0.0 and HEAD and overshadows the original Assertion failure bug.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1889411 b/results/classifier/gemma3:27b/runtime/1889411
new file mode 100644
index 00000000..fae0a101
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1889411
@@ -0,0 +1,66 @@
+
+
+
+RISC-V: Unable to unwind the stack upon signals
+
+Consider the following program:
+
+===============================================================
+#include <stdio.h>
+#include <stdlib.h>
+
+#define NOINLINE __attribute__ ((noinline))
+
+void NOINLINE abort_me(void) { abort(); /* trigger SIGABRT */ }
+
+void NOINLINE level1(void) { abort_me(); }
+
+void NOINLINE level2(void) { level1(); }
+
+void NOINLINE level3(void) { level2(); }
+
+void NOINLINE level4(void) { level3();}
+
+int main(void) {
+	level4();
+	return 0;
+}
+===============================================================
+
+$ riscv64-linux-gnu-gcc -march=rv64imafdc -O0 -g c.c
+$ qemu-riscv64 -g 31337 ./c &
+$ riscv64-unknown-linux-gnu-gdb -q -ex 'target remote localhost:31337' -ex 'b abort_me' -ex c -ex bt ./c
+Reading symbols from c...
+Remote debugging using localhost:31337
+Reading symbols from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1...
+0x0000004000804f30 in _start () from /home/lewurm/riscv/sysroot/lib/ld-linux-riscv64-lp64d.so.1
+Breakpoint 1 at 0x4000000632: file c.c, line 7.
+Continuing.
+
+Breakpoint 1, abort_me () at c.c:7
+7               abort(); /* trigger SIGABRT */
+#0  abort_me () at c.c:7
+#1  0x0000004000000642 in level1 () at c.c:11
+#2  0x0000004000000658 in level2 () at c.c:15
+#3  0x000000400000066e in level3 () at c.c:19
+#4  0x0000004000000684 in level4 () at c.c:23
+#5  0x000000400000069a in main () at c.c:27
+===============================================================
+
+So far so good, I get a proper backtrace as expected. If I let the signal trigger however, gdb is not able to unwind the stack:
+
+(gdb) c
+Continuing.
+
+Program received signal SIGABRT, Aborted.
+0x0000004000858074 in ?? ()
+(gdb) bt
+#0  0x0000004000858074 in ?? ()
+
+
+
+I get the same behaviour for SIGSEGV and SIGILL, I didn't try other signals. Apparently this scenario works on real hardware (see linked gdb issue below), and presumably it would work with system qemu (I haven't tested that yet though). So my guess is that qemu does something differently around signal handling than the linux kernel.
+
+
+Full reproducer: https://gist.github.com/lewurm/befb9ddf5894bad9628b1df77258598b
+RISC-V GDB issue: https://github.com/riscv/riscv-binutils-gdb/issues/223
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1890 b/results/classifier/gemma3:27b/runtime/1890
new file mode 100644
index 00000000..bacc2dcb
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1890
@@ -0,0 +1,28 @@
+
+
+
+qemu-arm 8.1.0 Error mapping file: Operation not permitted
+Description of problem:
+failed to execute the cortex-m binary hello_world, and says:
+qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted
+Steps to reproduce:
+1.
+```
+cat > hello_new.c <<EOF
+#include <stdio.h>
+int main()
+{printf("hello world"); return 0;}
+EOF
+```
+2.
+```
+arm-none-eabi-gcc -mcpu=cortex-m55 -g hello_world.c -o hello_world -specs=rdimon.specs
+```
+3.
+```
+qemu-arm -cpu cortex-m55 hello_world
+qemu-arm: /home/user/work/tests/c/hello_world: Error mapping file: Operation not permitted
+```
+Additional information:
+1, version 8.0.4 version is okay\
+2, arm-none-eabi-gcc version is 10.3.1 20210824 (release)
diff --git a/results/classifier/gemma3:27b/runtime/1894029 b/results/classifier/gemma3:27b/runtime/1894029
new file mode 100644
index 00000000..dbb691fe
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1894029
@@ -0,0 +1,42 @@
+
+
+
+qemu-i386 malloc error
+
+Hi!I use qemu-i386-static on 64 bit machines.And memory request succeeded, but the pointer is wrong.
+This is my test program:
+
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+int main(int argc, char **argv)
+{
+        void *pa=0,*pb=0,*pc=0,*pd=0;
+        pa = malloc(sizeof(uint32_t));
+        pb = malloc(sizeof(uint32_t));
+        pc = malloc(4);
+        pd = malloc(4);
+        printf("pa: 0x%x\n",pa);
+        printf("pb: 0x%x\n",pb);
+        printf("pc: 0x%x\n",pc);
+        printf("pd: 0x%x\n",pd);
+        printf("uint32_t:%d\n",sizeof(uint32_t));
+        free(pa);
+        free(pb);
+        free(pc);
+        free(pd);
+        return 0;
+}
+
+And it is wrong:
+
+pa: 0x400051a0
+pb: 0x400051b0
+pc: 0x400051c0
+pd: 0x400051d0
+uint32_t:4
+
+Why did I apply for 4 bytes of space, but the pointer only increased by 2 bytes??
+Is it a BUG??
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1895 b/results/classifier/gemma3:27b/runtime/1895
new file mode 100644
index 00000000..bfa89de8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1895
@@ -0,0 +1,149 @@
+
+
+
+qemu-user uses fixed stack size and ignores RLIMIT_STACK request, causing some guest programs to crash
+Description of problem:
+When compiling a source file, g++ segmentation faults in qemu-user riscv64. But it doesn't fail on real riscv64 boards.
+
+We discovered this problem while compiling nodejs-lts-hydrogen. The source file has been reduced to 5KB by cvise.
+Steps to reproduce:
+1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment
+2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U`
+3. Install gcc inside the container: `sudo pacman -Syu gcc`
+4. Run the following command in the container: `g++ -S testcase.i -w -fpreprocessed -o /dev/null` [testcase.i](/uploads/d63b1867a458a240ef0d90c760d76bc7/testcase.i)
+5. g++ segmentation faults: `g++: internal compiler error: Segmentation fault signal terminated program cc1plus`
+Additional information:
+Initially I thought this is a g++ bug. But I can't reproduce this bug on real riscv64 hardware.
+
+g++ version: g++ (GCC) 13.2.1 20230801
+
+testcase.i:
+
+```c++
+namespace std {
+typedef long unsigned size_t;
+inline namespace __cxx11 {}
+} // namespace std
+typedef char uint8_t;
+namespace std {
+template <typename _Default, typename, template <typename> class>
+struct __detector {
+  using type = _Default;
+};
+template <typename _Default, template <typename> class _Op>
+using __detected_or = __detector<_Default, void, _Op>;
+template <typename _Default, template <typename> class _Op>
+using __detected_or_t = typename __detected_or<_Default, _Op>::type;
+template <typename> class allocator;
+namespace __cxx11 {
+template <typename _CharT, typename = _CharT, typename = allocator<_CharT>>
+class basic_string;
+}
+typedef basic_string<char> string;
+} // namespace std
+template <typename _Tp> class __new_allocator {
+public:
+  typedef _Tp value_type;
+};
+namespace std {
+template <typename _Tp> using __allocator_base = __new_allocator<_Tp>;
+template <typename _Tp> class allocator : public __allocator_base<_Tp> {};
+template <class _E> class initializer_list {
+  typedef size_t size_type;
+  typedef _E *iterator;
+  iterator _M_array;
+  size_type _M_len;
+};
+struct __allocator_traits_base {
+  template <typename _Tp> using __pointer = typename _Tp::const_pointer;
+};
+template <typename _Alloc> struct allocator_traits : __allocator_traits_base {
+  typedef typename _Alloc::value_type value_type;
+  using pointer = __detected_or_t<value_type, __pointer>;
+};
+} // namespace std
+namespace __gnu_cxx {
+template <typename _Alloc>
+struct __alloc_traits : std::allocator_traits<_Alloc> {};
+} // namespace __gnu_cxx
+namespace std {
+namespace __cxx11 {
+template <typename _CharT, typename, typename _Alloc> class basic_string {
+  typedef __gnu_cxx::__alloc_traits<_Alloc> _Alloc_traits;
+
+public:
+  typedef typename _Alloc_traits::pointer pointer;
+  struct _Alloc_hider {
+    _Alloc_hider(pointer, _Alloc);
+  } _M_dataplus;
+  pointer _M_local_data();
+  basic_string(_CharT *, _Alloc __a = _Alloc())
+      : _M_dataplus(_M_local_data(), __a) {}
+  ~basic_string();
+};
+} // namespace __cxx11
+} // namespace std
+namespace v8 {
+class StartupData {};
+} // namespace v8
+namespace std {
+template <typename _Tp> class vector {
+public:
+  typedef _Tp value_type;
+  vector(initializer_list<value_type>);
+};
+namespace builtins {
+struct CodeCacheInfo {
+  string id;
+  vector<uint8_t> data;
+};
+} // namespace builtins
+struct IsolateDataSerializeInfo {};
+struct EnvSerializeInfo {};
+struct SnapshotMetadata {
+  enum { kDefault } type;
+  string node_version;
+  string node_arch;
+  string v8_cache_version_tag;
+};
+struct SnapshotData {
+  enum { kNotOwned } data_ownership;
+  SnapshotMetadata metadata;
+  v8::StartupData v8_snapshot_blob_data;
+  IsolateDataSerializeInfo isolate_data_info;
+  EnvSerializeInfo env_info;
+  vector<builtins::CodeCacheInfo> code_cache;
+} snapshot_data{
+    SnapshotData::kNotOwned,
+    SnapshotMetadata::kDefault,
+    "",
+    "",
+    "",
+    {},
+    {},
+    {},
+    {{""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""},
+     {""}, {""}, {""}, {""}, {""}, {""}, {""}, {""}}};
+} // namespace std
+```
diff --git a/results/classifier/gemma3:27b/runtime/1895080 b/results/classifier/gemma3:27b/runtime/1895080
new file mode 100644
index 00000000..eb26fb5f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1895080
@@ -0,0 +1,39 @@
+
+
+
+pgb_reserved_va: Assertion `addr == test' failed
+
+This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-user.
+
+Firstly, compile fails:
+Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o
+../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared here (not in a function)
+     FLAG_GENERIC(FALLOC_FL_KEEP_SIZE),
+
+I have to add below include to linux-user/strace.c
+diff --git a/linux-user/strace.c b/linux-user/strace.c
+index 11fea14fba..22e51d4a8a 100644
+--- a/linux-user/strace.c
++++ b/linux-user/strace.c
+@@ -7,6 +7,7 @@
+ #include <sys/mount.h>
+ #include <arpa/inet.h>
+ #include <netinet/tcp.h>
++#include <linux/falloc.h>
+ #include <linux/if_packet.h>
+ #include <linux/netlink.h>
+ #include <sched.h>
+
+Then trying qemu-riscv32 with a simple ELF, I get:
+linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed.
+
+strace shows that:
+mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x10000
+write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: ../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed.
+) = 103
+
+The source code is in the function pgb_reserved_va (linux-user/elfload.c). I think mmap cannot guarantee that the returned pointer (test) equals to the parameter of addr. So is this a bug to assert (addr == test)?
+
+Attached configure script and test ELF file.
+
+Thanks.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1895471 b/results/classifier/gemma3:27b/runtime/1895471
new file mode 100644
index 00000000..517420fb
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1895471
@@ -0,0 +1,26 @@
+
+
+
+compilation error with clang in util/async.c
+
+configured with ` CC=clang CXX=clang++ ../configure --target-list=x86_64-softmmu --enable-kvm --enable-curl --enable-debug --enable-jemalloc --enable-fuzzing --enable-sdl` and after make I get the following error related to c11 atomics. I'm using clang because I'm experimenting with fuzzer
+
+[glitz@archlinux /code/qemu/build]$ ninja -j5
+[479/2290] Compiling C object libqemuutil.a.p/util_async.c.o
+FAILED: libqemuutil.a.p/util_async.c.o
+clang -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -Ilinux-headers -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -g -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -fsanitize=fuzzer-no-link -iquote /code/qemu/tcg/i386 -isystem /code/qemu/linux-headers -iquote . -iquote /code/qemu -iquote /code/qemu/accel/tcg -iquote /code/qemu/include -iquote /code/qemu/disas/libvixl -pthread -fPIC -MD -MQ libqemuutil.a.p/util_async.c.o -MF libqemuutil.a.p/util_async.c.o.d -o libqemuutil.a.p/util_async.c.o -c ../util/async.c
+../util/async.c:79:17: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid)
+    old_flags = atomic_fetch_or(&bh->flags, BH_PENDING | new_flags);
+                ^               ~~~~~~~~~~
+/usr/lib/clang/10.0.1/include/stdatomic.h:138:42: note: expanded from macro 'atomic_fetch_or'
+#define atomic_fetch_or(object, operand) __c11_atomic_fetch_or(object, operand, __ATOMIC_SEQ_CST)
+                                         ^                     ~~~~~~
+../util/async.c:105:14: error: address argument to atomic operation must be a pointer to _Atomic type ('unsigned int *' invalid)
+    *flags = atomic_fetch_and(&bh->flags,
+             ^                ~~~~~~~~~~
+/usr/lib/clang/10.0.1/include/stdatomic.h:144:43: note: expanded from macro 'atomic_fetch_and'
+#define atomic_fetch_and(object, operand) __c11_atomic_fetch_and(object, operand, __ATOMIC_SEQ_CST)
+                                          ^                      ~~~~~~
+2 errors generated.
+[483/2290] Compiling C object libqemuutil.a.p/util_qemu-error.c.o
+ninja: build stopped: subcommand failed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1904259 b/results/classifier/gemma3:27b/runtime/1904259
new file mode 100644
index 00000000..df07207a
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1904259
@@ -0,0 +1,32 @@
+
+
+
+include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686)
+
+Hello.
+I haven't found any "official" executables, for emulating RISC-V (32bit; 64bit) so I had to compile those myself.
+
+I found that auto-generated build scripts, for Ninja, contained some warnings interpreted as errors:
+
+
+oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1
+[2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o
+FAILED: libqemuutil.a.p/util_qsp.c.o 
+clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers -iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote /home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg -iquote /home/oceanfish81/Desktop/qemu/include -iquote /home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function -fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d -o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c
+In file included from ../util/qsp.c:62:
+In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4:
+In file included from /home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10:
+/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment]
+    qatomic_set__nocheck(ptr, val);
+    ^
+/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded from macro 'qatomic_set__nocheck'
+    __atomic_store_n(ptr, i, __ATOMIC_RELAXED)
+    ^
+/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment]
+    return qatomic_read__nocheck(ptr);
+           ^
+/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded from macro 'qatomic_read__nocheck'
+    __atomic_load_n(ptr, __ATOMIC_RELAXED)
+    ^
+2 errors generated.
+ninja: build stopped: subcommand failed.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1907817 b/results/classifier/gemma3:27b/runtime/1907817
new file mode 100644
index 00000000..dc04f7b7
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1907817
@@ -0,0 +1,46 @@
+
+
+
+qemu-aarch64 tcg assertion v5.2.0
+
+After updating to 5.2 I am getting following assertion error:
+qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed.
+
+I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762
+
+Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following:
+ 
+max_align = maxsz >= 16 ? 15 : 7;
+tcg_debug_assert((maxsz & max_align) == 0);  <--- here assertion happens
+
+in my case maxsz=56.
+
+
+Whole backtrace:
+#4  0x0000004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54
+#5  0x0000004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89
+#6  0x0000004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630
+#7  0x00000040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679
+#8  0x0000004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538
+#9  0x0000004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592
+#10 0x0000004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600
+--Type <RET> for more, q to quit, c to continue without paging--
+#11 0x0000004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608
+#12 0x0000004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0)
+    at ../target/arm/translate-a64.c:6988
+#13 0x0000004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299
+#14 0x0000004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389
+#15 0x000000400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494
+#16 0x000000400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663
+#17 0x000000400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823
+#18 0x00000040002e8630 in translator_loop (ops=0x4000902e00 <aarch64_translator_ops>, db=0x40021a8180, cpu=0x7fac59b63150, 
+    tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103
+#19 0x00000040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512)
+    at ../target/arm/translate.c:9283
+#20 0x00000040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216)
+    at ../accel/tcg/translate-all.c:1744
+#21 0x000000400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414
+--Type <RET> for more, q to quit, c to continue without paging--
+#22 0x000000400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770
+#23 0x0000004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84
+#24 0x00000040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1907969 b/results/classifier/gemma3:27b/runtime/1907969
new file mode 100644
index 00000000..58e7ba57
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1907969
@@ -0,0 +1,61 @@
+
+
+
+linux-user/i386: Segfault when mixing threads and signals
+
+Given the following C program, qemu-i386 will surely and certainly segfault when executing it.
+The problem is only noticeable if the program is statically linked to musl's libc and, as written
+in the title, it only manifests when targeting i386.
+
+Removing the pthread calls or the second raise() makes it not segfault.
+
+The crash is in some part of the TCG-generated code, right when it tries to perform a
+%gs-relative access.
+
+If you want a quick way of cross-compiling this binary:
+
+* Download a copy of the Zig compiler from https://ziglang.org/download/
+* Compile it with
+  `zig cc -target i386-linux-musl <C-FILE> -o <OUT>`
+
+```
+#include <pthread.h>
+#include <signal.h>
+#include <stdio.h>
+#include <string.h>
+#include <sys/types.h>
+#include <unistd.h>
+#include <asm/prctl.h>
+#include <sys/syscall.h>
+
+void sig_func(int sig)
+{
+    write(1, "hi!\n", strlen("hi!\n"));
+}
+
+void func(void *p) { }
+
+typedef void *(*F)(void *);
+
+int main()
+{
+    pthread_t tid;
+
+    struct sigaction action;
+    action.sa_flags = 0;
+    action.sa_handler = sig_func;
+
+    if (sigaction(SIGUSR1, &action, NULL) == -1) {
+        return 1;
+    }
+
+    // This works.
+    raise(SIGUSR1);
+
+    pthread_create(&tid, NULL, (F)func, NULL);
+    pthread_join(tid, NULL);
+
+    // This makes qemu segfault.
+    raise(SIGUSR1);
+}
+```
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1908 b/results/classifier/gemma3:27b/runtime/1908
new file mode 100644
index 00000000..6375c0e2
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1908
@@ -0,0 +1,52 @@
+
+
+
+8.1.0 regression: abnormal segfault in qemu-riscv64-static
+Description of problem:
+loading_from_clipboard_test of Cockatrice segfaults in qemu-riscv64-static.
+Steps to reproduce:
+1. Setup an Arch Linux riscv64 qemu-user container: https://github.com/felixonmars/archriscv-packages/wiki/Setup-Arch-Linux-RISC-V-Development-Environment
+2. Start the container: `sudo systemd-nspawn -D ./archriscv -a -U`
+3. Build cockatrice 2.9.0 with tests in the container: https://github.com/Cockatrice/Cockatrice/releases/tag/2023-09-14-Release-2.9.0
+4. Run tests/loading_from_clipboard/loading_from_clipboard_test in the container
+Additional information:
+I have done bisection and find out that this commit caused the regression: 2d708164e0475064e0e2167bd73e8570e22df1e0
+
+qemu built from HEAD(494a6a2) is still affected by this bug.
+
+Backtrace:
+
+```
+#0  0x00007fffe849f133 in code_gen_buffer ()
+#1  0x00007ffff7b3a433 in cpu_tb_exec (cpu=0x7ffff7f71010, itb=0x7fffe849f040 <code_gen_buffer+4845587>,
+tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:457
+#2  0x00007ffff7b3aeac in cpu_loop_exec_tb (cpu=0x7ffff7f71010, tb=0x7fffe849f040 <code_gen_buffer+4845587>,
+pc=46912625654024, last_tb=0x7fffffffde30, tb_exit=0x7fffffffde20) at ../qemu/accel/tcg/cpu-exec.c:919
+#3  0x00007ffff7b3b0e0 in cpu_exec_loop (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0) at ../qemu/accel/tcg/cpu-exec.c:1040
+#4  0x00007ffff7b3b19e in cpu_exec_setjmp (cpu=0x7ffff7f71010, sc=0x7fffffffdeb0)
+at ../qemu/accel/tcg/cpu-exec.c:1057
+#5  0x00007ffff7b3b225 in cpu_exec (cpu=0x7ffff7f71010) at ../qemu/accel/tcg/cpu-exec.c:1083
+#6  0x00007ffff7a53707 in cpu_loop (env=0x7ffff7f71330) at ../qemu/linux-user/riscv/cpu_loop.c:37
+#7  0x00007ffff7b5d0e0 in main (argc=4, argv=0x7fffffffe768, envp=0x7fffffffe790) at ../qemu/linux-user/main.c:999
+```
+
+```
+0x7fffe849f105 <code_gen_buffer+4845784>        jl     0x7fffe849f265 <code_gen_buffer+4846136>                                                                                                                                        │
+│    0x7fffe849f10b <code_gen_buffer+4845790>        mov    0x50(%rbp),%rbx                                                                                                                                                                 │
+│    0x7fffe849f10f <code_gen_buffer+4845794>        mov    %rbx,%r12                                                                                                                                                                       │
+│    0x7fffe849f112 <code_gen_buffer+4845797>        mov    %r12,0x70(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f116 <code_gen_buffer+4845801>        movabs $0x2aaaaf9bb000,%r13                                                                                                                                                            │
+│    0x7fffe849f120 <code_gen_buffer+4845811>        mov    %r13,0x38(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f124 <code_gen_buffer+4845815>        movq   $0xffffffffaf9bb000,0x60(%rbp)                                                                                                                                                  │
+│    0x7fffe849f12c <code_gen_buffer+4845823>        mov    $0xffffffffaf9bb4e0,%r13                                                                                                                                                        │
+│  > 0x7fffe849f133 <code_gen_buffer+4845830>        movzwl 0x0(%r13),%r13d                                                                                                                                                                 │
+│    0x7fffe849f138 <code_gen_buffer+4845835>        and    $0x7f,%ebx                                                                                                                                                                      │
+│    0x7fffe849f13b <code_gen_buffer+4845838>        shl    $0x7,%r13                                                                                                                                                                       │
+│    0x7fffe849f13f <code_gen_buffer+4845842>        add    %r13,%rbx                                                                                                                                                                       │
+│    0x7fffe849f142 <code_gen_buffer+4845845>        mov    %rbx,0x50(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f146 <code_gen_buffer+4845849>        shl    %rbx                                                                                                                                                                            │
+│    0x7fffe849f149 <code_gen_buffer+4845852>        mov    %rbx,0x38(%rbp)                                                                                                                                                                 │
+│    0x7fffe849f14d <code_gen_buffer+4845856>        movabs $0x2aaaaf9a88e0,%r13                                                                                                                                                            │
+│    0x7fffe849f157 <code_gen_buffer+4845866>        add    %r13,%rbx                                                                                                                                                                       │
+│    0x7fffe849f15a <code_gen_buffer+4845869>        mov    %rbx,0x60(%rbp)                            
+```
diff --git a/results/classifier/gemma3:27b/runtime/1908551 b/results/classifier/gemma3:27b/runtime/1908551
new file mode 100644
index 00000000..42a66cbf
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1908551
@@ -0,0 +1,57 @@
+
+
+
+aarch64 SVE emulation breaks strnlen and strrchr
+
+arm optimized-routines have sve string functions with test code.
+
+the test worked up until recently: with qemu-5.2.0 i see
+
+$ qemu-aarch64 build/bin/test/strnlen
+PASS strnlen
+PASS __strnlen_aarch64
+__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80"
+__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a"
+__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a"
+__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
+__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
+__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
+__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c"
+__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00"
+__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc"
+__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35
+input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc"
+FAIL __strnlen_aarch64_sve
+
+however the test passes with
+
+qemu-aarch64 -cpu max,sve-max-vq=2
+
+there should be nothing vector length specific in the code.
+
+i haven't debugged it further, to reproduce the issue clone
+https://github.com/ARM-software/optimized-routines
+
+and run 'make build/bin/test/strnlen' with a config.mk like
+
+SUBS = string
+ARCH = aarch64
+CROSS_COMPILE = aarch64-none-linux-gnu-
+CC = $(CROSS_COMPILE)gcc
+CFLAGS = -std=c99 -pipe -O3
+CFLAGS += -march=armv8.2-a+sve
+EMULATOR = qemu-aarch64
+
+(native compilation works too, and you can run 'make check' to
+run all string tests) this will build a static linked executable
+into build/bin/test. if you want a smaller test case edit
+string/test/strnlen.c
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1909 b/results/classifier/gemma3:27b/runtime/1909
new file mode 100644
index 00000000..5c8aa930
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1909
@@ -0,0 +1,53 @@
+
+
+
+regression: 8.0.0 segfaults on coverage counter increment
+Description of problem:
+With qemu 8.0.0, my test program segfaults while incrementing a gcov counter:
+
+```
+Breakpoint 2, 0x00000000004bc9a8 in __CortexA53843419_464004 ()
+(gdb) x/2i $pc
+=> 0x4bc9a8 <__CortexA53843419_464004>:	str	x8, [x9, #2512]
+   0x4bc9ac <__CortexA53843419_464004+4>:	b	0x464008 <mock_hyp_params_Destroy+24>
+(gdb) p $x8
+$10 = 1
+(gdb) p $x9
+$11 = 5234688
+(gdb) x/x $x9+2512
+0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
+(gdb) stepi
+
+Program received signal SIGSEGV, Segmentation fault.
+0x00000000004bc9a8 in __CortexA53843419_464004 ()
+(gdb) x/x $x9+2512
+0x4fe9d0 <__llvm_gcov_ctr.5>:	0x00000000
+(gdb) shell llvm-objdump --syms --arch-name=aarch64 ./build/gcov/out/test_hyp-props.out | grep  4fe9d0
+00000000004fe9d0 l     O .bss	0000000000000008 __llvm_gcov_ctr.5
+(gdb) shell qemu-aarch64 --version
+qemu-aarch64 version 8.0.0
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+(gdb) 
+```
+
+With qemu 6.2.0, it doesn't segfault (at least not at this point, you
+may ignore the segfault at the end due to a bug in the test program).
+```
+$ /usr/bin/qemu-aarch64  --version
+qemu-aarch64 version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.12)
+Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
+
+$ /usr/bin/qemu-aarch64  ./build/gcov/out/test_hyp-props.out
+test_hyp-props.c:13:test__setup_str_prop:PASS
+test_hyp-props.c:14:test__log_print_handler:PASS
+test_hyp-props.c:15:test__setup_log_print_prop:PASS
+test_hyp-props.c:16:test__vm_vcpu_abort_reset_handler:PASS
+test_hyp-props.c:17:test__vm_info_alloc:PASS
+test_hyp-props.c:18:test__memory_status_get:PASS
+test_hyp-props.c:19:test__memory_status_get_fail:PASS
+Segmentation fault (core dumped)
+```
+Steps to reproduce:
+1. Compile and link statically (with ld.lld) a test program, with clang, targetting aarch64 with: -target aarch64-linux-android -mcpu=cortex-a53, using --coverage option to generate gcov coverage.
+2. Run it with qemu-aarch64 8.0.0
+3. Hopefully, it will segfault early for no good reason.
diff --git a/results/classifier/gemma3:27b/runtime/1909921 b/results/classifier/gemma3:27b/runtime/1909921
new file mode 100644
index 00000000..ed041b77
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1909921
@@ -0,0 +1,25 @@
+
+
+
+ Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e
+
+Hello,
+
+I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM Edition).
+I created a CentOS 7 VM on it and I'm using a Docker container which is running qemu inside it.
+
+This container is a Debian Bullseye OS and I'm using qemu-i386 to start my application inside it.
+The error given by qemu is the following :
+
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff9d5f9b0e
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff82f29b0e
+
+(The pc= value is always different, I guess it is randomly generated).
+
+My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)
+
+Could you please help me? Why am I facing this error?
+
+Feel free to ask any questions regarding this matter in order to find a solution to it!
+
+Regards
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1913 b/results/classifier/gemma3:27b/runtime/1913
new file mode 100644
index 00000000..155199be
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1913
@@ -0,0 +1,22 @@
+
+
+
+Regression in 8.1.1: qemu-aarch64-static running ldconfig
+Description of problem:
+Since updating to 8.1.1, qemu crashes when running ldconfig in my sysroot (It's a more or less default Ubuntu 22.04 arm64 rootfs)
+Steps to reproduce:
+1. Download the arm64 ubuntu base from https://cdimage.ubuntu.com/ubuntu-base/releases/jammy/release/
+2. Extract it
+3. Run `qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs` where `rootfs` is where you extracted it with qemu 8.1.1
+
+```bash
+$ qemu-aarch64-static --version
+qemu-aarch64 version 8.1.0
+$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs
+<works>
+$ sudo pacman -U /var/cache/pacman/pkg/qemu-user-static*-8.1.1*.zst
+$ qemu-aarch64-static --version
+qemu-aarch64 version 8.1.1
+$ qemu-aarch64-static rootfs/sbin/ldconfig.real -r rootfs
+<segfault>
+```
diff --git a/results/classifier/gemma3:27b/runtime/1915531 b/results/classifier/gemma3:27b/runtime/1915531
new file mode 100644
index 00000000..dc0a16e5
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1915531
@@ -0,0 +1,57 @@
+
+
+
+qemu-user child process hangs when forking due to glib allocation
+
+I and others have recently been using qemu-user for RISCV64 extensively. We have had many hangs. We have found that hangs happen in process with multiple threads and forking. For example
+`cargo` (a tool for the Rust compiler).
+
+It does not matter if there are a lot of calls to fork. What seems to matter most is that there are many threads running. So this happens more often on a CPU with a massive number of cores, and if nothing else is really running. The hang happens in the child process of the fork.
+
+To reproduce the problem, I have attached an example of C++ program to run through qemu-user.
+
+Here are the stacks of the child processes that hanged. This is for qemu c973f06521b07af0f82893b75a1d55562fffb4b5 with glib 2.66.4
+
+-------
+Thread 1:
+#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
+#1  0x00007f54e190c77c in g_mutex_lock_slowpath (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1462
+#2  0x00007f54e190d222 in g_mutex_lock (mutex=mutex@entry=0x7f54e1dc7600 <allocator+96>) at ../glib/gthread-posix.c:1486
+#3  0x00007f54e18e39f2 in magazine_cache_pop_magazine (countp=0x7f54280e6638, ix=2) at ../glib/gslice.c:769
+#4  thread_memory_magazine1_reload (ix=2, tmem=0x7f54280e6600) at ../glib/gslice.c:845
+#5  g_slice_alloc (mem_size=mem_size@entry=40) at ../glib/gslice.c:1058
+#6  0x00007f54e18f06fa in g_tree_node_new (value=0x7f54d4066540 <code_gen_buffer+419091>, key=0x7f54d4066560 <code_gen_buffer+419123>) at ../glib/gtree.c:517
+#7  g_tree_insert_internal (tree=0x555556aed800, key=0x7f54d4066560 <code_gen_buffer+419123>, value=0x7f54d4066540 <code_gen_buffer+419091>, replace=0) at ../glib/gtree.c:517
+#8  0x00007f54e186b755 in tcg_tb_insert (tb=0x7f54d4066540 <code_gen_buffer+419091>) at ../tcg/tcg.c:534
+#9  0x00007f54e1820545 in tb_gen_code (cpu=0x7f54980b4b60, pc=274906407438, cs_base=0, flags=24832, cflags=-16252928) at ../accel/tcg/translate-all.c:2118
+#10 0x00007f54e18034a5 in tb_find (cpu=0x7f54980b4b60, last_tb=0x7f54d4066440 <code_gen_buffer+418835>, tb_exit=0, cf_mask=524288) at ../accel/tcg/cpu-exec.c:462
+#11 0x00007f54e1803bd9 in cpu_exec (cpu=0x7f54980b4b60) at ../accel/tcg/cpu-exec.c:818
+#12 0x00007f54e1735a4c in cpu_loop (env=0x7f54980bce40) at ../linux-user/riscv/cpu_loop.c:37
+#13 0x00007f54e1844b22 in clone_func (arg=0x7f5402f3b080) at ../linux-user/syscall.c:6422
+#14 0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477
+#15 0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+
+Thread 2:
+#1  0x00007f54e18a8d6e in qemu_futex_wait (f=0x7f54e1dc7038 <rcu_call_ready_event>, val=4294967295) at /var/home/valentin/repos/qemu/include/qemu/futex.h:29
+#2  0x00007f54e18a8f32 in qemu_event_wait (ev=0x7f54e1dc7038 <rcu_call_ready_event>) at ../util/qemu-thread-posix.c:460
+#3  0x00007f54e18c0196 in call_rcu_thread (opaque=0x0) at ../util/rcu.c:258
+#4  0x00007f54e18a90eb in qemu_thread_start (args=0x7f5428244930) at ../util/qemu-thread-posix.c:521
+#5  0x00007f54e191950a in start_thread (arg=<optimized out>) at pthread_create.c:477
+#6  0x00007f54e19a52a3 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+-------
+
+Thread 1 seems to be the really hanged process.
+
+The problem is that glib is used in many places. Allocations are done through g_slice. g_slice has a global state that is not fork safe.
+
+So even though the cpu thread is set to exclusive before forking, it is not enough. Because there are other uses of glib data structures that are not part of the cpu loop (I think). So it seems not to be synchronized by `start_exclusive`, `end_exclusive`.
+
+So if one of the use of glib data structure is used during the fork, an allocation might lock a mutex in g_slice.
+
+When the cpu loop resumes in forked process, then the use of any glib data structure might just hang on a locked mutex in g_slice.
+
+So as a work-around we have starting using is setting environment `G_SLICE=always-malloc`. This resolves the hangs.
+
+I have opened an issue upstream: https://gitlab.gnome.org/GNOME/glib/-/issues/2326
+
+As fork documentation says, the child should be async-signal-safe. However, glibc's malloc is safe in fork child even though it is not async-signal-safe. So it is not that obvious where the responsability is. Should glib handle this case like malloc does? Or should qemu not use glib in the fork child?
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1916344 b/results/classifier/gemma3:27b/runtime/1916344
new file mode 100644
index 00000000..5d13405e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1916344
@@ -0,0 +1,27 @@
+
+
+
+User mode networking not working properly on QEMU on Mac OS X host
+
+Steps to reproduce:
+
+1. Install QEMU using homebrew on Mac OS X (I used Big Sur)
+2. Spin up a guest VM (say) Cent OS8 using user mode networking.
+3. Install podman inside the guest
+4. Run podman pull alpine
+
+The result is:
+
+[root@localhost ~]# podman pull alpine
+Resolved "alpine" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
+Trying to pull docker.io/library/alpine:latest...
+Getting image source signatures
+Copying blob ba3557a56b15 [======================================] 2.7MiB / 2.7MiB
+  unexpected EOF
+Error: Error writing blob: error storing blob to file "/var/tmp/storage851171596/1": error happened during read: unexpected EOF
+
+This is happening because QEMU is telling the guest that the TCP connection is closed even before reading all the data from the host socket and forwarding it to the guest.
+
+This issue doesn't happen on a Linux host. So, that tells me that this has something to do with QEMU installation on Mac OS X.
+
+This could be a slirp related issue. So, QEMU/slirp may need to work together on fixing this.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1917184 b/results/classifier/gemma3:27b/runtime/1917184
new file mode 100644
index 00000000..f7314da8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1917184
@@ -0,0 +1,8 @@
+
+
+
+qemu-user vm86() segfaults handling interrupt with ss:sp in same page as cs:ip
+
+When using qemu-i386 to run a program that uses vm86(), if the vm86 code calls an interrupt while cs:ip and ss:sp both point within the same page, do_int tries to write to the page while it is not writable, causing a segfault.
+
+qemu version 5.2.0, x86-64 host.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1927530 b/results/classifier/gemma3:27b/runtime/1927530
new file mode 100644
index 00000000..605bf2ed
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1927530
@@ -0,0 +1,42 @@
+
+
+
+qemu-aarch64 MTE fails to report tag mismatch
+
+Hi,
+
+While running the GCC testsuite with qemu-6.0 as simulator, I noticed several errors in the hwasan testsuite (output pattern tests).
+
+I am attaching:
+bitfield-2.exe
+ld-linux-aarch64.so.1
+libc.so.6
+libdl.so.2
+libhwasan.so.0
+libm.so.6
+libpthread.so.0
+librt.so.1
+
+The testcase can be executed via:
+qemu-aarch64 -L . bitfield-2.exe
+
+it currently generates:
+HWAddressSanitizer:DEADLYSIGNAL
+==21137==ERROR: HWAddressSanitizer: SEGV on unknown address 0x0000000000f0 (pc 0x00550084e318 bp 0x005f01650d00 sp 0x005f01650d00 T21137)
+==21137==The signal is caused by a UNKNOWN memory access.
+==21137==Hint: address points to the zero page.
+    #0 0x550084e318 in GetAccessInfo /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339
+    #1 0x550084e318 in HwasanOnSIGTRAP /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:401
+    #2 0x550084e318 in __hwasan::HwasanOnDeadlySignal(int, void*, void*) /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:426
+    #3 0x5f01651fec  (<unknown module>)
+    #4 0x550084b508 in __hwasan_load2 /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan.cpp:379
+    #5 0x400768 in f /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:17
+    #6 0x4007d0 in main /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/c-c++-common/hwasan/bitfield-2.c:24
+    #7 0x550124cee0 in __libc_start_main ../csu/libc-start.c:308
+    #8 0x400688  (/home/christophe.lyon/qemu-bug-hwasan-aarch64/bitfield-2.exe+0x400688)
+
+HWAddressSanitizer can not provide additional info.
+SUMMARY: HWAddressSanitizer: SEGV /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libsanitizer/hwasan/hwasan_linux.cpp:339 in GetAccessInfo
+==21146==ABORTING
+
+while the testcase expects HWAddressSanitizer: tag-mismatch on address 0x.....
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1930 b/results/classifier/gemma3:27b/runtime/1930
new file mode 100644
index 00000000..65a18ca7
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1930
@@ -0,0 +1,49 @@
+
+
+
+qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX
+Description of problem:
+We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+   Segmentation fault (core dumped)
+```
+
+We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error.
+Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated.
+Steps to reproduce:
+1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178.
+2. Write a simple hello world program.
+
+```
+     #include <stdio.h>
+     
+     int main(void) {
+         return printf("Hello World!");
+     }
+```
+
+3. Source QNX SDP to set some environment variables.
+
+   `$ source ./qnx710/qnxsdp-env.sh`
+
+4. Compile using the QNX compiler.
+
+   `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c`
+
+5. Running the binary as it is results to:
+
+```
+   $ ./hello-world
+   aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory
+```
+
+5. Running using QEMU emulator results to segmentation fault.
+
+```
+   $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world
+   qemu: uncaught target signal 11 (Segmentation fault) - core dumped  
+   Segmentation fault (core dumped)
+```
diff --git a/results/classifier/gemma3:27b/runtime/1936977 b/results/classifier/gemma3:27b/runtime/1936977
new file mode 100644
index 00000000..50182117
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1936977
@@ -0,0 +1,10 @@
+
+
+
+ qemu-arm-static crashes "segmentation fault" when running "git clone" 
+
+This is a reopen of #1869073 for `qemu-user-static/focal-updates,focal-security,now 1:4.2-3ubuntu6.17 amd64`. 
+
+`git clone` reproducably segfaults in `qemu-arm-static` chroot.
+
+#1869073 mentions this should have been fixed for newer versions of QEMU, but for `focal` there's no newer version available, even in `focal-backports`.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/1952 b/results/classifier/gemma3:27b/runtime/1952
new file mode 100644
index 00000000..b08e1312
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1952
@@ -0,0 +1,99 @@
+
+
+
+elf-linux-user: segfault caused by invalid loaddr extracted by the ELF loader
+Description of problem:
+Emulating ELF binaries as emitted by Zig may lead to segfault in QEMU, which typically looks like this
+
+```
+$ qemu-x86_64 simple
+fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
+```
+Steps to reproduce:
+1. Obtain latest Zig nightly
+2. Compile simple static C program using Zig's ELF linker:
+
+```
+$ echo "int main() { return 0 };" > simple.c
+$ zig build-exe simple.c -lc -target x86_64-linux-musl -fno-lld --image-base 0x1000000
+$ qemu-x86_64 simple
+fish: Job 1, 'qemu-x86_64 simple' terminated by signal SIGSEGV (Address boundary error)
+```
+Additional information:
+Note that running `simple` directly it's correctly mmaped and executed by the kernel:
+
+```
+$ ./simple
+$ echo $status
+0
+``` 
+
+The reason this happens is because of an assumption QEMU's ELF loader makes on the virtual addresses and offsets of `PT_LOAD` segments, namely:
+
+```
+vaddr2 - vaddr1 >= off2 - off1
+```
+
+Typically, to the best of my knowledge, this is conformed to by the linkers in the large, but it is not required at all. Here's a one-line tweak to QEMU's loader that fixes the segfault:
+
+```diff
+diff --git a/linux-user/elfload.c b/linux-user/elfload.c
+index f21e2e0c3d..eabb4fed03 100644
+--- a/linux-user/elfload.c
++++ b/linux-user/elfload.c
+@@ -3211,7 +3211,7 @@ static void load_elf_image(const char *image_name, int image_fd,
+     for (i = 0; i < ehdr->e_phnum; ++i) {
+         struct elf_phdr *eppnt = phdr + i;
+         if (eppnt->p_type == PT_LOAD) {
+-            abi_ulong a = eppnt->p_vaddr - eppnt->p_offset;
++            abi_ulong a = eppnt->p_vaddr & ~(eppnt->p_align - 1);
+             if (a < loaddr) {
+                 loaddr = a;
+             }
+```
+
+The reason why this breaks for ELF binaries emitted by Zig is that while virtual addresses are allocated sequentially or pre-allocated, file offsets are allocated on a best-effort basis wherever there is enough space in the file to fit a given section/segment so that we can move the contents in file while preserving the allocated virtual addresses on a whim. To provide a more concrete example, here's the load segment layout for `simple` as emitted by Zig:
+
+```
+$ readelf -l simple
+
+Elf file type is EXEC (Executable file)
+Entry point 0x1002000
+There are 7 program headers, starting at offset 64
+
+Program Headers:
+  Type           Offset             VirtAddr           PhysAddr
+                 FileSiz            MemSiz              Flags  Align
+  PHDR           0x0000000000000040 0x0000000001000040 0x0000000001000040
+                 0x0000000000000188 0x0000000000000188  R      0x8
+  LOAD           0x0000000000000000 0x0000000001000000 0x0000000001000000
+                 0x00000000000001c8 0x00000000000001c8  R      0x1000
+  LOAD           0x0000000000021000 0x0000000001001000 0x0000000001001000
+                 0x0000000000000078 0x0000000000000078  R      0x1000
+  LOAD           0x0000000000022000 0x0000000001002000 0x0000000001002000
+                 0x000000000000065a 0x000000000000065a  R E    0x1000
+  LOAD           0x0000000000023000 0x0000000001003000 0x0000000001003000
+                 0x0000000000000060 0x0000000000000278  RW     0x1000
+  GNU_EH_FRAME   0x0000000000021064 0x0000000001001064 0x0000000001001064
+                 0x0000000000000014 0x0000000000000014  R      0x4
+  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
+                 0x0000000000000000 0x0000000000000000  RW     0x1
+
+ Section to Segment mapping:
+  Segment Sections...
+   00
+   01
+   02     .rodata.str1.1 .rodata .eh_frame .eh_frame_hdr
+   03     .text .init .fini
+   04     .data .got .bss
+   05     .eh_frame_hdr
+   06
+```
+
+As you can see, initially `loaddr := 0x1000000 - 0x0 = 0x1000000`. However, upon iterating over the second load segment, we already get
+
+```
+a := 0x1001000 - 0x21000 = 0xfe000
+```
+
+and since `a < loaddr`, we incorrectly set `loaddr := 0xfe000`.
diff --git a/results/classifier/gemma3:27b/runtime/1953 b/results/classifier/gemma3:27b/runtime/1953
new file mode 100644
index 00000000..700d78cd
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/1953
@@ -0,0 +1,149 @@
+
+
+
+Segmentation fault when compiling elixir app on qemu aarch64 on x86_64 host
+Description of problem:
+When I try to install an elixir escript using
+
+```
+mix escript.install github upmaru/pakman --force 
+```
+
+I run into a segfault with the following output
+
+```
+
+
+Build and Deploy
+failed Oct 22, 2023 in 1m 27s
+2s
+2s
+22s
+56s
+remote: Compressing objects:  86% (144/167)        
+remote: Compressing objects:  87% (146/167)        
+remote: Compressing objects:  88% (147/167)        
+remote: Compressing objects:  89% (149/167)        
+remote: Compressing objects:  90% (151/167)        
+remote: Compressing objects:  91% (152/167)        
+remote: Compressing objects:  92% (154/167)        
+remote: Compressing objects:  93% (156/167)        
+remote: Compressing objects:  94% (157/167)        
+remote: Compressing objects:  95% (159/167)        
+remote: Compressing objects:  96% (161/167)        
+remote: Compressing objects:  97% (162/167)        
+remote: Compressing objects:  98% (164/167)        
+remote: Compressing objects:  99% (166/167)        
+remote: Compressing objects: 100% (167/167)        
+remote: Compressing objects: 100% (167/167), done.        
+remote: Total 2568 (delta 86), reused 188 (delta 58), pack-reused 2341        
+origin/HEAD set to develop
+Resolving Hex dependencies...
+Resolution completed in 0.872s
+New:
+  castore 1.0.4
+  finch 0.16.0
+  hpax 0.1.2
+  jason 1.4.1
+  mime 2.0.5
+  mint 1.5.1
+  nimble_options 1.0.2
+  nimble_pool 1.0.0
+  slugger 0.3.0
+  telemetry 1.2.1
+  tesla 1.7.0
+  yamerl 0.10.0
+  yaml_elixir 2.8.0
+* Getting tesla (Hex package)
+* Getting jason (Hex package)
+* Getting yaml_elixir (Hex package)
+* Getting slugger (Hex package)
+* Getting finch (Hex package)
+* Getting mint (Hex package)
+* Getting castore (Hex package)
+* Getting hpax (Hex package)
+* Getting mime (Hex package)
+* Getting nimble_options (Hex package)
+* Getting nimble_pool (Hex package)
+* Getting telemetry (Hex package)
+* Getting yamerl (Hex package)
+Resolving Hex dependencies...
+Resolution completed in 0.413s
+Unchanged:
+  castore 1.0.4
+  finch 0.16.0
+  hpax 0.1.2
+  jason 1.4.1
+  mime 2.0.5
+  mint 1.5.1
+  nimble_options 1.0.2
+  nimble_pool 1.0.0
+  slugger 0.3.0
+  telemetry 1.2.1
+  tesla 1.7.0
+  yamerl 0.10.0
+  yaml_elixir 2.8.0
+All dependencies are up to date
+==> mime
+Compiling 1 file (.ex)
+Generated mime app
+==> nimble_options
+Compiling 3 files (.ex)
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault (core dumped)
+```
+Steps to reproduce:
+1. Create a repo using the github action zacksiri/setup-alpine
+2. Install elixir
+3. run `mix escript.install github upmaru/pakman --force`
+Additional information:
+You can use the following github action config as an example / starting point.
+
+
+```yml
+name: 'Deployment'
+
+on:
+  push:
+    branches:
+      - main
+      - master
+      - develop
+
+jobs:
+  build_and_deploy:
+    name: Build and Deploy
+    runs-on: ubuntu-latest
+    steps:
+      - name: 'Checkout'
+        uses: actions/checkout@v3
+        with:
+          ref: ${{ github.event.workflow_run.head_branch }}
+          fetch-depth: 0
+
+      - name: 'Setup Alpine'
+        uses: zacksiri/setup-alpine@master
+        with:
+          branch: v3.18
+          arch: aarch64
+          qemu-repo: edge
+          packages: |
+            zip 
+            tar 
+            sudo 
+            alpine-sdk 
+            coreutils 
+            cmake
+            elixir
+
+      - name: 'Setup PAKman'
+        run: |
+          export MIX_ENV=prod
+
+          mix local.rebar --force
+          mix local.hex --force
+          mix escript.install github upmaru/pakman --force
+        shell: alpine.sh {0}
+```
+
+I'm using alpine 3.18 which has otp25 with jit enabled so I suspect this is something to do with https://gitlab.com/qemu-project/qemu/-/issues/1034
diff --git a/results/classifier/gemma3:27b/runtime/2027 b/results/classifier/gemma3:27b/runtime/2027
new file mode 100644
index 00000000..f9fb7e78
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2027
@@ -0,0 +1,236 @@
+
+
+
+Go runtime panic with qemu-x86_64-static on aarch64 (bisected)
+Description of problem:
+I have run into some crashes with certain x86 Go binaries running on arm64 (Asahi Linux) using qemu-user-static. The issue is also reproducible on current master (9c74490bff6c8886a922008d0c9ce6cae70dd17e). I have bisected the issue to commit 2d708164e0475064e0e2167bd73e8570e22df1e0:
+
+```
+first bad commit: [2d708164e0475064e0e2167bd73e8570e22df1e0] linux-user: Define TASK_UNMAPPED_BASE in $guest/target_mman.h
+```
+Steps to reproduce:
+1. Build example Go program `GOARCH=amd64 go build -o crashing .`
+2. Run it with `qemu-x86_64-static ./crashing`
+
+<details><summary>Go program to reproduce</summary>
+
+```go
+package main
+
+import "crypto/x509"
+
+func main() {
+  x509.SystemCertPool()
+}
+```
+
+</details>
+Additional information:
+<details><summary>Go program stacktrace</summary>
+
+```
+runtime: lfstack.push invalid packing: node=0xffff3c3a9780 cnt=0x1 packed=0xffff3c3a97800001 -> node=0xffffffff3c3a9780
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0x52cb61?, 0x2ce5?})
+	/usr/lib/golang/src/runtime/panic.go:1077 +0x5c fp=0xc000613f08 sp=0xc000613ed8 pc=0x433d5c
+runtime.(*lfstack).push(0xa0000000002?, 0xffffffffffffefe8?)
+	/usr/lib/golang/src/runtime/lfstack.go:29 +0x125 fp=0xc000613f48 sp=0xc000613f08 pc=0x40ac25
+runtime.(*spanSetBlockAlloc).free(...)
+	/usr/lib/golang/src/runtime/mspanset.go:322
+runtime.(*spanSet).reset(0x64d220)
+	/usr/lib/golang/src/runtime/mspanset.go:264 +0x79 fp=0xc000613f78 sp=0xc000613f48 pc=0x42ef79
+runtime.finishsweep_m()
+	/usr/lib/golang/src/runtime/mgcsweep.go:260 +0x95 fp=0xc000613fb8 sp=0xc000613f78 pc=0x423455
+runtime.gcStart.func2()
+	/usr/lib/golang/src/runtime/mgc.go:687 +0xf fp=0xc000613fc8 sp=0xc000613fb8 pc=0x45bd8f
+traceback: unexpected SPWRITE function runtime.systemstack
+runtime.systemstack()
+	/usr/lib/golang/src/runtime/asm_amd64.s:509 +0x4a fp=0xc000613fd8 sp=0xc000613fc8 pc=0x46016a
+
+goroutine 1 [running]:
+runtime.systemstack_switch()
+	/usr/lib/golang/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0001bb9f0 sp=0xc0001bb9e0 pc=0x460108
+runtime.gcStart({0xc000600000?, 0x98370?, 0x307800?})
+	/usr/lib/golang/src/runtime/mgc.go:686 +0x2e5 fp=0xc0001bba88 sp=0xc0001bb9f0 pc=0x418e05
+runtime.mallocgc(0x98370, 0x50bb80, 0x1)
+	/usr/lib/golang/src/runtime/malloc.go:1242 +0x76f fp=0xc0001bbaf0 sp=0xc0001bba88 pc=0x40caaf
+runtime.makeslice(0xc0001840a8?, 0x26?, 0x0?)
+	/usr/lib/golang/src/runtime/slice.go:103 +0x49 fp=0xc0001bbb18 sp=0xc0001bbaf0 pc=0x449729
+os.ReadFile({0xc00035a0f0?, 0x52dcd6?})
+	/usr/lib/golang/src/os/file.go:738 +0xe5 fp=0xc0001bbbf0 sp=0xc0001bbb18 pc=0x49ed25
+crypto/x509.loadSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root_unix.go:70 +0x3d4 fp=0xc0001bbcd8 sp=0xc0001bbbf0 pc=0x4fdef4
+crypto/x509.initSystemRoots()
+	/usr/lib/golang/src/crypto/x509/root.go:30 +0x5c fp=0xc0001bbd10 sp=0xc0001bbcd8 pc=0x4fd9fc
+sync.(*Once).doSlow(0x1?, 0xb30000c00018ada0?)
+	/usr/lib/golang/src/sync/once.go:74 +0xbf fp=0xc0001bbd70 sp=0xc0001bbd10 pc=0x467bff
+sync.(*Once).Do(...)
+	/usr/lib/golang/src/sync/once.go:65
+crypto/x509.systemRootsPool()
+	/usr/lib/golang/src/crypto/x509/root.go:21 +0x45 fp=0xc0001bbdc0 sp=0xc0001bbd70 pc=0x4fd8a5
+crypto/x509.SystemCertPool()
+	/usr/lib/golang/src/crypto/x509/cert_pool.go:112 +0x25 fp=0xc0001bbf30 sp=0xc0001bbdc0 pc=0x4f6705
+main.main()
+	/home/cyrill/dev/goruntime-crash/main.go:6 +0xf fp=0xc0001bbf40 sp=0xc0001bbf30 pc=0x4ff18f
+runtime.main()
+	/usr/lib/golang/src/runtime/proc.go:267 +0x2bb fp=0xc0001bbfe0 sp=0xc0001bbf40 pc=0x43673b
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0001bbfe8 sp=0xc0001bbfe0 pc=0x461f61
+
+goroutine 2 [force gc (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004efa8 sp=0xc00004ef88 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.forcegchelper()
+	/usr/lib/golang/src/runtime/proc.go:322 +0xb3 fp=0xc00004efe0 sp=0xc00004efa8 pc=0x436a13
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004efe8 sp=0xc00004efe0 pc=0x461f61
+created by runtime.init.6 in goroutine 1
+	/usr/lib/golang/src/runtime/proc.go:310 +0x1a
+
+goroutine 3 [GC sweep wait]:
+runtime.gopark(0x1?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004f778 sp=0xc00004f758 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.bgsweep(0x0?)
+	/usr/lib/golang/src/runtime/mgcsweep.go:321 +0xdf fp=0xc00004f7c8 sp=0xc00004f778 pc=0x4235bf
+runtime.gcenable.func1()
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x25 fp=0xc00004f7e0 sp=0xc00004f7c8 pc=0x418945
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004f7e8 sp=0xc00004f7e0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:200 +0x66
+
+goroutine 4 [GC scavenge wait]:
+runtime.gopark(0xc00006c000?, 0x570658?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004ff70 sp=0xc00004ff50 pc=0x436b8e
+runtime.goparkunlock(...)
+	/usr/lib/golang/src/runtime/proc.go:404
+runtime.(*scavengerState).park(0x625680)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:425 +0x49 fp=0xc00004ffa0 sp=0xc00004ff70 pc=0x420e49
+runtime.bgscavenge(0x0?)
+	/usr/lib/golang/src/runtime/mgcscavenge.go:658 +0x59 fp=0xc00004ffc8 sp=0xc00004ffa0 pc=0x4213f9
+runtime.gcenable.func2()
+	/usr/lib/golang/src/runtime/mgc.go:201 +0x25 fp=0xc00004ffe0 sp=0xc00004ffc8 pc=0x4188e5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004ffe8 sp=0xc00004ffe0 pc=0x461f61
+created by runtime.gcenable in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:201 +0xa5
+
+goroutine 17 [finalizer wait]:
+runtime.gopark(0x400000?, 0x10004e670?, 0x0?, 0x0?, 0x654640?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004e628 sp=0xc00004e608 pc=0x436b8e
+runtime.runfinq()
+	/usr/lib/golang/src/runtime/mfinal.go:193 +0x107 fp=0xc00004e7e0 sp=0xc00004e628 pc=0x4179c7
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004e7e8 sp=0xc00004e7e0 pc=0x461f61
+created by runtime.createfing in goroutine 1
+	/usr/lib/golang/src/runtime/mfinal.go:163 +0x3d
+
+goroutine 18 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004a750 sp=0xc00004a730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004a7e0 sp=0xc00004a750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004a7e8 sp=0xc00004a7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 19 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004af50 sp=0xc00004af30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004afe0 sp=0xc00004af50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004afe8 sp=0xc00004afe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 33 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090750 sp=0xc000090730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc0000907e0 sp=0xc000090750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc0000907e8 sp=0xc0000907e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 20 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004b750 sp=0xc00004b730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004b7e0 sp=0xc00004b750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004b7e8 sp=0xc00004b7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 49 [GC worker (idle)]:
+runtime.gopark(0x0?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00008c750 sp=0xc00008c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00008c7e0 sp=0xc00008c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00008c7e8 sp=0xc00008c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 21 [GC worker (idle)]:
+runtime.gopark(0xa740c76b8ab?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004bf50 sp=0xc00004bf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004bfe0 sp=0xc00004bf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004bfe8 sp=0xc00004bfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 22 [GC worker (idle)]:
+runtime.gopark(0xa740cc9dc5e?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004c750 sp=0xc00004c730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004c7e0 sp=0xc00004c750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004c7e8 sp=0xc00004c7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 23 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0xba?, 0x5f?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004cf50 sp=0xc00004cf30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004cfe0 sp=0xc00004cf50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 24 [GC worker (idle)]:
+runtime.gopark(0xa740c58ec16?, 0x0?, 0x0?, 0x0?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc00004d750 sp=0xc00004d730 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc00004d7e0 sp=0xc00004d750 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc00004d7e8 sp=0xc00004d7e0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+
+goroutine 34 [GC worker (idle)]:
+runtime.gopark(0x654640?, 0x1?, 0x7a?, 0xa3?, 0x0?)
+	/usr/lib/golang/src/runtime/proc.go:398 +0xce fp=0xc000090f50 sp=0xc000090f30 pc=0x436b8e
+runtime.gcBgMarkWorker()
+	/usr/lib/golang/src/runtime/mgc.go:1293 +0xe5 fp=0xc000090fe0 sp=0xc000090f50 pc=0x41a2c5
+runtime.goexit()
+	/usr/lib/golang/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000090fe8 sp=0xc000090fe0 pc=0x461f61
+created by runtime.gcBgMarkStartWorkers in goroutine 1
+	/usr/lib/golang/src/runtime/mgc.go:1217 +0x1c
+exit status 2
+```
+
+</details>
diff --git a/results/classifier/gemma3:27b/runtime/2035 b/results/classifier/gemma3:27b/runtime/2035
new file mode 100644
index 00000000..11a2bf38
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2035
@@ -0,0 +1,57 @@
+
+
+
+TCG Plugin exit callback not executing
+Description of problem:
+I cannot get the plugin exit callback to register/execute. I should see "Goodbye from plugin" but dont. I have also tried using `qemu_plugin_outs` without success.
+
+**Update: If I make my test binary an infinite loop and kill it with CTRL-C, then the callback is called as expected. Am I just using it wrong?**
+Steps to reproduce:
+1. Configured QEMU with `--target-list=riscv32-linux-user,riscv64-linux-user --enable-plugins --disable-system`
+2. Compiled plugin with 
+```
+gcc -I./qemu/include/qemu `pkg-config --libs glib-2.0` -O0 -fvisibility=hidden -Wall -shared -fPIC `pkg-config --cflags glib-2.0`
+```
+3. Compiled test binary (just a hello world) with `riscv64-unknown-elf-gcc test_qemu.c -o test_qemu`
+4. Ran ./qemu/build/qemu-riscv64 -plugin ./test_plugin.so -d plugin ./test_qemu
+Additional information:
+test_plugin.c
+```
+#include <inttypes.h>
+#include <assert.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <qemu-plugin.h>
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_version = QEMU_PLUGIN_VERSION;
+
+static void vcpu_tb_trans(qemu_plugin_id_t id, struct qemu_plugin_tb *tb)
+{
+    int n_insns = qemu_plugin_tb_n_insns(tb);
+    printf("> New TB of size %d\n", n_insns);
+
+    for (int i = 0; i < n_insns; i++) {
+        struct qemu_plugin_insn * insn = qemu_plugin_tb_get_insn(tb, i);
+        char * disassembly = qemu_plugin_insn_disas(insn);
+        printf(" > Instruciton: %s\n", disassembly);
+    }
+}
+
+static void plugin_exit(qemu_plugin_id_t id, void *p)
+{
+    printf("> Goodbye from plugin. %d\n", id);
+}
+
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+                                           const qemu_info_t *info,
+                                           int argc, char **argv)
+{
+    printf("> Hello From Plugin!\n");
+    qemu_plugin_register_vcpu_tb_trans_cb(id, vcpu_tb_trans);
+    qemu_plugin_register_atexit_cb(id, plugin_exit, NULL);
+    printf("> Everything was registered\n");
+    return 0;
+}
+```
diff --git a/results/classifier/gemma3:27b/runtime/2072564 b/results/classifier/gemma3:27b/runtime/2072564
new file mode 100644
index 00000000..3a9c3be0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2072564
@@ -0,0 +1,48 @@
+
+
+
+qemu-aarch64-static segfaults running ldconfig.real (amd64 host)
+
+This affects the qemu-user-static 1:8.2.2+ds-0ubuntu1 package on Ubuntu 24.04, running on a amd64 host.
+
+When running docker containers with Ubuntu 22.04 in them, emulating arm64 with qemu-aarch64-static, invocations of ldconfig (actually ldconfig.real) segfault. For example:
+
+$ docker run -ti --platform linux/arm64/v8 ubuntu:22.04 
+root@8861ff640a1c:/# /sbin/ldconfig.real
+Segmentation fault
+
+If you copy the ldconfig.real binary to the host, and run it directly via qemu-aarch64-static:
+
+$ gdb --args qemu-aarch64-static ./ldconfig.real 
+GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
+Copyright (C) 2024 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+Type "show copying" and "show warranty" for details.
+This GDB was configured as "x86_64-linux-gnu".
+Type "show configuration" for configuration details.
+For bug reporting instructions, please see:
+<https://www.gnu.org/software/gdb/bugs/>.
+Find the GDB manual and other documentation resources online at:
+    <http://www.gnu.org/software/gdb/documentation/>.
+
+For help, type "help".
+Type "apropos word" to search for commands related to "word"...
+Reading symbols from qemu-aarch64-static...
+Reading symbols from /home/dim/.cache/debuginfod_client/86579812b213be0964189499f62f176bea817bf2/debuginfo...
+(gdb) r
+Starting program: /usr/bin/qemu-aarch64-static ./ldconfig.real
+[Thread debugging using libthread_db enabled]
+Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+[New Thread 0x7ffff76006c0 (LWP 28378)]
+
+Thread 1 "qemu-aarch64-st" received signal SIGSEGV, Segmentation fault.
+0x00007fffe801645b in ?? ()
+(gdb) disassemble 
+No function contains program counter for selected frame.
+
+It looks like this is a known qemu regression after v8.1.1:
+https://gitlab.com/qemu-project/qemu/-/issues/1913
+
+Downgrading the package to qemu-user-static_8.0.4+dfsg-1ubuntu3_amd64.deb fixes the segfault.
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/2082 b/results/classifier/gemma3:27b/runtime/2082
new file mode 100644
index 00000000..33b0f7a9
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2082
@@ -0,0 +1,47 @@
+
+
+
+"Unable to find a guest_base to satisfy all guest address mapping requirements" running certain x86_64 binaries on aarch64 host
+Description of problem:
+Copying from:
+
+  https://bugzilla.redhat.com/show_bug.cgi?id=2256916
+
+With ``qemu-x86_64-static`` from ``qemu-8.1.3-1.fc39``, I can no longer run on the m1 the ``x86_64`` binary created by https://github.com/containers/PodmanHello
+
+If I try with ``qemu-x86_64-static`` from ``qemu-7.2.7-1.fc38`` then this works.
+
+If I build the binary manually on a fc39 x86 system with ``gcc -O2 -static -o podman_hello_world podman_hello_world.c``, then I can also run it successfully with ``qemu-8.1.3-1.fc39``.
+It's only the static binary built inside the alpine container which cannot be run on the M1.
+
+
+Misc tests I ran:
+
+```
+$ ./qemu-x86_64-static-8.1.3 podman_hello_world.alpine 
+qemu-x86_64-static-8.1.3: /var/roothome/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements
+  0000000000000000-0000000000000fff
+  0000000000400000-00000000004047ef
+
+$ ./qemu-x86_64-static-7.2.7 podman_hello_world.alpine 
+!... Hello Podman World ...!
+[...]
+
+$ ./qemu-x86_64-static-8.1.3 podman_hello_world.fc39 
+!... Hello Podman World ...!
+[...]
+```
+
+The issue is still present with ``qemu-8.2.0-0.3.rc2.fc40``
+
+I also could not reproduce on ``x86_64`` machines. I just tried it on fc39 installed on non-Apple ``aarch64`` hardware, and I'm seeing the same issue:
+
+```
+# rpm -qf /usr/bin/qemu-x86_64-static 
+qemu-user-static-x86-8.1.3-1.fc39.aarch64
+
+# qemu-x86_64-static ./podman_hello_world.alpine 
+qemu-x86_64-static: /root/podman_hello_world.alpine: Unable to find a guest_base to satisfy all guest address mapping requirements
+  0000000000000000-0000000000000fff
+  0000000000400000-00000000004047ef
+```
diff --git a/results/classifier/gemma3:27b/runtime/2101 b/results/classifier/gemma3:27b/runtime/2101
new file mode 100644
index 00000000..eefe4805
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2101
@@ -0,0 +1,20 @@
+
+
+
+[qemu-user/qemu-x86_64] run x86_64 'ls /' on aarch64 platform get wrong result
+Description of problem:
+```
+    qemu-x86_64 -L /tmp/ls-x86_64/root-x86_64-ls  /tmp/ls-x86_64/root-x86_64-ls/bin/ls  -l  /
+    ```
+get wrong result
+Steps to reproduce:
+1. copy /usr/bin/ls and the so library files it depends on from x86_64 platform to aarch64 platform
+2. qemu-x86_64 -L /path/to/x86_64/lib/root/dir  /path/to/ls  /  -l
+Additional information:
+Actual test script:
+```
+# host
+curl -Ls https://github.com/tcler/kiss-vm-ns/raw/master/utils/archive-ld-program.sh | sudo bash /dev/stdin ls
+scp  ls.x86_64.ash  root@jiyin-fedora-39_aarch64:
+ssh root@jiyin-fedora-39_aarch64 ./ls.x86_64.ash -l /
+```
diff --git a/results/classifier/gemma3:27b/runtime/2119 b/results/classifier/gemma3:27b/runtime/2119
new file mode 100644
index 00000000..c2d7b188
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2119
@@ -0,0 +1,4 @@
+
+
+
+target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed  when the single-letter V is enabled
diff --git a/results/classifier/gemma3:27b/runtime/2122 b/results/classifier/gemma3:27b/runtime/2122
new file mode 100644
index 00000000..859d184f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2122
@@ -0,0 +1,10 @@
+
+
+
+qemu-user-static segfault running ldconfig on host x86_64 with client arm64
+Description of problem:
+qemu segfault
+Steps to reproduce:
+1. download ubuntu jammy arm64 rootfs (I assume any will do)
+2. mount it (with /proc from host so apt is happy)
+3. execute an apt uninstall that triggers libc-bin processing
diff --git a/results/classifier/gemma3:27b/runtime/2123 b/results/classifier/gemma3:27b/runtime/2123
new file mode 100644
index 00000000..ec7f9aaa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2123
@@ -0,0 +1,34 @@
+
+
+
+Invalid subprocess commands spawns successfully when running under QEMU
+Description of problem:
+When executing a subprocess from with a non-existing command EQMU still spawns a process.
+
+Consider this small rust program for instance:
+```rust
+use std::process::Command;
+
+fn main() {
+    match Command::new("thisdoesnotexist").spawn() {
+        Ok(child) => {
+            println!("Child process id is {}", child.id());
+        }
+        Err(_) => {
+            println!("This should happen");
+        }
+    }
+}
+```
+
+**Executing with `qemu-aarch64`:**
+```shell
+qemu-aarch64 ./rust-app
+Child process id is 20182
+```
+
+**Executing regularly:**
+```shell
+./rust-app
+This should happen
+```
diff --git a/results/classifier/gemma3:27b/runtime/2127 b/results/classifier/gemma3:27b/runtime/2127
new file mode 100644
index 00000000..083ec4b3
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2127
@@ -0,0 +1,4 @@
+
+
+
+test-aio-multithread.c:371:test_multi_fair_mutex: assertion failed (counter == atomic_counter): (316636 == 316637)
diff --git a/results/classifier/gemma3:27b/runtime/2156 b/results/classifier/gemma3:27b/runtime/2156
new file mode 100644
index 00000000..4e1504da
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2156
@@ -0,0 +1,18 @@
+
+
+
+Userland QEMU segfaults when emulating itself thrice
+Description of problem:
+See title. 
+```
+$ qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+qemu-x86_64-static: QEMU internal SIGSEGV {code=ACCERR, addr=0x7f9ae80001a0}
+[1]    15705 segmentation fault (core dumped)  qemu-x86_64-static qemu-x86_64-static qemu-x86_64-static /bin/true
+```
+Steps to reproduce:
+1. Execute command above
+Additional information:
+Coredump (~322MB uncompressed)
+[qemu_qemu-x86_64-static_20240208-123447_15705.core.xz](/uploads/a6723aaf956dfd1efc434303e62c25e2/qemu_qemu-x86_64-static_20240208-123447_15705.core.xz)
+
+SHA1: 31c2b06a61f63dca5199b64b767aa2fdeefbeec6
diff --git a/results/classifier/gemma3:27b/runtime/2157 b/results/classifier/gemma3:27b/runtime/2157
new file mode 100644
index 00000000..0223b0aa
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2157
@@ -0,0 +1,46 @@
+
+
+
+qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB
+Description of problem:
+`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB
+(such as LoongArch, ppc64le, arm64 with 3 level page tables).
+Steps to reproduce:
+1. Compile x86 binary which makes a single exit(0) syscall:
+   ```
+   cat > exit0.S << EOF
+   #include <sys/syscall.h>
+   .text
+   .global _start
+    _start:
+      movl $__NR_exit, %eax
+      movl $0, %ebx
+      int $0x80
+   EOF
+   i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S
+   ```
+   Alternatively one might compile it on a x86 host:
+   ```
+   gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S
+   ```
+   and transfer the `exit0` binary to ppc64/LoongArch/arm64 system
+
+   2. Run the `exit0` binary with `qemu-i386`
+   ```
+   qemu-i386-static ./exit0
+   ```
+
+   #
+Additional information:
+`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB:
+```
+Program Headers:
+  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
+  LOAD           0x000000 0x08048000 0x08048000 0x00100 0x00100 R   0x1000
+  LOAD           0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000
+  NOTE           0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R   0x4
+  GNU_PROPERTY   0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R   0x4
+```
+
+Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch)
+alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied.
diff --git a/results/classifier/gemma3:27b/runtime/2223 b/results/classifier/gemma3:27b/runtime/2223
new file mode 100644
index 00000000..3331178e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2223
@@ -0,0 +1,38 @@
+
+
+
+Weird behavior on RISC-V code running on QEMU
+Description of problem:
+I am currently facing some weird problems on a RISC-V project meant to run on the QEMU environment and thought that maybe someone here could give me a light on the subject. The goal is to run a project built on top of one of FreeRTOS' official demo ports that target the 'virt' QEMU board. I ran across a few weird behaviors where code execution would just hang at some point (QEMU would keep execution but the expected terminal output would never come up). I don't have sufficient knowledge to tell whether the issue is with the FreeRTOS port, the RISC-V gnu toolchain or QEMU itself, hence why I am raising my hand for help on all related channels.
+
+This [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/) contains more details and a sample project that illustrates well one of the problems I've been getting lately (I also give more context about it [here](https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1434)). It basically goes like this: the program **executes fine** when a certain code snippet is encapsulated **within a function**, but "**crashes**" (i.e. hangs) when the same snippet is placed **directly in the main code**:
+
+```c
+for(int i=0; i < NUMBER_OF_ITEMS; i++){
+    createAndPushItem(i);
+
+    // the function above does the exact same thing as the commented code below
+    // yet, the commented code does not work and will crash the program. but why??
+        
+    // int index = priorities[i];                                               
+    // void *value = (void *) getValue(i + 1);
+    // LinkedListItem_t *item = createItem(index, value);                          
+    // if(item){
+    //     push(item, &list);
+    // }
+}
+```
+
+The scope shouldn't matter at all here, since there is no local variable being used or anything like that. I have tested workarounds like removing compiling optimization (i.e. changing -Os for -O0) and using regular malloc() instead of FreeRTOS' dynamic allocation API, but all without success.  Note that even though the project is build on top of the FreeRTOS demo port, no RTOS functionality is used within this code to make it as simple as it gets.
+Steps to reproduce:
+1. clone this [repository](https://bitbucket.org/softcps-investigacao-risc-v/freertos-riscv-bugs/src/master/)
+2. follow the readme to install the toolchain
+3. follow the readme to compile the program and run it
+Additional information:
+The expected output is supposed to be:
+
+![image](/uploads/462aa1a7872262df8f2588ee92dd5879/image.png)
+
+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:
+
+![image](/uploads/d2f7cc5614b293a5953e6fffa535aaca/image.png)
diff --git a/results/classifier/gemma3:27b/runtime/2304 b/results/classifier/gemma3:27b/runtime/2304
new file mode 100644
index 00000000..98b4e73d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2304
@@ -0,0 +1,41 @@
+
+
+
+Disabling SVE via `-cpu max,sve=off` leaves SVE2 advertised by `getauxval`
+Description of problem:
+The documentation on https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html suggests that it should be possible to disable SVE support by passing `-cpu max,sve=off` on the command line, however this appears to only disable the SVE support advertised in the return value from `getauxval(AT_HWCAP)`. In particular it leaves SVE2 reported as enabled. This leaves the feature set advertised by `getauxval` in an inconsistent state since SVE is mandatory if SVE2 is available.
+
+This may also affect other feature dependencies for example FEAT_SVE_BITPerm also requiring SVE2 to be available, I've not checked exhaustively.
+
+For example, given the following code:
+
+    #include <sys/auxv.h>
+    #include <stdio.h>
+
+    int main() {
+      unsigned long hwcap = getauxval(AT_HWCAP);
+      unsigned long hwcap2 = getauxval(AT_HWCAP2);
+
+      if (hwcap & HWCAP_SVE) {
+        printf("have sve!\n");
+      } else {
+        printf("don't have sve!\n");
+      }
+      if (hwcap2 & HWCAP2_SVE2) {
+        printf("have sve2!\n");
+      } else {
+        printf("don't have sve2!\n");
+      }
+    }
+
+We can observe the following:
+
+    $ aarch64-linux-gnu-gcc test.c -static
+    $ ../qemu-aarch64 -cpu max ./a.out
+    have sve!
+    have sve2!
+    $ ../qemu-aarch64 -cpu max,sve=off ./a.out
+    don't have sve!
+    have sve2!
+
+I don't believe that there is a `-cpu ...,sve2=off` option, so I would expect that disabling SVE also prevents SVE2 from being advertised as available.
diff --git a/results/classifier/gemma3:27b/runtime/2309 b/results/classifier/gemma3:27b/runtime/2309
new file mode 100644
index 00000000..41394ee5
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2309
@@ -0,0 +1,34 @@
+
+
+
+qemu-aarch64 hangs running cargo test after libc6 upgrade to 2.36-9+deb12u6
+Description of problem:
+qemu-aarch64 seems to hang with 100% cpu usage without any indication.
+with -p 12345 for gdb debugging, gdb could not interrupt the remote with ctrl-c.
+Steps to reproduce:
+1. Ensure the test env has 2.36-9+deb12u6
+2. Install the latest rust toolchain.
+3. mkdir test_test && cargo init
+4. ensure src/main.rs has
+```
+fn main() {
+    println!("Hello, world!");
+}
+
+#[test]
+fn test() {
+    println!("hAAA!");
+}
+```
+5. create .cargo/config.toml 
+```
+[target.aarch64-unknown-linux-gnu]
+linker = "aarch64-linux-gnu-gcc"
+runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu"
+rustflags = ["-C", "target-cpu=neoverse-n1"]
+```
+6. cargo test --target aarch64-unknown-linux-gnu
+Additional information:
+The issue does not seem to occur with libc6:2.36-9+deb12u4
+
+The same binary runs fine on a real arm64 target with the upgraded libc6 version 2.36-9+deb12u6.
diff --git a/results/classifier/gemma3:27b/runtime/2336 b/results/classifier/gemma3:27b/runtime/2336
new file mode 100644
index 00000000..52e60fc6
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2336
@@ -0,0 +1,26 @@
+
+
+
+qemu-x86_64 crash on LoongArch
+Description of problem:
+
+Steps to reproduce:
+1. build a static  hello test on x86_64 machine.
+2. build qemu-x86_64 on LoongArch.
+3. run 'qemu-x86_64 hello 'on LoongArch.
+Additional information:
+1  result
+
+[root@localhost qemu]# ./build/qemu-x86_64 ~/hello  
+Bus error (core dumped)
+
+2  Since commit 45bf0e7aa648369cf8ab2333bd20144806fc1be3 
+
+3  full log with -d in_asm,op,out_asm,strace
+see log.txt
+
+[log.txt](/uploads/9a0e3250bfafa6db31d6688b8c60feb7/log.txt)
+
+[qemu-x86_64](/uploads/728fc4f4633054097b6028cd99a20e8b/qemu-x86_64)
+
+[hello](/uploads/d7dec3bdb844273a8e26464ed418c1a0/hello)
diff --git a/results/classifier/gemma3:27b/runtime/2448 b/results/classifier/gemma3:27b/runtime/2448
new file mode 100644
index 00000000..ba65ac92
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2448
@@ -0,0 +1,49 @@
+
+
+
+linux-user as binfmt_misc fails to recognize AT_EXECFD if it's 0 and leaves it open as stdin
+Description of problem:
+When a `*-linux-user` is used as binfmt_misc, and...
+
+- The `O` (i.e. open-binary) flag is set
+- File descriptor 0 is closed when running the executable
+
+FD 0 is opened to point at the executable and passed as `AT_EXECFD`, which QEMU fails to recognize and leaves open before handing control over to the executable, leading to the program to think stdin is opened for reading its own executable.
+
+Some use cases rely on closed stdin to behave correctly. For example, this problem causes the `tests/tail/follow-stdin.sh` and `tests/tac/tac-2-nonseekable.sh` tests in GNU coreutils to fail. In any case, having the executable itself be stdin is definitely incorrect and quite surprising behavior.
+Steps to reproduce:
+1. Set up qemu-riscv64 as binfmt_misc with `qemu-binfmt-conf.sh`, with the `--credential` flag (which enables open-binary)
+2. Get a coreutils built for riscv64 (Let's say it can be found in `riscv64-coreutils/bin`)
+3. Run it with something like `riscv64-coreutils/bin/cat <&- | xxd | head` (`xxd | head` to catch the binary output)
+
+The correct behavior is (You can see by running the native `cat <&-`):
+
+```
+cat: -: Bad file descriptor
+cat: closing standard input: Bad file descriptor
+```
+
+Instead, the executable `cat` itself is dumped to stdout.
+
+Perhaps slightly more clear is `riscv64-coreutils/bin/ls -l /proc/self/fd <&-` which shows fd 0 unexpectedly pointing to the coreutils executable.
+Additional information:
+I'm interested in writing a patch to fix this issue but I'm uncertain how to proceed. This is what I've found so far:
+
+In `linux-user/main.c` if (effectively) `getauxval(AT_EXECFD)` is 0 it's treated as nonexistent. (https://gitlab.com/qemu-project/qemu/-/blob/0d9f1016d43302108d33d1268304a06cc3fb2021/linux-user/main.c#L758-765)
+
+```c
+    execfd = qemu_getauxval(AT_EXECFD);
+    if (execfd == 0) {
+        execfd = open(exec_path, O_RDONLY);
+        if (execfd < 0) {
+            printf("Error while loading %s: %s\n", exec_path, strerror(errno));
+            _exit(EXIT_FAILURE);
+        }
+    }
+```
+
+However as we've seen `getauxval(AT_EXECFD)` can have 0 as a valid value.
+
+`qemu_getauxval` in `util/getauxval.c` implements several strategies to get the auxv, but doesn't currently give a way to distinguish not found and 0. FreeBSD `elf_aux_info` has `EINVAL` and `ENOENT` error codes but it's ignored here. On Linux, glibc sets `errno` to `ENOENT` to distinguish the two cases but only on glibc >= 2.19. Musl's `getauxval` has always had setting `errno` to `ENOENT`.
+
+Once we add a proper "`AT_EXECFD` doesn't exist" check this will no longer be a problem since (IIUC) `execfd` will eventually be closed after loading. How should we add "not found" support to `qemu_getauxval`? Is just simply relying on libc's `getauxval` setting `errno` okay?
diff --git a/results/classifier/gemma3:27b/runtime/2460 b/results/classifier/gemma3:27b/runtime/2460
new file mode 100644
index 00000000..19cfd6dc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2460
@@ -0,0 +1,11 @@
+
+
+
+Significant performance degradation of qemu-x86_64 starting from version 3 on aarch64
+Description of problem:
+When I ran CoreMark with different qemu user-mode versions，guest x86-64-> host arm64, I found that the performance was highest with QEMU 2.x versions, and there was a significant performance degradation starting from QEMU version 3. What is the reason?
+
+|  |             |             |             |             |             |             |            |             |             |             |             |
+|------------------------------------------|-------------|-------------|-------------|-------------|-------------|-------------|------------|-------------|-------------|-------------|-------------|
+| qemu version                             | 2.5.1       | 2.8.0       | 2.9.0       | 2.9.1       | 3.0.0       | 4.0.0       | 5.2.0      | 6.2.0       | 7.2.13      | 8.2.6       | 9.0.1       |
+| coremark score                           | 3905.995703 | 4465.947153 | 4534.119247 | 4538.577912 | 1167.337886 | 1163.399453 | 928.348384 | 1327.051954 | 1301.659616 | 1034.714677 | 1085.304971 |
diff --git a/results/classifier/gemma3:27b/runtime/2486 b/results/classifier/gemma3:27b/runtime/2486
new file mode 100644
index 00000000..6cd7e064
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2486
@@ -0,0 +1,15 @@
+
+
+
+RISC-V Regression: QEMU_CPU=f=false,zfinx=true gives misleading error message
+Description of problem:
+The f extension looks like it should be toggle-able using qemu_cpu since it doesn't throw error messages when specified.
+Disabling the extension using f=false does not actually disable it as shown by the zfinx error message.
+Eg. Unsupported extension is explicitly rejected
+```
+> QEMU_CPU=rv64,j=false ./qemu-riscv64 test.out
+qemu-riscv64: can't apply global rv64-riscv-cpu.j=false: Property 'rv64-riscv-cpu.j' not found
+```
+Steps to reproduce:
+1. Compile any riscv binary like: `int main() {}`
+2. Execute using `QEMU_CPU=rv64,zfinx=true,f=false ./qemu-riscv64 test.out`
diff --git a/results/classifier/gemma3:27b/runtime/2505 b/results/classifier/gemma3:27b/runtime/2505
new file mode 100644
index 00000000..3eaa737f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2505
@@ -0,0 +1,4 @@
+
+
+
+Interpreter ELF flags ignored when selecting CPU
diff --git a/results/classifier/gemma3:27b/runtime/2525 b/results/classifier/gemma3:27b/runtime/2525
new file mode 100644
index 00000000..5ba0def1
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2525
@@ -0,0 +1,4 @@
+
+
+
+bFLT triggers accel/tcg/user-exec.c:505: page_set_flags: Assertion `have_mmap_lock()' failed.
diff --git a/results/classifier/gemma3:27b/runtime/2560 b/results/classifier/gemma3:27b/runtime/2560
new file mode 100644
index 00000000..9fb270f2
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2560
@@ -0,0 +1,108 @@
+
+
+
+Go garbage collector crashes when using qemu-x86_64 on an aarch64 host
+Description of problem:
+Apps compiled for Go and the Go compiler/tool itself crash when they are run with `qemu-x86_64` on an AARCH64 host system. This was not a problem on QEMU 8.2.x (I bisected, see further down). I also seem to recall that Go 1.21 is fine on QEMU 9.x, so maybe some recent change in Go 1.22 + recent changes in QEMU broke something?
+
+The crash from Go seems to be in the garbage collector, I cannot reproduce the issue when I disable the GC with `GOGC=off`.
+
+Output from Go when it crashes:
+
+```
+$ sudo chroot . go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+
+runtime stack:
+runtime.throw({0xa95b29?, 0x797b1e2a383c?})
+        runtime/panic.go:1023 +0x5c fp=0xc000515f08 sp=0xc000515ed8 pc=0x43c27c
+runtime.(*lfstack).push(0x0?, 0xc0005041c0?)
+        runtime/lfstack.go:29 +0x125 fp=0xc000515f48 sp=0xc000515f08 pc=0x40fd45
+runtime.(*spanSetBlockAlloc).free(...)
+        runtime/mspanset.go:322
+runtime.(*spanSet).reset(0xf46980)
+        runtime/mspanset.go:264 +0x79 fp=0xc000515f78 sp=0xc000515f48 pc=0x437219
+runtime.finishsweep_m()
+        runtime/mgcsweep.go:258 +0x8d fp=0xc000515fb8 sp=0xc000515f78 pc=0x42a6cd
+runtime.gcStart.func2()
+        runtime/mgc.go:685 +0xf fp=0xc000515fc8 sp=0xc000515fb8 pc=0x46e40f
+runtime.systemstack(0x0)
+        runtime/asm_amd64.s:509 +0x4a fp=0xc000515fd8 sp=0xc000515fc8 pc=0x47442a
+````
+Steps to reproduce:
+0. Use an aarch64 host system!
+
+1. Set up binfmt to use qemu-x86_64:
+
+```
+$ cat /proc/sys/fs/binfmt_misc/qemu-x86_64
+enabled
+interpreter /usr/bin/qemu-x86_64
+flags: OCF
+offset 0
+magic 7f454c4602010100000000000000000002003e00
+mask fffffffffffefe00fffffffffffffffffeffffff
+```
+
+2. Download/extract x86_64 rootfs:
+
+```
+$ curl -O https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-minirootfs-3.20.2-x86_64.tar.gz	
+```
+
+3. Create example app in the x86_64 rootfs:
+
+```
+package main
+
+func main() {
+}
+```
+
+4. Build using chroot:
+
+```
+$ sudo chroot /path/to/x86_64/rootfs apk add go
+$ sudo chroot /path/to/x86_64/rootfs go build main.go
+runtime: lfstack.push invalid packing: node=0xffff6542b2c0 cnt=0x1 packed=0xffff6542b2c00001 -> node=0xffffffff6542b2c0
+fatal error: lfstack.push
+...
+```
+
+5. As noted previously, if the Go garbage collector is disabled, then it works, presumably because it avoids the bug(?) in QEMU:
+
+```
+$ sudo chroot . env GOGC=off go build main.go
+# might have to mount /dev to build successfully, but Go doesn't panic!
+```
+Additional information:
+I've bisected this exact crash/failure to:
+
+```
+commit 2952b642a555207748dd961fcbfdc48f198eebb6
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Feb 13 10:20:27 2024 -1000
+
+    linux-user: Split out do_munmap
+
+    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+Though a different crash starts happening at the commit before that one:
+
+```
+commit ad87d26e6bb13257409f412224c862fc54025e8b
+Author: Richard Henderson <richard.henderson@linaro.org>
+Date:   Tue Jan 2 12:57:55 2024 +1100
+
+    linux-user: Do early mmap placement only for reserved_va
+
+    For reserved_va, place all non-fixed maps then proceed
+    as for MAP_FIXED.
+
+    Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
+```
+
+FYI @rth7680
diff --git a/results/classifier/gemma3:27b/runtime/2569 b/results/classifier/gemma3:27b/runtime/2569
new file mode 100644
index 00000000..2d07cccc
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2569
@@ -0,0 +1,8 @@
+
+
+
+The alpha target doesn't support tcg plugin register tracking due to missing XML
+Description of problem:
+There is no register tracking because we build our register list based on XML and there was no XML for alpha because its so old. We could synthesise one to cover the register to fix this.
+Steps to reproduce:
+1. ./qemu-alpha -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=\* ./tests/tcg/alpha-linux-user/hello-alpha
diff --git a/results/classifier/gemma3:27b/runtime/2580 b/results/classifier/gemma3:27b/runtime/2580
new file mode 100644
index 00000000..cdc12b61
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2580
@@ -0,0 +1,15 @@
+
+
+
+qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature()
+Description of problem:
+```
+❯ cat empty.c
+void _start() {}
+❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld
+❯ qemu-aarch64_be ./a.out
+**
+ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached
+Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached
+fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort)
+```
diff --git a/results/classifier/gemma3:27b/runtime/2590 b/results/classifier/gemma3:27b/runtime/2590
new file mode 100644
index 00000000..94fcd1b8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2590
@@ -0,0 +1,26 @@
+
+
+
+qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries.
+Description of problem:
+GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work.
+Steps to reproduce:
+1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary`
+2. Connect GDB to the debug server:
+```
+$ gdb-multiarch ./x86_64-binary
+(gdb) set verbose on
+(gdb) target remote :PORT
+```
+3. GDB displays a warning and fails to load shared libraries:
+```
+(gdb) target remote :PORT
+Remote debugging using :PORT
+warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.
+(gdb) info sharedlibrary
+No shared libraries loaded at this time.
+```
+Additional information:
+This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. 
+
+GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected.
diff --git a/results/classifier/gemma3:27b/runtime/2592 b/results/classifier/gemma3:27b/runtime/2592
new file mode 100644
index 00000000..6f7daacf
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2592
@@ -0,0 +1,40 @@
+
+
+
+qemu-aarch64 cannot properly support some python functions from the `time` module
+Description of problem:
+When a function is run in python (for example, `time.time()`), python returns the following error:
+```
+Traceback (most recent call last):
+  File "<string>", line 1, in <module>
+OSError: [Errno 0] Error
+```
+I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem.
+Steps to reproduce:
+Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts.
+1. Create a simple codespace environment.
+2. Run the following commands through the terminal:
+```
+git clone https://github.com/termux-pacman/glibc-packages
+cd glibc-packages
+./get-build-package.sh
+sudo mkdir /data
+sudo chown codespace /data
+sudo chgrp codespace /data
+sudo apt update
+sudo apt install patchelf
+./scripts/setup-cgct.sh
+```
+3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete.
+```
+./build-package.sh -I -w --library glibc gpkg/gobject-introspection
+```
+4. Install standard qemu via apt.
+5. Run the following command:
+```
+qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()"
+```
+Additional information:
+- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur.
+ - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502.  
+For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35.
diff --git a/results/classifier/gemma3:27b/runtime/2596 b/results/classifier/gemma3:27b/runtime/2596
new file mode 100644
index 00000000..153a9d45
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2596
@@ -0,0 +1,4 @@
+
+
+
+linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY)
diff --git a/results/classifier/gemma3:27b/runtime/2598 b/results/classifier/gemma3:27b/runtime/2598
new file mode 100644
index 00000000..0a978ad0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2598
@@ -0,0 +1,4 @@
+
+
+
+linux-user on riscv64 host: Unable to find a guest_base to satisfy all guest address mapping requirements 00000000-ffffffff
diff --git a/results/classifier/gemma3:27b/runtime/261 b/results/classifier/gemma3:27b/runtime/261
new file mode 100644
index 00000000..5e5ce90d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/261
@@ -0,0 +1,4 @@
+
+
+
+broken signal handling in nios2 user-mode emulation
diff --git a/results/classifier/gemma3:27b/runtime/2619 b/results/classifier/gemma3:27b/runtime/2619
new file mode 100644
index 00000000..785f3844
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2619
@@ -0,0 +1,4 @@
+
+
+
+INTEGER_OVERFLOW in nios2.c
diff --git a/results/classifier/gemma3:27b/runtime/2628 b/results/classifier/gemma3:27b/runtime/2628
new file mode 100644
index 00000000..3a92fac0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2628
@@ -0,0 +1,23 @@
+
+
+
+dpkg-deb in userspace emulation crashes in compression routine (armv7, aarch64, s390) on some machines
+Description of problem:
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_s390x.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Aborted), core dumped 
+
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped 
+
+chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_armhf.deb Version
+
+dpkg-deb: error: subprocess was killed by signal (Segmentation fault), core dumped
+Steps to reproduce:
+1. debootstrap --arch=arm64 stable /scratch/debian-stable
+2. chroot /scratch/debian-stable/ dpkg-deb -f /var/cache/apt/archives/dpkg_1.21.22_arm64.deb Version
+Additional information:
+Working environment: Debian 12 x86_64 Linux 6.1.0-25-amd64 qemu 7.2.13 AMD E-450 APU
+
+chroot can be created on this machine, when transferred to the broken machine (including the qemu binary used for emulation) dpkg cannot extract packages and crashes
diff --git a/results/classifier/gemma3:27b/runtime/2647 b/results/classifier/gemma3:27b/runtime/2647
new file mode 100644
index 00000000..ac6622d8
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2647
@@ -0,0 +1,50 @@
+
+
+
+A code error in accel/tcg/user-exec.c
+Description of problem:
+accel/tcg/user-exec.c:
+```
+static int probe_access_internal(CPUArchState *env, vaddr addr,
+                                 int fault_size, MMUAccessType access_type,
+                                 bool nonfault, uintptr_t ra)
+{
+    int acc_flag;
+    bool maperr;
+
+    switch (access_type) {
+    case MMU_DATA_STORE:
+        acc_flag = PAGE_WRITE_ORG;
+        break;
+    case MMU_DATA_LOAD:
+        acc_flag = PAGE_READ;
+        break;
+    case MMU_INST_FETCH:
+        acc_flag = PAGE_EXEC;
+        break;
+    default:
+        g_assert_not_reached();
+    }
+
+    if (guest_addr_valid_untagged(addr)) {
+        int page_flags = page_get_flags(addr);
+        if (page_flags & acc_flag) {
+            if ((acc_flag == PAGE_READ || acc_flag == PAGE_WRITE)
+                && cpu_plugin_mem_cbs_enabled(env_cpu(env))) {
+                return TLB_MMIO;
+            }
+            return 0; /* success */
+        }
+        maperr = !(page_flags & PAGE_VALID);
+    } else {
+        maperr = true;
+    }
+
+    if (nonfault) {
+        return TLB_INVALID_MASK;
+    }
+
+    cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra);
+}
+```
+The conditional judgment "acc_flag == PAGE_WRITE" seems to have an issue, because acc_flag can only be PAGE_WRITE_ORG, PAGE_READ or PAGE_EXEC from the previous code.
diff --git a/results/classifier/gemma3:27b/runtime/2655 b/results/classifier/gemma3:27b/runtime/2655
new file mode 100644
index 00000000..eb6cecce
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2655
@@ -0,0 +1,42 @@
+
+
+
+A problem in target/riscv/vector_helper.c: vext_ldff()
+Description of problem:
+I‘m confused about a behavior in function vext_ldff() in target/riscv/vector_helper.c:
+```
+static inline void
+vext_ldff(...)
+{
+...
+    for (i = env->vstart; i < env->vl; i++) {
+...
+        if (i == 0) {
+            probe_pages(env, addr, nf << log2_esz, ra, MMU_DATA_LOAD);
+        } else {
+...
+                flags = probe_access_flags(env, addr, offset, MMU_DATA_LOAD,
+                                           mmu_index, true, &host, 0);
+...
+                if (flags & ~TLB_WATCHPOINT) {
+                    vl = i;
+                    goto ProbeSuccess;
+                }
+...
+        }
+    }
+ProbeSuccess:
+...
+}
+```
+If the current instruction has a memory callback by plugin, the function probe_access_flags() will return TLB_MMIO when the page is exist.
+
+In this case, the function will always set vl to 1, goto ProbeSuccess, and only load the first element. Does it meet expectations? 
+
+This problem occurred in both linux-user mode and full-system mode.
+
+Maybe we can add extra parameter to probe_access_flags(), in order to change the behavior of inner functions.
+Steps to reproduce:
+1. Make a binary with instruction vle(x)ff.v, what I am using is https://github.com/chipsalliance/riscv-vector-tests.
+2. Write a plugin to add memory callbacks.
+3. Observe the behavior of the function.
diff --git a/results/classifier/gemma3:27b/runtime/2683 b/results/classifier/gemma3:27b/runtime/2683
new file mode 100644
index 00000000..d39a01af
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2683
@@ -0,0 +1,42 @@
+
+
+
+TCG: probe_access() has inconsistent behavior
+Description of problem:
+In full-system mode, probe_access() will return NULL when the flag is TLB_MMIO.
+
+accel/tcg/cputlb.c: probe_access_internal()
+```
+    if (unlikely(flags & ~(TLB_WATCHPOINT | TLB_NOTDIRTY | TLB_CHECK_ALIGNED))
+        || (access_type != MMU_INST_FETCH && force_mmio)) {
+        *phost = NULL;
+        return TLB_MMIO;
+    }
+```
+But in linux-user mode, it will return correct address when the flag is TLB_MMIO.
+
+accel/tcg/user-exec.c: probe_access()
+```
+    return size ? g2h(env_cpu(env), addr) : NULL;
+```
+This will lead to some different behaviors, like cbo.zero in RISC-V.
+
+target/riscv/op_helper.c: helper_cbo_zero()
+```
+    mem = probe_write(env, address, cbozlen, mmu_idx, ra);
+
+    if (likely(mem)) {
+        memset(mem, 0, cbozlen);
+    } else {
+        for (int i = 0; i < cbozlen; i++) {
+            cpu_stb_mmuidx_ra(env, address + i, 0, mmu_idx, ra);
+        }
+    }
+```
+When the current instruction has memory callback by plugin:
+
+Full-system mode uses slow-path(cpu_stb_mmuidx_ra) and inject mem_cbs correctly.
+
+Linux-user mode uses fast-path(memset) and doesn't inject callbacks.
+
+To ensure consistent results, probe_access() should return NULL when the flag is TLB_MMIO in linux-user mode.
diff --git a/results/classifier/gemma3:27b/runtime/2738 b/results/classifier/gemma3:27b/runtime/2738
new file mode 100644
index 00000000..0af80376
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2738
@@ -0,0 +1,13 @@
+
+
+
+golang 1.23 build hangs when running under qemu-user on x86_64 host
+Description of problem:
+Forwarded from https://github.com/golang/go/issues/70329.
+
+#
+Steps to reproduce:
+1. Setup qemu-user binfmt for a foreign ISA, for example, installs qemu-user-static-aarch64 on Fedora.
+2. Build the Dockerfile for specified arch: `podman build --arch aarch64 .`
+Additional information:
+
diff --git a/results/classifier/gemma3:27b/runtime/275 b/results/classifier/gemma3:27b/runtime/275
new file mode 100644
index 00000000..e7650ebe
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/275
@@ -0,0 +1,4 @@
+
+
+
+Error in user-mode calculation of ELF aux vector's AT_PHDR
diff --git a/results/classifier/gemma3:27b/runtime/276 b/results/classifier/gemma3:27b/runtime/276
new file mode 100644
index 00000000..b4472530
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/276
@@ -0,0 +1,4 @@
+
+
+
+Error in user-mode calculation of ELF program's brk
diff --git a/results/classifier/gemma3:27b/runtime/2761 b/results/classifier/gemma3:27b/runtime/2761
new file mode 100644
index 00000000..83689da6
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2761
@@ -0,0 +1,11 @@
+
+
+
+Emulation of x86_64 binary on ARM64 fails with "Unable to find a guest_base to satisfy all guest address mapping requirements"
+Description of problem:
+Virtualisation fails with error "Unable to find a guest_base to satisfy all guest address mapping requirements"
+
+```
+file   /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash
+/nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /nix/store/razasrvdg7ckplfmvdxv4ia3wbayr94s-bootstrap-tools/lib/ld-linux-x86-64.so.2, for GNU/Linux 3.10.0, BuildID[sha1]=2938b076ebbc4ea582b8eb1ea5c3f65d7a1b6261, stripped
+```
diff --git a/results/classifier/gemma3:27b/runtime/280 b/results/classifier/gemma3:27b/runtime/280
new file mode 100644
index 00000000..a52d19ec
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/280
@@ -0,0 +1,4 @@
+
+
+
+(ARM64) qemu-x86_64+schroot(Debian bullseye) can't run chrome and can't load HTML
diff --git a/results/classifier/gemma3:27b/runtime/2815 b/results/classifier/gemma3:27b/runtime/2815
new file mode 100644
index 00000000..4236102b
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2815
@@ -0,0 +1,4 @@
+
+
+
+clang 17 and newer -fsanitize=function causes QEMU user-mode to SEGV when calling TCG prologue
diff --git a/results/classifier/gemma3:27b/runtime/2846 b/results/classifier/gemma3:27b/runtime/2846
new file mode 100644
index 00000000..e2a6268f
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/2846
@@ -0,0 +1,4 @@
+
+
+
+linux-user hangs if fd_trans_lock is held during fork
diff --git a/results/classifier/gemma3:27b/runtime/311 b/results/classifier/gemma3:27b/runtime/311
new file mode 100644
index 00000000..ff15261d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/311
@@ -0,0 +1,4 @@
+
+
+
+qemu user mode: rt signals not implemented for sparc guests
diff --git a/results/classifier/gemma3:27b/runtime/324 b/results/classifier/gemma3:27b/runtime/324
new file mode 100644
index 00000000..fe76e37d
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/324
@@ -0,0 +1,4 @@
+
+
+
+chrome based apps can not be run under qemu user mode
diff --git a/results/classifier/gemma3:27b/runtime/326 b/results/classifier/gemma3:27b/runtime/326
new file mode 100644
index 00000000..f635a610
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/326
@@ -0,0 +1,4 @@
+
+
+
+QEMU-user ignores MADV_DONTNEED
diff --git a/results/classifier/gemma3:27b/runtime/333 b/results/classifier/gemma3:27b/runtime/333
new file mode 100644
index 00000000..674954ef
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/333
@@ -0,0 +1,4 @@
+
+
+
+random errors on aarch64 when executing __aarch64_cas8_acq_rel
diff --git a/results/classifier/gemma3:27b/runtime/355 b/results/classifier/gemma3:27b/runtime/355
new file mode 100644
index 00000000..8286c0d0
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/355
@@ -0,0 +1,4 @@
+
+
+
+A possible divide by zero bug in get_whole_cluster
diff --git a/results/classifier/gemma3:27b/runtime/419 b/results/classifier/gemma3:27b/runtime/419
new file mode 100644
index 00000000..f9d5b396
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/419
@@ -0,0 +1,4 @@
+
+
+
+bsd-user dumps core for all binaries emulated
diff --git a/results/classifier/gemma3:27b/runtime/442 b/results/classifier/gemma3:27b/runtime/442
new file mode 100644
index 00000000..ea8a9a23
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/442
@@ -0,0 +1,4 @@
+
+
+
+Firebird crashes on qemu-m68k-user with pthread_mutex_init error
diff --git a/results/classifier/gemma3:27b/runtime/447 b/results/classifier/gemma3:27b/runtime/447
new file mode 100644
index 00000000..ab149091
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/447
@@ -0,0 +1,4 @@
+
+
+
+qemu-arm: Unable to reserve 0xffff0000 bytes of virtual address space at 0x1000 (Success) for use as guest address space (check yourvirtual memory ulimit setting, min_mmap_addr or reserve less using -R option)
diff --git a/results/classifier/gemma3:27b/runtime/562107 b/results/classifier/gemma3:27b/runtime/562107
new file mode 100644
index 00000000..89ee1857
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/562107
@@ -0,0 +1,15 @@
+
+
+
+QEmu GDB stub uses IPv6 instead of v4 (or both)
+
+This bug has been reported by several people already.
+
+See http://migeel.sk/blog/2009/04/21/gdb-and-qemu-on-windows/
+and http://qemu-forum.ipi.fi/viewtopic.php?f=5&t=5579&p=16248&hilit=gdb+ipv6#p16248
+
+
+Seems like a very easy fix. 
+
+Regards,
+Matthijs ter Woord
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/625 b/results/classifier/gemma3:27b/runtime/625
new file mode 100644
index 00000000..53d7d0c2
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/625
@@ -0,0 +1,26 @@
+
+
+
+qemu-hppa floating point POWER function is incorrect
+Description of problem:
+The floating point power function produces incorrect values, and possibly stack misshapes as well.
+Steps to reproduce:
+1. $ hppa1.1-unknown-linux-gnu-gcc pow.c -o pow -lm -static
+2. $ qemu-hppa pow
+3. the expected result is 10.0 ^ 6.0 = 6000000.0, instead of 403.45
+Additional information:
+Example C source to reproduce, pow.c:
+```
+#include <stdio.h>
+#include <math.h>
+int main()
+{
+    double base, expo, res;
+    base=10.0;
+    expo=6.0;
+    // res sould be 1e+6
+    res = pow(base, expo);
+    printf("%.1lf^%.1lf = %.2lf\n", base, expo, res);
+    return 0;
+}
+```
diff --git a/results/classifier/gemma3:27b/runtime/645662 b/results/classifier/gemma3:27b/runtime/645662
new file mode 100644
index 00000000..50426a81
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/645662
@@ -0,0 +1,43 @@
+
+
+
+QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit
+
+When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux version 2.6.26-2-686 (Debian 2.6.26-25lenny1)),
+gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu,
+3 math tests fail, apparently because the floating point unit is buggy. Qmeu was compiled from original sources
+on Debian Lenny with kernel  2.6.34.6 from kernel.org, gcc  (Debian 4.3.2-1.1) 4.3. 
+
+Regression testing errors:
+
+test_cmath
+test test_cmath failed -- Traceback (most recent call last):
+  File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in
+    self.fail(error_message)
+AssertionError: acos0034: acos(complex(-1.0000000000000002, 0.0))
+Expected: complex(3.141592653589793, -2.1073424255447014e-08)
+Received: complex(3.141592653589793, -2.1073424338879928e-08)
+Received value insufficiently close to expected value.
+
+
+test_float
+test test_float failed -- Traceback (most recent call last):
+  File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in
+    self.assertEqual(s, repr(float(s)))
+AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25'
+
+
+test_math
+test test_math failed -- multiple errors occurred; run in verbose mode for deta
+
+=>
+
+runtests.sh -v test_math
+
+le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math
+test_math BAD
+ 1 BAD
+ 0 GOOD
+ 0 SKIPPED
+ 1 total
+le01:~/tools/python3/Python-3.1.2#
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/690 b/results/classifier/gemma3:27b/runtime/690
new file mode 100644
index 00000000..16e56404
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/690
@@ -0,0 +1,22 @@
+
+
+
+32bit qemu-arm can't run GCC due to failure to allocate memory range for guest (Allocating guest commpage error)
+Description of problem:
+I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Since version 5.1 (include latest 6.1), QEMU cannot run GCC and some other things with an error `Allocating guest commpage: Operation not permitted`. The problem is NOT reproducible on QEMU 5.0, so probably the problem was caused by a [rework of init_guest_space or the following commits](https://gitlab.com/qemu-project/qemu/-/commit/ee94743034bfb443cf246eda4971bdc15d8ee066) a year ago.
+
+Also the problem is not reproducible for all users. It is known that it is reproduced on all Arch Linux host machines and some Debian, and probably depends on some kernel build parameters.
+
+The sysctl `vm.mmap_min_addr` parameter also affects the problem. The error varies depending on its value:
+```
+[0 ... 53248] - No error at all
+[53249 ... 61440] - Cannot allocate memory
+[61441 ... 65536 and higher] - Operation not permitted
+```
+Steps to reproduce:
+1. Download and extract attached tarball: [qemu-test-gcc.tgz](/uploads/0031fdf6705183626f646b78a281dd2a/qemu-test-gcc.tgz)
+2. `$ make # will build the docker container`
+3. `$ make run # will enter the container`
+4. Once in the container, run: `# /qemu-arm-static-50 /bin/bash /runme.sh`
+Additional information:
+A detailed description of the problem and feedback from other users is here: https://bugs.launchpad.net/qemu/+bug/1891748
diff --git a/results/classifier/gemma3:27b/runtime/693 b/results/classifier/gemma3:27b/runtime/693
new file mode 100644
index 00000000..30224262
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/693
@@ -0,0 +1,13 @@
+
+
+
+Qemu increased memory usage with TCG
+Description of problem:
+The issue is that instances that are supposed to use only a small amount of memory (like 256MB) suddenly use a much higher amount of RSS when running the accel=tcg, around 512MB in the above example. This was not happening with qemu-4.2 (on Ubuntu 20.04). This is also not happening when using accel=kvm instead. The issue has been first noticed on Debian 11 (Bullseye) with the versions above, but it is happening in the same way on Centos 8 Stream, Ubuntu 21.10 and a pre-release version of Ubuntu 22.04. It also also seen when testing with qemu-6.1 built from source.
+Steps to reproduce:
+1. Deploy devstack (https://opendev.org/openstack/devstack) with VIRT_TYPE=qemu on a VM
+2. Start an instance with cirros image and a flavor allocating 256MB
+3. Do a ps and see a RSS size of about 512MB being used after the instance has finished booting
+4. Expected result (seen with qemu-4.2 or VIRT_TYPE=kvm): RSS stays < 256MB
+Additional information:
+I can try to find a smaller commandline for manual reproduction if needed. The above sample is generated by OpenStack Nova via libvirt.
diff --git a/results/classifier/gemma3:27b/runtime/695 b/results/classifier/gemma3:27b/runtime/695
new file mode 100644
index 00000000..9b14ae6c
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/695
@@ -0,0 +1,4 @@
+
+
+
+MIPS: nanomips p32 ABI not supported
diff --git a/results/classifier/gemma3:27b/runtime/697 b/results/classifier/gemma3:27b/runtime/697
new file mode 100644
index 00000000..35cb85c4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/697
@@ -0,0 +1,4 @@
+
+
+
+linux-user create default CPU type before parsing the ELF header for specific CPU type
diff --git a/results/classifier/gemma3:27b/runtime/698 b/results/classifier/gemma3:27b/runtime/698
new file mode 100644
index 00000000..35855075
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/698
@@ -0,0 +1,361 @@
+
+
+
+linux-user: emulated process reading /proc/self/mem doesn't see guest view of memory map
+Description of problem:
+QEMU user-mode emulation of a 32-bit guest on a 64-bit host doesn't seem to emulate `/proc/self/mem` (or `/proc/$pid/mem`) correctly. Based on the contents of `/proc/self/maps`, there seems to be some sort of address translation happening that `/proc/self/mem` doesn't honor.
+
+The following source file:
+
+```c
+#include <fcntl.h>
+#include <inttypes.h>
+#include <stdbool.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <sys/wait.h>
+
+static const char string[] = "Hello, world!\n";
+
+static bool copy_to_stdout(const char *path)
+{
+	bool success = false;
+
+	int fd = open(path, O_RDONLY);
+	if (fd < 0) {
+		perror("open");
+		return false;
+	}
+
+	char buf[16 * 1024];
+	while (true) {
+		ssize_t bytes_read = read(fd, buf, sizeof(buf));
+		if (bytes_read == 0) {
+			success = true;
+			goto out;
+		} else if (bytes_read < 0) {
+			perror("read");
+			goto out;
+		}
+		ssize_t bytes_written = 0;
+		while (bytes_written < bytes_read) {
+			ssize_t ret = write(STDOUT_FILENO, buf + bytes_written,
+					    bytes_read - bytes_written);
+			if (ret < 0) {
+				perror("write");
+				goto out;
+			}
+			bytes_written += ret;
+		}
+	}
+
+out:
+	close(fd);
+	return success;
+}
+
+static bool dump_maps(void)
+{
+	printf("Maps read by self:\n");
+	fflush(stdout);
+	if (!copy_to_stdout("/proc/self/maps"))
+		return false;
+
+	printf("\nMaps read by child process:\n");
+	fflush(stdout);
+	pid_t pid = fork();
+	if (pid < 0) {
+		perror("fork");
+		return false;
+	}
+	if (pid == 0) {
+		char parent_maps[32];
+		sprintf(parent_maps, "/proc/%u/maps", (unsigned int)getppid());
+		if (copy_to_stdout(parent_maps))
+			_exit(EXIT_SUCCESS);
+		else
+			_exit(EXIT_FAILURE);
+	}
+	int wstatus;
+	if (waitpid(pid, &wstatus, 0) < 0 ||
+	    !WIFEXITED(wstatus) || WEXITSTATUS(wstatus) != EXIT_SUCCESS)
+		return false;
+
+	printf("\n");
+	return true;
+}
+
+int main(void)
+{
+	if (!dump_maps())
+		return EXIT_FAILURE;
+
+	int fd = open("/proc/self/mem", O_RDONLY);
+	if (fd < 0) {
+		perror("open: /proc/self/mem");
+		return EXIT_FAILURE;
+	}
+
+	char buf[sizeof(string)];
+	printf("Reading %zu bytes from %p (%" PRIuPTR ") to %p of PID %u\n",
+	       sizeof(buf), string, (uintptr_t)string, buf,
+	       (unsigned int)getpid());
+	fflush(stdout);
+
+	if (pread(fd, buf, sizeof(buf), (uintptr_t)string) < 0) {
+		perror("pread: /proc/self/mem");
+		return EXIT_FAILURE;
+	}
+
+	if (memcmp(buf, string, sizeof(buf)) != 0) {
+		fprintf(stderr, "buffer doesn't match\n");
+		return EXIT_FAILURE;
+	}
+
+	return EXIT_SUCCESS;
+}
+```
+
+when compiled for 32-bit ARM produces the following output:
+
+```
+Maps read by self:
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+7c000-8b000 ---p 00000000 00:00 0                                        
+8b000-8c000 r--p 0006b000 00:19 8275924                                  /home/osandov/repro
+8c000-8d000 rw-p 0006c000 00:19 8275924                                  /home/osandov/repro
+8d000-b0000 rw-p 00000000 00:00 0                                        
+3ffff000-40000000 r-xp 00000000 00:00 0                                  
+40000000-40001000 ---p 00000000 00:00 0                                  
+40001000-40801000 rw-p 00000000 00:00 0                                  [stack]
+
+Maps read by child process:
+00010000-00020000 ---p 00000000 00:00 0 
+00020000-0008c000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+0008c000-0009b000 ---p 00000000 00:00 0 
+0009b000-0009c000 r--p 0006b000 00:19 8275924                            /home/osandov/repro
+0009c000-0009d000 rw-p 0006c000 00:19 8275924                            /home/osandov/repro
+0009d000-000c0000 rw-p 00000000 00:00 0 
+000c0000-4000f000 ---p 00000000 00:00 0 
+4000f000-40010000 r--p 00000000 00:00 0 
+40010000-40011000 ---p 00000000 00:00 0 
+40011000-40811000 rw-p 00000000 00:00 0 
+40811000-100000000 ---p 00000000 00:00 0 
+100000000-100001000 r--p 00000000 00:00 0 
+5636dd7a2000-5636dd8a4000 r--p 00000000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636dd8a4000-5636ddb13000 r-xp 00102000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddb13000-5636ddf69000 r--p 00371000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddf6a000-5636ddfe7000 r--p 007c7000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddfe7000-5636ddff3000 rw-p 00844000 00:19 8270028                    /home/osandov/repos/qemu/build/qemu-arm
+5636ddff3000-5636de010000 rw-p 00000000 00:00 0 
+5636df67b000-5636df80c000 rw-p 00000000 00:00 0                          [heap]
+7f3008000000-7f300ffff000 rwxp 00000000 00:00 0 
+7f300ffff000-7f3010000000 ---p 00000000 00:00 0 
+7f3010000000-7f3010021000 rw-p 00000000 00:00 0 
+7f3010021000-7f3014000000 ---p 00000000 00:00 0 
+7f3017119000-7f301719a000 rw-p 00000000 00:00 0 
+7f301719a000-7f301719b000 ---p 00000000 00:00 0 
+7f301719b000-7f30179a1000 rw-p 00000000 00:00 0 
+7f30179a1000-7f30179a3000 r--p 00000000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179a3000-7f30179a9000 r-xp 00002000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179a9000-7f30179ab000 r--p 00008000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ab000-7f30179ac000 r--p 00009000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ac000-7f30179ad000 rw-p 0000a000 00:19 3660771                    /usr/lib/libffi.so.8.1.0
+7f30179ad000-7f30179be000 r--p 00000000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f30179be000-7f3017a32000 r-xp 00011000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a32000-7f3017a49000 r--p 00085000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a49000-7f3017a4a000 ---p 0009c000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4a000-7f3017a4c000 r--p 0009c000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4c000-7f3017a4d000 rw-p 0009e000 00:19 1476709                    /usr/lib/libgmp.so.10.4.1
+7f3017a4d000-7f3017a56000 r--p 00000000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a56000-7f3017a69000 r-xp 00009000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a69000-7f3017a93000 r--p 0001c000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a93000-7f3017a95000 r--p 00045000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a95000-7f3017a96000 rw-p 00047000 00:19 2871144                    /usr/lib/libhogweed.so.6.4
+7f3017a96000-7f3017a98000 rw-p 00000000 00:00 0 
+7f3017a98000-7f3017aa4000 r--p 00000000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017aa4000-7f3017ac5000 r-xp 0000c000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017ac5000-7f3017adb000 r--p 0002d000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adb000-7f3017adc000 ---p 00043000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adc000-7f3017ade000 r--p 00043000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017ade000-7f3017adf000 rw-p 00045000 00:19 2871147                    /usr/lib/libnettle.so.8.4
+7f3017adf000-7f3017ae2000 r--p 00000000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017ae2000-7f3017aee000 r-xp 00003000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017aee000-7f3017af2000 r--p 0000f000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af2000-7f3017af3000 ---p 00013000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af3000-7f3017af4000 r--p 00013000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af4000-7f3017af5000 rw-p 00014000 00:19 2550729                    /usr/lib/libtasn1.so.6.6.1
+7f3017af5000-7f3017b06000 r--p 00000000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017b06000-7f3017b3b000 r-xp 00011000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017b3b000-7f3017c72000 r--p 00046000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c72000-7f3017c76000 r--p 0017c000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c76000-7f3017c77000 rw-p 00180000 00:19 937656                     /usr/lib/libunistring.so.2.1.0
+7f3017c77000-7f3017c79000 r--p 00000000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c79000-7f3017c7d000 r-xp 00002000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c7d000-7f3017c97000 r--p 00006000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c97000-7f3017c98000 r--p 0001f000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c98000-7f3017c99000 rw-p 00020000 00:19 3212638                    /usr/lib/libidn2.so.0.3.7
+7f3017c99000-7f3017cc2000 r--p 00000000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017cc2000-7f3017d60000 r-xp 00029000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017d60000-7f3017dba000 r--p 000c7000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dba000-7f3017dc4000 r--p 00120000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dc4000-7f3017dce000 rw-p 0012a000 00:19 3663986                    /usr/lib/libp11-kit.so.0.3.0
+7f3017dce000-7f3017dd0000 r--p 00000000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd0000-7f3017dd2000 r-xp 00002000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd2000-7f3017dd3000 r--p 00004000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd3000-7f3017dd4000 r--p 00004000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd4000-7f3017dd5000 rw-p 00005000 00:19 2549813                    /usr/lib/libdl-2.33.so
+7f3017dd5000-7f3017dd7000 rw-p 00000000 00:00 0 
+7f3017dd7000-7f3017dd9000 r--p 00000000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017dd9000-7f3017e2f000 r-xp 00002000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e2f000-7f3017e4c000 r--p 00058000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4c000-7f3017e4d000 r--p 00074000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4d000-7f3017e4e000 rw-p 00075000 00:19 3020974                    /usr/lib/libpcre.so.1.2.13
+7f3017e4e000-7f3017e74000 r--p 00000000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3017e74000-7f3017fbf000 r-xp 00026000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3017fbf000-7f301800b000 r--p 00171000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f301800b000-7f301800e000 r--p 001bc000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f301800e000-7f3018011000 rw-p 001bf000 00:19 2549806                    /usr/lib/libc-2.33.so
+7f3018011000-7f301801a000 rw-p 00000000 00:00 0 
+7f301801a000-7f3018021000 r--p 00000000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018021000-7f3018030000 r-xp 00007000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018030000-7f3018034000 r--p 00016000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018034000-7f3018035000 ---p 0001a000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018035000-7f3018036000 r--p 0001a000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018036000-7f3018037000 rw-p 0001b000 00:19 2549847                    /usr/lib/libpthread-2.33.so
+7f3018037000-7f301803b000 rw-p 00000000 00:00 0 
+7f301803b000-7f301803e000 r--p 00000000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f301803e000-7f3018050000 r-xp 00003000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018050000-7f3018053000 r--p 00015000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018053000-7f3018054000 ---p 00018000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018054000-7f3018055000 r--p 00018000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018055000-7f3018056000 rw-p 00019000 00:19 2550528                    /usr/lib/libgcc_s.so.1
+7f3018056000-7f3018065000 r--p 00000000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018065000-7f30180ff000 r-xp 0000f000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f30180ff000-7f3018197000 r--p 000a9000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018197000-7f3018198000 ---p 00141000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018198000-7f3018199000 r--p 00141000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f3018199000-7f301819a000 rw-p 00142000 00:19 2549819                    /usr/lib/libm-2.33.so
+7f301819a000-7f3018233000 r--p 00000000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f3018233000-7f3018333000 r-xp 00099000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f3018333000-7f301839f000 r--p 00199000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f301839f000-7f30183ac000 r--p 00204000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f30183ac000-7f30183ad000 rw-p 00211000 00:19 2550558                    /usr/lib/libstdc++.so.6.0.29
+7f30183ad000-7f30183b2000 rw-p 00000000 00:00 0 
+7f30183b2000-7f30183e6000 r--p 00000000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30183e6000-7f3018508000 r-xp 00034000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f3018508000-7f301859d000 r--p 00156000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f301859d000-7f301859e000 ---p 001eb000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f301859e000-7f30185af000 r--p 001eb000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30185af000-7f30185b1000 rw-p 001fc000 00:19 2907924                    /usr/lib/libgnutls.so.30.30.0
+7f30185b1000-7f30185b3000 rw-p 00000000 00:00 0 
+7f30185b3000-7f30185b5000 r--p 00000000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b5000-7f30185b7000 r-xp 00002000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b7000-7f30185b8000 r--p 00004000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b8000-7f30185b9000 r--p 00004000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185b9000-7f30185ba000 rw-p 00005000 00:19 3662215                    /usr/lib/libgmodule-2.0.so.0.7000.0
+7f30185ba000-7f30185d7000 r--p 00000000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30185d7000-7f3018664000 r-xp 0001d000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f3018664000-7f30186ec000 r--p 000aa000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ec000-7f30186ed000 ---p 00132000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ed000-7f30186ee000 r--p 00132000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ee000-7f30186ef000 rw-p 00133000 00:19 3662212                    /usr/lib/libglib-2.0.so.0.7000.0
+7f30186ef000-7f30186f0000 rw-p 00000000 00:00 0 
+7f30186f0000-7f30186f2000 r--p 00000000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f2000-7f30186f4000 r-xp 00002000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f4000-7f30186f5000 r--p 00004000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f5000-7f30186f6000 r--p 00004000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f6000-7f30186f7000 rw-p 00005000 00:19 3440204                    /usr/lib/liburing.so.2.1.0
+7f30186f7000-7f30186fa000 r--p 00000000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f30186fa000-7f30186fe000 r-xp 00003000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f30186fe000-7f3018700000 r--p 00007000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018700000-7f3018701000 r--p 00008000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018701000-7f3018702000 rw-p 00009000 00:19 2549855                    /usr/lib/librt-2.33.so
+7f3018702000-7f3018705000 r--p 00000000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018705000-7f3018713000 r-xp 00003000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018713000-7f3018719000 r--p 00011000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f3018719000-7f301871a000 ---p 00017000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871a000-7f301871b000 r--p 00017000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871b000-7f301871c000 rw-p 00018000 00:19 15838                      /usr/lib/libz.so.1.2.11
+7f301871c000-7f301871e000 rw-p 00000000 00:00 0 
+7f301871e000-7f301871f000 r--p 00000000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301871f000-7f3018743000 r-xp 00001000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f3018743000-7f301874c000 r--p 00025000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301874c000-7f301874e000 r--p 0002d000 00:19 2549795                    /usr/lib/ld-2.33.so
+7f301874e000-7f3018750000 rw-p 0002f000 00:19 2549795                    /usr/lib/ld-2.33.so
+7ffc5c8f6000-7ffc5c917000 rw-p 00000000 00:00 0                          [stack]
+7ffc5c935000-7ffc5c939000 r--p 00000000 00:00 0                          [vvar]
+7ffc5c939000-7ffc5c93b000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+
+Reading 15 bytes from 0x6377c (407420) to 0x40800638 of PID 278331
+buffer doesn't match
+```
+
+The program is trying to read from 0x6377c, which according to the emulated maps is in this mapping:
+
+```
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+```
+
+but on the host, it's mapped differently:
+
+```
+00020000-0008c000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+```
+
+When using `qemu-arm-static` (version `6.1.0 (Debian 1:6.1+dfsg-6)`) via `binfmt_misc`, I also saw a case where the address isn't mapped in the host at all:
+
+```
+Maps read by self:
+10000-7c000 r-xp 00000000 00:19 8275924                                  /home/osandov/repro
+7c000-8b000 ---p 00000000 00:00 0                                        
+8b000-8c000 r--p 0006b000 00:19 8275924                                  /home/osandov/repro
+8c000-8d000 rw-p 0006c000 00:19 8275924                                  /home/osandov/repro
+8d000-b0000 rw-p 00000000 00:00 0                                        
+40000000-40001000 ---p 00000000 00:00 0                                  
+40001000-40801000 rw-p 00000000 00:00 0                                  [stack]
+
+Maps read by child process:
+00400000-00401000 r--p 00000000 00:19 297                                /usr/bin/qemu-arm-static
+00401000-00769000 r-xp 00001000 00:19 297                                /usr/bin/qemu-arm-static
+00769000-00abe000 r--p 00369000 00:19 297                                /usr/bin/qemu-arm-static
+00abe000-00c58000 r--p 006bd000 00:19 297                                /usr/bin/qemu-arm-static
+00c58000-00cd3000 rw-p 00857000 00:19 297                                /usr/bin/qemu-arm-static
+00cd3000-00cf7000 rw-p 00000000 00:00 0 
+0253c000-0268e000 rw-p 00000000 00:00 0                                  [heap]
+42645000-42655000 ---p 00000000 00:00 0 
+42655000-426c1000 r--p 00000000 00:19 8275924                            /home/osandov/repro
+426c1000-426d0000 ---p 00000000 00:00 0 
+426d0000-426d1000 r--p 0006b000 00:19 8275924                            /home/osandov/repro
+426d1000-426d2000 rw-p 0006c000 00:19 8275924                            /home/osandov/repro
+426d2000-426f5000 rw-p 00000000 00:00 0 
+426f5000-82645000 ---p 00000000 00:00 0 
+82645000-82646000 ---p 00000000 00:00 0 
+82646000-82e46000 rw-p 00000000 00:00 0 
+82e46000-142635000 ---p 00000000 00:00 0 
+142635000-142636000 r--p 00000000 00:00 0 
+7f5584000000-7f558bfff000 rwxp 00000000 00:00 0 
+7f558bfff000-7f558c000000 ---p 00000000 00:00 0 
+7f558c000000-7f558c021000 rw-p 00000000 00:00 0 
+7f558c021000-7f5590000000 ---p 00000000 00:00 0 
+7f55929b5000-7f5592a36000 rw-p 00000000 00:00 0 
+7f5592a36000-7f5592a37000 ---p 00000000 00:00 0 
+7f5592a37000-7f5593237000 rw-p 00000000 00:00 0 
+7ffc4971a000-7ffc4973b000 rw-p 00000000 00:00 0                          [stack]
+7ffc497fa000-7ffc497fe000 r--p 00000000 00:00 0                          [vvar]
+7ffc497fe000-7ffc49800000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+
+Reading 15 bytes from 0x6377c (407420) to 0x40800648 of PID 278443
+pread: /proc/self/mem: Input/output error
+```
+Steps to reproduce:
+1. Download statically-linked ARM [reproducer](/uploads/5563ad67d01f0ec4a10f27d1967216c4/repro).
+2. Run `qemu-arm ./repro`.
+Additional information:
+I encountered this when trying out a CI system that uses QEMU user-mode emulation for 32-bit ARM builds. My project is a debugger that uses `/proc/self/mem`, and a test case tripped over this. See https://github.com/osandov/drgn/pull/126.
+
+This also seems to happen with a i386 guest, but not with an aarch64 guest, so I'm assuming that it's a 32-bit guest issue.
diff --git a/results/classifier/gemma3:27b/runtime/704 b/results/classifier/gemma3:27b/runtime/704
new file mode 100644
index 00000000..25f04331
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/704
@@ -0,0 +1,4 @@
+
+
+
+linux-user: misaligned address for type 'struct linux_dirent64'
diff --git a/results/classifier/gemma3:27b/runtime/739785 b/results/classifier/gemma3:27b/runtime/739785
new file mode 100644
index 00000000..f02406e4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/739785
@@ -0,0 +1,37 @@
+
+
+
+qemu-i386 user mode can't fork (bash: fork: Invalid argument)
+
+Good time of day everybody,
+
+I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work.
+
+1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/
+2. I comiled qemu-i386 static and put it into /i386/usr/bin/
+./configure --static --disable-blobs --disable-system --target-list=i386-linux-user
+make
+
+3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it.
+uname -a
+Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux
+
+4. Added the following options into /etc/rc.local
+/sbin/modprobe binfmt_misc
+/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc
+echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register
+
+5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/
+
+6.Now i chroot into /i386 and I get this:
+[root@Plugbox i386]# chroot .
+[II aI hnve ao n@P /]# pacman -Suy
+bash: fork: Invalid argument
+
+7.I also downloaded linux-user-test-0.3 from qemu website and ran the test:
+[root@Plugbox linux-user-test-0.3]# make
+./qemu-linux-user.sh
+[qemu-i386]
+../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile
+BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
+make: *** [test] Error 127
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/754635 b/results/classifier/gemma3:27b/runtime/754635
new file mode 100644
index 00000000..84577858
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/754635
@@ -0,0 +1,58 @@
+
+
+
+-d option outs wrong info about sections
+
+For example, after run ./qemu-i386 -d in_asm /bin/ls from 0.14.0 release, I received this qemu.log file:
+$ cat /tmp/qemu.log | grep -A7 guest
+Relocating guest address space from 0x08048000 to 0x8048000
+guest_base  0x0
+start    end      size     prot
+00048000-0005f000 00017000 r-x
+0005f000-00069000 0000a000 rw-
+00040000-00041000 00001000 ---
+00041000-00041800 00000800 rw-
+00041800-0005d800 0001c000 r-x
+0005d800-0005f800 00002000 rw-
+
+But such command in 0.12.5 release outs this:
+$ cat /tmp/qemu.log | grep -A7 guest
+guest_base  0x0
+start    end      size     prot
+00f38000-00f39000 00001000 ---
+08048000-0805f000 00017000 r-x
+0805f000-08061000 00002000 rw-
+40000000-40080000 00080000 rw-
+40080000-40081000 00001000 ---
+40081000-4009d000 0001c000 r-x
+
+It looks correct.
+I received such differences and with qemu-microblaze. 
+
+After comparing 0.12.5 and 0.14.0 releases I found this differences in exec.c:
+in 0.12.5:
+end = (i << (32 - L1_BITS)) | (j << TARGET_PAGE_BITS);
+
+in 0.14.0:
+int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
+
+V_L1_SHIFT in my case is 10, but 32 - L1_BITS is 22
+
+I make this changes:
+$ diff -up qemu-0.14.0/exec.c exec.c
+--- qemu-0.14.0/exec.c	2011-04-08 17:26:00.524464002 +0400
++++ exec.c	2011-04-08 17:26:09.800464003 +0400
+@@ -2340,7 +2340,7 @@ int walk_memory_regions(void *priv, walk
+     data.prot = 0;
+ 
+     for (i = 0; i < V_L1_SIZE; i++) {
+-        int rc = walk_memory_regions_1(&data, (abi_ulong)i << V_L1_SHIFT,
++        int rc = walk_memory_regions_1(&data, (abi_ulong)i << (V_L1_SHIFT + TARGET_PAGE_BITS),
+                                        V_L1_SHIFT / L2_BITS - 1, l1_map + i);
+         if (rc != 0) {
+             return rc;
+
+After this outputs looks correct. 
+
+I don't know code base good, and think what may to do more general corrections.
+Host system: linux i386
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/805 b/results/classifier/gemma3:27b/runtime/805
new file mode 100644
index 00000000..1d393a30
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/805
@@ -0,0 +1,17 @@
+
+
+
+qemu-hexagon: [binary]: Error mapping file: Invalid argument
+Description of problem:
+Running a (32bit) hexagon binary on a 64bit/32bit system gives the following error:
+`qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument`
+Steps to reproduce:
+```
+./qemu-hexagon <hexagon-binary>
+qemu-hexagon: hexagon-hello-world: Error mapping file: Invalid argument
+```
+Additional information:
+A similar problem has been reported on the mailing list:
+https://www.mail-archive.com/qemu-devel@nongnu.org/msg836466.html
+
+Unfortunately without a solution.
diff --git a/results/classifier/gemma3:27b/runtime/866 b/results/classifier/gemma3:27b/runtime/866
new file mode 100644
index 00000000..344afc81
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/866
@@ -0,0 +1,56 @@
+
+
+
+linux-user: substantial memory leak when threads are created and destroyed
+Description of problem:
+Substantial memory leak when the following simple program is executed on `qemu-arm`,
+```c
+// compile with `arm-none-linux-gnueabihf-gcc test_qemu.c -o test_qemu.out -pthread`
+
+#include <assert.h>
+#include <pthread.h>
+
+#define MAGIC_RETURN ((void *)42)
+
+void *thread_main(void *arg)
+{
+    return MAGIC_RETURN;
+}
+
+int main(int argc, char *argv[])
+{
+    size_t i;
+    for (i = 0;; i++)
+    {
+        pthread_t thread;
+        assert(pthread_create(&thread, NULL, thread_main, NULL) == 0);
+        void *ret;
+        assert(pthread_join(thread, &ret) == 0);
+        assert(ret == MAGIC_RETURN);
+    }
+
+    return 0;
+}
+```
+Steps to reproduce:
+1. 
+```
+export TOOLCHAIN_PREFIX=arm-none-linux-gnueabihf
+export ARMSDK=/${TOOLCHAIN_PREFIX}
+export SYSROOT=${ARMSDK}/${TOOLCHAIN_PREFIX}/libc
+export CC=${ARMSDK}/bin/${TOOLCHAIN_PREFIX}-gcc
+```
+2. Download the arm toolchain: `curl --output ${TOOLCHAIN_PREFIX}.tar.xz -L 'https://developer.arm.com/-/media/Files/downloads/gnu-a/10.2-2020.11/binrel/gcc-arm-10.2-2020.11-x86_64-arm-none-linux-gnueabihf.tar.xz?revision=d0b90559-3960-4e4b-9297-7ddbc3e52783&la=en&hash=985078B758BC782BC338DB947347107FBCF8EF6B'`
+3. `mkdir -p ${ARMSDK} && tar xf ${TOOLCHAIN_PREFIX}.tar.xz -C ${ARMSDK} --strip-components=1`
+4. `$CC test_qemu.c -o test_qemu.out -pthread`
+5. `qemu-arm -L $SYSROOT ./test_qemu.out`
+6. Observe memory usage keeps ramping up and crashes the process once out of memory.
+Additional information:
+Valgrind annotation logs [annot.log](/uploads/f8d05d8f216d5a589e8da0758a345de6/annot.log) generated by a local build on master@0a301624c2f4ced3331ffd5bce85b4274fe132af from
+```bash
+valgrind --xtree-memory=full --xtree-memory-file=xtmemory.kcg bin/debug/native/qemu-arm -L $SYSROOT /mnt/f/test_qemu3.out
+# Send CTRL-C before the process crashes due to oom
+callgrind_annotate --auto=yes --inclusive=yes --sort=curB:100,curBk:100,totB:100,totBk:100,totFdB:100,totFdBk:100  xtmemory.kcg > annot.log
+```
+
+#
diff --git a/results/classifier/gemma3:27b/runtime/886621 b/results/classifier/gemma3:27b/runtime/886621
new file mode 100644
index 00000000..95c15b1e
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/886621
@@ -0,0 +1,295 @@
+
+
+
+Mac OS X Lion: segmentation fault
+
+
+Process:         qemu [5680]
+Path:            /usr/local/xeos-build/qemu/bin/qemu
+Identifier:      qemu
+Version:         ??? (???)
+Code Type:       X86-64 (Native)
+Parent Process:  make [5677]
+
+Date/Time:       2011-11-05 18:53:25.574 +0100
+OS Version:      Mac OS X 10.7.2 (11C74)
+Report Version:  9
+Sleep/Wake UUID: 3C81B8F7-0321-4621-923C-AB655F2CC701
+
+Interval Since Last Report:          503994 sec
+Crashes Since Last Report:           35
+Per-App Crashes Since Last Report:   9
+Anonymous UUID:                      28E7367A-4697-43A4-8D12-005F1917DFD3
+
+Crashed Thread:  0  Dispatch queue: com.apple.main-thread
+
+Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
+Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000003a
+
+VM Regions Near 0x3a:
+--> 
+    __TEXT                 0000000107c75000-0000000107ebc000 [ 2332K] r-x/rwx SM=COW  /usr/local/xeos-build/qemu/bin/qemu
+
+Application Specific Information:
+objc[5680]: garbage collection is OFF
+
+Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
+0   qemu                          	0x0000000107d9d0ed 0x107c75000 + 1212653
+1   qemu                          	0x0000000107dabc39 0x107c75000 + 1272889
+2   ???                           	0x000000010c3b007c 0 + 4500160636
+
+Thread 1:: Dispatch queue: com.apple.libdispatch-manager
+0   libsystem_kernel.dylib        	0x00007fff85abb7e6 kevent + 10
+1   libdispatch.dylib             	0x00007fff8e7b15be _dispatch_mgr_invoke + 923
+2   libdispatch.dylib             	0x00007fff8e7b014e _dispatch_mgr_thread + 54
+
+Thread 2:
+0   libsystem_kernel.dylib        	0x00007fff85abb192 __workq_kernreturn + 10
+1   libsystem_c.dylib             	0x00007fff85886594 _pthread_wqthread + 758
+2   libsystem_c.dylib             	0x00007fff85887b85 start_wqthread + 13
+
+Thread 3:
+0   libsystem_kernel.dylib        	0x00007fff85abb192 __workq_kernreturn + 10
+1   libsystem_c.dylib             	0x00007fff85886594 _pthread_wqthread + 758
+2   libsystem_c.dylib             	0x00007fff85887b85 start_wqthread + 13
+
+Thread 4:
+0   libsystem_kernel.dylib        	0x00007fff85abb192 __workq_kernreturn + 10
+1   libsystem_c.dylib             	0x00007fff85886594 _pthread_wqthread + 758
+2   libsystem_c.dylib             	0x00007fff85887b85 start_wqthread + 13
+
+Thread 5:
+0   libsystem_kernel.dylib        	0x00007fff85abb036 __sigwait + 10
+1   libsystem_c.dylib             	0x00007fff8583aaab sigwait + 68
+2   qemu                          	0x0000000107d221ef 0x107c75000 + 709103
+3   libsystem_c.dylib             	0x00007fff858848bf _pthread_start + 335
+4   libsystem_c.dylib             	0x00007fff85887b75 thread_start + 13
+
+Thread 0 crashed with X86 Thread State (64-bit):
+  rax: 0x5433ade07f7c29e7  rbx: 0x0000000000000010  rcx: 0x0000000000000000  rdx: 0x0000000000002000
+  rdi: 0x0000000000000010  rsi: 0x0000000000000000  rbp: 0x00007fff678714a0  rsp: 0x00007fff67871470
+   r8: 0x0000000109fe8000   r9: 0x0000000000000fff  r10: 0x00007fa7c185c01d  r11: 0x0000000000000246
+  r12: 0x00000001087ae368  r13: 0x0000000000000000  r14: 0x0000000000000000  r15: 0x0000000000001f80
+  rip: 0x0000000107d9d0ed  rfl: 0x0000000000010202  cr2: 0x000000000000003a
+Logical CPU: 6
+
+Binary Images:
+       0x107c75000 -        0x107ebbff7 +qemu (??? - ???) <FECE8C8E-BD8E-34F1-B222-32D79C7A0037> /usr/local/xeos-build/qemu/bin/qemu
+       0x1087cb000 -        0x1088b5fe7 +libglib-2.0.0.dylib (2704.0.0 - compatibility 2704.0.0) <5E6151CC-61F8-3335-A6FA-EFDD71474FA6> /usr/local/macmade/sw/glib/lib/libglib-2.0.0.dylib
+       0x108917000 -        0x10891ffff +libintl.8.dylib (9.1.0 - compatibility 9.0.0) <7D75E177-3172-2F78-1E08-1118A3D2D2A9> /usr/local/webstart/sw/gettext/lib/libintl.8.dylib
+       0x108928000 -        0x108949fff +libpng12.0.dylib (23.0.0 - compatibility 23.0.0) <FDE69E98-1D25-EEA1-99CF-F0A04A9AD7FF> /usr/local/webstart/sw/lib-png/lib/libpng12.0.dylib
+       0x10895a000 -        0x10897aff7 +libjpeg.62.dylib (63.0.0 - compatibility 63.0.0) <AD465C8A-66A4-E794-CA9A-96FB1B4D6CF0> /usr/local/webstart/sw/lib-jpeg/lib/libjpeg.62.dylib
+       0x108987000 -        0x108a67ff7 +libiconv.2.dylib (8.0.0 - compatibility 8.0.0) <54A03BBE-E505-9FF1-79AA-D4D5139BBF9C> /usr/local/webstart/sw/lib-iconv/lib/libiconv.2.dylib
+    0x7fff67875000 -     0x7fff678a9ac7  dyld (195.5 - ???) <4A6E2B28-C7A2-3528-ADB7-4076B9836041> /usr/lib/dyld
+    0x7fff8547d000 -     0x7fff8547efff  libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib
+    0x7fff8582b000 -     0x7fff8582efff  com.apple.help (1.3.2 - 42) <AB67588E-7227-3993-927F-C9E6DAC507FD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
+    0x7fff8582f000 -     0x7fff85835fff  libmacho.dylib (800.0.0 - compatibility 1.0.0) <D86F63EC-D2BD-32E0-8955-08B5EAFAD2CC> /usr/lib/system/libmacho.dylib
+    0x7fff85836000 -     0x7fff85913fef  libsystem_c.dylib (763.12.0 - compatibility 1.0.0) <FF69F06E-0904-3C08-A5EF-536FAFFFDC22> /usr/lib/system/libsystem_c.dylib
+    0x7fff85914000 -     0x7fff85914fff  com.apple.audio.units.AudioUnit (1.7.1 - 1.7.1) <04C10813-CCE5-3333-8C72-E8E35E417B3B> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
+    0x7fff85915000 -     0x7fff8591bfff  IOSurface (??? - ???) <06FA3FDD-E6D5-391F-B60D-E98B169DAB1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
+    0x7fff85964000 -     0x7fff85972fff  com.apple.NetAuth (1.0 - 3.0) <F384FFFD-70F6-3B1C-A886-F5B446E456E7> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
+    0x7fff85aa4000 -     0x7fff85ac4fff  libsystem_kernel.dylib (1699.22.73 - compatibility 1.0.0) <69F2F501-72D8-3B3B-8357-F4418B3E1348> /usr/lib/system/libsystem_kernel.dylib
+    0x7fff85ac5000 -     0x7fff85b10ff7  com.apple.SystemConfiguration (1.11.1 - 1.11) <F832FE21-5509-37C6-B1F1-48928F31BE45> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
+    0x7fff85c2a000 -     0x7fff85c39ff7  com.apple.opengl (1.7.5 - 1.7.5) <2945F1A6-910C-3596-9988-5701B04BD821> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
+    0x7fff85c3a000 -     0x7fff85c3eff7  com.apple.CommonPanels (1.2.5 - 94) <0BB2C436-C9D5-380B-86B5-E355A7711259> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
+    0x7fff85ebb000 -     0x7fff85fbefff  libsqlite3.dylib (9.6.0 - compatibility 9.0.0) <7F60B0FF-4946-3639-89AB-B540D318B249> /usr/lib/libsqlite3.dylib
+    0x7fff85fbf000 -     0x7fff86063fef  com.apple.ink.framework (1.3.2 - 110) <F69DBD44-FEC8-3C14-8131-CC0245DBBD42> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
+    0x7fff860c5000 -     0x7fff860cafff  libpam.2.dylib (3.0.0 - compatibility 3.0.0) <D952F17B-200A-3A23-B9B2-7C1F7AC19189> /usr/lib/libpam.2.dylib
+    0x7fff860dd000 -     0x7fff86147fff  com.apple.framework.IOKit (2.0 - ???) <87D55F1D-CDB5-3D13-A5F9-98EA4E22F8EE> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
+    0x7fff86148000 -     0x7fff8614ffff  libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib
+    0x7fff8627e000 -     0x7fff862abfe7  libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <095FDD3C-3961-3865-A59B-A5B0A4B8B923> /usr/lib/libSystem.B.dylib
+    0x7fff862ac000 -     0x7fff86314ff7  com.apple.Symbolication (1.2 - 89) <1D7F9E72-B1B6-30CF-AC8A-23A763930A92> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
+    0x7fff86315000 -     0x7fff86316ff7  libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib
+    0x7fff8633a000 -     0x7fff8634cff7  libbsm.0.dylib (??? - ???) <349BB16F-75FA-363F-8D98-7A9C3FA90A0D> /usr/lib/libbsm.0.dylib
+    0x7fff8634d000 -     0x7fff863b5ff7  com.apple.audio.CoreAudio (4.0.1 - 4.0.1) <7966E3BE-376B-371A-A21D-9BD763C0BAE7> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
+    0x7fff86411000 -     0x7fff86423ff7  libsasl2.2.dylib (3.15.0 - compatibility 3.0.0) <6245B497-784B-355C-98EF-2DC6B45BF05C> /usr/lib/libsasl2.2.dylib
+    0x7fff86428000 -     0x7fff86462fff  libncurses.5.4.dylib (5.4.0 - compatibility 5.4.0) <387DE593-9CC5-38C7-911B-A5F2264D34F2> /usr/lib/libncurses.5.4.dylib
+    0x7fff86463000 -     0x7fff864a2ff7  libGLImage.dylib (??? - ???) <2D1D8488-EC5F-3229-B983-CFDE0BB37586> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
+    0x7fff864a3000 -     0x7fff86545ff7  com.apple.securityfoundation (5.0 - 55005) <0D59908C-A61B-389E-AF37-741ACBBA6A94> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
+    0x7fff86546000 -     0x7fff865cbff7  com.apple.Heimdal (2.1 - 2.0) <C92E327E-CB5F-3C9B-92B0-F1680095C8A3> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
+    0x7fff865cc000 -     0x7fff865d0fff  libCGXType.A.dylib (600.0.0 - compatibility 64.0.0) <5EEAD17D-006C-3855-8093-C7A4A97EE0D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
+    0x7fff865d1000 -     0x7fff8664cff7  com.apple.print.framework.PrintCore (7.1 - 366.1) <3F140DEB-9F87-3672-97CC-F983752581AC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
+    0x7fff8664d000 -     0x7fff86654ff7  com.apple.CommerceCore (1.0 - 17) <AA783B87-48D4-3CA6-8FF6-0316396022F4> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
+    0x7fff86655000 -     0x7fff86655fff  com.apple.Accelerate.vecLib (3.7 - vecLib 3.7) <C06A140F-6114-3B8B-B080-E509303145B8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
+    0x7fff86656000 -     0x7fff8665afff  libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib
+    0x7fff8665b000 -     0x7fff86768fff  libJP2.dylib (??? - ???) <6052C973-9354-35CB-AAB9-31D00D8786F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
+    0x7fff86769000 -     0x7fff867acff7  libRIP.A.dylib (600.0.0 - compatibility 64.0.0) <2B1571E1-8E87-364E-BC36-C9C9B5D3EAC4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
+    0x7fff867ad000 -     0x7fff86d91fff  libBLAS.dylib (??? - ???) <C34F6D88-187F-33DC-8A68-C0C9D1FA36DF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
+    0x7fff86d92000 -     0x7fff86da4ff7  libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib
+    0x7fff87016000 -     0x7fff8701cfff  libGFXShared.dylib (??? - ???) <343AE6C0-EB02-333C-8D35-DF6093B92758> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
+    0x7fff8701d000 -     0x7fff87290fff  com.apple.CoreImage (7.82 - 1.0.1) <282801B6-5D80-3E2C-88A4-00FE29906D5A> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
+    0x7fff872da000 -     0x7fff87315fff  com.apple.LDAPFramework (3.0 - 120.1) <0C23534F-A8E7-3144-B2B2-50F9875101E2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
+    0x7fff87322000 -     0x7fff87524fff  libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <38CD6ED3-C8E4-3CCD-89AC-9C3198803101> /usr/lib/libicucore.A.dylib
+    0x7fff87a4c000 -     0x7fff87a4dfff  libsystem_sandbox.dylib (??? - ???) <8D14139B-B671-35F4-9E5A-023B4C523C38> /usr/lib/system/libsystem_sandbox.dylib
+    0x7fff87b4f000 -     0x7fff87b4ffff  libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib
+    0x7fff87b50000 -     0x7fff87ba7fff  libTIFF.dylib (??? - ???) <FF0D9A24-6956-3F03-81EA-3EEAD22C9DB8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
+    0x7fff87c87000 -     0x7fff8839a587  com.apple.CoreGraphics (1.600.0 - ???) <A9F2451E-6F60-350E-A6E5-539669B53074> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
+    0x7fff8839b000 -     0x7fff883b1ff7  com.apple.ImageCapture (7.0 - 7.0) <69E6E2E1-777E-332E-8BCF-4F0611517DD0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
+    0x7fff883b2000 -     0x7fff883b9fff  com.apple.NetFS (4.0 - 4.0) <B9F41443-679A-31AD-B0EB-36557DAF782B> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
+    0x7fff883d7000 -     0x7fff884b5fff  com.apple.ImageIO.framework (3.1.1 - 3.1.1) <13E549F8-5BD6-3BAE-8C33-1D0BD269C081> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
+    0x7fff884b6000 -     0x7fff884b6fff  com.apple.Cocoa (6.6 - ???) <021D4214-9C23-3CD8-AFB2-F331697A4508> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
+    0x7fff884b7000 -     0x7fff884b7fff  com.apple.ApplicationServices (41 - 41) <03F3FA8F-8D2A-3AB6-A8E3-40B001116339> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
+    0x7fff884b8000 -     0x7fff8861efff  com.apple.CFNetwork (520.2.5 - 520.2.5) <406712D9-3F0C-3763-B4EB-868D01F1F042> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
+    0x7fff8861f000 -     0x7fff88943fff  com.apple.HIToolbox (1.8 - ???) <A3BE7C59-52E6-3A7F-9B30-24B7DD3E95F2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
+    0x7fff88944000 -     0x7fff88961ff7  com.apple.openscripting (1.3.3 - ???) <A64205E6-D3C5-3E12-B1A0-72243151AF7D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
+    0x7fff88962000 -     0x7fff88c3aff7  com.apple.security (7.0 - 55010) <93713FF4-FE86-3B4C-8150-5FCC7F3320C8> /System/Library/Frameworks/Security.framework/Versions/A/Security
+    0x7fff88c5b000 -     0x7fff88cbbfff  libvDSP.dylib (325.4.0 - compatibility 1.0.0) <3A7521E6-5510-3FA7-AB65-79693A7A5839> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
+    0x7fff88cbf000 -     0x7fff88d43ff7  com.apple.ApplicationServices.ATS (317.5.0 - ???) <FE629F2D-6BC0-3A58-9844-D8B9A6808A00> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
+    0x7fff88d81000 -     0x7fff88e48ff7  com.apple.ColorSync (4.7.0 - 4.7.0) <F325A9D7-7203-36B7-8C1C-B6A4D5CC73A8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
+    0x7fff88e59000 -     0x7fff88e6dff7  com.apple.LangAnalysis (1.7.0 - 1.7.0) <04C31EF0-912A-3004-A08F-CEC27030E0B2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
+    0x7fff88e6e000 -     0x7fff88e79ff7  com.apple.speech.recognition.framework (4.0.19 - 4.0.19) <7ADAAF5B-1D78-32F2-9FFF-D2E3FBB41C2B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
+    0x7fff88f54000 -     0x7fff88f55fff  libunc.dylib (24.0.0 - compatibility 1.0.0) <C67B3B14-866C-314F-87FF-8025BEC2CAAC> /usr/lib/system/libunc.dylib
+    0x7fff89095000 -     0x7fff89148fff  com.apple.CoreText (220.11.0 - ???) <4EA8E2DF-542D-38D5-ADB9-C0DAA73F898B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
+    0x7fff8932e000 -     0x7fff894cdfff  com.apple.QuartzCore (1.7 - 270.0) <E8FC9AA4-A5CB-384B-AD29-7190A1387D3E> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
+    0x7fff894f6000 -     0x7fff89530fe7  com.apple.DebugSymbols (2.1 - 87) <E9000AB8-CCE4-3636-871D-E17703814B68> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
+    0x7fff89531000 -     0x7fff8958cff7  com.apple.HIServices (1.10 - ???) <BAB8B422-7047-3D2D-8E0A-13FCF153E4E7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
+    0x7fff89a1d000 -     0x7fff89a6bfff  libauto.dylib (??? - ???) <D8AC8458-DDD0-3939-8B96-B6CED81613EF> /usr/lib/libauto.dylib
+    0x7fff89a6c000 -     0x7fff89ac0ff7  com.apple.ScalableUserInterface (1.0 - 1) <1873D7BE-2272-31A1-8F85-F70C4D706B3B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
+    0x7fff89ac1000 -     0x7fff89ae0fff  libresolv.9.dylib (46.0.0 - compatibility 1.0.0) <33263568-E6F3-359C-A4FA-66AD1300F7D4> /usr/lib/libresolv.9.dylib
+    0x7fff89b26000 -     0x7fff89b65fff  com.apple.AE (527.7 - 527.7) <B82F7ABC-AC8B-3507-B029-969DD5CA813D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
+    0x7fff89fd5000 -     0x7fff8a1a9fff  com.apple.CoreFoundation (6.7.1 - 635.15) <FE4A86C2-3599-3CF8-AD1A-822F1FEA820F> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
+    0x7fff8a1aa000 -     0x7fff8a1d3fff  libJPEG.dylib (??? - ???) <64D079F9-256A-323B-A837-84628B172F21> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
+    0x7fff8a929000 -     0x7fff8a94dfff  com.apple.Kerberos (1.0 - 1) <1F826BCE-DA8F-381D-9C4C-A36AA0EA1CB9> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
+    0x7fff8a94e000 -     0x7fff8a94efff  com.apple.CoreServices (53 - 53) <043C8026-8EDD-3241-B090-F589E24062EF> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
+    0x7fff8a94f000 -     0x7fff8a9c4ff7  libc++.1.dylib (19.0.0 - compatibility 1.0.0) <C0EFFF1B-0FEB-3F99-BE54-506B35B555A9> /usr/lib/libc++.1.dylib
+    0x7fff8af21000 -     0x7fff8afa4fef  com.apple.Metadata (10.7.0 - 627.20) <E00156B0-663A-35EF-A307-A2CEB00F1845> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
+    0x7fff8b02d000 -     0x7fff8b036ff7  libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib
+    0x7fff8b06d000 -     0x7fff8b10cfff  com.apple.LaunchServices (480.21 - 480.21) <6BFADEA9-5BC1-3B53-A013-488EB7F1AB57> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
+    0x7fff8b10d000 -     0x7fff8b14efff  com.apple.QD (3.12 - ???) <4F3C5629-97C7-3E55-AF3C-ACC524929DA2> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
+    0x7fff8b14f000 -     0x7fff8b251ff7  libxml2.2.dylib (10.3.0 - compatibility 10.0.0) <D46F371D-6422-31B7-BCE0-D80713069E0E> /usr/lib/libxml2.2.dylib
+    0x7fff8b2f6000 -     0x7fff8b2f9fff  libCoreVMClient.dylib (??? - ???) <E034C772-4263-3F48-B083-25A758DD6228> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
+    0x7fff8b2fd000 -     0x7fff8b402ff7  libFontParser.dylib (??? - ???) <B9A53808-C97E-3293-9C33-1EA9D4E83EC8> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
+    0x7fff8b41e000 -     0x7fff8b449ff7  libxslt.1.dylib (3.24.0 - compatibility 3.0.0) <8051A3FC-7385-3EA9-9634-78FC616C3E94> /usr/lib/libxslt.1.dylib
+    0x7fff8b49e000 -     0x7fff8b4a3fff  libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib
+    0x7fff8b656000 -     0x7fff8b65bfff  libcache.dylib (47.0.0 - compatibility 1.0.0) <B7757E2E-5A7D-362E-AB71-785FE79E1527> /usr/lib/system/libcache.dylib
+    0x7fff8b65c000 -     0x7fff8b695fe7  libssl.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <79AAEC98-1258-3DA4-B1C0-4120049D390B> /usr/lib/libssl.0.9.8.dylib
+    0x7fff8b696000 -     0x7fff8b69bff7  libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib
+    0x7fff8b6c6000 -     0x7fff8b6d1ff7  libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib
+    0x7fff8b909000 -     0x7fff8bd36fff  libLAPACK.dylib (??? - ???) <4F2E1055-2207-340B-BB45-E4F16171EE0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
+    0x7fff8bd37000 -     0x7fff8bd42fff  com.apple.CommonAuth (2.1 - 2.0) <BFDD0A8D-4BEA-39EC-98B3-2E083D7B1ABD> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
+    0x7fff8bd43000 -     0x7fff8bd76ff7  com.apple.GSS (2.1 - 2.0) <9A2C9736-DA10-367A-B376-2C7A584E6C7A> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
+    0x7fff8bd77000 -     0x7fff8bd78ff7  libremovefile.dylib (21.0.0 - compatibility 1.0.0) <C6C49FB7-1892-32E4-86B5-25AD165131AA> /usr/lib/system/libremovefile.dylib
+    0x7fff8bd79000 -     0x7fff8bd7dfff  libdyld.dylib (195.5.0 - compatibility 1.0.0) <F1903B7A-D3FF-3390-909A-B24E09BAD1A5> /usr/lib/system/libdyld.dylib
+    0x7fff8bdac000 -     0x7fff8bdc8ff7  com.apple.GenerationalStorage (1.0 - 125) <31F60175-E38D-3C63-8D95-32CFE7062BCB> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
+    0x7fff8bdcd000 -     0x7fff8bdf5ff7  com.apple.CoreVideo (1.7 - 70.1) <98F917B2-FB53-3EA3-B548-7E97B38309A7> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
+    0x7fff8bdf6000 -     0x7fff8be0dfff  com.apple.MultitouchSupport.framework (220.62.1 - 220.62.1) <F21C79C0-4B5A-3645-81A6-74F8EFA900CE> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
+    0x7fff8be0e000 -     0x7fff8be34ff7  com.apple.framework.familycontrols (3.0 - 300) <41A6DFC2-EAF5-390A-83A1-C8832528705C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
+    0x7fff8c071000 -     0x7fff8c155def  libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <C5F2392D-B481-3A9D-91BE-3D039FFF4DEC> /usr/lib/libobjc.A.dylib
+    0x7fff8c156000 -     0x7fff8c17dfff  com.apple.PerformanceAnalysis (1.10 - 10) <2A058167-292E-3C3A-B1F8-49813336E068> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
+    0x7fff8c17e000 -     0x7fff8c1c0ff7  libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <A5B9778E-11C3-3F61-B740-1F2114E967FB> /usr/lib/system/libcommonCrypto.dylib
+    0x7fff8c3ff000 -     0x7fff8c452fff  libFontRegistry.dylib (??? - ???) <57FBD85F-41A6-3DB9-B5F4-FCC6B260F1AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
+    0x7fff8c461000 -     0x7fff8c4fbff7  com.apple.SearchKit (1.4.0 - 1.4.0) <4E70C394-773E-3A4B-A93C-59A88ABA9509> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
+    0x7fff8d20f000 -     0x7fff8d24aff7  libsystem_info.dylib (??? - ???) <9C8C2DCB-96DB-3471-9DCE-ADCC26BE2DD4> /usr/lib/system/libsystem_info.dylib
+    0x7fff8d24b000 -     0x7fff8d250fff  libGIF.dylib (??? - ???) <393E2DB5-9479-39A6-A75A-B5F20B852532> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
+    0x7fff8d251000 -     0x7fff8d268fff  com.apple.CFOpenDirectory (10.7 - 144) <9709423E-8484-3B26-AAE8-EF58D1B8FB3F> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
+    0x7fff8d269000 -     0x7fff8d26efff  com.apple.OpenDirectory (10.7 - 146) <91A87249-6A2F-3F89-A8DE-0E95C0B54A3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
+    0x7fff8d26f000 -     0x7fff8d2c1ff7  libGLU.dylib (??? - ???) <3C9153A0-8499-3DC0-AAA4-9FA6E488BE13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
+    0x7fff8d2c2000 -     0x7fff8d789fff  FaceCoreLight (1.4.7 - compatibility 1.0.0) <E9D2A69C-6E81-358C-A162-510969F91490> /System/Library/PrivateFrameworks/FaceCoreLight.framework/Versions/A/FaceCoreLight
+    0x7fff8d78a000 -     0x7fff8d792fff  libsystem_dnssd.dylib (??? - ???) <7749128E-D0C5-3832-861C-BC9913F774FA> /usr/lib/system/libsystem_dnssd.dylib
+    0x7fff8d793000 -     0x7fff8d7bcfff  com.apple.CoreServicesInternal (113.8 - 113.8) <C1A3CF1B-BC45-3FC6-82B3-1511EBBA9D51> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
+    0x7fff8d823000 -     0x7fff8d838fff  com.apple.speech.synthesis.framework (4.0.74 - 4.0.74) <C061ECBB-7061-3A43-8A18-90633F943295> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
+    0x7fff8e34d000 -     0x7fff8e371ff7  com.apple.RemoteViewServices (1.2 - 39) <862849C8-84C1-32A1-B87E-B29E74778C9F> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
+    0x7fff8e508000 -     0x7fff8e51bff7  libCRFSuite.dylib (??? - ???) <034D4DAA-63F0-35E4-BCEF-338DD7A453DD> /usr/lib/libCRFSuite.dylib
+    0x7fff8e7a7000 -     0x7fff8e7a9ff7  com.apple.print.framework.Print (7.1 - 247.1) <8A4925A5-BAA3-373C-9B5D-03E0270C6B12> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
+    0x7fff8e7aa000 -     0x7fff8e7adff7  com.apple.securityhi (4.0 - 1) <B37B8946-BBD4-36C1-ABC6-18EDBC573F03> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
+    0x7fff8e7ae000 -     0x7fff8e7bcfff  libdispatch.dylib (187.7.0 - compatibility 1.0.0) <712AAEAC-AD90-37F7-B71F-293FF8AE8723> /usr/lib/system/libdispatch.dylib
+    0x7fff8e7bd000 -     0x7fff8e7befff  liblangid.dylib (??? - ???) <CACBE3C3-2F7B-3EED-B50E-EDB73F473B77> /usr/lib/liblangid.dylib
+    0x7fff8e7cc000 -     0x7fff8e7e9fff  libPng.dylib (??? - ???) <3C70A94C-9442-3E11-AF51-C1B0EF81680E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
+    0x7fff8e7ea000 -     0x7fff8e7eafff  com.apple.Accelerate (1.7 - Accelerate 1.7) <82DDF6F5-FBC3-323D-B71D-CF7ABC5CF568> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
+    0x7fff8e7eb000 -     0x7fff8e801fff  libGL.dylib (??? - ???) <6A473BF9-4D35-34C6-9F8B-86B68091A9AF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
+    0x7fff8e810000 -     0x7fff8e81aff7  liblaunch.dylib (392.18.0 - compatibility 1.0.0) <39EF04F2-7F0C-3435-B785-BF283727FFBD> /usr/lib/system/liblaunch.dylib
+    0x7fff8e95f000 -     0x7fff8e9f5ff7  libvMisc.dylib (325.4.0 - compatibility 1.0.0) <642D8D54-F9F5-3FBB-A96C-EEFE94C6278B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
+    0x7fff8e9f6000 -     0x7fff8ec10fef  com.apple.CoreData (104 - 358.12) <33B1FA75-7970-3751-9DCC-FF809D3E1FA2> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
+    0x7fff8ef91000 -     0x7fff8f2aaff7  com.apple.Foundation (6.7.1 - 833.20) <D922F590-FDA6-3D89-A271-FD35E2290624> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
+    0x7fff8f2ab000 -     0x7fff8f38cfff  com.apple.CoreServices.OSServices (478.29 - 478.29) <B487110E-C942-33A8-A494-3BDEDB88B1CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
+    0x7fff8f3c8000 -     0x7fff8f3d5fff  libCSync.A.dylib (600.0.0 - compatibility 64.0.0) <931F40EB-CA75-3A90-AC97-4DB8E210BC76> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
+    0x7fff8f44d000 -     0x7fff8f4c0fff  libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib
+    0x7fff8f7e3000 -     0x7fff8f7e3fff  com.apple.Carbon (153 - 153) <895C2BF2-1666-3A59-A669-311B1F4F368B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
+    0x7fff8fb82000 -     0x7fff8fc9aff7  com.apple.DesktopServices (1.6.1 - 1.6.1) <4418EAA6-7163-3A77-ABD3-F8289796C81A> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
+    0x7fff8fc9d000 -     0x7fff8fc9ffff  com.apple.TrustEvaluationAgent (2.0 - 1) <1F31CAFF-C1C6-33D3-94E9-11B721761DDF> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
+    0x7fff8fca0000 -     0x7fff8fdf9fff  com.apple.audio.toolbox.AudioToolbox (1.7.1 - 1.7.1) <4877267E-F736-3019-85D3-40A32A042A80> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
+    0x7fff8fef9000 -     0x7fff8ff39ff7  libcups.2.dylib (2.9.0 - compatibility 2.0.0) <B7173CA4-CE16-3BAB-8D83-185FCEFA15F5> /usr/lib/libcups.2.dylib
+    0x7fff8ff9c000 -     0x7fff900a8fff  libcrypto.0.9.8.dylib (44.0.0 - compatibility 0.9.8) <3A8E1F89-5E26-3C8B-B538-81F5D61DBF8A> /usr/lib/libcrypto.0.9.8.dylib
+    0x7fff900a9000 -     0x7fff900b7ff7  libkxld.dylib (??? - ???) <65BE345D-6618-3D1A-9E2B-255E629646AA> /usr/lib/system/libkxld.dylib
+    0x7fff900b8000 -     0x7fff900beff7  libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib
+    0x7fff900cb000 -     0x7fff90204fef  com.apple.vImage (5.1 - 5.1) <EB634387-CD15-3246-AC28-5FB368ACCEA2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
+    0x7fff9020d000 -     0x7fff9023dff7  com.apple.DictionaryServices (1.2.1 - 158.2) <3FC86118-7553-38F7-8916-B329D2E94476> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
+    0x7fff9024e000 -     0x7fff90343fff  libiconv.2.dylib (7.0.0 - compatibility 7.0.0) <5C40E880-0706-378F-B864-3C2BD922D926> /usr/lib/libiconv.2.dylib
+    0x7fff90344000 -     0x7fff9038aff7  libcurl.4.dylib (7.0.0 - compatibility 7.0.0) <EAF61ADC-DC00-34CE-B23E-7238ED54E31D> /usr/lib/libcurl.4.dylib
+    0x7fff9038b000 -     0x7fff903a8ff7  libxpc.dylib (77.17.0 - compatibility 1.0.0) <72A16104-2F23-3C22-B474-1953F06F9376> /usr/lib/system/libxpc.dylib
+    0x7fff90b3e000 -     0x7fff90b3ffff  libdnsinfo.dylib (395.6.0 - compatibility 1.0.0) <718A135F-6349-354A-85D5-430B128EFD57> /usr/lib/system/libdnsinfo.dylib
+    0x7fff90b40000 -     0x7fff90e5cff7  com.apple.CoreServices.CarbonCore (960.18 - 960.18) <6020C3FB-6125-3EAE-A55D-1E77E38BEDEA> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
+    0x7fff90e9b000 -     0x7fff90e9bfff  com.apple.vecLib (3.7 - vecLib 3.7) <9A58105C-B36E-35B5-812C-4ED693F2618F> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
+    0x7fff90fe4000 -     0x7fff90feafff  com.apple.DiskArbitration (2.4.1 - 2.4.1) <CEA34337-63DE-302E-81AA-10D717E1F699> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
+    0x7fff91024000 -     0x7fff91027fff  libRadiance.dylib (??? - ???) <CD89D70D-F177-3BAE-8A26-644EA7D5E28E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
+    0x7fff91220000 -     0x7fff91222fff  libquarantine.dylib (36.0.0 - compatibility 1.0.0) <4C3BFBC7-E592-3939-B376-1C2E2D7C5389> /usr/lib/system/libquarantine.dylib
+    0x7fff91223000 -     0x7fff9128bfff  com.apple.CoreSymbolication (2.1 - 71) <0715BF39-D53C-3BFE-BBEA-B8EBF7274850> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
+    0x7fff9128c000 -     0x7fff912eefff  com.apple.coreui (1.2.1 - 164.1) <F7972630-F696-3FC5-9FCF-A6E1C8771078> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
+    0x7fff912ef000 -     0x7fff9135ffff  com.apple.datadetectorscore (3.0 - 179.4) <2A822A13-94B3-3A43-8724-98FDF698BB12> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
+    0x7fff91367000 -     0x7fff91394ff7  com.apple.opencl (1.50.63 - 1.50.63) <DB335C5C-3ABD-38C8-B6A5-8436EE1484D3> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
+    0x7fff91395000 -     0x7fff91f96ff7  com.apple.AppKit (6.7.2 - 1138.23) <5CD2C850-4F52-3BA2-BA11-3107DFD2D23C> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
+    0x7fff91f97000 -     0x7fff91f99fff  libCVMSPluginSupport.dylib (??? - ???) <61D89F3C-C64D-3733-819F-8AAAE4E2E993> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
+
+External Modification Summary:
+  Calls made by other processes targeting this process:
+    task_for_pid: 2
+    thread_create: 0
+    thread_set_state: 0
+  Calls made by this process:
+    task_for_pid: 0
+    thread_create: 0
+    thread_set_state: 0
+  Calls made by all processes on this machine:
+    task_for_pid: 103153
+    thread_create: 1
+    thread_set_state: 0
+
+VM Region Summary:
+ReadOnly portion of Libraries: Total=144.3M resident=100.5M(70%) swapped_out_or_unallocated=43.8M(30%)
+Writable regions: Total=185.9M written=3692K(2%) resident=23.0M(12%) swapped_out=0K(0%) unallocated=162.9M(88%)
+ 
+REGION TYPE                      VIRTUAL
+===========                      =======
+CG backing stores                  1496K
+CG image                              4K
+CG raster data                       64K
+CG shared images                   3480K
+CoreGraphics                         16K
+CoreServices                       4112K
+MALLOC                             67.1M
+MALLOC guard page                    32K
+MALLOC_LARGE (reserved)            25.3M        reserved VM address space (unallocated)
+Memory tag=242                       12K
+STACK GUARD                          24K
+Stack                              66.5M
+VM_ALLOCATE                        16.1M
+__CI_BITMAP                          80K
+__DATA                             21.1M
+__IMAGE                            1256K
+__LINKEDIT                         48.1M
+__TEXT                             96.2M
+__UNICODE                           544K
+mapped file                        32.2M
+shared memory                       308K
+===========                      =======
+TOTAL                             383.7M
+TOTAL, minus reserved VM space    358.4M
+
+Model: MacBookPro8,3, BootROM MBP81.0047.B24, 4 processors, Intel Core i7, 2.3 GHz, 8 GB, SMC 1.70f3
+Graphics: AMD Radeon HD 6750M, AMD Radeon HD 6750M, PCIe, 1024 MB
+Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB
+Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
+Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
+AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.100.98.75.18)
+Bluetooth: Version 4.0.1f4, 2 service, 11 devices, 1 incoming serial ports
+Network Service: Wi-Fi, AirPort, en1
+Serial ATA Device: APPLE SSD TS512C, 500.28 GB
+Serial ATA Device: MATSHITADVD-R   UJ-898
+USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8509, 0xfa200000 / 3
+USB Device: hub_device, 0x0424  (SMSC), 0x2514, 0xfa100000 / 2
+USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 5
+USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x821a, 0xfa113000 / 7
+USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0253, 0xfa120000 / 4
+USB Device: hub_device, 0x0424  (SMSC), 0x2514, 0xfd100000 / 2
+USB Device: Freecom Hard Drive XS, 0x07ab  (Freecom Computer Peripherals), 0xfc8e, 0xfd120000 / 5
+USB Device: IR Receiver, apple_vendor_id, 0x8242, 0xfd110000 / 3
\ No newline at end of file
diff --git a/results/classifier/gemma3:27b/runtime/909 b/results/classifier/gemma3:27b/runtime/909
new file mode 100644
index 00000000..dc380c91
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/909
@@ -0,0 +1,14 @@
+
+
+
+qemu-mipsn32(el) user mode emulator fails to execute any recently built n32 binaries
+Description of problem:
+**Note: Before trying to reproduce this issue, have a look at issue 843 - the binfmt-misc magic for n32 needs to be fixed.**
+
+Trying to chroot into a mips n32 installation fails with 
+```
+/bin/bash: error while loading shared libraries: /lib32/libc.so.6: cannot read file data
+```
+however, bash, libc.so.6, and qemu all exist and have the proper abi
+
+The problem occurs for both big and little endian N32 ABI. O32 and N64 work fine. The same N32 binaries also work fine on native hardware.
diff --git a/results/classifier/gemma3:27b/runtime/922 b/results/classifier/gemma3:27b/runtime/922
new file mode 100644
index 00000000..6078a920
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/922
@@ -0,0 +1,23 @@
+
+
+
+QEMU 7.0.0-rc0: Random segfaults when running grep using qemu-arm-static
+Description of problem:
+I'm running ARM binaries using 32 bit qemu-arm-static on x86_64 host. Sometimes when running grep via qemu, I get a random segmentation fault. Sometimes it happens faster, sometimes it takes several thousand iterations, but sooner or later it happens and really annoying.
+
+This problem is also reproduced on 6.2, 5.2 and 5.1 releases, and NOT reproduced on 5.0
+
+I wrote small test to demonstrate this bug.
+Steps to reproduce:
+1. Download the test environment: [qemu-test-segfault.tar.bz2](/uploads/8f52617d46ba1e5bf29fc273cd07131d/qemu-test-segfault.tar.bz2)
+2. `$ make # To build the docker container`
+3. `$ make shell # To run ARM bash`
+4. Inside a container, run `while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done`. After a while you will get segfault:
+```
+[root@0d81b08f032b /]# /qemu --version
+qemu-arm version 6.2.90
+Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
+[root@0d81b08f032b /]# while true; do /qemu /bin/grep -E f text > /dev/null; [ $? -ne 0 ] && break; done
+Segmentation fault (core dumped)
+[root@0d81b08f032b /]#
+```
diff --git a/results/classifier/gemma3:27b/runtime/939 b/results/classifier/gemma3:27b/runtime/939
new file mode 100644
index 00000000..6525f2ba
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/939
@@ -0,0 +1,78 @@
+
+
+
+qemu-mipsn32el user mode emulator allocates pointers beyond upper memory limit
+Description of problem:
+In qemu-based N32 mips chroots (both BE and LE), I became aware of memory-intensive programs segfaulting, apparently at random. tar, gcc, but only in specific situations. Watching the strace output of gcc, I got the impression that it happens when memory beyond 2Gbyte is allocated. (mips n32 and o32 uses only 31 bit of a pointer, I've been told, so this is somewhat expected, but a segfault is nevertheless wrong.) 
+
+So, I used the following test program, statically linked:
+```
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+
+int main() {
+
+  char *pointer;
+  int i;
+
+  for (i=1; i<301; i++) {
+
+    printf("Allocation %i : ", i);
+    pointer = malloc(20480000 * sizeof(char));
+
+    printf(" pointer is %p, ", pointer);
+
+    if (! pointer) {
+      printf("malloc failed\n");
+      exit(0);
+    };
+
+    memset(pointer, 0xDB, 20480000);
+    printf(" filled\n");
+  }
+};
+```
+
+With mips3 n32 I get the following output:
+```
+pinacolada ~ # file /var/lib/machines/mips64el-n32/root/memtest
+/var/lib/machines/mips64el-n32/root/memtest: ELF 32-bit LSB executable, MIPS, N32 MIPS-III version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
+pinacolada ~ # /usr/bin/qemu-mipsn32el /var/lib/machines/mips64el-n32/root/memtest
+Allocation 1 :  pointer is 0x40802010,  filled
+Allocation 2 :  pointer is 0x41b8b010,  filled
+Allocation 3 :  pointer is 0x42f14010,  filled
+[...]
+Allocation 51 :  pointer is 0x7d8c4010,  filled
+Allocation 52 :  pointer is 0x7ec4d010,  filled
+qemu: unhandled CPU exception 0x15 - aborting
+pc=0x0000000010021944 HI=0x0000000000000004 LO=0x00000000100218f0 ds 02ea 00000000100218f0 0
+GPR00: r0 0000000000000000 at 0000000000000001 v0 000000007ffd6010 v1 0000000026f77200
+GPR04: a0 000000007ffd6010 a1 dbdbdbdbdbdbdbdb a2 0000000001388000 a3 0000000001388000
+GPR08: t0 0000000025252525 t1 0000000025252525 t2 ffffffffffffffff t3 000000001006c369
+GPR12: t4 000000001006c368 t5 0000000000000000 t6 0000000000000000 t7 0000000000000010
+GPR16: s0 0000000000000001 s1 00000000407ffd54 s2 000000001009b270 s3 0000000000000000
+GPR20: s4 0000000010000760 s5 00000000407ffd5c s6 0000000000000000 s7 0000000000000000
+GPR24: t8 0000000000000000 t9 00000000100218f0 k0 0000000000000000 k1 0000000000000000
+GPR28: gp 00000000100a7320 sp 00000000407ffbf0 s8 00000000407ffbf0 ra 0000000010000854
+CP0 Status  0x24800010 Cause   0x00000000 EPC    0x0000000000000000
+    Config0 0x80004482 Config1 0xbe61309b LLAddr 0x0000000000000000
+    Config2 0x80000000 Config3 0x00000000
+    Config4 0x00000000 Config5 0x00000000
+**
+ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu)
+Bail out! ERROR:../accel/tcg/cpu-exec.c:928:cpu_exec: assertion failed: (cpu == current_cpu)
+```
+
+For mips2 o32 I get the more correct looking output
+```
+pinacolada ~ # file /var/lib/machines/mips-o32/root/memtest
+/var/lib/machines/mips-o32/root/memtest: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, not stripped
+pinacolada ~ # /usr/bin/qemu-mips /var/lib/machines/mips-o32/root/memtest
+Allocation 1 :  pointer is 0x3ec76008,  filled
+Allocation 2 :  pointer is 0x3d8ed008,  filled
+Allocation 3 :  pointer is 0x3c564008,  filled
+[...]
+Allocation 104 :  pointer is 0x4082c008,  filled
+Allocation 105 :  pointer is (nil), malloc failed
+```
diff --git a/results/classifier/gemma3:27b/runtime/967 b/results/classifier/gemma3:27b/runtime/967
new file mode 100644
index 00000000..ff15a3c4
--- /dev/null
+++ b/results/classifier/gemma3:27b/runtime/967
@@ -0,0 +1,227 @@
+
+
+
+qemu 6.2 user mode memory leak when mmap + munmap is called
+Description of problem:
+Launch a program with qemu user mode emulator,
+If this program calls mmap to allocate 40GB virtual memory and call munmap to free it later, the memory const of qemu user mode emulator grows to a very big value. 
+
+Excepted behavior: qemu-x86_64 costs very less memory after munmap is called.
+Observed behavior: qemu-x86_64 costs around 2.5GiB after munmap is called. Most of the memory is consumed by [heap].
+Steps to reproduce:
+1.Compile this code with g++.
+```shell
+g++ -o main.bin main.cpp
+```
+```cpp
+#include <chrono>
+#include <cstdio>
+#include <sys/types.h>
+#include <unistd.h>
+#include <cstdlib>
+#include <sys/mman.h>
+
+#include <thread>
+
+static constexpr size_t  pageSize = 4096;
+
+int main(){
+	constexpr size_t size = 1024*100*pageSize*1000;
+
+	void* data = mmap(nullptr, size, PROT_NONE,  MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
+	
+	if(data == nullptr){
+		perror("mmap failed");
+		exit(1);
+	}
+
+	int error = munmap(data, size);
+
+	if(error !=0){
+		perror("munmap failed");
+		exit(1);
+	}
+	
+
+	printf("mmap munmap test done\n");
+	while(true){
+		std::this_thread::sleep_for(std::chrono::seconds(10000));
+	}
+	
+	return 0;
+}
+```
+2. run main.bin with qemu-x86_64
+```shell
+$ qemu-x86_64 ./main.bin
+mmap munmap test done
+```
+3. check memory usage by top
+```
+$ top -p `pgrep "qemu"`
+top - 16:00:39 up  6:41,  1 user,  load average: 0.08, 0.12, 0.10
+Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
+%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
+MiB Mem :  15969.1 total,   8249.3 free,   6048.2 used,   1671.5 buff/cache
+MiB Swap:   2048.0 total,   1209.6 free,    838.4 used.   9544.3 avail Mem 
+
+    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                             
+  38521 jcq       20   0 2634324   2.3g   7840 S   0.0  14.8   0:04.48 qemu-x86_64                                                                                                                         
+```
+
+4. check memory usage by mmap. Heap is 5611ca5e0000-56125d125000, the size of heap is more than 2GiB.
+```shell
+$ cat /proc/38521/maps
+4000000000-4000001000 r--p 00000000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000001000-4000002000 r--p 00001000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000002000-4000003000 r--p 00002000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000003000-4000004000 r--p 00002000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000004000-4000005000 rw-p 00003000 00:35 49812                          /mnt/hgfs/workspace/LearningProjects/CMakeLearn/src/main.bin
+4000005000-4000026000 rw-p 00000000 00:00 0 
+4001005000-4001006000 ---p 00000000 00:00 0 
+4001006000-4001806000 rw-p 00000000 00:00 0 
+4001806000-400183d000 r--p 00000000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+400183d000-400183e000 ---p 00000000 00:00 0 
+400183e000-4001840000 r--p 00037000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+4001840000-4001842000 rw-p 00039000 08:05 4456513                        /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+4001842000-4001844000 rw-p 00000000 00:00 0 
+4001863000-4001a78000 r--p 00000000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a78000-4001a7c000 r--p 00214000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a7c000-4001a7e000 rw-p 00218000 08:05 4456541                        /usr/lib/x86_64-linux-gnu/libc.so.6
+4001a7e000-4001a8d000 rw-p 00000000 00:00 0 
+5611c96af000-5611c9734000 r--p 00000000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9734000-5611c9885000 r-xp 00085000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9885000-5611c9901000 r--p 001d6000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9902000-5611c993c000 r--p 00252000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c993c000-5611c9950000 rw-p 0028c000 08:05 4467878                    /usr/bin/qemu-x86_64
+5611c9950000-5611c996e000 rw-p 00000000 00:00 0 
+5611ca5e0000-56125d125000 rw-p 00000000 00:00 0                          [heap]
+7f2038000000-7f203ffff000 rwxp 00000000 00:00 0 
+7f203ffff000-7f2040000000 ---p 00000000 00:00 0 
+7f2040000000-7f2040021000 rw-p 00000000 00:00 0 
+7f2040021000-7f2044000000 ---p 00000000 00:00 0 
+7f2047def000-7f2047e70000 rw-p 00000000 00:00 0 
+7f2047e70000-7f2047e71000 ---p 00000000 00:00 0 
+7f2047e71000-7f2048676000 rw-p 00000000 00:00 0 
+7f2048676000-7f2048678000 r--p 00000000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048678000-7f204867f000 r-xp 00002000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f204867f000-7f2048680000 r--p 00009000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048680000-7f2048681000 ---p 0000a000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048681000-7f2048682000 r--p 0000a000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048682000-7f2048683000 rw-p 0000b000 08:05 4456538                    /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0
+7f2048683000-7f204868d000 r--p 00000000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f204868d000-7f20486ec000 r-xp 0000a000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f20486ec000-7f2048703000 r--p 00069000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048703000-7f2048704000 r--p 0007f000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048704000-7f2048705000 rw-p 00080000 08:05 4457088                    /usr/lib/x86_64-linux-gnu/libgmp.so.10.4.1
+7f2048705000-7f204870d000 r--p 00000000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204870d000-7f2048720000 r-xp 00008000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f2048720000-7f204874a000 r--p 0001b000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874a000-7f204874b000 ---p 00045000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874b000-7f204874c000 r--p 00045000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874c000-7f204874d000 rw-p 00046000 08:05 4461541                    /usr/lib/x86_64-linux-gnu/libhogweed.so.6.4
+7f204874d000-7f2048757000 r--p 00000000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048757000-7f204877a000 r-xp 0000a000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f204877a000-7f2048790000 r--p 0002d000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048790000-7f2048792000 r--p 00042000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048792000-7f2048793000 rw-p 00044000 08:05 4464736                    /usr/lib/x86_64-linux-gnu/libnettle.so.8.4
+7f2048793000-7f2048795000 rw-p 00000000 00:00 0 
+7f2048795000-7f2048798000 r--p 00000000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f2048798000-7f20487a6000 r-xp 00003000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487a6000-7f20487aa000 r--p 00011000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487aa000-7f20487ab000 ---p 00015000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ab000-7f20487ac000 r--p 00015000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ac000-7f20487ad000 rw-p 00016000 08:05 4459610                    /usr/lib/x86_64-linux-gnu/libtasn1.so.6.6.2
+7f20487ad000-7f20487be000 r--p 00000000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f20487be000-7f20487f4000 r-xp 00011000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f20487f4000-7f2048952000 r--p 00047000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048952000-7f2048956000 r--p 001a5000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048956000-7f2048957000 rw-p 001a9000 08:05 4460136                    /usr/lib/x86_64-linux-gnu/libunistring.so.2.2.0
+7f2048957000-7f2048959000 r--p 00000000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048959000-7f204895d000 r-xp 00002000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f204895d000-7f2048976000 r--p 00006000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048976000-7f2048977000 r--p 0001e000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048977000-7f2048978000 rw-p 0001f000 08:05 4465922                    /usr/lib/x86_64-linux-gnu/libidn2.so.0.3.7
+7f2048978000-7f20489a1000 r--p 00000000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f20489a1000-7f2048a45000 r-xp 00029000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048a45000-7f2048a9f000 r--p 000cd000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048a9f000-7f2048aa9000 r--p 00126000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048aa9000-7f2048ab3000 rw-p 00130000 08:05 4459606                    /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.3.0
+7f2048ab3000-7f2048ab5000 r--p 00000000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048ab5000-7f2048b0a000 r-xp 00002000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b0a000-7f2048b27000 r--p 00057000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b27000-7f2048b28000 r--p 00073000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b28000-7f2048b29000 rw-p 00074000 08:05 4456747                    /usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
+7f2048b29000-7f2048b51000 r--p 00000000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048b51000-7f2048ce6000 r-xp 00028000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048ce6000-7f2048d3e000 r--p 001bd000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d3e000-7f2048d42000 r--p 00214000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d42000-7f2048d44000 rw-p 00218000 08:05 4456541                    /usr/lib/x86_64-linux-gnu/libc.so.6
+7f2048d44000-7f2048d53000 rw-p 00000000 00:00 0 
+7f2048d53000-7f2048d56000 r--p 00000000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d56000-7f2048d6d000 r-xp 00003000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d6d000-7f2048d71000 r--p 0001a000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d71000-7f2048d72000 r--p 0001d000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d72000-7f2048d73000 rw-p 0001e000 08:05 4457972                    /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
+7f2048d73000-7f2048d81000 r--p 00000000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048d81000-7f2048dfd000 r-xp 0000e000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048dfd000-7f2048e58000 r--p 0008a000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e58000-7f2048e59000 r--p 000e4000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e59000-7f2048e5a000 rw-p 000e5000 08:05 4456717                    /usr/lib/x86_64-linux-gnu/libm.so.6
+7f2048e5a000-7f2048e8b000 r--p 00000000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2048e8b000-7f2048fb4000 r-xp 00031000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2048fb4000-7f2049031000 r--p 0015a000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049031000-7f2049041000 r--p 001d6000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049041000-7f2049043000 rw-p 001e6000 08:05 4456481                    /usr/lib/x86_64-linux-gnu/libgnutls.so.30.31.0
+7f2049043000-7f2049045000 rw-p 00000000 00:00 0 
+7f2049045000-7f2049047000 r--p 00000000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f2049047000-7f2049049000 r-xp 00002000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f2049049000-7f204904a000 r--p 00004000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904a000-7f204904b000 r--p 00004000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904b000-7f204904c000 rw-p 00005000 08:05 4465165                    /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.7200.0
+7f204904c000-7f2049069000 r--p 00000000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049069000-7f20490f8000 r-xp 0001d000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f20490f8000-7f2049182000 r--p 000ac000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049182000-7f2049183000 ---p 00136000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049183000-7f2049184000 r--p 00136000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049184000-7f2049185000 rw-p 00137000 08:05 4465132                    /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7200.0
+7f2049185000-7f2049186000 rw-p 00000000 00:00 0 
+7f2049186000-7f2049188000 r--p 00000000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f2049188000-7f204918a000 r-xp 00002000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918a000-7f204918b000 r--p 00004000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918b000-7f204918c000 r--p 00004000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f204918c000-7f204918d000 rw-p 00005000 08:05 4463546                    /usr/lib/x86_64-linux-gnu/liburing.so.2.1.0
+7f20491ac000-7f20491ae000 rw-p 00000000 00:00 0 
+7f20491ae000-7f20491b0000 r--p 00000000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491b0000-7f20491da000 r-xp 00002000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491da000-7f20491e5000 r--p 0002c000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491e6000-7f20491e8000 r--p 00037000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7f20491e8000-7f20491ea000 rw-p 00039000 08:05 4456513                    /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
+7fffe17ee000-7fffe1810000 rw-p 00000000 00:00 0                          [stack]
+7fffe19d1000-7fffe19d5000 r--p 00000000 00:00 0                          [vvar]
+7fffe19d5000-7fffe19d7000 r-xp 00000000 00:00 0                          [vdso]
+ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]
+```
+Additional information:
+qemu is installed by ubuntu's apt.
+
+sudo apt install qemu-user
+
+compiler version:
+```
+g++ --version
+g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
+Copyright (C) 2021 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+```
+
+libc version:
+```
+ldd --version
+ldd (Ubuntu GLIBC 2.35-0ubuntu3) 2.35
+Copyright (C) 2022 Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+Written by Roland McGrath and Ulrich Drepper.
+```