diff options
Diffstat (limited to 'results/classifier/gemma3:12b/manual-review')
115 files changed, 3904 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/manual-review/1006702 b/results/classifier/gemma3:12b/manual-review/1006702 new file mode 100644 index 00000000..ff638a89 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1006702 @@ -0,0 +1,9 @@ + +something wrong in function type_initialize() in object.c in the source code of qemu-1.1.0 + +In the function type_initialize() in file object.c, about line 237, the sentence : + memset((void *)ti->class + class_size, 0, ti->class_size - class_size); +after the + if (type_has_parent(ti)){} +will clean the information copied from the parent in the if block. +I'm wondering whether this will lead to a bug. Thanks. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1086 b/results/classifier/gemma3:12b/manual-review/1086 new file mode 100644 index 00000000..20569306 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1086 @@ -0,0 +1,70 @@ + +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:12b/manual-review/1087 b/results/classifier/gemma3:12b/manual-review/1087 new file mode 100644 index 00000000..95343dc1 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1087 @@ -0,0 +1,2 @@ + +QEMU 7.0.0 fails to build on PowerPC diff --git a/results/classifier/gemma3:12b/manual-review/1097 b/results/classifier/gemma3:12b/manual-review/1097 new file mode 100644 index 00000000..1e51cbc5 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1097 @@ -0,0 +1,2 @@ + +linux-user build broken on 32-bit ppc diff --git a/results/classifier/gemma3:12b/manual-review/1098729 b/results/classifier/gemma3:12b/manual-review/1098729 new file mode 100644 index 00000000..b693708a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1098729 @@ -0,0 +1,44 @@ + +qemu-user-static for armhf: segfault in threaded code + + +Currently running QEMU from git (fedf2de31023) and running the armhf version of qemu-user-static which I have renamed qemu-armhf-static to follow the naming convention used in Debian. + +The host systems is a Debian testing x86_64-linux and I have an Debian testing armhf chroot which I invoke using schroot. + +Majority of program in the armhf chroot run fine, but I'm getting qemu segfaults in multi-threaded programs. + +As an example, I've grabbed the threads demo program here: + + https://computing.llnl.gov/tutorials/pthreads/samples/dotprod_mutex.c + +and changed NUMTHRDS from 4 to 10. I compile it as (same compile command on both x86_64 host and armhf guest): + + gcc -Wall -lpthread dotprod_mutex.c -o dotprod_mutex + +When compiled for x86_64 host it runs perfectly and even under Valgrind displays no errors whatsoever. + +However, when I compile the program in my armhs chroot and run it it usually (but not always) segaults or hangs or crashes. Example output: + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + Thread 0 did 0 to 100000: mysum=100000.000000 global sum=200000.000000 + TCG temporary leak before f6731ca0 + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg-op.h:2371: + tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask & (1 << idx)) == 0' failed. + + + (armhf) $ ./dotprod_mutex + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault + + (armhf) $ ./dotprod_mutex + qemu-arm-static: /home/erikd/Git/qemu-posix-timer-hacking/Upstream/tcg/tcg.c:519: + tcg_temp_free_internal: Assertion `idx >= s->nb_globals && idx < s->nb_temps' failed. + + + (armhf) $ ./dotprod_mutex + Thread 1 did 100000 to 200000: mysum=100000.000000 global sum=100000.000000 + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1100 b/results/classifier/gemma3:12b/manual-review/1100 new file mode 100644 index 00000000..4cd636a7 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1100 @@ -0,0 +1,2 @@ + +It riscv64 platform support user model?? diff --git a/results/classifier/gemma3:12b/manual-review/1130533 b/results/classifier/gemma3:12b/manual-review/1130533 new file mode 100644 index 00000000..5732cb6a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1130533 @@ -0,0 +1,12 @@ + +Documentation cannot be build since commit c70a01e449536c616c85ab820c6fbad7d7e9cf39 + +I tried to build git -based qemu and when documentation is processed I got this error : + +./qemu-options.texi:1526: unknown command `list' +./qemu-options.texi:1526: table requires an argument: the formatter for @item +./qemu-options.texi:1526: warning: @table has text but no @item + +Looks like commit c70a01e449536c616c85ab820c6fbad7d7e9cf39 is guilty ?! + +Or any modification related to documentation, I think. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1188 b/results/classifier/gemma3:12b/manual-review/1188 new file mode 100644 index 00000000..feff171b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1188 @@ -0,0 +1,5 @@ + +qapi: add support to default value for optional members +Additional information: +This is a proposal to the QAPI spec itself to have a simple way to express that +an absent member defaults to a value. diff --git a/results/classifier/gemma3:12b/manual-review/1240 b/results/classifier/gemma3:12b/manual-review/1240 new file mode 100644 index 00000000..4ebcfbdf --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1240 @@ -0,0 +1,16 @@ + +The help document of qemu-nbd misses an option +Description of problem: +The "--help" option of qemu-nbd misses the option "tls-hostname". +Steps to reproduce: +1. For the option "tls-hostname", the following code appears during option parsing and modifies the tlshostname in qemu-nbd.c:760-762. + +``` + case QEMU_NBD_OPT_TLSHOSTNAME: + tlshostname = optarg; + break; +``` +Additional information: +But it does not appear in the document provided by "--help". + +It may prevent users from using the relevant function. diff --git a/results/classifier/gemma3:12b/manual-review/1244 b/results/classifier/gemma3:12b/manual-review/1244 new file mode 100644 index 00000000..6dd64747 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1244 @@ -0,0 +1,46 @@ + +macOS 12.x ld: warning: -undefined dynamic_lookup may not work with chained fixups +Description of problem: +Not sure if this is a serious or negligible problem and if it has any significant runtime implications but reporting it anyway: + +``` +$ ld -v +@(#)PROGRAM:ld PROJECT:ld64-819.6 +BUILD 14:58:44 Aug 5 2022 +configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em +LTO support using: LLVM version 14.0.0, (clang-1400.0.29.102) (static support for 29, runtime is 29) +TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) + +$ ninja -C build +ninja: Entering directory `build' +[314/2946] Linking static target libevent-loop-base.a +warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: archive library: libevent-loop-base.a the table of contents is empty (no object file members in the library define global symbols) +[2044/2946] Generating qemu-system-aarch64 with a custom command +qemu-system-aarch64.tmp: replacing existing signature +[2584/2946] Linking target tests/plugin/libempty.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2585/2946] Linking target tests/plugin/libbb.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2588/2946] Linking target tests/plugin/libinsn.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2589/2946] Linking target tests/plugin/libmem.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2592/2946] Linking target tests/plugin/libsyscall.dylib +ld: warning: -undefined dynamic_lookup may not work with chained fixups +[2946/2946] Linking target tests/qtest/test-arm-mptimer +``` + +I saw a similar discussions in Bazel building system, CPython, and Ruby: +- https://github.com/bazelbuild/bazel/issues/16413 +- https://github.com/python/cpython/issues/97524 +- https://github.com/ruby/ruby/pull/6193 +- https://issues.guix.gnu.org/issue/57849 +Steps to reproduce: +1. ` ./configure --target-list=aarch64-softmmu,arm-softmmu --enable-cocoa --enable-plugins` (note that target list is not that important in this case though) +2. `ninja -C build` +3. Observe the warnings +Additional information: +See "New Features" subsection under "Linking" section for chained fixup +https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-notes for more information: + +> All programs and dylibs built with a deployment target of macOS 12 or iOS 15 or later now use the chained fixups format. This uses different load commands and LINKEDIT data, and won’t run or load on older OS versions. (49851380) diff --git a/results/classifier/gemma3:12b/manual-review/1254828 b/results/classifier/gemma3:12b/manual-review/1254828 new file mode 100644 index 00000000..e2f2ea03 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1254828 @@ -0,0 +1,38 @@ + +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:12b/manual-review/1257099 b/results/classifier/gemma3:12b/manual-review/1257099 new file mode 100644 index 00000000..47d7dddf --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1257099 @@ -0,0 +1,64 @@ + +QEMU fails to build on CentOS 5.10 with relocation R_X86_64_PC32 error + + lt LINK libcacard.la +/usr/bin/ld: libcacard/.libs/vcard.o: relocation R_X86_64_PC32 against `vcard_buffer_response_delete' can not be used when making a shared object; recompile with -fPIC +/usr/bin/ld: final link failed: Bad value +collect2: ld returned 1 exit status +make[4]: *** [libcacard.la] Error 1 +make[3]: *** [subdir-libcacard] Error 2 + +I have bisect'd this to: + +dcs-xen-53:~/qemu>git-bisect next +00c705fb92bc6e69e955aeac3614e05ca02feacd is the first bad commit +commit 00c705fb92bc6e69e955aeac3614e05ca02feacd +Author: Paolo Bonzini <email address hidden> +Date: Tue May 29 11:40:24 2012 +0200 + + build: libcacard Makefile cleanups + + Build vscclient from toplevel Makefile, limit usage of vpath. + + Signed-off-by: Paolo Bonzini <email address hidden> + +:100644 100644 a10005a22fe44a107dfec15106960612b43be71f 1d34b9539e9ba47fdb7028ad0569389fa48712b9 M Makefile +:100644 100644 ae3770a5f718742838844f9064be6a7153ac7469 74110dda7e38b8ddae47a53ad4cb6ecf48231fa0 M Makefile.objs +:100644 100644 3dfdf925fdc2c92239b7053a3d4e09687dcc2171 555894db4aa717f15cfc24093d838131f422fc78 M Makefile.target +:100755 100755 e50ad0bb8fc2e331562f3c09e605af6597a143b1 cd5e8b349c137f621d2e9dc516145bc650d977c0 M configure +:040000 040000 160d565b7e551c3248333c9e49f34edb7a30f5e0 008bc3fccda52f78accf9494539ba62bfb1621a0 M libcacard + +dcs-xen-53:~/qemu>git bisect log +git bisect start +# bad: [7457fe9541b5162f285454947448d553a5d5a531] Update version for v1.7.0-rc2 release +git bisect bad 7457fe9541b5162f285454947448d553a5d5a531 +# good: [ed7ec8400707fe42f4a0f40db2f2d5827ecea789] Merge remote-tracking branch 'bonzini/scsi.2' into staging +git bisect good ed7ec8400707fe42f4a0f40db2f2d5827ecea789 +# bad: [1d31fca470648ec66afd8743491bfb5846306341] qemu-barrier: Fix compilation on i386 hosts +git bisect bad 1d31fca470648ec66afd8743491bfb5846306341 +# good: [9de36b1a7cf61aa8be365f13c81668b3e19fbc7f] Make -machine/-enable-kvm options merge into a single list +git bisect good 9de36b1a7cf61aa8be365f13c81668b3e19fbc7f +# bad: [3edb8f92e8b5f18797693d8ed9fad3962e11e25d] target-s390x: Pass S390CPU to s390_cpu_restart() +git bisect bad 3edb8f92e8b5f18797693d8ed9fad3962e11e25d +# good: [aecff6924dab0197b6c8f132e44502b25fd98a38] hw/arm_gic: Make gic_reset a sysbus reset function +git bisect good aecff6924dab0197b6c8f132e44502b25fd98a38 +# good: [b9531b6eed93c9e1769d6f371c4da5d1f955e0d1] block/qcow2: Add missing GCC_FMT_ATTR to function report_unsupported() +git bisect good b9531b6eed93c9e1769d6f371c4da5d1f955e0d1 +# good: [dd86df756e02b684718dd5378725927361b0ad36] Merge remote-tracking branch 'sstabellini/for_1.1_rc3' into staging +git bisect good dd86df756e02b684718dd5378725927361b0ad36 +# good: [8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83] sun4u: Use cpu_sparc_init() to obtain SPARCCPU +git bisect good 8ebdf9dcc6036171a9f8bac3fe8dc459725a3e83 +# good: [8867aef02e1e5817c72b2e09be4ae952eb0c9d9d] build: move ui/ objects to nested Makefile.objs +git bisect good 8867aef02e1e5817c72b2e09be4ae952eb0c9d9d +# bad: [e8de1ea849176812765bf30514f66c5450a1edc6] target-xtensa: add attributes to helper functions +git bisect bad e8de1ea849176812765bf30514f66c5450a1edc6 +# bad: [fa79c914efd35cb60e0bc18512c03690c48b13e2] Merge remote-tracking branch 'bonzini/nested-makefiles-3' into staging +git bisect bad fa79c914efd35cb60e0bc18512c03690c48b13e2 +# good: [c353f261946ddbd814b333ae2440712b486977fd] build: move per-target hw/ objects to nested Makefile.objs +git bisect good c353f261946ddbd814b333ae2440712b486977fd +# bad: [25f27a4f7160d077d6992e811021b4bc3a82abc1] build: compile oslib-obj-y once +git bisect bad 25f27a4f7160d077d6992e811021b4bc3a82abc1 +# bad: [00c705fb92bc6e69e955aeac3614e05ca02feacd] build: libcacard Makefile cleanups +git bisect bad 00c705fb92bc6e69e955aeac3614e05ca02feacd +# good: [49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45] build: move device tree to per-target Makefile.objs +git bisect good 49ac9e0a8cfb737d6da9c0b056c062e3dec0ba45 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1303926 b/results/classifier/gemma3:12b/manual-review/1303926 new file mode 100644 index 00000000..d35df152 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1303926 @@ -0,0 +1,25 @@ + +qemu-system-x86_64 crashed with SIGABRT + +I've been getting this periodically since my upgrade to qemu 2.0 in trusty this morning. + +ProblemType: Crash +DistroRelease: Ubuntu 14.04 +Package: qemu-system-x86 2.0.0~rc1+dfsg-0ubuntu1 +ProcVersionSignature: Ubuntu 3.13.0-23.45-generic 3.13.8 +Uname: Linux 3.13.0-23-generic x86_64 +ApportVersion: 2.14.1-0ubuntu1 +Architecture: amd64 +Date: Mon Apr 7 13:31:53 2014 +ExecutablePath: /usr/bin/qemu-system-x86_64 +InstallationDate: Installed on 2013-11-26 (131 days ago) +InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1) +ProcEnviron: PATH=(custom, no user) +Registers: No symbol table is loaded. Use the "file" command. +Signal: 6 +SourcePackage: qemu +StacktraceTop: + +Title: qemu-system-x86_64 crashed with SIGABRT +UpgradeStatus: Upgraded to trusty on 2014-01-17 (79 days ago) +UserGroups: \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1310 b/results/classifier/gemma3:12b/manual-review/1310 new file mode 100644 index 00000000..a52d1390 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1310 @@ -0,0 +1,191 @@ + +qemu-nbd export img and detect block if is zero with libnbd +Description of problem: +In our project,we use qemu-nbd to export a img,and use libnbd to read/write data.if the img is preallocated,we wonder the data block if is zero,we use api nbd_block_status in libnbd to get the block status,but it shows server does not support structured replies: Operation not supported.I know our qemu is too old.so,i want to know how can i know if the block in preallocated is zero or not in nbd client. +Steps to reproduce: +1.qemu-nbd -p 8889 -f raw a.img + +2.the nbd client use libnbd,code is: +```c +#include <config.h> + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <assert.h> +#include <stdbool.h> +#include <errno.h> + +#include <libnbd.h> + +static const char *bitmap; + +struct data { + bool req_one; /* input: true if req_one was passed to request */ + int count; /* input: count of expected remaining calls */ + bool fail; /* input: true to return failure */ + bool seen_base; /* output: true if base:allocation encountered */ + bool seen_dirty; /* output: true if qemu:dirty-bitmap encountered */ +}; + +static int +cb (void *opaque, const char *metacontext, uint64_t offset, + uint32_t *entries, size_t len, int *error) +{ + struct data *data = opaque; + + /* libnbd does not actually verify that a server is fully compliant + * to the spec; the asserts marked [qemu-nbd] are thus dependent on + * the fact that qemu-nbd is compliant. Furthermore, qemu 5.2 and + * 6.0 disagree on whether base:allocation includes the hole bit for + * the zeroes at 512k (both answers are compliant); but we care more + * that the zeroes show up in the dirty bitmap + */ + assert (offset == 0); + assert (!*error || (data->fail && data->count == 1 && *error == EPROTO)); + assert (data->count-- > 0); /* [qemu-nbd] */ + + if (strcmp (metacontext, LIBNBD_CONTEXT_BASE_ALLOCATION) == 0) { + assert (!data->seen_base); /* [qemu-nbd] */ + data->seen_base = true; + if (data->req_one) + assert (len == 2); /* [qemu-nbd] */ + else + assert ((len & 1) == 0 && len > 2); /* [qemu-nbd] */ + + /* Data block offset 0 size 128k */ + assert (entries[0] == 131072); assert (entries[1] == 0); + if (!data->req_one) { + if (len == 4) { + /* hole|zero offset 128k size 896k */ + assert (entries[2] == 917504); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + else { + assert (len == 8); + /* hole|zero offset 128k size 384k */ + assert (entries[2] == 393216); + assert (entries[3] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + /* allocated zero offset 512k size 64k */ + assert (entries[4] == 65536); + assert (entries[5] == LIBNBD_STATE_ZERO); + /* hole|zero offset 576k size 448k */ + assert (entries[6] == 458752); + assert (entries[7] == (LIBNBD_STATE_HOLE| + LIBNBD_STATE_ZERO)); + } + } + } + else if (strcmp (metacontext, bitmap) == 0) { + assert (!data->seen_dirty); /* [qemu-nbd] */ + data->seen_dirty = true; + assert (len == (data->req_one ? 2 : 10)); /* [qemu-nbd] */ + + assert (entries[0] == 65536); assert (entries[1] == 0); + if (!data->req_one) { + /* dirty block offset 64K size 64K */ + assert (entries[2] == 65536); assert (entries[3] == 1); + assert (entries[4] == 393216); assert (entries[5] == 0); + /* dirty block offset 512K size 64K */ + assert (entries[6] == 65536); assert (entries[7] == 1); + assert (entries[8] == 458752); assert (entries[9] == 0); + } + } + else { + fprintf (stderr, "unexpected context %s\n", metacontext); + exit (EXIT_FAILURE); + } + + if (data->fail) { + /* Something NBD servers can't send */ + *error = data->count == 1 ? EPROTO : ECONNREFUSED; + return -1; + } + return 0; +} + +int +main (int argc, char *argv[]) +{ + struct nbd_handle *nbd; + int64_t exportsize; + struct data data; + char c; + + if (argc < 3) { + fprintf (stderr, "%s bitmap qemu-nbd [args ...]\n", argv[0]); + exit (EXIT_FAILURE); + } + bitmap = argv[1]; + + nbd = nbd_create (); + if (nbd == NULL) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_add_meta_context (nbd, LIBNBD_CONTEXT_BASE_ALLOCATION); + nbd_add_meta_context (nbd, bitmap); + + if (nbd_connect_tcp (nbd, argv[2],argv[3]) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + exportsize = nbd_get_size (nbd); + if (exportsize == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + data = (struct data) { .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + data = (struct data) { .req_one = true, .count = 2, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + LIBNBD_CMD_FLAG_REQ_ONE) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + assert (data.seen_base && data.seen_dirty); + + /* Trigger a failed callback, to prove connection stays up. */ + data = (struct data) { .count = 2, .fail = true, }; + if (nbd_block_status (nbd, exportsize, 0, + (nbd_extent_callback) { .callback = cb, .user_data = &data }, + 0) != -1) { + fprintf (stderr, "unexpected block status success\n"); + exit (EXIT_FAILURE); + } + assert (nbd_get_errno () == EPROTO && nbd_aio_is_ready (nbd)); + assert (data.seen_base && data.seen_dirty); + + if (nbd_pread (nbd, &c, 1, 0, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + if (nbd_shutdown (nbd, 0) == -1) { + fprintf (stderr, "%s\n", nbd_get_error ()); + exit (EXIT_FAILURE); + } + + nbd_close (nbd); + + exit (EXIT_SUCCESS); +} + +``` +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/manual-review/1324112 b/results/classifier/gemma3:12b/manual-review/1324112 new file mode 100644 index 00000000..bf90897c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1324112 @@ -0,0 +1,23 @@ + +qemu parallel building error on libcacard.la + +hi, + +im building qemu with a large make -j value(9). +sometimes the build fails because of an error: +libtool: link: ar cru .libs/libcacard.a stubs/arch-query-cpu-def.o stubs/clock-warp.o stubs/cpu-get-clock.o stubs/cpu-get-icount.o stubs/dump.o stubs/fdset-add-fd.o stubs/fdset-find-fd.o stubs/fdset-get-fd.o stubs/fdset-remove-fd.o stubs/gdbstub.o stubs/get-fd.o stubs/get-vm-name.o stubs/iothread-lock.o stubs/migr-blocker.o stubs/mon-is-qmp.o stubs/mon-printf.o stubs/mon-print-filename.o stubs/mon-protocol-event.o stubs/mon-set-error.o stubs/pci-drive-hot-add.o stubs/qtest.o stubs/reset.o stubs/runstate-check.o stubs/set-fd-handler.o stubs/slirp.o stubs/sysbus.o stubs/uuid.o stubs/vm-stop.o stubs/vmstate.o stubs/cpus.o stubs/kvm.o libcacard/cac.o libcacard/event.o libcacard/vcard.o libcacard/vreader.o libcacard/vcard_emul_nss.o libcacard/vcard_emul_type.o libcacard/card_7816.o libcacard/vcardt.o util/osdep.o util/cutils.o util/qemu-timer-common.o util/error.o util/qemu-error.o util/oslib-posix.o util/qemu-thread-posix.o trace/generated-events.o trace/default.o trace/control.o trace/generated-tracers.o +ar: trace/generated-events.o: No such file or directory +make[2]: *** [libcacard.la] Error 1 + + +i see the build of generated-events.o in the log before the ar command. +because of the -j it was probably not completed yet. +the generated-events.o build command: +/usr/bin/gcc -I/home/npsdb/qemu/qemu/tcg -I/home/npsdb/qemu/qemu/tcg/i386 -I/home/npsdb/qemu/qemu/linux-headers -I/home/npsdb/qemu/build/linux_x86_64/linux-headers -I. -I/home/npsdb/qemu/qemu -I/home/npsdb/jenkins/qemu/qemu/include -I/home/npsdb/qemu/qemu/libcacard -Itrace -Itrace -fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/libpng12 -I/usr/include/nss3 -I/usr/include/nspr4 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/home/npsdb/qemu/qemu/tests -I qga/qapi-generated -MMD -MP -MT trace/generated-events.o -MF trace/generated-events.d -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g -c -o trace/generated-events.o trace/generated-events.c + + +must be a race condition in the makefile because of a missing dependency. +i tried to find it but it was a little bit complicated to me. + +thanks, +tal \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1357206 b/results/classifier/gemma3:12b/manual-review/1357206 new file mode 100644 index 00000000..7c78e11a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1357206 @@ -0,0 +1,60 @@ + +QEMU user mode still crashes in multi-thread code. + +I compiled the qemu 2.0 release source and find out qemu crashing when emulating multi-thread code in user mode. + +I did a little search and found LP:668799 but it is far from now and it is probably not the problem here. + +I used program below as the test program: + +#include <stdio.h> +#include <stdlib.h> +#include <pthread.h> + +void *print_message_function( void *ptr ); + +main() +{ + pthread_t thread1, thread2; + const char *message1 = "Thread 1"; + const char *message2 = "Thread 2"; + int iret1, iret2; + + /* Create independent threads each of which will execute function */ + + iret1 = pthread_create( &thread1, NULL, print_message_function, (void*) message1); + if(iret1) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret1); + exit(EXIT_FAILURE); + } + + iret2 = pthread_create( &thread2, NULL, print_message_function, (void*) message2); + if(iret2) + { + fprintf(stderr,"Error - pthread_create() return code: %d\n",iret2); + exit(EXIT_FAILURE); + } + + printf("pthread_create() for thread 1 returns: %d\n",iret1); + printf("pthread_create() for thread 2 returns: %d\n",iret2); + + /* Wait till threads are complete before main continues. Unless we */ + /* wait we run the risk of executing an exit which will terminate */ + /* the process and all threads before the threads have completed. */ + + pthread_join( thread1, NULL); + pthread_join( thread2, NULL); + + exit(EXIT_SUCCESS); +} + +void *print_message_function( void *ptr ) +{ + char *message; + message = (char *) ptr; + printf("%s \n", message); +} + +Compiled to i386 and aarch64 object, +and both qemu-i386 and qemu-aarch64 had segmentation faults. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1358287 b/results/classifier/gemma3:12b/manual-review/1358287 new file mode 100644 index 00000000..f71d6fab --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1358287 @@ -0,0 +1,13 @@ + +-readconfig file doesn't interpret memory size correctly + +I'm running Qemu 2.1 and have issues with the config file format. + +Specifically Qemu wrote the following snippet with '-writeconfig': + +[memory] + size = "1024" + +However, upon starting a VM with this setting it only receives 128MiB (the default size). + +I'm reverting back to using the command line option now - that works. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1396497 b/results/classifier/gemma3:12b/manual-review/1396497 new file mode 100644 index 00000000..a61e3bb5 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1396497 @@ -0,0 +1,76 @@ + +'qemu-img snapshot' allows new snapshot to be created with the name of an existing snapshot + +qemu-img _may_ be working as designed, but it feels like this could be a bug. I'd certainly prefer to only allow unique snapshot names (unless maybe something like a "--force-non-unique-snapshot-names" was also specified). + +If this really is correct behaviour, it should be documented as qemu-img(1) currently specifies no details whatsoever regarding expected behaviour or valid snapshot names. + +$ qemu-img snapshot -l image.cow +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +$ qemu-img snapshot -c foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +1 foo 0 2014-11-26 08:30:53 00:00:00.000 +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +2 foo 0 2014-11-26 08:30:58 00:00:00.000 +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +Snapshot list: +ID TAG VM SIZE DATE VM CLOCK +3 foo 0 2014-11-26 08:31:00 00:00:00.000 +$ qemu-img snapshot -d foo image.cow +$ qemu-img snapshot -l image.cow +$ + +Note also how snapshot deletion works in reverse order - the oldest snapshot with a given name is deleted first. + +ProblemType: Bug +DistroRelease: Ubuntu 15.04 +Package: qemu-utils 2.1+dfsg-4ubuntu9 +ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7 +Uname: Linux 3.16.0-25-generic x86_64 +ApportVersion: 2.14.7-0ubuntu10 +Architecture: amd64 +CurrentDesktop: Unity +Date: Wed Nov 26 08:28:16 2014 +InstallationDate: Installed on 2014-04-11 (228 days ago) +InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Daily amd64 (20140409) +KvmCmdLine: + COMMAND STAT EUID RUID PID PPID %CPU COMMAND + kvm-irqfd-clean S< 0 0 719 2 0.0 [kvm-irqfd-clean] +MachineType: LENOVO 20AQCTO1WW +ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7 +SourcePackage: qemu +UpgradeStatus: Upgraded to vivid on 2014-05-08 (201 days ago) +dmi.bios.date: 02/10/2014 +dmi.bios.vendor: LENOVO +dmi.bios.version: GJET71WW (2.21 ) +dmi.board.asset.tag: Not Available +dmi.board.name: 20AQCTO1WW +dmi.board.vendor: LENOVO +dmi.board.version: 0B98405 STD +dmi.chassis.asset.tag: No Asset Information +dmi.chassis.type: 10 +dmi.chassis.vendor: LENOVO +dmi.chassis.version: Not Available +dmi.modalias: dmi:bvnLENOVO:bvrGJET71WW(2.21):bd02/10/2014:svnLENOVO:pn20AQCTO1WW:pvrThinkPadT440s:rvnLENOVO:rn20AQCTO1WW:rvr0B98405STD:cvnLENOVO:ct10:cvrNotAvailable: +dmi.product.name: 20AQCTO1WW +dmi.product.version: ThinkPad T440s +dmi.sys.vendor: LENOVO \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1414 b/results/classifier/gemma3:12b/manual-review/1414 new file mode 100644 index 00000000..e2f39943 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1414 @@ -0,0 +1,21 @@ + +Configure script fix for glib version +Description of problem: +Script "configure" uses "pkg-config" directly, at line 2420: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 + +Because of it, GLIB_VERSION in "config-host.mak" can be taken from host system, under some circumstances (if PKG_CONFIG_PATH is not defined). + +In case of cross-compilation, "**$pkg_config**" should be used instead of "pkg-config", to use pkg-config from cross-compilation toolchain and to take GLIB_VERSION of cross-compiled glib (as it is **correctly used at line 1476**: https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L1476 ). +Steps to reproduce: +1. Do not define PKG_CONFIG_PATH environment variable, use PKG_CONFIG variable instead. +2. Try to ./configure with cross-compiled glib. +3. GLIB_VERSION in config-host.mak will be from host glib. +Additional information: +Change lihe 2420:<br> +https://gitlab.com/qemu-project/qemu/-/blob/f9f0e6173e1d570847930abfe2b4560c7b6a964a/configure#L2420 +<br> +echo "GLIB_VERSION=$(**pkg-config** --modversion glib-2.0)" >> $config_host_mak +<br>to:<br> +echo "GLIB_VERSION=$(**\$pkg_config** --modversion glib-2.0)" >> $config_host_mak + +P.s. Sorry for posting the patch here, GitLab requires signing with a key to push the commit, it's too complicated to post 2-bytes fix. diff --git a/results/classifier/gemma3:12b/manual-review/1457275 b/results/classifier/gemma3:12b/manual-review/1457275 new file mode 100644 index 00000000..80432a85 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1457275 @@ -0,0 +1,106 @@ + +qemu-user hangs in m{,un}map loop + +Gentoo amd64 there, tried both 2.3.0 and eba05e922e8e7f307bc5d4104a78797e55124e97 versions of qemu. Reproduces with qemu-x86_64 as well. + +∞ strace qemu-arm bin/true 2>&1| head -n 100 +execve("/usr/bin/qemu-arm", ["qemu-arm", "bin/true"], [/* 49 vars */]) = 0 +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +brk(0) = 0x62a4d070 +brk(0x62a4e2b0) = 0x62a4e2b0 +arch_prctl(ARCH_SET_FS, 0x62a4d980) = 0 +set_tid_address(0x62a4dc50) = 7841 +set_robust_list(0x62a4dc60, 24) = 0 +rt_sigaction(SIGRTMIN, {0x6011bd10, [], SA_RESTORER|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigaction(SIGRT_1, {0x6011bda0, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x60122710}, NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +readlink("/proc/self/exe", "/usr/bin/qemu-arm", 4096) = 17 +brk(0x62a6f2b0) = 0x62a6f2b0 +brk(0x62a70000) = 0x62a70000 +rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 +mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x2c951ff9000 +mprotect(0x2c951ff9000, 4096, PROT_NONE) = 0 +clone(child_stack=0x2c9527f8df0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c9527f99d0, tls=0x2c9527f9700, child_tidptr=0x2c9527f99d0) = 7842 +rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 +gettimeofday({1432174351, 569148}, NULL) = 0 +getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 +time(NULL) = 1432174351 +openat(AT_FDCWD, "/usr/gnemul/qemu-arm", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) +uname({sysname="Linux", nodename="l29ah-home", ...}) = 0 +mprotect(0x60519000, 33558528, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 +madvise(0x605190b0, 33554432, MADV_HUGEPAGE) = -1 EINVAL (Invalid argument) +mmap(NULL, 50331648, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c94eff9000 +brk(0x62a91000) = 0x62a91000 +mmap(NULL, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x1000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x2000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x3000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x4000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x5000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x6000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x7000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x8000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x9000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xa000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xb000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xc000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xd000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xe000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0xf000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x10000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 +mmap(0x11000, 4143972352, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2c857ff9000 +mmap(0x2c957fe9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2c857ff8000 +munmap(0x2c857ff8000, 4096) = 0 +munmap(0x2c857ff9000, 4143972352) = 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1502 b/results/classifier/gemma3:12b/manual-review/1502 new file mode 100644 index 00000000..04c59bf7 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1502 @@ -0,0 +1,2 @@ + +Usermode qemu-m68k futex crash while running "cmake -E cmake_autogen" diff --git a/results/classifier/gemma3:12b/manual-review/1512 b/results/classifier/gemma3:12b/manual-review/1512 new file mode 100644 index 00000000..7dd6b319 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1512 @@ -0,0 +1,2 @@ + +AVX/AVX2 not correcly detected in user mode diff --git a/results/classifier/gemma3:12b/manual-review/1528 b/results/classifier/gemma3:12b/manual-review/1528 new file mode 100644 index 00000000..3e362e98 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1528 @@ -0,0 +1,10 @@ + +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:12b/manual-review/1531 b/results/classifier/gemma3:12b/manual-review/1531 new file mode 100644 index 00000000..13b4b62a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1531 @@ -0,0 +1,16 @@ + +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/gemma3:12b/manual-review/1600681 b/results/classifier/gemma3:12b/manual-review/1600681 new file mode 100644 index 00000000..0cd7f444 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1600681 @@ -0,0 +1,46 @@ + +Usermode qemu-mips64 does not run on 32 bit i686 hosts + +Hi, + +This issue happens when building Yocto project on i686 hosts. + +Yocto version: 2.1 (krogoth branch) +qemu: 2.5 +gobject-introspection: 1.46 + +and +Yocto version: 2.2 (master/branch) +qemu: 2.6 +gobject-introspection: 1.48 + +Host: Fedora 23 (i686) or Debian 8 (i686) + +Steps: +1. Set MACHINE = "qemumips64" +2. Run bitbake gobject-introspection + +I got some errors like below: + +env PATH=".libs:/buildarea/poky/build/tmp/sysroots-uninative/i686-linux/usr/bin:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin/python3-native:/buildarea/p oky/scripts:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin/mips64-poky-linux:/buildarea/poky/build/tmp/sysroots/qemumips64/usr/bin/crossscripts:/buildarea /poky/build/tmp/sysroots/i686-linux/usr/sbin:/buildarea/poky/build/tmp/sysroots/i686-linux/usr/bin:/buildarea/poky/build/tmp/sysroots/i686-linux/sbin:/buildarea/ poky/build/tmp/sysroots/i686-linux/bin:/buildarea/poky/scripts:/buildarea/poky/bitbake/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" /buildarea/p oky/build/tmp/work/mips64-poky-linux/gobject-introspection/1.48.0-r0/build/g-ir-scanner-qemuwrapper ./.libs/g-ir-compiler --includedir=../gobject-introspection-1 .48.0 --includedir=../gobject-introspection-1.48.0/gir --includedir=. --includedir=. --includedir=./gir --includedir=. ../gobject-introspection-1.48.0/gir/freety pe2-2.0.gir -o gir/freetype2-2.0.typelib +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/fontconfig-2.0.typelib' failed +make[2]: *** [gir/fontconfig-2.0.typelib] Error 1 +make[2]: *** Waiting for unfinished jobs.... +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/freetype2-2.0.typelib' failed +make[2]: *** [gir/freetype2-2.0.typelib] Error 1 +./.libs/g-ir-compiler: Address overflow loading ELF binary +If the above error message is about missing .so libraries, then setting up GIR_EXTRA_LIBS_PATH in the recipe should help. +(typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" ) +Makefile:3528: recipe for target 'gir/DBus-1.0.typelib' failed +make[2]: *** [gir/DBus-1.0.typelib] Error 1 + + +You can check Yocto bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=9285 + +I attached the full compile log. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1636 b/results/classifier/gemma3:12b/manual-review/1636 new file mode 100644 index 00000000..132736ef --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1636 @@ -0,0 +1,103 @@ + +RISCV: Interrupt not cleared correctly (supervisor external IRQ) +Description of problem: + +Steps to reproduce: +1. Set mie -> 0 +2. Assert all interrupt sources which can be taken in M-mode (i.e. set mei, msi, mti, sei, ssi, sti) +3. I'm using the imsic for the external interrupts and the clint for timer interrupts. +4. Once all IRQs are pending set mie -> 0xFFFF +5. IRQs are taken one by one, all M-level IRQs are cleared without issues. +6. The issue occurs when trying to clear the S-external IRQ, when writing stopei to clear the IRQ mip is not updated correctly. + +I believe I have located the issue in target/riscv/cpu.c:1314 + +**Old code:** +``` +riscv_cpu_update_mip(cpu, 1 << irq, + BOOL_TO_MASK(level | env->software_seip)); +``` +**Changed code:** +``` +riscv_cpu_update_mip(cpu, 1 << irq, + BOOL_TO_MASK(level)); +``` + +When we reach the next code snippet (cpu_helper.c:628) we enter cpu_interrupt instead of cpu_reset_interrupt and thus end up in an infinite loop since the imsic message from that point on will be 0. It looks weird to me to use env->software_seip and not env->external_seip, in any case I changed it to BOOL_TO_MASK(level) and I now see the behavior I expect from my test program. + +```c + env->mip = (env->mip & ~mask) | (value & mask); + + if (env->mip | vsgein | vstip) { + cpu_interrupt(cs, CPU_INTERRUPT_HARD); + } else { + cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD); + } + +``` +Additional information: +Log when getting the error. +``` +TRACE: [src/hart_ctrl.c:35] STARTING CPU 0 +DEBUG: [src/trap_handling.c: 938] Setting up trap handlers +TRACE: [src/page_tables.c:341] Setting up page tables between 0x80000000 -> 0x81c00000 +TRACE: [src/page_tables.c:355] Setting up page tables for UART 0x10000000 +TRACE: [src/page_tables.c:365] Setting up page tables for CLINT 0x2000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x24000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28000000 +DEBUG: [src/page_tables.c: 383] Mapping IMISIC 0x28001000 +DEBUG: [src/util_fn.c: 339] Setting satp: 0x8000100000081017 +DEBUG: [src/util_fn.c: 342] Setting hgatp: 0x8000000000081014 +TRACE: [src/main.c:40] Asserting M-level interrupts simultaneously +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine external interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine software interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause machine timer interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor external interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor software interrupt +DEBUG: [src/irq_trigger.c: 121] Setting inteded cause to: Cause supervisor timer interrupt +riscv_cpu_do_interrupt: hart:0, async:1, cause:000000000000000b, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_external +DEBUG: [src/trap_handling.c: 315] mtvec_mei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine external interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000003, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_software +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine software interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine software interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000007, epc:0x0000000080004d80, tval:0x0000000000000000, desc=m_timer +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause machine timer interrupt +DEBUG: [src/trap_handling.c: 76] Cause machine timer interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external +DEBUG: [src/trap_handling.c: 296] mtvec_sei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause supervisor external interrupt +DEBUG: [src/trap_handling.c: 76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +mip + ssip (1) = 1 + vssip(2) = 0 + msip (3) = 0 + stip (5) = 1 + vstip(6) = 0 + mtip (7) = 0 + seip (9) = 1 + vseip(10) = 0 + meip (11) = 0 + sgeip(12) = 0 +DEBUG: [src/aia_ctrl.c: 339] Writing stopei -> 0 +DEBUG: [src/aia_ctrl.c: 344] stopei = 0x0000000000000000 +DEBUG: [src/aia_ctrl.c: 352] Popped IMSIC message = 1 +mip + ssip (1) = 1 + vssip(2) = 0 + msip (3) = 0 + stip (5) = 1 + vstip(6) = 0 + mtip (7) = 0 + seip (9) = 1 + vseip(10) = 0 + meip (11) = 0 + sgeip(12) = 0 +riscv_cpu_do_interrupt: hart:0, async:1, cause:0000000000000009, epc:0x0000000080004d80, tval:0x0000000000000000, desc=s_external +DEBUG: [src/trap_handling.c: 296] mtvec_sei +DEBUG: [src/trap_handling.c: 65] Cause to check is currently Cause supervisor software interrupt +DEBUG: [src/trap_handling.c: 76] Cause supervisor external interrupt exception: MEPC = 0x80004d80, MTVAL = 0x0 +ERROR: [src/trap_handling.c:121] The following assert failed: masked_cause == cause2check +masked_cause = 9 diff --git a/results/classifier/gemma3:12b/manual-review/1650175 b/results/classifier/gemma3:12b/manual-review/1650175 new file mode 100644 index 00000000..1f463a97 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1650175 @@ -0,0 +1,6 @@ + +wrong version in 2.8.0-rc03 + +When you compile qemu the version still 2.7.93 instead 2.8.0-rc03 + +build/config-host.mak:VERSION=2.7.93 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1660599 b/results/classifier/gemma3:12b/manual-review/1660599 new file mode 100644 index 00000000..8465a831 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1660599 @@ -0,0 +1,6 @@ + +v2.8.0 won't compile if g++ compiler doesn't understand "-fstack-protector-strong" + +For example, Ubuntu Trusty (LTS 14.04) uses g++ v4.8.5. +Compilation fails with a syntax error saying that the ""-fstack-protector-strong" option in g++ is unrecognized. +Instead, under Ubuntu Xenial (LTS 16.04), the g++ compiler is v5.4.0 and the compilation goes on smoothly. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1668 b/results/classifier/gemma3:12b/manual-review/1668 new file mode 100644 index 00000000..5dd16e87 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1668 @@ -0,0 +1,46 @@ + +Fedora 38 build of clang 16 fails when run under s390x emulation (both system & linux-user) +Description of problem: +Spawn a Fedora 38 container using `s390x` linux-user based emulation + +``` +$ podman run -it --platform linux/s390x fedora:latest +``` + +Install clang inside it + +``` +sh-5.2# dnf -y install clang +``` + +Try to run clang + +``` +sh-5.2# clang --version +clang version 16.0.4 (Fedora 16.0.4-1.fc38) +Target: s390x-redhat-linux-gnu +Thread model: posix +InstalledDir: /usr/bin +sh-5.2# clang --help +clang-16: error: unsupported option '--help'; did you mean '--help'? +clang-16: error: no input files +``` + +Notice the nonsense error message when requesting `--help`. With Fedora 37 build of clang 15 (compiled with gcc 12), under s390x emulation, `--help` will correctly print the help. In fact all options except for `--version` appear to be broken: + +``` +sh-5.2# echo "void foo(void) {}" > foo.c +sh-5.2# clang -c foo.c +clang-16: error: unknown argument: '-c' +``` + + +IOW, there appears to be something in the clang 16 (compiled with gcc 13) in Fedora 38 that is tripping up s390x emulation. + +It is unclear whether the trigger was from building clang 16 with a newer gcc 13, or whether something changed from clang 15 -> 16. + +Originally reported with qemu-user-static-7.2.1-1.fc38.x86_64, but I've reproduced with QEMU upstream 7.1.0 release and QEMU upstream git master (v8.0.0-394-gc2b7158455) + +This was originally reported in Fedora at + + https://bugzilla.redhat.com/show_bug.cgi?id=2209635 diff --git a/results/classifier/gemma3:12b/manual-review/1696773 b/results/classifier/gemma3:12b/manual-review/1696773 new file mode 100644 index 00000000..c16cc471 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1696773 @@ -0,0 +1,8 @@ + +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:12b/manual-review/1712027 b/results/classifier/gemma3:12b/manual-review/1712027 new file mode 100644 index 00000000..8e79c35f --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1712027 @@ -0,0 +1,46 @@ + +qemu: Cryptography adding encrypted disk with luks format failed + +I'm using libvirt to attach luks encrypted disk to a running VM. The qemu-monitor-command like the + +following: + +{"execute":"object-add","arguments":{"qom-type":"secret","id":"virtio-disk11-luks-secret0","props":{"data":"El7jOYLCZwrij2Mue0q2tA==","keyid":"masterKey0","iv":"J2je0WJjCa89L3iKc1lceg==","format":"base64"}} + +the masterKey0 specify the secret which has been created before. + +command above return with error message "Incorrect number of padding bytes XXX found on decrypted + +data". This is triggered by the following code snippets in qemu/crypto/secret.c: + +if (plaintext[ciphertextlen - 1] > 16 || + plaintext[ciphertextlen - 1] > ciphertextlen) { + error_setg(errp, "Incorrect number of padding bytes (%d) " + "found on decrypted data", + (int)plaintext[ciphertextlen - 1]); + … + } + +The bug is: There is on padding in plaintext if the actual length of the plaintext decrypted is + +equal to ciphertext. + +In this case, the last element in plaintext array may be one of the character in base64 code table + +or other. + +I would like to know why length of padding bytes cannot exceed 16 and whether i can remove + +judement: “plaintext[ciphertextlen - 1] > 16” so that I can eliminate the error above. + +Much appreciate it if doubts above is cleared up. + +libvirt/qemu version: + +# virsh version +Compiled against library: libvirt 3.0.0 +Using library: libvirt 3.0.0 +Using API: QEMU 3.0.0 +Running hypervisor: QEMU 2.7.1 + +OS: Ubuntu 12.04 LTS \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1716292 b/results/classifier/gemma3:12b/manual-review/1716292 new file mode 100644 index 00000000..8c339b7a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1716292 @@ -0,0 +1,31 @@ + +User mode emulation returns wrong value for write(fd, NULL, 0) + +QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c) +OS version: Ubuntu 14.04.3 +Configured with: ../configure --target-list=x86_64-linux-user + +QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1. + +I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case: + +zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c +#include <stdio.h> +#include <unistd.h> +#include <fcntl.h> + +int main() { + ssize_t ret = write(STDOUT_FILENO, NULL, 0); + fprintf(stderr, "write returned %ld\n", ret); + return 0; +} +zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c +zhuowei@zhuowei-tablet:/tmp$ uname -a +Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux +zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes +write returned 0 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes +write returned -1 +zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version +qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1728325 b/results/classifier/gemma3:12b/manual-review/1728325 new file mode 100644 index 00000000..9caa818a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1728325 @@ -0,0 +1,61 @@ + +POWER8: Wrong behaviour with float-to-int punning + +Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8' produces wrong results at runtime. I don't think gcc is at fault here. + +--- +#include <stdio.h> + +int getWord(const float x) +{ + return *(int*)&x; +} + +void main() +{ + int foo = getWord(+123.456f); + int bar = getWord(-123.456f); + + printf("%d\n", foo); + printf("%d\n", bar); + return; +} +--- + +This prints: +--- +0 +0 +--- + +Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the expected result: +--- +1123477881 +-1024005767 +--- + + +The different between the two programs is: + +--- power7.s ++++ power8.s +@@ -6,9 +6,9 @@ + .globl getWord + .type getWord, @function + getWord: +- stfs 1,-16(1) +- ori 2,2,0 +- lwa 3,-16(1) ++ xscvdpspn 0,1 ++ mfvsrwz 3,0 ++ extsw 3,3 + blr + .long 0 + .byte 0,0,0,0,0,0,0,0 + .size getWord,.-getWord + + +Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly. + +https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40 +https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1731277 b/results/classifier/gemma3:12b/manual-review/1731277 new file mode 100644 index 00000000..e272040b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1731277 @@ -0,0 +1,32 @@ + +Provide target specific qemu man pages + +Right now, all qemu target binaries (qemu-system-...) share the same man page. + +The current man page is primarily focused on x86, and therefore the information given is entirely wrong for e.g. arm, powerpc or s390x. + +NAME + qemu-doc - QEMU Emulator User Documentation + +SYNOPSIS + qemu-system-i386 [options] [disk_image] + +DESCRIPTION + The QEMU PC System emulator simulates the following peripherals: + + - i440FX host PCI bridge and PIIX3 PCI to ISA bridge + + - Cirrus CLGD 5446 PCI VGA card or dummy VGA card with Bochs VESA extensions (hardware level, including all non + standard modes). + + - PS/2 mouse and keyboard + + - 2 PCI IDE interfaces with hard disk and CD-ROM support + + - Floppy disk + +... + +We should have target specific man pages, with the common options/settings factored out, so they are included in all target specific man pages. + +"man qemu-system-s390x" should give s390x specific (+common) information and "man qemu-system-x86_64" should contain x86 specific (+common) information. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1753437 b/results/classifier/gemma3:12b/manual-review/1753437 new file mode 100644 index 00000000..47a5c17d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1753437 @@ -0,0 +1,15 @@ + +pc-bios/s390-ccw/libc: size_t should be unsigned + +qemu/pc-bios/s390-ccw/libc.c:82]: (style) Unsigned variable 'num_idx' can't be negative so it is unnecessary to test it. + +Source code is + + + while (num_idx >= 0) { + +but + + size_t num_idx = 1; /* account for NUL */ + +So there is no escape from the while loop. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1754295 b/results/classifier/gemma3:12b/manual-review/1754295 new file mode 100644 index 00000000..6a523ac9 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1754295 @@ -0,0 +1,17 @@ + +Incorrect en-us keymap in QEMU 2.11 + +I'm using the latest Arch Linux installation ISO as a live system and start QEMU with the following command: + +$ qemu-system-x86_64 -enable-kvm -boot d -cdrom ~/isos/archlinux-2018.03.01-x86_64.iso -m 512 -vnc :0 -k en-us + +Then I use Vinagre to connect to the guest system, boot the default bootloader option, and type the character '<' at the command prompt. The guest prints the character '>' instead of the '<' I typed. + +I believe this is caused by the updated en-us keymap in QEMU 2.11. [1] + +If I start QEMU with `-k en-gb` (or without the -k switch at all), I can type '<' and get the same character to appear on the guest's command line. The issue happens with the updated en-us keymap. It is also fixed if I replace /usr/share/qemu/keymaps/en-us with the old keymap file (before commit a7815faf). + +This problem was originally reported against Packer because we were seeing '>' characters in place of '<' when using it with the QEMU builder. [2] + +[1] https://github.com/qemu/qemu/commit/a7815faffb2bd594b92aa3542d7b799cc89c5414 +[2] https://github.com/hashicorp/packer/issues/5769 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1759264 b/results/classifier/gemma3:12b/manual-review/1759264 new file mode 100644 index 00000000..ddf635d2 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1759264 @@ -0,0 +1,9 @@ + +fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns + +After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered. + +helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity. + +The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However, +I'm not sure if this breaks other targets and I have no easy way to test it. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1774412 b/results/classifier/gemma3:12b/manual-review/1774412 new file mode 100644 index 00000000..e7ae56a4 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1774412 @@ -0,0 +1,11 @@ + +-icount sleep=on|off documentation is confusing + +The documentation for the -icount option in the qemu man page says: + +"When the virtual cpu is sleeping, the virtual time will advance at default speed unless sleep=on|off is specified. With sleep=on|off, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode and will not advance if no timer is enabled." + +Taking this literally and specifying "sleep=on|off" on the command line does not work, so presumably the two instances of "sleep=on|off" should be either "sleep=on" or "sleep=off", +whichever is correct :) + +Also, the synopsis line "-icount [shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot" fails to mention the sleep keyword at all. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1776096 b/results/classifier/gemma3:12b/manual-review/1776096 new file mode 100644 index 00000000..bb806712 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1776096 @@ -0,0 +1,61 @@ + +qemu 2.12.0 qemu-system-ppc illegal instruction on ppc64le, crashes emulator + +% uname -a +Linux tim.floodgap.com 4.16.14-300.fc28.ppc64le #1 SMP Tue Jun 5 15:59:48 UTC 2018 ppc64le ppc64le ppc64le GNU/Linux + +STR: +Start QEMU and boot Mac OS X 10.4.11. +Download the current version of TenFourFox (I used G3 so that AltiVec was not a confounder). +Try to start TenFourFox in safe mode (hold down Option as you double-click while the icon bounces in the Dock). + +Expected: +TenFourFox starts. + +Actual: +The entire emulator exits with an illegal instruction error. + +Trace of session (including some disassembly so you can see where TCG went wrong): + +tim:/home/spectre/src/qemu-2.12.0/ppc-softmmu/% gdb --args ./qemu-system-ppc -M mac99,accel=tcg -m 2048 -prom-env boot-args=-v -boot c -drive file=tigerhd.img,format=raw,cache=none -netdev user,id=mynet0 -device usb-net,netdev=mynet0 -usb -device usb-tablet + +GNU gdb (GDB) Fedora 8.1-15.fc28 +[...] +Reading symbols from ./qemu-system-ppc...done. +(gdb) run +[...] + +Thread 6 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault. +[Switching to Thread 0x7ffff242ea30 (LWP 7017)] +0xfffffffffffffffc in ?? () +#0 0xfffffffffffffffc in () +#1 0x00007fffd4edec00 in code_gen_buffer () +#2 0x00000000100c9e20 in cpu_tb_exec (itb=<optimized out>, cpu=<optimized out>) at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:169 +#3 0x00000000100c9e20 in cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:626 +#4 0x00000000100c9e20 in cpu_exec (cpu=<optimized out>) + at /home/spectre/src/qemu-2.12.0/accel/tcg/cpu-exec.c:734 +#5 0x000000001007decc in tcg_cpu_exec (cpu=0x11774e10) + at /home/spectre/src/qemu-2.12.0/cpus.c:1362 +(gdb) disas 0x00007fffd4edebf0, 0x00007fffd4edec10 +Dump of assembler code from 0x7fffd4edebf0 to 0x7fffd4edec10: + 0x00007fffd4edebf0 <code_gen_buffer+284027700>: addi r0,r4,3 + 0x00007fffd4edebf4 <code_gen_buffer+284027704>: rlwinm r0,r0,0,0,19 + 0x00007fffd4edebf8 <code_gen_buffer+284027708>: cmplw cr7,r0,r12 + 0x00007fffd4edebfc <code_gen_buffer+284027712>: bnel cr7,0x7fffd4ed8b64 <code_gen_buffer+284002984> + 0x00007fffd4edec00 <code_gen_buffer+284027716>: lwbrx r14,r3,r4 + 0x00007fffd4edec04 <code_gen_buffer+284027720>: stw r14,40(r27) + 0x00007fffd4edec08 <code_gen_buffer+284027724>: clrldi r4,r14,32 + 0x00007fffd4edec0c <code_gen_buffer+284027728>: rlwinm r3,r4,25,19,26 +End of assembler dump. +(gdb) disas 0x7fffd4ed8b60, 0x7fffd4ed8b70 +Dump of assembler code from 0x7fffd4ed8b60 to 0x7fffd4ed8b70: + 0x00007fffd4ed8b60 <code_gen_buffer+284002980>: bctrl + 0x00007fffd4ed8b64 <code_gen_buffer+284002984>: mtctr r3 + 0x00007fffd4ed8b68 <code_gen_buffer+284002988>: mr r31,r3 + 0x00007fffd4ed8b6c <code_gen_buffer+284002992>: li r3,0 +End of assembler dump. +(gdb) i reg ctr +ctr 0xffffffffffffffff 18446744073709551615 + +It appears that the branch at 0x00007fffd4edebfc caused a jump back (a return?) through CTR, but CTR has -1 in it, hence setting PC to 0xfffffffffffffffc. I am not sure how to debug this further. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1783362 b/results/classifier/gemma3:12b/manual-review/1783362 new file mode 100644 index 00000000..fef58cff --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1783362 @@ -0,0 +1,48 @@ + +qemu-user: mmap should return failure (MAP_FAILED, -1) instead of success (NULL, 0) when len==0 + +As shown in https://github.com/beehive-lab/mambo/issues/19#issuecomment-407420602, with len==0 mmap returns success (NULL, 0) instead of failure (MAP_FAILED, -1) in a x86_64 host executing a ELF 64-bit LSB executable, ARM aarch64 binary. + +Steps to reproduce the bug: + +- (cross-)compile the attached source file: + +$ aarch64-linux-gnu-gcc -static -std=gnu99 -lpthread test/mmap_qemu.c -o mmap_qemu + +- Execute in a x86_64 host with qemu-user and qemu-user-binfmt: + +$ ./mmap_qemu +alloc: 0 +MAP_FAILED: -1 +errno: 0 +mmap_qemu: test/mmap_qemu.c:15: main: Assertion `alloc == MAP_FAILED' failed. +qemu: uncaught target signal 6 (Aborted) - core dumped +Aborted (core dumped) + +- Execute in a ARM host without any additional dependecy: + +$ ./mmap_qemu +alloc: -1 +MAP_FAILED: -1 +errno: 22 + +The bug is present in Fedora: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.11.2(qemu-2.11.2-1.fc28) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.17.7-200.fc28.x86_64 + +And also in Ubuntu: + +$ qemu-aarch64 --version +qemu-aarch64 version 2.12.0 (Debian 1:2.12+dfsg-3ubuntu3) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +$ uname -r +4.15.0-23-generic + +Possibly related to: + +- https://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029109.html +- https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203852 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1785670 b/results/classifier/gemma3:12b/manual-review/1785670 new file mode 100644 index 00000000..af029de2 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1785670 @@ -0,0 +1,297 @@ + +Guest(ubuntu 18.04) crashes when trying uploading file + +I speficy slirp network, and I can open websites, git clone repos. But when I try to upload a file to slack, or try to do a git push, it crashes. + +My host is ubuntu 16.04 with kernel 4.15.0-29-generic, and qemu is latest source in git(commit 1fb57da72ae0886e). The command I use is + +./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm -m 2048 -drive file=../qcow2/guest.qcow2 -netdev user,id=realnet0 -device e1000e,netdev=realnet0 + +The trace is as follows + +*** Error in `./x86_64-softmmu/qemu-system-x86_64': free(): invalid next size (normal): 0x00007f66d80b7300 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f66fb7967e5] +/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f66fb79f37a] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f66fb7a353c] +./x86_64-softmmu/qemu-system-x86_64(+0x6a8549)[0x55dc10c7d549] +./x86_64-softmmu/qemu-system-x86_64(+0x6a99d4)[0x55dc10c7e9d4] +./x86_64-softmmu/qemu-system-x86_64(+0x6ad09a)[0x55dc10c8209a] +./x86_64-softmmu/qemu-system-x86_64(+0x6a3feb)[0x55dc10c78feb] +./x86_64-softmmu/qemu-system-x86_64(+0x6a746e)[0x55dc10c7c46e] +./x86_64-softmmu/qemu-system-x86_64(+0x68fe2c)[0x55dc10c64e2c] +./x86_64-softmmu/qemu-system-x86_64(+0x685b3b)[0x55dc10c5ab3b] +./x86_64-softmmu/qemu-system-x86_64(+0x685bfd)[0x55dc10c5abfd] +./x86_64-softmmu/qemu-system-x86_64(+0x6885a8)[0x55dc10c5d5a8] +./x86_64-softmmu/qemu-system-x86_64(+0x688717)[0x55dc10c5d717] +./x86_64-softmmu/qemu-system-x86_64(+0x685d27)[0x55dc10c5ad27] +./x86_64-softmmu/qemu-system-x86_64(+0x685d54)[0x55dc10c5ad54] +./x86_64-softmmu/qemu-system-x86_64(+0x586bb8)[0x55dc10b5bbb8] +./x86_64-softmmu/qemu-system-x86_64(+0x586d92)[0x55dc10b5bd92] +./x86_64-softmmu/qemu-system-x86_64(+0x586ecd)[0x55dc10b5becd] +./x86_64-softmmu/qemu-system-x86_64(+0x593ea8)[0x55dc10b68ea8] +./x86_64-softmmu/qemu-system-x86_64(+0x59419d)[0x55dc10b6919d] +./x86_64-softmmu/qemu-system-x86_64(+0x5947df)[0x55dc10b697df] +./x86_64-softmmu/qemu-system-x86_64(+0x597ddf)[0x55dc10b6cddf] +./x86_64-softmmu/qemu-system-x86_64(+0x5989e7)[0x55dc10b6d9e7] +./x86_64-softmmu/qemu-system-x86_64(+0x58ae11)[0x55dc10b5fe11] +./x86_64-softmmu/qemu-system-x86_64(+0x30d4f6)[0x55dc108e24f6] +./x86_64-softmmu/qemu-system-x86_64(+0x30d70e)[0x55dc108e270e] +./x86_64-softmmu/qemu-system-x86_64(+0x310336)[0x55dc108e5336] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac368)[0x55dc10881368] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac4b2)[0x55dc108814b2] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac7b8)[0x55dc108817b8] +./x86_64-softmmu/qemu-system-x86_64(+0x2ac809)[0x55dc10881809] +./x86_64-softmmu/qemu-system-x86_64(+0x32b673)[0x55dc10900673] +./x86_64-softmmu/qemu-system-x86_64(+0x2f2875)[0x55dc108c7875] +./x86_64-softmmu/qemu-system-x86_64(+0x81b91c)[0x55dc10df091c] +/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f66fbaf06ba] +/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f66fb82641d] +======= Memory map: ======== +55dc105d5000-55dc112a9000 r-xp 00000000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc114a9000-55dc115bd000 r--p 00cd4000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc115bd000-55dc11773000 rw-p 00de8000 103:02 5767220 /home/biggerfish/src/qemu/x86_64-softmmu/qemu-system-x86_64 +55dc11773000-55dc117b5000 rw-p 00000000 00:00 0 +55dc134d6000-55dc14e20000 rw-p 00000000 00:00 0 [heap] +7f6634000000-7f6634021000 rw-p 00000000 00:00 0 +7f6634021000-7f6638000000 ---p 00000000 00:00 0 +7f663c000000-7f663c021000 rw-p 00000000 00:00 0 +7f663c021000-7f6640000000 ---p 00000000 00:00 0 +7f6642000000-7f6644000000 rw-s 00000000 00:05 4882443 /SYSV00000000 (deleted) +7f6644000000-7f6644021000 rw-p 00000000 00:00 0 +7f6644021000-7f6648000000 ---p 00000000 00:00 0 +7f66491cc000-7f66491cd000 ---p 00000000 00:00 0 +7f66491cd000-7f66499cd000 rw-p 00000000 00:00 0 +7f66499cd000-7f66499ce000 ---p 00000000 00:00 0 +7f66499ce000-7f664a1ce000 rw-p 00000000 00:00 0 +7f664a1ce000-7f664a1cf000 ---p 00000000 00:00 0 +7f664a1cf000-7f664a9cf000 rw-p 00000000 00:00 0 +7f664a9cf000-7f664a9d0000 ---p 00000000 00:00 0 +7f664a9d0000-7f664b1d0000 rw-p 00000000 00:00 0 +7f664b1d0000-7f664b1d1000 ---p 00000000 00:00 0 +7f664b1d1000-7f664b9d1000 rw-p 00000000 00:00 0 +7f664b9d1000-7f664b9d2000 ---p 00000000 00:00 0 +7f664b9d2000-7f664bad2000 rw-p 00000000 00:00 0 +7f664bad2000-7f664bad3000 ---p 00000000 00:00 0 +7f664bad3000-7f664bbd3000 rw-p 00000000 00:00 0 +7f664bbd3000-7f664bbd4000 ---p 00000000 00:00 0 +7f664bbd4000-7f664bcd4000 rw-p 00000000 00:00 0 +7f664bcd4000-7f664bcd5000 ---p 00000000 00:00 0 +7f664bcd5000-7f664c4d5000 rw-p 00000000 00:00 0 +7f664c4d5000-7f664c4d6000 ---p 00000000 00:00 0 +7f664c4d6000-7f664c5d6000 rw-p 00000000 00:00 0 +7f664c5d6000-7f664c5d7000 ---p 00000000 00:00 0 +7f664c5d7000-7f664c6d7000 rw-p 00000000 00:00 0 +7f664c6d7000-7f664c6d8000 ---p 00000000 00:00 0 +7f664c6d8000-7f664c7d8000 rw-p 00000000 00:00 0 +7f664c7d8000-7f664c7d9000 ---p 00000000 00:00 0 +7f664c7d9000-7f664c8d9000 rw-p 00000000 00:00 0 +7f664c8d9000-7f664c8da000 ---p 00000000 00:00 0 +7f664c8da000-7f664c9da000 rw-p 00000000 00:00 0 +7f664c9da000-7f664c9db000 ---p 00000000 00:00 0 +7f664c9db000-7f664cadb000 rw-p 00000000 00:00 0 +7f664cadb000-7f664cadc000 ---p 00000000 00:00 0 +7f664cadc000-7f664cbdc000 rw-p 00000000 00:00 0 +7f664cbdc000-7f664cbdd000 ---p 00000000 00:00 0 +7f664cbdd000-7f664ccdd000 rw-p 00000000 00:00 0 +7f664ccdd000-7f664ccde000 ---p 00000000 00:00 0 +7f664ccde000-7f664cdde000 rw-p 00000000 00:00 0 +7f664cdde000-7f664cddf000 ---p 00000000 00:00 0 +7f664cddf000-7f664cedf000 rw-p 00000000 00:00 0 +7f664cedf000-7f664cee0000 ---p 00000000 00:00 0 +7f664cee0000-7f664cfe0000 rw-p 00000000 00:00 0 +7f664cfe0000-7f664cfe1000 ---p 00000000 00:00 0 +7f664cfe1000-7f664d0e1000 rw-p 00000000 00:00 0 +7f664d0e1000-7f664d0e2000 ---p 00000000 00:00 0 +7f664d0e2000-7f664d1e2000 rw-p 00000000 00:00 0 +7f664d1e2000-7f664d1e3000 ---p 00000000 00:00 0 +7f664d1e3000-7f664d2e3000 rw-p 00000000 00:00 0 +7f664d2e3000-7f664d2e4000 ---p 00000000 00:00 0 +7f664d2e4000-7f664d3e4000 rw-p 00000000 00:00 0 +7f664d3e4000-7f664d3e5000 ---p 00000000 00:00 0 +7f664d3e5000-7f664d4e5000 rw-p 00000000 00:00 0 +7f664d4e5000-7f664d4e6000 ---p 00000000 00:00 0 +7f664d4e6000-7f664d5e6000 rw-p 00000000 00:00 0 +7f664d5e6000-7f664d5e7000 ---p 00000000 00:00 0 +7f664d5e7000-7f664d6e7000 rw-p 00000000 00:00 0 +7f664d6e7000-7f664d6e8000 ---p 00000000 00:00 0 +7f664d6e8000-7f664d7e8000 rw-p 00000000 00:00 0 +7f664d7e8000-7f664d7e9000 ---p 00000000 00:00 0 +7f664d7e9000-7f664d8e9000 rw-p 00000000 00:00 0 +7f664d8e9000-7f664d8ea000 ---p 00000000 00:00 0 +7f664d8ea000-7f664d9ea000 rw-p 00000000 00:00 0 +7f664d9ea000-7f664d9eb000 ---p 00000000 00:00 0 +7f664d9eb000-7f664daeb000 rw-p 00000000 00:00 0 +7f664daeb000-7f664daec000 ---p 00000000 00:00 0 +7f664daec000-7f664dbec000 rw-p 00000000 00:00 0 +7f664dbec000-7f664dbed000 ---p 00000000 00:00 0 +7f664dbed000-7f664dced000 rw-p 00000000 00:00 0 +7f664dced000-7f664dcee000 ---p 00000000 00:00 0 +7f664dcee000-7f664ddee000 rw-p 00000000 00:00 0 +7f664ddee000-7f664ddef000 ---p 00000000 00:00 0 +7f664ddef000-7f664deef000 rw-p 00000000 00:00 0 +7f664deef000-7f664def0000 ---p 00000000 00:00 0 +7f664def0000-7f664dff0000 rw-p 00000000 00:00 0 +7f664dff0000-7f664dff1000 ---p 00000000 00:00 0 +7f664dff1000-7f664e0f1000 rw-p 00000000 00:00 0 +7f664e0f1000-7f664e0f2000 ---p 00000000 00:00 0 +7f664e0f2000-7f664e1f2000 rw-p 00000000 00:00 0 +7f664e1f2000-7f664e1f3000 ---p 00000000 00:00 0 +7f664e1f3000-7f664e2f3000 rw-p 00000000 00:00 0 +7f664e2f3000-7f664e2f4000 ---p 00000000 00:00 0 +7f664e2f4000-7f664e3f4000 rw-p 00000000 00:00 0 +7f664e3f4000-7f664e3f5000 ---p 00000000 00:00 0 +7f664e3f5000-7f664e4f5000 rw-p 00000000 00:00 0 +7f664e4f5000-7f664e4f6000 ---p 00000000 00:00 0 +7f664e4f6000-7f664e5f6000 rw-p 00000000 00:00 0 +7f664e5f6000-7f664e5f7000 ---p 00000000 00:00 0 +7f664e5f7000-7f664e6f7000 rw-p 00000000 00:00 0 +7f664e6f7000-7f664e6f8000 ---p 00000000 00:00 0 +7f664e6f8000-7f664e7f8000 rw-p 00000000 00:00 0 +7f664e7f8000-7f664e7f9000 ---p 00000000 00:00 0 +7f664e7f9000-7f664e8f9000 rw-p 00000000 00:00 0 +7f664e8f9000-7f664e8fa000 ---p 00000000 00:00 0 +7f664e8fa000-7f664e9fa000 rw-p 00000000 00:00 0 +7f664e9fa000-7f664e9fb000 ---p 00000000 00:00 0 +7f664e9fb000-7f664eafb000 rw-p 00000000 00:00 0 +7f664eafb000-7f664eafc000 ---p 00000000 00:00 0 +7f664eafc000-7f664ebfc000 rw-p 00000000 00:00 0 +7f664ebfc000-7f664ebfd000 ---p 00000000 00:00 0 +7f664ebfd000-7f664ecfd000 rw-p 00000000 00:00 0 +7f664ecfd000-7f664ecfe000 ---p 00000000 00:00 0 +7f664ecfe000-7f664edfe000 rw-p 00000000 00:00 0 +7f664edfe000-7f664edff000 ---p 00000000 00:00 0 +7f664edff000-7f664eeff000 rw-p 00000000 00:00 0 +7f664eeff000-7f664ef00000 ---p 00000000 00:00 0 +7f664ef00000-7f664f000000 rw-p 00000000 00:00 0 +7f664f6fe000-7f664f6ff000 ---p 00000000 00:00 0 +7f664f6ff000-7f664f7ff000 rw-p 00000000 00:00 0 +7f664f7ff000-7f664f800000 ---p 00000000 00:00 0 +7f664f800000-7f6650000000 rw-p 00000000 00:00 0 +7f6650000000-7f6650022000 rw-p 00000000 00:00 0 +7f6650022000-7f6654000000 ---p 00000000 00:00 0 +7f66540f5000-7f66540f6000 ---p 00000000 00:00 0 +7f66540f6000-7f66541f6000 rw-p 00000000 00:00 0 +7f66541f6000-7f66541f7000 ---p 00000000 00:00 0 +7f66541f7000-7f66542f7000 rw-p 00000000 00:00 0 +7f66542f7000-7f66542f8000 ---p 00000000 00:00 0 +7f66542f8000-7f66543f8000 rw-p 00000000 00:00 0 +7f66543f8000-7f66543f9000 ---p 00000000 00:00 0 +7f66543f9000-7f66544f9000 rw-p 00000000 00:00 0 +7f66544f9000-7f66544fa000 ---p 00000000 00:00 0 +7f66544fa000-7f66545fa000 rw-p 00000000 00:00 0 +7f66545fa000-7f66545fb000 ---p 00000000 00:00 0 +7f66545fb000-7f66546fb000 rw-p 00000000 00:00 0 +7f66546fb000-7f66546fc000 ---p 00000000 00:00 0 +7f66546fc000-7f66547fc000 rw-p 00000000 00:00 0 +7f66547fc000-7f66547fd000 ---p 00000000 00:00 0 +7f66547fd000-7f66548fd000 rw-p 00000000 00:00 0 +7f66548fd000-7f66548fe000 ---p 00000000 00:00 0 +7f66548fe000-7f66549fe000 rw-p 00000000 00:00 0 +7f66549fe000-7f66549ff000 ---p 00000000 00:00 0 +7f66549ff000-7f6654aff000 rw-p 00000000 00:00 0 +7f6654aff000-7f6654b00000 ---p 00000000 00:00 0 +7f6654b00000-7f6654c00000 rw-p 00000000 00:00 0 +7f6654c00000-7f6654c01000 rw-p 00000000 00:00 0 +7f6654c01000-7f6654c02000 ---p 00000000 00:00 0 +7f6654cff000-7f6654d00000 ---p 00000000 00:00 0 +7f6654d00000-7f6654e00000 rw-p 00000000 00:00 0 +7f6654e00000-7f6654e01000 rw-p 00000000 00:00 0 +7f6654e01000-7f6654e02000 ---p 00000000 00:00 0 +7f6654eff000-7f6654f00000 ---p 00000000 00:00 0 +7f6654f00000-7f6655000000 rw-p 00000000 00:00 0 +7f6655000000-7f6655200000 rw-p 00000000 00:00 0 +7f6655200000-7f6655201000 ---p 00000000 00:00 0 +7f665523b000-7f6656af1000 r-xp 00000000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656af1000-7f6656cf0000 ---p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf0000-7f6656cf1000 r--p 018b5000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf1000-7f6656cf2000 rw-p 018b6000 103:02 2233416 /usr/lib/x86_64-linux-gnu/libicudata.so.55.1 +7f6656cf2000-7f6656e71000 r-xp 00000000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6656e71000-7f6657071000 ---p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657071000-7f6657081000 r--p 0017f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657081000-7f6657082000 rw-p 0018f000 103:02 2233420 /usr/lib/x86_64-linux-gnu/libicuuc.so.55.1 +7f6657082000-7f6657086000 rw-p 00000000 00:00 0 +7f6657086000-7f6657237000 r-xp 00000000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657237000-7f6657436000 ---p 001b1000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657436000-7f665743e000 r--p 001b0000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f665743e000-7f6657440000 rw-p 001b8000 103:02 2237922 /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.3 +7f6657440000-7f6657441000 rw-p 00000000 00:00 0 +7f6657441000-7f6657e00000 r--p 00000000 103:02 2235565 /usr/lib/locale/locale-archive +7f6657e00000-7f66d7e00000 rw-p 00000000 00:00 0 +7f66d7e00000-7f66d7e01000 ---p 00000000 00:00 0 +7f66d7eff000-7f66d7f00000 ---p 00000000 00:00 0 +7f66d7f00000-7f66d8000000 rw-p 00000000 00:00 0 +7f66d8000000-7f66d8b29000 rw-p 00000000 00:00 0 +7f66d8b29000-7f66dc000000 ---p 00000000 00:00 0 +7f66dc000000-7f66dc022000 rw-p 00000000 00:00 0 +7f66dc022000-7f66e0000000 ---p 00000000 00:00 0 +7f66e008a000-7f66e008b000 ---p 00000000 00:00 0 +7f66e008b000-7f66e018b000 rw-p 00000000 00:00 0 +7f66e018b000-7f66e01c2000 r-xp 00000000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e01c2000-7f66e03c2000 ---p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c2000-7f66e03c5000 r--p 00037000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c5000-7f66e03c6000 rw-p 0003a000 103:02 2236734 /usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1 +7f66e03c6000-7f66e03fb000 r-xp 00000000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e03fb000-7f66e05fb000 ---p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fb000-7f66e05fc000 r--p 00035000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fc000-7f66e05fd000 rw-p 00036000 103:02 2237572 /usr/lib/x86_64-linux-gnu/librsvg-2.so.2.40.13 +7f66e05fd000-7f66e05ff000 r-xp 00000000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e05ff000-7f66e07fe000 ---p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07fe000-7f66e07ff000 r--p 00001000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e07ff000-7f66e0800000 rw-p 00002000 103:02 2493292 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so +7f66e0800000-7f66e0840000 rw-p 00000000 00:00 0 +7f66e0840000-7f66e0841000 ---p 00000000 00:00 0 +7f66e08ff000-7f66e0900000 ---p 00000000 00:00 0 +7f66e0900000-7f66e0a00000 rw-p 00000000 00:00 0 +7f66e0a00000-7f66e0a10000 rw-p 00000000 00:00 0 +7f66e0a10000-7f66e0a11000 ---p 00000000 00:00 0 +7f66e0aff000-7f66e0b00000 ---p 00000000 00:00 0 +7f66e0b00000-7f66e0c00000 rw-p 00000000 00:00 0 +7f66e0c00000-7f66e1c00000 rw-p 00000000 00:00 0 +7f66e1c00000-7f66e1c01000 ---p 00000000 00:00 0 +7f66e1cff000-7f66e1d00000 ---p 00000000 00:00 0 +7f66e1d00000-7f66e1e00000 rw-p 00000000 00:00 0 +7f66e1e00000-7f66e1e20000 rw-p 00000000 00:00 0 +7f66e1e20000-7f66e1e21000 ---p 00000000 00:00 0 +7f66e1e5c000-7f66e1eb3000 r--p 00000000 103:02 3277771 /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-R.ttf +7f66e1eb3000-7f66e1ebe000 r--s 00000000 103:02 3019418 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-6 +7f66e1ebe000-7f66e1ed3000 r--s 00000000 103:02 3019394 /var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-6 +7f66e1eff000-7f66e1f00000 ---p 00000000 00:00 0 +7f66e1f00000-7f66e2000000 rw-p 00000000 00:00 0 +7f66e2000000-7f66e2040000 rw-p 00000000 00:00 0 +7f66e2040000-7f66e2041000 ---p 00000000 00:00 0 +7f66e204a000-7f66e204b000 rw-p 00000000 00:00 0 +7f66e204b000-7f66e2051000 r--s 00000000 103:02 3019400 /var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-6 +7f66e2051000-7f66e2052000 r--s 00000000 103:02 3019397 /var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-6 +7f66e2052000-7f66e2053000 r--s 00000000 103:02 3019399 /var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-6 +7f66e2053000-7f66e2057000 r--s 00000000 103:02 3019404 /var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-6 +7f66e2057000-7f66e2058000 r--s 00000000 103:02 3019431 /var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-6 +7f66e2058000-7f66e205b000 r--s 00000000 103:02 3019414 /var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-6 +7f66e205b000-7f66e2060000 r--s 00000000 103:02 3019417 /var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-6 +7f66e2060000-7f66e2067000 r--s 00000000 103:02 3019401 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-6 +7f66e2067000-7f66e206d000 r--s 00000000 103:02 3019422 /var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-6 +7f66e206d000-7f66e2080000 r--s 00000000 103:02 3019428 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-6 +7f66e2080000-7f66e208b000 r--s 00000000 103:02 3019416 /var/cache/fontconfig/83bf95040141907cd45bb53cf7c1c148-le64.cache-6 +7f66e208b000-7f66e209d000 r--s 00000000 103:02 3019420 /var/cache/fontconfig/9b89f8e3dae116d678bbf48e5f21f69b-le64.cache-6 +7f66e209d000-7f66e20bc000 r--s 00000000 103:02 2752558 /usr/share/mime/mime.cache +7f66e20bc000-7f66e20bd000 ---p 00000000 00:00 0 +7f66e20bd000-7f66e21bd000 rw-p 00000000 00:00 0 +7f66e21bd000-7f66e21be000 ---p 00000000 00:00 0 +7f66e21be000-7f66e2ca2000 rw-p 00000000 00:00 0 +7f66e2ca2000-7f66e2ca3000 ---p 00000000 00:00 0 +7f66e2ca3000-7f66e2da3000 rw-p 00000000 00:00 0 +7f66e2da3000-7f66e2da4000 ---p 00000000 00:00 0 +7f66e2da4000-7f66e35a4000 rw-p 00000000 00:00 0 +7f66e35a4000-7f66e35ab000 r-xp 00000000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e35ab000-7f66e37ab000 ---p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ab000-7f66e37ac000 r--p 00007000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ac000-7f66e37ad000 rw-p 00008000 103:02 2237425 /usr/lib/x86_64-linux-gnu/libogg.so.0.8.2 +7f66e37ad000-7f66e37d7000 r-xp 00000000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e37d7000-7f66e39d6000 ---p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d6000-7f66e39d7000 r--p 00029000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d7000-7f66e39d8000 rw-p 0002a000 103:02 2233113 /usr/lib/x86_64-linux-gnu/libvorbis.so.0.4.8 +7f66e39d8000-7f66e39e1000 r-xp 00000000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e39e1000-7f66e3be0000 ---p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be0000-7f66e3be1000 r--p 00008000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be1000-7f66e3be2000 rw-p 00009000 103:02 2237286 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1 +7f66e3be2000-7f66e3bf6000 r-xp 00000000 103:02 2237676 /usr/lib/x86_64-linux-gnu/libtdb.so.1.3.8Aborted (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1791763 b/results/classifier/gemma3:12b/manual-review/1791763 new file mode 100644 index 00000000..0fc3bd43 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1791763 @@ -0,0 +1,14 @@ + +broken signal handling in nios2 user-mode emulation + +This bug is against the 3.0 release. + +It appears that the signal handling parts of the nios2 user-mode emulation have never really been completed or tested. Some examples of failing tests from the GCC testsuite are gcc.dg/pr78185.c and gcc.dg/cleanup-10.c. + +Some problems I've identified and tried to fix with the attached patch are: + +- Code copied from the Linux kernel wasn't adjusted to differentiate between host and target data types and address spaces. + +- The sigaltstack() system call returns EINVAL because fields are listed in the wrong order in struct target_sigaltstack. + +With this patch, the system calls to set up the signal handler are returning successfully, but the handler isn't being invoked, so something is still wrong. I think I need another pair of eyes to look over this code. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1793119 b/results/classifier/gemma3:12b/manual-review/1793119 new file mode 100644 index 00000000..041f7b3b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1793119 @@ -0,0 +1,30 @@ + +Wrong floating-point emulation on AArch64 with FPCR set to zero + +On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). + +I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`. + +Output on real hardware: +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` equals `q`. + +Output on qemu 3.0.0 (Linux user-mode emulation): +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` is not equal to `q`. + +Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv". + +Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1810603 b/results/classifier/gemma3:12b/manual-review/1810603 new file mode 100644 index 00000000..216840bd --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1810603 @@ -0,0 +1,54 @@ + +QEMU QCow Images grow dramatically + +I've recently migrated our VM infrastructure (~200 guest on 15 hosts) from vbox to Qemu (using KVM / libvirt). We have a master image (QEMU QCow v3) from which we spawn multiple instances (linked clones). All guests are being revert once per hour for security reasons. + +About 2 weeks after we successfully migrated to Qemu, we noticed that almost all disks went full across all 15 hosts. Our investigation showed that the initial qcow disk images blow up from a few gigabytes to 100GB and more. This should not happen, as we revert all VMs back to the initial snapshot once per hour and hence all changes that have been made to disks must be reverted too. + +We did an addition test with 24 hour time frame with which we could reproduce this bug as documented below. + +Initial disk image size (created on Jan 04): +-rw-r--r-- 1 root root 7.1G Jan 4 15:59 W10-TS01-0.img +-rw-r--r-- 1 root root 7.3G Jan 4 15:59 W10-TS02-0.img +-rw-r--r-- 1 root root 7.4G Jan 4 15:59 W10-TS03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:02 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 8.6G Jan 4 16:05 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:05 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 8.3G Jan 4 16:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:12 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 8.0G Jan 4 16:12 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 8.1G Jan 4 16:16 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:16 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 7.6G Jan 4 16:19 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 7.5G Jan 4 16:21 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +Disk image size after 24 hours (printed on Jan 05): +-rw-r--r-- 1 root root 13G Jan 5 15:07 W10-TS01-0.img +-rw-r--r-- 1 root root 8.9G Jan 5 14:20 W10-TS02-0.img +-rw-r--r-- 1 root root 9.0G Jan 5 15:07 W10-TS03-0.img +-rw-r--r-- 1 root root 10G Jan 5 15:08 W10-CLIENT01-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT02-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT03-0.img +-rw-r--r-- 1 root root 11G Jan 5 15:08 W10-CLIENT04-0.img +-rw-r--r-- 1 root root 19G Jan 5 15:07 W10-CLIENT05-0.img +-rw-r--r-- 1 root root 14G Jan 5 15:08 W10-CLIENT06-0.img +-rw-r--r-- 1 root root 9.7G Jan 5 15:07 W10-CLIENT07-0.img +-rw-r--r-- 1 root root 35G Jan 5 15:08 W10-CLIENT08-0.img +-rw-r--r-- 1 root root 9.2G Jan 5 15:07 W10-CLIENT09-0.img +-rw-r--r-- 1 root root 41G Jan 5 15:08 W10-ROUTER-0.img +-rw-r--r-- 1 root root 18G Jan 4 16:25 W10-MASTER-IMG.qcow2 + +You can reproduce this bug as follow: +1) create an initial disk image +2) create a linked clone +3) create a snapshot of the linked clone +4) revert the snapshot every X minutes / hours + +Due the described behavior / bug, our VM farm is completely down at the moment (as we run out of disk space on all host systems). A quick fix for this bug would be much appreciated. + +Host OS: Ubuntu 18.04.01 LTS +Kernel: 4.15.0-43-generic +Qemu: 3.1.0 +libvirt: 4.10.0 +Guest OS: Windows 10 64bit \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1812 b/results/classifier/gemma3:12b/manual-review/1812 new file mode 100644 index 00000000..9ca7d16c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1812 @@ -0,0 +1,26 @@ + +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:12b/manual-review/1817268 b/results/classifier/gemma3:12b/manual-review/1817268 new file mode 100644 index 00000000..a84f7965 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1817268 @@ -0,0 +1,156 @@ + +Input/output error during migration + +Operating system: Ubuntu 18.04.2 LTS +qemu version: 2.11.1, but also reproduced with 3.1.0 (compiled manually). +virsh --version: 4.0.0 + +Hello, + +I am having an issue with migration of UEFI virtual machines. If the --copy-storage-inc and the --tunnelled libvirt flags are used together, the migration fails. The same command for non-uefi virtual machines (e.g the same libvirt xml without the <nvram> and <loader> tags) works. + +The command/output error is: + +virsh migrate --verbose --live --p2p --tunnelled --copy-storage-inc --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +error: internal error: qemu unexpectedly closed the monitor: Receiving block device images +2019-02-21T16:20:15.263261Z qemu-system-x86_64: error while loading state section id 2(block) +2019-02-21T16:20:15.263996Z qemu-system-x86_64: load of migration failed: Input/output error + +If I remove one of the --tunnelled or the --copy-storage-inc flag, it works, for example: + +virsh migrate --verbose --live --p2p --copy-storage-inc --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +Migration: [100 %] + +virsh migrate --verbose --live --p2p --tunnelled --change-protection --abort-on-error testuefi qemu+tcp://<ip>/system +Migration: [100 %] + +I have no idea why those two flags combined together produce an error, and only for UEFI virtual machines. + +here is the libvirt xml definition: + +<domain type='kvm' id='4'> + <name>testuefi</name> + <uuid>ce12de05-ec09-4b4b-a27a-47003a511bda</uuid> + <description>CentOS 4.5 (32-bit)</description> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>1048576</currentMemory> + <vcpu placement='static'>2</vcpu> + <cputune> + <shares>878</shares> + </cputune> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>Apache Software Foundation</entry> + <entry name='product'>CloudStack KVM Hypervisor</entry> + <entry name='uuid'>ce12de05-ec09-4b4b-a27a-47003a511bda</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-2.11'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/testuefi_VARS.fd</nvram> + <boot dev='cdrom'/> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>Westmere</model> + <feature policy='require' name='vmx'/> + <feature policy='require' name='vme'/> + <feature policy='require' name='pclmuldq'/> + <feature policy='require' name='x2apic'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/kvm-spice</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' cache='none'/> + <source file='/var/lib/libvirt/images/testmigration.qcow2'/> + <backingStore type='file' index='1'> + <format type='raw'/> + <source file='/var/lib/libvirt/images/b3e4b880-0611-43bc-9d71-9cdac138f6e2'/> + <backingStore/> + </backingStore> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver cache='none'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <alias name='ide0-1-0'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='06:6a:20:00:00:55'/> + <source bridge='public'/> + <target dev='vnet4'/> + <model type='virtio'/> + <driver queues='2'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='pty'> + <source path='/dev/pts/2'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <console type='pty' tty='/dev/pts/2'> + <source path='/dev/pts/2'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </memballoon> + </devices> +</domain> + +Here is the qemu command on the destination host: + +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name guest=testuefi-VM,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-14-testuefi-VM/master-key.aes -machine pc-i440fx-2.11,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server,vmx=on,pcid=on,ssbd=on,hypervisor=on -drive file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/testuefi-VM_VARS.fd,if=pflash,format=raw,unit=1 -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid b340b117-1704-4ccf-93a7-21303b12dd7f -smbios 'type=1,manufacturer=Apache Software Foundation,product=CloudStack KVM Hypervisor,uuid=b340b117-1704-4ccf-93a7-21303b12dd7f' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-14-testuefi-VM/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/testmigration.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-ide0-1-0,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=35,id=hostnet0,vhost=on,vhostfd=37 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=06:a0:66:00:00:0c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc vnc=unix:/var/run/qemu/b340b117-1704-4ccf-93a7-21303b12dd7f.sock -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -incoming defer -msg timestamp=on + +Thanks, \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1821006 b/results/classifier/gemma3:12b/manual-review/1821006 new file mode 100644 index 00000000..124ec6a6 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1821006 @@ -0,0 +1,36 @@ + +qemu: Unsupported syscall: 382 + +I used + +qemu-user-static/stable,stable,now 1:2.8+dfsg-6+deb9u5 amd64 [installed] + +When I try to build an image of a docker for an arm, an error occurs. + +This affects the operation of applications. + + +Dockerfile + +ARG ARCH +FROM ${ARCH}/debian:buster-slim + +RUN \ + printf "Install dependencies...\n" && \ + apt-get update && \ + apt-get install -y --no-install-recommends ca-certificates curl + +RUN curl https://google.com + +EOF + +The command that I run + +docker build --build-arg ARCH=arm32v7 --file ./Dockerfile -t test . + + +root@unit6:/lib/binfmt.d# cat qemu-arm-static.conf +:qemu-arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:F + +Here is a related discussion. +https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923479 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1821515 b/results/classifier/gemma3:12b/manual-review/1821515 new file mode 100644 index 00000000..ef634e8e --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1821515 @@ -0,0 +1,39 @@ + +qemu-ppc (user) incorrectly converts float(nan)->double(non-nan) + +Noticed on qemu-3.1.0 on GHC test suite where float32 comparisons didn't work on NaNs. +Here is the minimal reproducer: + +```c +// cat a.c +#include <stdio.h> +#include <math.h> +#include <stdint.h> + +int main() { + volatile float f1 = NAN; + volatile float f2 = NAN; + printf ("f1 (%e, %#x) >= f2 (%e, %#x): %s\n", + f1, *(volatile uint32_t*)&f1, + f2, *(volatile uint32_t*)&f2, + (f1 >= f2) ? "True" + : "False"); + volatile double d = f1; + printf ("d (%e, %#llx)\n", + d, *(volatile uint64_t*)&d); +} +``` + +``` +# incorrect execution: +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -o a -static && qemu-ppc ./a +f1 (5.104236e+38, 0x7fc00000) >= f2 (5.104236e+38, 0x7fc00000): True +d (5.104236e+38, 0x47f8000000000000) + +# correct execution +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/; ssh timberdoodle.ppc64.dev.gentoo.org ./a +f1 (nan, 0x7fc00000) >= f2 (nan, 0x7fc00000): False +d (nan, 0x7ff8000000000000) +``` + +Note: qemu-ppc handled float32 extension as it was not a NaN (exp=111..1111) but a normalized number. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1834613 b/results/classifier/gemma3:12b/manual-review/1834613 new file mode 100644 index 00000000..f79ffbf4 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1834613 @@ -0,0 +1,49 @@ + +Crypto related operations failing on Alpine Linux on QEMU 4.0 + +I'm unable to boot the netboot image of Alpine Linux using QEMU 4.0. + +Steps to reproduce: + +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/vmlinuz-vanilla +curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/initramfs-vanilla +qemu-system-ppc64 -kernel vmlinuz-vanilla -initrd initramfs-vanilla -nographic -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/v3.10/main" + +The init script will automatically download and install an in-memory Alpine Linux environment. However, with QEMU 4.0, the installation process will fail with "BAD SIGNATURE" errors: + + + + * Installing packages to root filesystem: fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/ppc64le/APKINDEX.tar.gz +(1/20) Installing musl (1.1.22-r2) +ERROR: musl-1.1.22-r2: BAD signature (2/20) Installing busybox (1.30.1-r2) +ERROR: busybox-1.30.1-r2: BAD signature (3/20) Installing alpine-baselayout (3.1.2-r0) +Executing alpine-baselayout-3.1.2-r0.pre-install ERROR: alpine-baselayout-3.1.2-r0.pre-install: script exited with error 127 +ERROR: alpine-baselayout-3.1.2-r0: BAD signature (4/20) Installing openrc (0.41.2-r1) +ERROR: openrc-0.41.2-r1: BAD signature (5/20) Installing alpine-conf (3.8.3-r0) +ERROR: alpine-conf-3.8.3-r0: BAD signature (6/20) Installing libcrypto1.1 (1.1.1c-r0) +ERROR: libcrypto1.1-1.1.1c-r0: BAD signature (7/20) Installing libssl1.1 (1.1.1c-r0) +ERROR: libssl1.1-1.1.1c-r0: BAD signature (8/20) Installing ca-certificates-cacert (20190108-r0) +ERROR: ca-certificates-cacert-20190108-r0: BAD signature (9/20) Installing libtls-standalone (2.9.1-r0) +ERROR: libtls-standalone-2.9.1-r0: BAD signature (10/20) Installing ssl_client (1.30.1-r2) +ERROR: ssl_client-1.30.1-r2: BAD signature (11/20) Installing zlib (1.2.11-r1) +ERROR: zlib-1.2.11-r1: BAD signature (12/20) Installing apk-tools (2.10.4-r1) +ERROR: apk-tools-2.10.4-r1: BAD signature (13/20) Installing busybox-suid (1.30.1-r2) +ERROR: busybox-suid-1.30.1-r2: BAD signature (14/20) Installing busybox-initscripts (3.1-r7) +ERROR: busybox-initscripts-3.1-r7: BAD signature (15/20) Installing scanelf (1.2.3-r0) +ERROR: scanelf-1.2.3-r0: BAD signature (16/20) Installing musl-utils (1.1.22-r2) +ERROR: musl-utils-1.1.22-r2: BAD signature (17/20) Installing libc-utils (0.7.1-r0) +ERROR: libc-utils-0.7.1-r0: BAD signature (18/20) Installing alpine-keys (2.1-r2) +ERROR: alpine-keys-2.1-r2: BAD signature (19/20) Installing alpine-base (3.10.0-r0) +ERROR: alpine-base-3.10.0-r0: BAD signature (20/20) Installing openssl (1.1.1c-r0) +ERROR: openssl-1.1.1c-r0: BAD signature 20 errors; 0 MiB in 0 packages +ok. +grep: /sysroot/etc/inittab: No such file or directory +/sbin/init not found in new root. Launching emergency recovery shell +Type exit to continue boot. +sh: can't access tty; job control turned off +/ # + + +If I boot up a disk image created by a previous version QEMU, crypto related operations like verifying a RSA signature using the "openssl" command will also fail. + +I didn't see these errors on previous QEMU versions or other architectures on QEMU 4.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1835693 b/results/classifier/gemma3:12b/manual-review/1835693 new file mode 100644 index 00000000..32e22fb4 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1835693 @@ -0,0 +1,18 @@ + +s390x binaries segfault + +Hello World appears to segfault with qemu s390x, on a Debian 10.0.0 Buster amd64 host. + +$ cat hello.cpp +#include <iostream> +using std::cout; + +int main() { + cout << "Hello World!\n"; + return 0; +} + +$ s390x-linux-gnu-g++ -o hello hello.cpp + +$ qemu-s390x-static hello +Segmentation fault \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1836078 b/results/classifier/gemma3:12b/manual-review/1836078 new file mode 100644 index 00000000..583ac8e7 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1836078 @@ -0,0 +1,23 @@ + +Regressions on arm-linux-gnueabihf target with some GCC tests + +Hi, + +After trying qemu master: +commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde +Merge: 68d7ff0 14f5d87 +Author: Peter Maydell <email address hidden> +Date: Fri Jun 21 15:40:50 2019 +0100 + +even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, +I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite. +I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. + +All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. + +This was noticed with GCC master configured with +--target arm-none-linux-gnueabihf +--with-cpu cortex-a57 +--with-fpu crypto-neon-fp-armv8 + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1836192 b/results/classifier/gemma3:12b/manual-review/1836192 new file mode 100644 index 00000000..01b49c3e --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1836192 @@ -0,0 +1,22 @@ + +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:12b/manual-review/1841491 b/results/classifier/gemma3:12b/manual-review/1841491 new file mode 100644 index 00000000..2d7f776b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1841491 @@ -0,0 +1,36 @@ + +floating point emulation can fail to set FE_UNDERFLOW + +Floating point emulation can fail to set FE_UNDERFLOW in some circumstances. This shows up often in glibc's "math" tests. A similar test is attached. + +This is similar to bug #1841442, but not the same problem, and I don't think the fix will be in the same code. + +On ppc64le native: +-- +$ gcc -c -O2 fma.c +$ gcc -O2 test-fma.c fma.o -lm -o test-fma +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0xa000000 +FE_INEXACT FE_UNDERFLOW +0x1p-1022 +-- + +On qemu-system-ppc64: +-- +$ ./test-fma $(./test-fma) +fma(0x1.ffffffffffffcp-1022, 0x1.0000000000001p-1, 0x0.0000000000001p-1022) +0x0 + +0x2000000 +FE_INEXACT +0x1p-1022 +-- + +QEMU versions vary, but not too much, and are pretty close to git HEAD: +- 586f3dced9 (HEAD -> master, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190822' into staging +- 864ab31 Update version for v4.1.0-rc4 release + +There are worse symptoms on qemu-x86_64, but this is apparently not surprising per https://bugs.launchpad.net/qemu/+bug/1841442/comments/6. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1854 b/results/classifier/gemma3:12b/manual-review/1854 new file mode 100644 index 00000000..4c7cfed2 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1854 @@ -0,0 +1,19 @@ + +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:12b/manual-review/1872847 b/results/classifier/gemma3:12b/manual-review/1872847 new file mode 100644 index 00000000..0bd8ee0d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1872847 @@ -0,0 +1,23 @@ + +qemu-alpha linux-user breaks python3.6 + +Running on Gentoo Linux in a chroot environment: +# python3 -c 'import selectors; selectors.DefaultSelector()' +Traceback (most recent call last): + File "<string>", line 1, in <module> + File "/usr/lib/python3.7/selectors.py", line 349, in __init__ + self._selector = self._selector_cls() +OSError: [Errno 22] Invalid argument + +However, on real hardware, with the same binaries there is no exception. + +This impacts whole python3 based Gentoo ebuild system (package management), and renders linux user mode alpha emulation in chroot environment building useless, more or less. + +The used systems: +# qemu-alpha --version +qemu-alpha version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +# uname -a +Linux blackbird 5.4.28-gentoo-blackbird-06 #2 SMP Sat Apr 4 13:13:10 CEST 2020 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux +(chroot)# python3 --version +Python 3.7.7 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1874674 b/results/classifier/gemma3:12b/manual-review/1874674 new file mode 100644 index 00000000..a8fa010a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1874674 @@ -0,0 +1,7 @@ + +[Feature request] acceptance test class to run user-mode binaries + +Currently the acceptance test framework only target system-mode emulation. +It would be useful to test user-mode too. + +Ref: https://<email address hidden>/msg626610.html \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1881450 b/results/classifier/gemma3:12b/manual-review/1881450 new file mode 100644 index 00000000..f72c0c21 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1881450 @@ -0,0 +1,24 @@ + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1883560 b/results/classifier/gemma3:12b/manual-review/1883560 new file mode 100644 index 00000000..10dc887b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1883560 @@ -0,0 +1,32 @@ + +mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build + +From time to time I find check-tcg crashes with a one of the MIPS binaries. The last time it crashed was running the test: + + ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-user/threadcount + +Inevitably after some time noodling around wondering what could be causing this weird behaviour I wonder if it is a build issue. I wipe all the mips* build directories, re-run configure and re-build and voila problem goes away. + +It seems there must be some sort of build artefact which isn't being properly re-generated on a build update which causes weird problems. Additional data point if I: + + rm -rf mips64el-linux-user + ../../configure + make + +then I see failures in mip32 builds - eg: + + GEN mipsn32el-linux-user/config-target.h + In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10, + from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16, + from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5: + /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: unterminated #ifndef + #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H + + make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: linux-user/linuxload.o] Error 1 + make[1]: *** Waiting for unfinished jobs.... + +which implies there is a cross dependency between different targets somewhere. If I executed: + + rm -rf mips* + +before re-configuring and re-building then everything works again. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1886 b/results/classifier/gemma3:12b/manual-review/1886 new file mode 100644 index 00000000..8e49c803 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1886 @@ -0,0 +1,18 @@ + +migration-test is unreliable +Description of problem: +The following intermittent failure occurred in the CI: + +``` +>>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=116 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 /builds/qemu-project/qemu/build/tests/qtest/migration-test --tap -k +――――――――――――――――――――――――――――――――――――― ✀ ――――――――――――――――――――――――――――――――――――― +stderr: +qemu-system-x86_64: Unable to read from socket: Connection reset by peer +Memory content inconsistency at 5b43000 first_byte = bd last_byte = bc current = 4f hit_edge = 1 +** +ERROR:../tests/qtest/migration-test.c:300:check_guests_ram: assertion failed: (bad == 0) +(test program exited with status code -6) +``` + +You can find the full output here: +https://gitlab.com/qemu-project/qemu/-/jobs/5080200417 diff --git a/results/classifier/gemma3:12b/manual-review/1887306 b/results/classifier/gemma3:12b/manual-review/1887306 new file mode 100644 index 00000000..0ea9a50c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1887306 @@ -0,0 +1,56 @@ + +qemu-user deadlocks when forked in a multithreaded process + +The following program (also attached) deadlocks when run under QEMU user on Linux. + +#include <pthread.h> +#include <stdio.h> +#include <stdlib.h> +#include <sys/types.h> +#include <sys/wait.h> +#include <unistd.h> + +#define NUM_THREADS 100 +#define NUM_FORKS 10 + +pthread_barrier_t barrier; + +void *t(void *arg) { + for (int i = 0; i < NUM_FORKS; i++) { + pid_t pid = fork(); + if (pid < 0) + abort(); + if (!pid) + _exit(0); + if (waitpid(pid, NULL, 0) < 0) + abort(); + } + //pthread_barrier_wait(&barrier); + return NULL; +} + +int main(void) { + pthread_barrier_init(&barrier, NULL, NUM_THREADS); + pthread_t ts[NUM_THREADS]; + for (size_t i = 0; i < NUM_THREADS; i++) { + if (pthread_create(&ts[i], NULL, t, NULL)) + abort(); + } + for (size_t i = 0; i < NUM_THREADS; i++) { + pthread_join(ts[i], NULL); + } + printf("Done: %d\n", getpid()); + return 0; +} + +To reproduce: +$ gcc test.c -pthread +$ while qemu-x86_64 ./a.out; do :; done + +(Be careful, Ctrl-C/SIGINT doesn't kill the deadlocked child). + +Larger values of NUM_THREADS/NUM_FORKS lead to more often deadlocks. With the values above it often deadlocks on the first try on my machine. When it deadlocks, there is a child qemu process with two threads which is waited upon by one of the worker threads of the parent. + +I tried to avoid the deadlock by serializing fork() with a mutex, but it didn't help. However, ensuring that no thread exits until all forks are done (by adding a barrier to t()) does seem to help, at least, the program above could run for a half an hour until I terminated it. + +Tested on QEMU 5.0.0, 4.2.0 and 2.11.1, with x86_64 and AArch64 linux-user targets. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1888303 b/results/classifier/gemma3:12b/manual-review/1888303 new file mode 100644 index 00000000..559d7a1c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1888303 @@ -0,0 +1,21 @@ + +Intermittent buggines with user mode emulation of x86-64 on aarch64 + +QEMU Version: 5.0.0 +./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static + +Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm + +aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages. + +On aarch64 machine, invoke: + +./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile + +Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data. + +But, about once every 10 times, it will not sefault and will continue working just fine forever. + +The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault. + +This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1906 b/results/classifier/gemma3:12b/manual-review/1906 new file mode 100644 index 00000000..fd5b0f4a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1906 @@ -0,0 +1,35 @@ + +Failed to compile QEMU 7.0.0 source code. recipe for target 'run-ninja' failed. +Description of problem: +Failed to compiling the download QEMU 7.0.0 source code. It seems to be due to something wrong with ninja. +The followings are error logs after executing command "make -j$(nproc)": + +changing dir to build for make ""... +make[1]: Entering directory '/home/liangke/os-env/qemu-7.0.0/build' +/usr/bin/ninja build.ninja && touch build.ninja.stamp +**ninja: no work to do.** +... +... +... +[1350/2396] Compiling C object libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o +**FAILED: libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o** +cc -m64 -mcx16 -Ilibqemu-riscv64-softmmu.fa.p -I. -I.. -Itarget/riscv -I../target/riscv -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/liangke/os-env/qemu-7.0.0/linux-headers -isystem linux-headers -iquote . -iquote /home/liangke/os-env/qemu-7.0.0 -iquote /home/liangke/os-env/qemu-7.0.0/include -iquote /home/liangke/os-env/qemu-7.0.0/disas/libvixl -iquote /home/liangke/os-env/qemu-7.0.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="riscv64-softmmu-config-target.h"' '-DCONFIG_DEVICES="riscv64-softmmu-config-devices.h"' -MD -MQ libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -MF libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o.d -o libqemu-riscv64-softmmu.fa.p/target_riscv_translate.c.o -c ../target/riscv/translate.c +**cc: fatal error: Killed signal terminated program cc1** +**compilation terminated.** +**ninja: build stopped: subcommand failed.** +**Makefile:163: recipe for target 'run-ninja' failed** +**make[1]: *** [run-ninja] Error 1** +make[1]: Leaving directory '/home/liangke/os-env/qemu-7.0.0/build' +**GNUmakefile:10: recipe for target 'all' failed** +**make: *** [all] Error 2** +Steps to reproduce: +1. cd qemu-7.0.0 source code folder; +2. ./configure --target-list=riscv64-softmmu,riscv64-linux-user; +3. make -j$(nproc) +Additional information: +1. I downloaded the source code from https://download.qemu.org/qemu-7.0.0.tar.xz. +2. my compiling prerequisites: +sudo apt install autoconf automake autotools-dev curl libmpc-dev libmpfr-dev libgmp-dev \ + gawk build-essential bison flex texinfo gperf libtool patchutils bc ninja-build \ + zlib1g-dev libexpat-dev pkg-config libglib2.0-dev libpixman-1-dev git tmux python3 +3. Found ninja-1.8.2 at /usr/bin/ninja diff --git a/results/classifier/gemma3:12b/manual-review/1906193 b/results/classifier/gemma3:12b/manual-review/1906193 new file mode 100644 index 00000000..3ea80846 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1906193 @@ -0,0 +1,58 @@ + +riscv32 user mode emulation: fork return values broken + +When running in a chroot with riscv32 (on x86_64; qemu git master as of today): + +The following short program forks; the child immediately returns with exit(42). The parent checks for the return value - and obtains 40! + +gcc-10.2 + +=============================================== +#include <stdlib.h> +#include <unistd.h> +#include <stdio.h> +#include <sys/wait.h> + +main(c, v) + int c; + char **v; +{ + pid_t pid, p; + int s, i, n; + + s = 0; + pid = fork(); + if (pid == 0) + exit(42); + + /* wait for the process */ + p = wait(&s); + if (p != pid) + exit (255); + + if (WIFEXITED(s)) + { + int r=WEXITSTATUS(s); + if (r!=42) { + printf("child wants to return %i (0x%X), parent received %i (0x%X), difference %i\n",42,42,r,r,r-42); + } + } +} +=============================================== + +(riscv-ilp32 chroot) farino /tmp # ./wait-test-short +child wants to return 42 (0x2A), parent received 40 (0x28), difference -2 + +=============================================== +(riscv-ilp32 chroot) farino /tmp # gcc --version +gcc (Gentoo 10.2.0-r1 p2) 10.2.0 +Copyright (C) 2020 Free Software Foundation, Inc. +Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es +gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. + +(riscv-ilp32 chroot) farino /tmp # ld --version +GNU ld (Gentoo 2.34 p6) 2.34.0 +Copyright (C) 2020 Free Software Foundation, Inc. +This program is free software; you may redistribute it under the terms of +the GNU General Public License version 3 or (at your option) a later version. +This program has absolutely no warranty. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/191 b/results/classifier/gemma3:12b/manual-review/191 new file mode 100644 index 00000000..23b62294 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/191 @@ -0,0 +1,2 @@ + +qemu64 CPU model is incorrect diff --git a/results/classifier/gemma3:12b/manual-review/1917591 b/results/classifier/gemma3:12b/manual-review/1917591 new file mode 100644 index 00000000..4e9bf7c0 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1917591 @@ -0,0 +1,29 @@ + +qemu-i386 under aarch64: Segfaulting on Steamcmd + +I am trying to set up a Valheim server on my Raspberry Pi. I have installed the aarch64 image of Arm Arch Linux. + +I installed qemu-user-static from the AUR: https://aur.archlinux.org/packages/qemu-user-static/ +I have correctly set up binfmt support: https://aur.archlinux.org/packages/binfmt-qemu-static-all-arch/ + +This allows me to successfully run i386 and amd64 docker images: + +[alarm@server ~]$ sudo docker run --rm i386/debian uname -a +WARNING: The requested image's platform (linux/386) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 9fd8d345b0aa 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 i686 GNU/Linux + +and + +[alarm@server ~]$ sudo docker run --rm amd64/debian uname -a +WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested +Linux 4f50fd228ab6 5.11.1-1-ARCH #1 SMP Tue Feb 23 20:00:47 MST 2021 x86_64 GNU/Linux + +However, when I try to run the docker image that is going to host the server, the download of Valheim never succeeds because the used steamcmd application segfaults: + +The following command successfully runs the server: sudo docker run -d --name valheim-server -p 2456-2458:2456-2458/udp -e SERVER_NAME="My Server" -e WORLD_NAME="Neotopia" -e SERVER_PASS="secret" lloesche/valheim-server + +However, when we look into the container's logs via this command: sudo docker logs valheim-server + +We see the following entry in the log file: ./steamcmd.sh: line 38: 86 Segmentation fault (core dumped) $DEBUGGER "$STEAMEXE" "$@" + +This means that the download never completes, and therefor the Valheim server is never actually started. Any help would be much appreciated. If there is anything unclear or if you need more details, please let me know! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1918084 b/results/classifier/gemma3:12b/manual-review/1918084 new file mode 100644 index 00000000..4afe7e6f --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1918084 @@ -0,0 +1,25 @@ + +Build fails on macOS 11.2.2 + +Hi, + +I got the latest version from git. I have pre-compiled the dependency libraries. All good. configure creates the necessary files. When I build I got the following error: + +[1368/6454] Compiling C object libcapstone.a.p/capstone_arch_AArch64_AArch64InstPrinter.c.o +ninja: build stopped: subcommand failed. +make[1]: *** [run-ninja] Error 1 +make: *** [all] Error 2 + +I've ran make as make -j 8 + +original config: + +PKG_CONFIG_PATH="$SERVERPLUS_DIR/dependencies/glib/lib/pkgconfig:$SERVERPLUS_DIR/dependencies/pixman/lib/pkgconfig:$SERVERPLUS_DIR/dependencies/cyrus-sasl/lib/pkgconfig" ./configure --prefix="$SERVERPLUS_DIR" --enable-hvf --enable-cocoa --enable-vnc-sasl --enable-auth-pam --ninja=/opt/build/build/stage/tools/ninja/ninja --python="$SERVERPLUS_DIR/dependencies/python/bin/python3" --enable-bsd-user + +if I build with --target-list=x86_64-softmmu then it will build but I will get only the x86_64 QEMU built. With 5.0 I could build all emulators. + +$SERVERPLUS_DIR is my target dir. + +Thanks, + +Eddy \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1922773 b/results/classifier/gemma3:12b/manual-review/1922773 new file mode 100644 index 00000000..6d85d265 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1922773 @@ -0,0 +1,98 @@ + +RISCV32 illegal instruction exception + +I'm running a machine learning model on qemu riscv32 and I ran into illegal instruction exception for some reason. I wasn't sure if this is a bug and if so whether it is related to zephyr or qemu, however I'll try to provide as much as information to get a better understanding. + +Here is the assembly code that I'm running: + +0x8000bd74 <+0>: lw a4,0(a0) + 0x8000bd76 <+2>: lw a5,8(a0) + 0x8000bd78 <+4>: lw a0,0(a4) + 0x8000bd7a <+6>: lw a1,0(a5) + 0x8000bd7c <+8>: li a3,0 + 0x8000bd7e <+10>: j 0x8000bda4 <fused_nn_pad_layout_transform+48> + 0x8000bd80 <+12>: addi a5,a3,-2 + 0x8000bd84 <+16>: li a2,27 + 0x8000bd86 <+18>: bgeu a2,a5,0x8000bdae <fused_nn_pad_layout_transform+58> +=> 0x8000bd8a <+22>: fmv.w.x fa5,zero + 0x8000bd8e <+26>: slli a5,a3,0x5 + 0x8000bd92 <+30>: add a5,a5,a4 + 0x8000bd94 <+32>: slli a5,a5,0x2 + 0x8000bd96 <+34>: add a5,a5,a1 + 0x8000bd98 <+36>: fsw fa5,0(a5) + 0x8000bd9a <+38>: addi a4,a4,1 + 0x8000bd9c <+40>: li a5,31 + 0x8000bd9e <+42>: bge a5,a4,0x8000bd80 <fused_nn_pad_layout_transform+12> + 0x8000bda2 <+46>: addi a3,a3,1 + 0x8000bda4 <+48>: li a5,31 + 0x8000bda6 <+50>: blt a5,a3,0x8000bde0 <fused_nn_pad_layout_transform+108> + 0x8000bdaa <+54>: li a4,0 + 0x8000bdac <+56>: j 0x8000bd9c <fused_nn_pad_layout_transform+40> + 0x8000bdae <+58>: li a5,1 + 0x8000bdb0 <+60>: bge a5,a4,0x8000bdd4 <fused_nn_pad_layout_transform+96> + 0x8000bdb4 <+64>: li a5,29 + 0x8000bdb6 <+66>: blt a5,a4,0x8000bdda <fused_nn_pad_layout_transform+102> + 0x8000bdba <+70>: li a5,28 + 0x8000bdbc <+72>: mul a5,a3,a5 + 0x8000bdc0 <+76>: add a5,a5,a4 + 0x8000bdc2 <+78>: lui a2,0x40000 + 0x8000bdc6 <+82>: addi a2,a2,-58 # 0x3fffffc6 + 0x8000bdca <+86>: add a5,a5,a2 + 0x8000bdcc <+88>: slli a5,a5,0x2 + 0x8000bdce <+90>: add a5,a5,a0 + 0x8000bdd0 <+92>: flw fa5,0(a5) + 0x8000bdd2 <+94>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bdd4 <+96>: fmv.w.x fa5,zero + 0x8000bdd8 <+100>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bdda <+102>: fmv.w.x fa5,zero + 0x8000bdde <+106>: j 0x8000bd8e <fused_nn_pad_layout_transform+26> + 0x8000bde0 <+108>: li a0,0 + 0x8000bde2 <+110>: ret + +My code breaks on line 0x8000bd8a and then the mcause register is loaded with value 0x02 which translates to illegal instruction. Please let me know if you need more information about this. + +I also posted this on ZephyrProject in case it is related to the Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026 + +I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same code on qemu riscv64 and didn't have the same problem. Here is the assembly code that is generated for the same operation: + +=> 0x000000008000b446 <+0>: ld a4,0(a0) + 0x000000008000b448 <+2>: ld a5,8(a0) + 0x000000008000b44a <+4>: ld a0,0(a4) + 0x000000008000b44c <+6>: ld a1,0(a5) + 0x000000008000b44e <+8>: li a3,0 + 0x000000008000b450 <+10>: j 0x8000b476 <fused_nn_pad_layout_transform+48> + 0x000000008000b452 <+12>: addiw a5,a3,-2 + 0x000000008000b456 <+16>: li a2,27 + 0x000000008000b458 <+18>: bgeu a2,a5,0x8000b480 <fused_nn_pad_layout_transform+58> + 0x000000008000b45c <+22>: li a2,0 + 0x000000008000b460 <+26>: slliw a5,a3,0x5 + 0x000000008000b464 <+30>: addw a5,a5,a4 + 0x000000008000b466 <+32>: slli a5,a5,0x2 + 0x000000008000b468 <+34>: add a5,a5,a1 + 0x000000008000b46a <+36>: sw a2,0(a5) + 0x000000008000b46c <+38>: addiw a4,a4,1 + 0x000000008000b46e <+40>: li a5,31 + 0x000000008000b470 <+42>: bge a5,a4,0x8000b452 <fused_nn_pad_layout_transform+12> + 0x000000008000b474 <+46>: addiw a3,a3,1 + 0x000000008000b476 <+48>: li a5,31 + 0x000000008000b478 <+50>: blt a5,a3,0x8000b4ac <fused_nn_pad_layout_transform+102> + 0x000000008000b47c <+54>: li a4,0 + 0x000000008000b47e <+56>: j 0x8000b46e <fused_nn_pad_layout_transform+40> + 0x000000008000b480 <+58>: li a5,1 + 0x000000008000b482 <+60>: bge a5,a4,0x8000b4a0 <fused_nn_pad_layout_transform+90> + 0x000000008000b486 <+64>: li a5,29 + 0x000000008000b488 <+66>: blt a5,a4,0x8000b4a6 <fused_nn_pad_layout_transform+96> + 0x000000008000b48c <+70>: li a5,28 + 0x000000008000b48e <+72>: mulw a5,a5,a3 + 0x000000008000b492 <+76>: addw a5,a5,a4 + 0x000000008000b494 <+78>: addiw a5,a5,-58 + 0x000000008000b498 <+82>: slli a5,a5,0x2 + 0x000000008000b49a <+84>: add a5,a5,a0 + 0x000000008000b49c <+86>: lw a2,0(a5) + 0x000000008000b49e <+88>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4a0 <+90>: li a2,0 + 0x000000008000b4a4 <+94>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4a6 <+96>: li a2,0 + 0x000000008000b4aa <+100>: j 0x8000b460 <fused_nn_pad_layout_transform+26> + 0x000000008000b4ac <+102>: li a0,0 + 0x000000008000b4ae <+104>: ret \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1926202 b/results/classifier/gemma3:12b/manual-review/1926202 new file mode 100644 index 00000000..fb45856f --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1926202 @@ -0,0 +1,19 @@ + +qemu-user can't run some ppc binaries + +qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. + +The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: + +$ uname -m +x86_64 +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t qemu-bug:centos -f Dockerfile.centos . +$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . +$ qemu-ppc version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-ppc-static ./helloworld-centos.static.ppc +emu: uncaught target signal 4 (Illegal instruction) - core dumped +[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc + +I can also provide the binary if necessary. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/1930 b/results/classifier/gemma3:12b/manual-review/1930 new file mode 100644 index 00000000..34e8dd84 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/1930 @@ -0,0 +1,47 @@ + +qemu-aarch64 results in segmentation fault while running a test binary compiled for QNX +Description of problem: +We have cross compiled a simple hello world program for QNX SDP 7.1.0 on Ubuntu Focal x86_64. Running the binary using qemu-aarch64 results in segmentation fault error. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` + +We also tried Ubuntu Jammy which has qemu-aarch64 v6.2.0 but got the same error. +Can you tell us how we can emulate the binary using QEMU emulator that is built for QNX on x86_64 platform? Any help would be much appreciated. +Steps to reproduce: +1. Download QNX SDP from QNX software center https://www.qnx.com/download/group.html?programid=29178. +2. Write a simple hello world program. + +``` + #include <stdio.h> + + int main(void) { + return printf("Hello World!"); + } +``` + +3. Source QNX SDP to set some environment variables. + + `$ source ./qnx710/qnxsdp-env.sh` + +4. Compile using the QNX compiler. + + `$ qcc -Vgcc_ntoaarch64le -o hello-world hello-world.c` + +5. Running the binary as it is results to: + +``` + $ ./hello-world + aarch64-binfmt-P: Could not open '/usr/lib/ldqnx-64.so.2': No such file or directory +``` + +5. Running using QEMU emulator results to segmentation fault. + +``` + $ qemu-aarch64 -L /home/vsts/qnx710/target/qnx7/aarch64le ./hello-world + qemu: uncaught target signal 11 (Segmentation fault) - core dumped + Segmentation fault (core dumped) +``` diff --git a/results/classifier/gemma3:12b/manual-review/197 b/results/classifier/gemma3:12b/manual-review/197 new file mode 100644 index 00000000..44403272 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/197 @@ -0,0 +1,2 @@ + +Unpredictable behaviour resulting in User process faults diff --git a/results/classifier/gemma3:12b/manual-review/2011 b/results/classifier/gemma3:12b/manual-review/2011 new file mode 100644 index 00000000..9ddabc4a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2011 @@ -0,0 +1,2 @@ + +ARM emulation layer for Windows x86_64 OS request diff --git a/results/classifier/gemma3:12b/manual-review/2049 b/results/classifier/gemma3:12b/manual-review/2049 new file mode 100644 index 00000000..35147b7d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2049 @@ -0,0 +1,12 @@ + +drive-mirror RBD thin +Description of problem: +I found that this problem was first discovered in 2014. There was a post +[2014 bug description](https://lists.gnu.org/archive/html/qemu-devel/2014-10/msg01231.html )、 +[2014 patch](https://patchwork.ozlabs.org/project/qemu-devel/patch/1433747185-16797-2-git-send-email-famz@redhat.com/) +mentioning this bug. +The patch in the post said that this problem had been solved, but after trying and asking, I found that the problem had not been solved. +Later, I saw this problem in the [2017 bug description](https://forum.proxmox.com/threads/drive-mirror-rbd-thin.33250/#post-613502) forum and it was said that there was a patch to fix it, but it was not. +I tried the latest qemu version and found that this problem has not been solved. +Additional information: +nbd is normal, but rbd is wrong！ diff --git a/results/classifier/gemma3:12b/manual-review/209 b/results/classifier/gemma3:12b/manual-review/209 new file mode 100644 index 00000000..86559b54 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/209 @@ -0,0 +1,2 @@ + +the version number of qemu 6.0.0 is still 5.2.0 diff --git a/results/classifier/gemma3:12b/manual-review/2096 b/results/classifier/gemma3:12b/manual-review/2096 new file mode 100644 index 00000000..ebd4b8b5 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2096 @@ -0,0 +1,2 @@ + +test-x86-cpuid-compat qtest produces warnings on TCG diff --git a/results/classifier/gemma3:12b/manual-review/2097 b/results/classifier/gemma3:12b/manual-review/2097 new file mode 100644 index 00000000..7fa48ab3 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2097 @@ -0,0 +1,2 @@ + +qtest timeouts on cross-i686-tci job diff --git a/results/classifier/gemma3:12b/manual-review/2103 b/results/classifier/gemma3:12b/manual-review/2103 new file mode 100644 index 00000000..f85a86e0 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2103 @@ -0,0 +1,2 @@ + +docs/system/keys.rst.inc still refers to removed options -alt-grab and -ctrl-grab diff --git a/results/classifier/gemma3:12b/manual-review/2112 b/results/classifier/gemma3:12b/manual-review/2112 new file mode 100644 index 00000000..86d2d9eb --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2112 @@ -0,0 +1,27 @@ + +Limited Support for MIPS clone syscall in QEMU User Mode +Description of problem: +Hello, + +I have been working with QEMU user mode to run programs based on the MIPS architecture and have encountered a limitation regarding the support for the MIPS clone syscall in the current implementation of QEMU user mode. Specifically, when invoking the clone syscall with certain flags, it results in the error "errno=22 (Invalid argument)" due to the absence of corresponding handling code in QEMU. + +Upon further investigation, I pinpointed the probable cause. QEMU user mode appears to check if the flags for the clone syscall include all the flags defined in CLONE_THREAD_FLAGS. If there is a mismatch, it returns "-TARGET_EINVAL". + +[source code](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c?ref_type=heads#L6564) + +The current CLONE_THREAD_FLAGS in QEMU are set to include: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | CLONE_SYSVSEM). + +However, in my MIPS program, the flags are only: (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). + +Aligning my MIPS program to include all the flags as per CLONE_THREAD_FLAGS alters the clone syscall's behavior, deviating from the original semantics required by my MIPS program. + +I am seeking guidance on whether there is a way in QEMU user mode's MIPS syscall handling to exclusively use the flags (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND). Alternatively, I am interested in any possible approach to enable support for the MIPS architecture's clone syscall in QEMU user mode. + +Thank you for your time and assistance. +Steps to reproduce: +1. Write a C program that utilizes the clone function, specifying the flags as: CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND. + +strace output: +``` +clone(CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND,child_stack=0x009359a8,parent_tidptr=0x00000f00,tls=0x00000003,child_tidptr=0x2b36d510) = -1 errno=22 (Invalid argument) +``` diff --git a/results/classifier/gemma3:12b/manual-review/2153 b/results/classifier/gemma3:12b/manual-review/2153 new file mode 100644 index 00000000..10cfb826 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2153 @@ -0,0 +1,2 @@ + +ubuntu-20.04-s390x-all CI job is very flaky diff --git a/results/classifier/gemma3:12b/manual-review/2157 b/results/classifier/gemma3:12b/manual-review/2157 new file mode 100644 index 00000000..7f6e2bf0 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2157 @@ -0,0 +1,44 @@ + +qemu-user fails to run 32-bit x86 binaries on hosts with a page size > 4KB +Description of problem: +`qemu-i386` refuses to run 32-bit x86 binaries on hosts with a page size > 4KB +(such as LoongArch, ppc64le, arm64 with 3 level page tables). +Steps to reproduce: +1. Compile x86 binary which makes a single exit(0) syscall: + ``` + cat > exit0.S << EOF + #include <sys/syscall.h> + .text + .global _start + _start: + movl $__NR_exit, %eax + movl $0, %ebx + int $0x80 + EOF + i586-linux-gnu-gcc -nostdlib -static -no-pie -o exit0 exit0.S + ``` + Alternatively one might compile it on a x86 host: + ``` + gcc -m32 -nostdlib -static -no-pie -o exit0 exit0.S + ``` + and transfer the `exit0` binary to ppc64/LoongArch/arm64 system + + 2. Run the `exit0` binary with `qemu-i386` + ``` + qemu-i386-static ./exit0 + ``` + + # +Additional information: +`.text` segment of (32-bit) x86 binaries is typically aligned at 4KB: +``` +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align + LOAD 0x000000 0x08048000 0x08048000 0x00100 0x00100 R 0x1000 + LOAD 0x001000 0x08049000 0x08049000 0x0000c 0x0000c R E 0x1000 + NOTE 0x0000b4 0x080480b4 0x080480b4 0x0004c 0x0004c R 0x4 + GNU_PROPERTY 0x0000d8 0x080480d8 0x080480d8 0x00028 0x00028 R 0x4 +``` + +Thus on a host with a page size being 64 KB (ppc64, arm64 with 3 level page tables) or 16 KB (LoongArch) +alignment requirements in [pbg_dynamic](https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/elfload.c?ref_type=heads#L3020) can not be satisfied. diff --git a/results/classifier/gemma3:12b/manual-review/2267 b/results/classifier/gemma3:12b/manual-review/2267 new file mode 100644 index 00000000..f1e9a88d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2267 @@ -0,0 +1,553 @@ + +Out of bounds access in tx_fifo_push() +Description of problem: +I detected an out-of-bounds access in tx_fifo_push with my fuzzer. + +Stack trace (part):\ +`hw/net/lan9118.c:798:17: runtime error: index 2048 out of bounds for`\ +`type 'uint8_t[2048]' (aka 'unsigned char[2048]')`\ + `#0 0x563ec9a057b1 in tx_fifo_push hw/net/lan9118.c:798:43`\ + `#1 0x563ec99fbb28 in lan9118_writel hw/net/lan9118.c:1042:9`\ + `#2 0x563ec99f2de2 in lan9118_16bit_mode_write hw/net/lan9118.c:1205:9`\ + `#3 0x563ecbf78013 in memory_region_write_accessor system/memory.c:497:5`\ + `#4 0x563ecbf776f5 in access_with_adjusted_size system/memory.c:573:18`\ + `#5 0x563ecbf75643 in memory_region_dispatch_write system/memory.c:1521:16`\ + `#6 0x563ecc01bade in flatview_write_continue_step system/physmem.c:2713:18`\ + `#7 0x563ecc01b374 in flatview_write_continue system/physmem.c:2743:19`\ + `#8 0x563ecbff1c9b in flatview_write system/physmem.c:2774:12`\ + `#9 0x563ecbff1768 in address_space_write system/physmem.c:2894:18`\ +`...` +Steps to reproduce: +Reproducer:\ +export QEMU_ARGS="-display none -machine accel=qtest, -m 512M -machine smdkc210"\ +cat \<\< EOF | ./qemu-system-arm $QEMU_ARGS -qtest /dev/null -qtest stdio\ +outl 0xcf8 0x80000010\ +outl 0xcfc 0x5000000\ +outl 0xcf8 0x80000004\ +outl 0xcfc 0x07\ +writew 0x5000030 0x4918237b\ +writew 0x5000030 0x4918237b\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writew 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writew 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x500003c 0x223bd37f\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000024 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x17954990\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0xcb06897\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +writel 0x5000020 0x6a035c1b\ +EOF +Additional information: +Ack: Chuhong Yuan (hslester96@gmail.com) diff --git a/results/classifier/gemma3:12b/manual-review/2275 b/results/classifier/gemma3:12b/manual-review/2275 new file mode 100644 index 00000000..b5d5977a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2275 @@ -0,0 +1,10 @@ + +qemu crash +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: + diff --git a/results/classifier/gemma3:12b/manual-review/2298 b/results/classifier/gemma3:12b/manual-review/2298 new file mode 100644 index 00000000..a76928ef --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2298 @@ -0,0 +1,13 @@ + +Invariant result in opts-visitor.c +Description of problem: +Expressions: +1) val2 <= INT64_MAX +2) INT64_MIN <= val2 +in line [431](https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/qapi/opts-visitor.c#L431) are always true. + +Seems like this checks are redundant. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/gemma3:12b/manual-review/2367 b/results/classifier/gemma3:12b/manual-review/2367 new file mode 100644 index 00000000..a2288a98 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2367 @@ -0,0 +1,2 @@ + +qemu8.2 check test failed diff --git a/results/classifier/gemma3:12b/manual-review/238 b/results/classifier/gemma3:12b/manual-review/238 new file mode 100644 index 00000000..703dc07c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/238 @@ -0,0 +1,2 @@ + +capstone link failure building linux-user static diff --git a/results/classifier/gemma3:12b/manual-review/2383 b/results/classifier/gemma3:12b/manual-review/2383 new file mode 100644 index 00000000..2a858206 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2383 @@ -0,0 +1,4 @@ + +Support SMRR for x86 emulation +Additional information: + diff --git a/results/classifier/gemma3:12b/manual-review/240 b/results/classifier/gemma3:12b/manual-review/240 new file mode 100644 index 00000000..da82da5d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/240 @@ -0,0 +1,2 @@ + +qemu-3.1.0-rc0: mips emulation hangs when executing invalid instructions diff --git a/results/classifier/gemma3:12b/manual-review/2401 b/results/classifier/gemma3:12b/manual-review/2401 new file mode 100644 index 00000000..d70e48cc --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2401 @@ -0,0 +1,2 @@ + +"-nic none" option has no equivalent in config file diff --git a/results/classifier/gemma3:12b/manual-review/2476 b/results/classifier/gemma3:12b/manual-review/2476 new file mode 100644 index 00000000..15b7b83b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2476 @@ -0,0 +1,53 @@ + +Regression 9.1.0-rc0: Msys2/Clang64 build fails +Description of problem: +Building QEMU in Msys2/Clang64 environment now fails. It is possible with 8.2.0 and 9.0.0 if option "--disable-plugins" is used. + +I suppose this option is broken now: + +``` +[2207/2362] Linking target qemu-system-aarch64.exe +FAILED: qemu-system-aarch64.exe +"cc" "-m64" @qemu-system-aarch64.exe.rsp +lld: error: unknown argument: --dynamic-list=D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/plugins/qemu-plugins.symbols + + +cc: error: linker command failed with exit code 1 (use -v to see invocation) + + +ninja: build stopped: subcommand failed. +make[1]: *** [Makefile:167: run-ninja] Error 1 +make[1]: Leaving directory '/home/Normalo/qemu-9.1.0-rc0/build' +make: *** [GNUmakefile:6: build] Error 2 +``` +Steps to reproduce: +1. tar -xf qemu-9.1.0-rc0.tar.xz +2. cd qemu-9.1.0-rc0 +3. ./configure --target-list=aarch64-softmmu --disable-plugins +4. make +Additional information: +See attached log files [configure.log](/uploads/c56dd6c9064d98d3498923adcd61a4f9/configure.log) and [build.log](/uploads/c3f16160cffcd4a817f0304226db604e/build.log) + +After reverting the last commit on plugins/meson.build the build succeeds, because here the parameter causing the failure (`--dynamic-list`) is only applied, if plugins are enabled. +``` +commit 0082475e26430297ef65e598db5b67c8ac182620 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Thu Jun 6 15:07:23 2024 +0200 + + meson: merge plugin_ldflags into emulator_link_args + + These serve the same purpose, except plugin_ldflags ends up in the linker + command line in a more roundabout way (through specific_ss). Simplify. + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> +``` + +Configuring with plugins enabled fails with: +``` +../plugins/meson.build:28:32: ERROR: Command `D:\msys64plain\clang64\bin/dlltool.EXE --input-def D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/plugins/qemu_plugin_api.def --output-delaylib D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/plugins/libqemu_plugin_api.a --dllname qemu.exe` failed with status 1. + +A full log can be found at D:/msys64plain/home/Normalo/qemu-9.1.0-rc0/build/meson-logs/meson-log.txt + +ERROR: meson setup failed +``` +See attached log files [configure-plugins-enabled.log](/uploads/5ce608791fe9a47165c3fecaddce1aa8/configure-plugins-enabled.log) and [meson-log-plugins-enabled.txt](/uploads/8dc1e95726847270052def5d7b0bd63a/meson-log-plugins-enabled.txt) diff --git a/results/classifier/gemma3:12b/manual-review/2596 b/results/classifier/gemma3:12b/manual-review/2596 new file mode 100644 index 00000000..269ba2a1 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2596 @@ -0,0 +1,2 @@ + +linux-user elf parsing endianness issue (Invalid note in PT_GNU_PROPERTY) diff --git a/results/classifier/gemma3:12b/manual-review/261 b/results/classifier/gemma3:12b/manual-review/261 new file mode 100644 index 00000000..2bfe84e6 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/261 @@ -0,0 +1,2 @@ + +broken signal handling in nios2 user-mode emulation diff --git a/results/classifier/gemma3:12b/manual-review/2650 b/results/classifier/gemma3:12b/manual-review/2650 new file mode 100644 index 00000000..ff54fc10 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2650 @@ -0,0 +1,193 @@ + +qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed +Description of problem: +If a named dirty bitmap already exists on a disk and another disk is added via hotplug after the guest has booted, it will definitely cause the hot migration to fail. +Steps to reproduce: +1. Create 2 images of type qcow2 + + ``` + qemu-img create -f qcow2 vda.qcow2 50G + qemu-img create -f qcow2 vdb.qcow2 2G # set to 2G + ``` +2. Start the guest using the following libvirt xml + + ``` + # virsh create i-btacsctt.xml + + <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm"> + <name>i-btacsctt</name> + <uuid>973f7352-ad1d-31ea-9a9f-237f3e9a384f</uuid> + <memory unit="MiB">2048</memory> + <vcpu current="2">2</vcpu> + <os> + <type arch="x86_64" machine="pc">hvm</type> + </os> + <features> + <acpi/> + <apic/> + <pae/> + </features> + <devices> + <emulator>/opt/qemu-5.1.0.9/usr/bin/qemu-system-x86_64</emulator> + <disk device="disk" type="file"> + <driver cache="writeback" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vda.qcow2"/> + <target dev="vda"/> + </disk> + <disk device="disk" type="file"> + <driver cache="none" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdb.qcow2"/> + <target dev="vdb"/> + </disk> + </devices> + </domain> + ``` +3. Create bitmap for vda + + ``` + # The node name of vda is "libvirt-2-format" + virsh qemu-monitor-command i-btacsctt --hmp "info block" + libvirt-2-format: /tmp/echohu3/vda.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk0/virtio-backend + Cache mode: writethrough + + libvirt-1-format: /tmp/echohu3/vdb.qcow2 (qcow2) + Attached to: /machine/peripheral/virtio-disk1/virtio-backend + Cache mode: writeback, direct + + # Create bitmap + virsh qemu-monitor-command i-btacsctt '{"execute":"block-dirty-bitmap-add","arguments":{"node":"libvirt-2-format","name":"bitmap0","persistent":true}}' + ``` +4. Create vdc and run hotpluggin + + ``` + qemu-img create -f qcow2 vdc.qcow2 50G + + cat disk.xml + <disk device="disk" type="file"> + <driver cache="none" discard="ignore" io="threads" name="qemu" type="qcow2"/> + <source file="/tmp/echohu3/vdc.qcow2"/> + <target dev="vdc"/> + </disk> + + virsh attach-device i-btacsctt disk.xml + ``` +5. Start live migrationg + + ``` + # scp *.qcow2 172.31.68.42:/tmp/echohu3/ + virsh qemu-monitor-command i-btacsctt --hmp "migrate_set_capability dirty-bitmaps on" + virsh dumpxml --migratable i-btacsctt >/tmp/ivm-btacsctt.xml + virsh migrate --live --abort-on-error --xml /tmp/ivm-btacsctt.xml i-btacsctt qemu+tcp://172.31.68.42/system + error: internal error: qemu unexpectedly closed the monitor: qemu-system-x86_64: util/hbitmap.c:614: serialization_chunk: Assertion `(last >> hb->granularity) < hb->size' failed. + ``` +Additional information: +Set breakpoints on the source side + +``` +gdb -p $pid -ex "break add_bitmaps_to_list" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 add_bitmaps_to_list (bs=bs@entry=0x55c5bbaf85d0, bs_name=0x55c5bbafc674 "libvirt-2-format", alias_map=alias_map@entry=0x0, s=<optimized out>) at migration/block-dirty-bitmap.c:502 +#1 0x000055c5ba3b2878 in init_dirty_bitmap_migration (s=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:660 +#2 dirty_bitmap_save_setup (f=0x55c5bc981c40, opaque=0x55c5bb11a080 <dbm_state>) at migration/block-dirty-bitmap.c:1226 +#3 0x000055c5ba3a3c4d in qemu_savevm_state_setup (f=0x55c5bc981c40) at migration/savevm.c:1176 +#4 0x000055c5ba39e16b in migration_thread (opaque=opaque@entry=0x55c5bbaa2400) at migration/migration.c:3487 +#5 0x000055c5ba530cf3 in qemu_thread_start (args=<optimized out>) at util/qemu-thread-posix.c:521 +#6 0x00007f39846d9609 in start_thread (arg=<optimized out>) at pthread_create.c:477 +#7 0x00007f3983d11293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 +(gdb) p bs->node_name +$4 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p bitmap->name +$5 = 0x55c5bbaf13d0 "bitmap0" +``` + +Set a breakpoint on the target side after hitting the breakpoint on the source side. + +``` +gdb -p $pid -ex "break serialization_chunk if ((start + count - 1) >> hb->granularity) >= hb->size" -ex "break dirty_bitmap_load_header" -ex "handle SIGUSR1 nostop" -ex "continue" +(gdb) bt +#0 dirty_bitmap_load_header (alias_map=0x0, s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:1146 +#1 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1187 +#2 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#3 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#4 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#5 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#6 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#7 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#8 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#9 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +``` + +in dirty_bitmap_load_header + +``` +s->bs = bdrv_lookup_bs(s->node_name, s->node_name, &local_err); // node_name is "libvirt-2-format" +s->bitmap = bdrv_find_dirty_bitmap(s->bs, s->bitmap_name); // bitmap_name is "bitmap0" + +# Target side: “libvirt-2-format” is the node name of vdb. +(gdb) p s->bs->node_name +$10 = "libvirt-2-format", '\000' <repeats 15 times> +(gdb) p s->bs->filename +$11 = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times> +``` + +We can also see from the target /var/log/libvirt/qemu/i-btacsctt.log file that “libvirt-2-format” is the node name of the vdb，while the node name of vda is libvirt-3-format. + +``` +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vda.qcow2","aio":"threads","node-name":"libvirt-3-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":false,"discard":"ignore","cache":{"direct":false,"no-flush":false},"driver":"qcow2","file":"libvirt-3-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x2,drive=libvirt-3-format,id=virtio-disk0,bootindex=1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdb.qcow2","aio":"threads","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \ +-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-2-format,id=virtio-disk1,write-cache=on \ +-blockdev '{"driver":"file","filename":"/tmp/echohu3/vdc.qcow2","aio":"threads","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"ignore","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":null}' \ +``` + +From the source code, we know that HBitmap.size is from vdb size (2G), but bitmap is from vda (50G), so it triggers assert exception in serialization_chunk. + +``` +(gdb) bt +#0 serialization_chunk (hb=hb@entry=0x55748ba28470, start=2147483648, count=536870912, first_el=first_el@entry=0x7f53503ffd20, el_count=el_count@entry=0x7f53503ffd18) at util/hbitmap.c:610 +#1 0x0000557487f18654 in hbitmap_deserialize_zeroes (hb=0x55748ba28470, start=start@entry=2147483648, count=count@entry=536870912, finish=finish@entry=false) at util/hbitmap.c:701 +#2 0x0000557487e7cfb0 in bdrv_dirty_bitmap_deserialize_zeroes (bitmap=<optimized out>, offset=offset@entry=2147483648, bytes=bytes@entry=536870912, finish=finish@entry=false) at block/dirty-bitmap.c:749 +#3 0x0000557487d86b51 in dirty_bitmap_load_bits (s=0x557488aef0a8 <dbm_state+40>, f=0x55748bcfd8f0) at migration/block-dirty-bitmap.c:992 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +#5 0x0000557487d7759a in vmstate_load (se=0x55748adfb8b0, f=0x55748bcfd8f0) at migration/savevm.c:883 +#6 vmstate_load (f=0x55748bcfd8f0, se=0x55748adfb8b0) at migration/savevm.c:879 +#7 0x0000557487d79fdd in qemu_loadvm_section_part_end (mis=0x55748ad55be0, f=0x55748bcfd8f0) at migration/savevm.c:2365 +#8 qemu_loadvm_state_main (f=f@entry=0x55748bcfd8f0, mis=mis@entry=0x55748ad55be0) at migration/savevm.c:2518 +#9 0x0000557487d7b2ad in qemu_loadvm_state (f=0x55748bcfd8f0) at migration/savevm.c:2590 +#10 0x0000557487d7078f in process_incoming_migration_co (opaque=<optimized out>) at migration/migration.c:480 +#11 0x0000557487f15283 in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:173 +#12 0x00007f5360189660 in __start_context () at ../sysdeps/unix/sysv/linux/x86_64/__start_context.S:91 +#13 0x00007ffffb29c410 in () +#14 0x0000000000000000 in () +(gdb) p *hb +$16 = {orig_size = 2147483648, size = 32768, count = 0, granularity = 16, meta = 0x0, levels = {0x55748ad55ad0, 0x55748acd8df0, 0x55748b0866a0, 0x55748acf8c10, 0x55748b1c4180, 0x55748b154f60, 0x55748adf2370}, sizes = {1, 1, 1, 1, 1, 8, + 512}} +``` + +``` +(gdb) f 4 +#4 dirty_bitmap_load (f=0x55748bcfd8f0, opaque=0x557488aef080 <dbm_state>, version_id=<optimized out>) at migration/block-dirty-bitmap.c:1198 +(gdb) p *s->bs +$21 = {open_flags = 10274, read_only = false, encrypted = false, sg = false, probed = false, force_share = false, implicit = false, drv = 0x557488aa2ee0 <bdrv_qcow2>, opaque = 0x55748acf8c90, aio_context = 0x55748acd1080, + aio_notifiers = {lh_first = 0x0}, walking_aio_notifiers = false, filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing_file = '\000' <repeats 4095 times>, auto_backing_file = '\000' <repeats 4095 times>, + backing_format = '\000' <repeats 15 times>, full_open_options = 0x55748b3c68e0, exact_filename = "/tmp/echohu3/vdb.qcow2", '\000' <repeats 4073 times>, backing = 0x0, file = 0x55748aa5de40, bl = {request_alignment = 1, + max_pdiscard = 0, pdiscard_alignment = 65536, max_pwrite_zeroes = 0, pwrite_zeroes_alignment = 65536, opt_transfer = 0, max_transfer = 0, min_mem_alignment = 512, opt_mem_alignment = 4096, max_iov = 1024}, supported_write_flags = 0, + supported_zero_flags = 260, supported_truncate_flags = 2, node_name = "libvirt-2-format", '\000' <repeats 15 times>, node_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0e8}}, + bs_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d0f8}}, monitor_list = {tqe_next = 0x55748adeb060, tqe_circ = {tql_next = 0x55748adeb060, tql_prev = 0x55748ad4d108}}, refcnt = 2, + op_blockers = {{lh_first = 0x0} <repeats 16 times>}, inherits_from = 0x0, children = {lh_first = 0x55748aa5de40}, parents = {lh_first = 0x55748bbc0380}, options = 0x55748ad4d2d0, explicit_options = 0x55748ad525a0, + detect_zeroes = BLOCKDEV_DETECT_ZEROES_OPTIONS_OFF, backing_blocker = 0x0, total_sectors = 4194304, before_write_notifiers = {notifiers = {lh_first = 0x0}}, write_threshold_offset = 0, write_threshold_notifier = {notify = 0x0, node = { + le_next = 0x0, le_prev = 0x0}}, dirty_bitmap_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 39 times>, __align = 0}, initialized = true}, dirty_bitmaps = {lh_first = 0x55748b4655f0}, wr_highest_offset = {value = 0}, copy_on_read = 0, in_flight = 0, serialising_in_flight = 0, io_plugged = 0, + enable_write_cache = 0, quiesce_counter = 0, recursive_quiesce_counter = 0, write_gen = 0, reqs_lock = {locked = 0, ctx = 0x0, from_push = {slh_first = 0x0}, to_pop = {slh_first = 0x0}, handoff = 0, sequence = 0, holder = 0x0}, + tracked_requests = {lh_first = 0x0}, flush_queue = {entries = {sqh_first = 0x0, sqh_last = 0x55748ad52570}}, active_flush_req = false, flushed_gen = 0, never_freeze = false} +``` + +When we merge into commit https://gitlab.com/qemu-project/qemu/-/commit/31e4c354b38cd42a051ad030eb7779d5e7ee32fe and then run `block-bitmap-mapping` before migration, the hot migration can be completed successfully. I would like to confirm with the community whether this solution is reasonable and if there are any other solutions to address this issue. + +``` +virsh qemu-monitor-command i-btacsctt '{"execute": "migrate-set-parameters", "arguments":{"block-bitmap-mapping":[{"node-name":"libvirt-2-format", "alias":"libvirt-3-format","bitmaps":[{"name":"bitmap0", "alias":"bitmap0"}]}]}}' +``` diff --git a/results/classifier/gemma3:12b/manual-review/271 b/results/classifier/gemma3:12b/manual-review/271 new file mode 100644 index 00000000..1f580069 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/271 @@ -0,0 +1,2 @@ + +ARM cpu emulation regression on QEMU 4.2.0 diff --git a/results/classifier/gemma3:12b/manual-review/275 b/results/classifier/gemma3:12b/manual-review/275 new file mode 100644 index 00000000..8feddf4f --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/275 @@ -0,0 +1,2 @@ + +Error in user-mode calculation of ELF aux vector's AT_PHDR diff --git a/results/classifier/gemma3:12b/manual-review/276 b/results/classifier/gemma3:12b/manual-review/276 new file mode 100644 index 00000000..669b5872 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/276 @@ -0,0 +1,2 @@ + +Error in user-mode calculation of ELF program's brk diff --git a/results/classifier/gemma3:12b/manual-review/2890 b/results/classifier/gemma3:12b/manual-review/2890 new file mode 100644 index 00000000..0cbe31ef --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/2890 @@ -0,0 +1,2 @@ + +RFE: Individual ON_SHUTDOWN diff --git a/results/classifier/gemma3:12b/manual-review/312 b/results/classifier/gemma3:12b/manual-review/312 new file mode 100644 index 00000000..424b7794 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/312 @@ -0,0 +1,2 @@ + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/gemma3:12b/manual-review/327 b/results/classifier/gemma3:12b/manual-review/327 new file mode 100644 index 00000000..dec95417 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/327 @@ -0,0 +1,2 @@ + +Storage | Two decimal digits precision diff --git a/results/classifier/gemma3:12b/manual-review/367 b/results/classifier/gemma3:12b/manual-review/367 new file mode 100644 index 00000000..38b228c0 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/367 @@ -0,0 +1,2 @@ + +qemu-system-aarch64 crash on qemu 6.0 - Windows 10 diff --git a/results/classifier/gemma3:12b/manual-review/385 b/results/classifier/gemma3:12b/manual-review/385 new file mode 100644 index 00000000..97ce257c --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/385 @@ -0,0 +1,2 @@ + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/gemma3:12b/manual-review/555 b/results/classifier/gemma3:12b/manual-review/555 new file mode 100644 index 00000000..1dd663b5 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/555 @@ -0,0 +1,2 @@ + +qemu user aarch64 crashes when giving the dynamic loader as argument diff --git a/results/classifier/gemma3:12b/manual-review/567 b/results/classifier/gemma3:12b/manual-review/567 new file mode 100644 index 00000000..0df16f8f --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/567 @@ -0,0 +1,2 @@ + +qemu 6.1.0 build fail on alpine linux diff --git a/results/classifier/gemma3:12b/manual-review/577 b/results/classifier/gemma3:12b/manual-review/577 new file mode 100644 index 00000000..a94b9ad0 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/577 @@ -0,0 +1,26 @@ + +getdtablesize() returns wrong value in qemu user mode on Linux/alpha +Description of problem: +The `getdtablesize()` function returns a value that is too large. Namely, `getdtablesize() - 1` ought to be a valid file descriptor, but is not. +Steps to reproduce: +[foo.c](/uploads/7a9e99d3811fe4a7eef183ed98c966a4/foo.c) + +1. +``` +# apt install g++-10-alpha-linux-gnu +``` +2. +``` +$ alpha-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/4fffa6dd2332885f51e4030dcbe25644/a.out) + +3. Transfer the a.out file to a Linux/alpha machine; execute it there. The return code is 0. +4. +``` +$ QEMU_LD_PREFIX=/usr/alpha-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-alpha ./a.out ; echo $? +``` +Expected: `0` +Actual: `1` +Additional information: + diff --git a/results/classifier/gemma3:12b/manual-review/578 b/results/classifier/gemma3:12b/manual-review/578 new file mode 100644 index 00000000..e82ed3f7 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/578 @@ -0,0 +1,31 @@ + +getdomainname() is not implemented in QEMU user mode on Linux/sparc64 +Description of problem: +The `getdomainname()` function fails, instead of succeeding. +Steps to reproduce: +[foo.c](/uploads/7586c9aab788855b232a5c2f6aaeb4fc/foo.c) + +1. +``` +# apt install g++-10-sparc64-linux-gnu +# mkdir -p /usr/sparc64-linux-gnu/etc +# touch /usr/sparc64-linux-gnu/etc/ld.so.cache +``` +2. +``` +$ sparc64-linux-gnu-gcc-10 -Wall -static foo.c +``` +[a.out](/uploads/39d291b95caa182d74b0b622a82667e8/a.out) + +3. Transfer the a.out file to a Linux/sparc64 machine; execute it there. It prints +``` +result: (none) +``` +4. +``` +$ QEMU_LD_PREFIX=/usr/sparc64-linux-gnu ~/inst-qemu/6.1.0/bin/qemu-sparc64 ./a.out +``` +Expected: `result: (none)` +Actual: `getdomainname: Function not implemented` +Additional information: + diff --git a/results/classifier/gemma3:12b/manual-review/582 b/results/classifier/gemma3:12b/manual-review/582 new file mode 100644 index 00000000..9202a4d4 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/582 @@ -0,0 +1,2 @@ + +Possible regression in qemu-user-static v5.7 from Fedora 34 Repo? diff --git a/results/classifier/gemma3:12b/manual-review/616 b/results/classifier/gemma3:12b/manual-review/616 new file mode 100644 index 00000000..bab55454 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/616 @@ -0,0 +1,108 @@ + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/gemma3:12b/manual-review/645 b/results/classifier/gemma3:12b/manual-review/645 new file mode 100644 index 00000000..fc7f1a1a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/645 @@ -0,0 +1,2 @@ + +Centos6.8 compiling qeum-2.12.0 failed, Does centos6.8 not support qeum-2.12.0? diff --git a/results/classifier/gemma3:12b/manual-review/67 b/results/classifier/gemma3:12b/manual-review/67 new file mode 100644 index 00000000..07240fbd --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/67 @@ -0,0 +1,2 @@ + +incomplete emulation of fstenv under TCG diff --git a/results/classifier/gemma3:12b/manual-review/746 b/results/classifier/gemma3:12b/manual-review/746 new file mode 100644 index 00000000..2fc62d1d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/746 @@ -0,0 +1,2 @@ + +Current file VERSION of tag 6.2.0-rc2 contains 6.2.92, not 6.1.92 diff --git a/results/classifier/gemma3:12b/manual-review/788701 b/results/classifier/gemma3:12b/manual-review/788701 new file mode 100644 index 00000000..c0742a3d --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/788701 @@ -0,0 +1,11 @@ + +qemu-user fails to run rpcgen (i386, x86_64) + +Confirmed on qemu current development tree (git commit aa29141). While trying to run eglibc's rpcgen from native system by qemu-user, I get an error: + +qemu-x86_64 /usr/bin/rpcgen -c /dev/null +fork: Invalid argument + +I am running a Debian Wheezy system and rpcgen comes from libc-dev-bin. Just in case I am attaching my rpcgen binaries from i386 and x86_64 systems. + +Very similar problem was mentioned on the QEMU forum on February 2007, so I guess it might be a known issue. Nevertheless, I was unable to find any information about bug reports, fixes nor workarounds for it so I'm reporting it here. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/manual-review/794 b/results/classifier/gemma3:12b/manual-review/794 new file mode 100644 index 00000000..b601f8e2 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/794 @@ -0,0 +1,10 @@ + +Documentation: Broken links to removed features in old changelog pages +Description of problem: +In QEMU changelogs prior to 6.1 (notably 6.0 at least) the removed features link goes to https://qemu-project.gitlab.io/qemu/system/removed-features.html instead of https://qemu-project.gitlab.io/qemu/about/removed-features.html. The deprecated features links are also broken. + +This caused me some amount of confusion while trying to find the cause of several emulation issues. +Additional information: +Would have fixed myself but I cannot create a QEMU wiki account to do so. If there is a process for approval for that I will happily follow it and fix the issue when approved. I also can't see anywhere else to report this so apologies if this is the wrong place. + +Perhaps the main changelog page could include links to the removed and deprecated features pages too? diff --git a/results/classifier/gemma3:12b/manual-review/82 b/results/classifier/gemma3:12b/manual-review/82 new file mode 100644 index 00000000..a5495469 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/82 @@ -0,0 +1,2 @@ + +[Feature request] acceptance test class to run user-mode binaries diff --git a/results/classifier/gemma3:12b/manual-review/867 b/results/classifier/gemma3:12b/manual-review/867 new file mode 100644 index 00000000..704dad52 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/867 @@ -0,0 +1,14 @@ + +qemu-system-x86_64: warning: usb-redir connection broken during migration +Description of problem: +Create Snapshot, Restore snapshot, crash +Steps to reproduce: +1. Create Snapshot +2. Restore Snapshot +3. Crash +Additional information: + + +No redirecting: + + diff --git a/results/classifier/gemma3:12b/manual-review/914 b/results/classifier/gemma3:12b/manual-review/914 new file mode 100644 index 00000000..0dd1113a --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/914 @@ -0,0 +1,2 @@ + +Raspi4 emulation diff --git a/results/classifier/gemma3:12b/manual-review/918 b/results/classifier/gemma3:12b/manual-review/918 new file mode 100644 index 00000000..0b159b79 --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/918 @@ -0,0 +1,2 @@ + +TILE Cpu Host & Emulator support? diff --git a/results/classifier/gemma3:12b/manual-review/922 b/results/classifier/gemma3:12b/manual-review/922 new file mode 100644 index 00000000..93a55b9b --- /dev/null +++ b/results/classifier/gemma3:12b/manual-review/922 @@ -0,0 +1,21 @@ + +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 /]# +``` |