summary refs log tree commit diff stats
path: root/results/classifier/108/other/142
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/14216
-rw-r--r--results/classifier/108/other/142054
-rw-r--r--results/classifier/108/other/142230
-rw-r--r--results/classifier/108/other/1422285122
-rw-r--r--results/classifier/108/other/142328
-rw-r--r--results/classifier/108/other/142352848
-rw-r--r--results/classifier/108/other/142366829
-rw-r--r--results/classifier/108/other/1424118
-rw-r--r--results/classifier/108/other/142423771
-rw-r--r--results/classifier/108/other/142599
-rw-r--r--results/classifier/108/other/142559746
-rw-r--r--results/classifier/108/other/142653
-rw-r--r--results/classifier/108/other/142609255
-rw-r--r--results/classifier/108/other/142659358
-rw-r--r--results/classifier/108/other/142835265
-rw-r--r--results/classifier/108/other/1428657176
-rw-r--r--results/classifier/108/other/1428958107
-rw-r--r--results/classifier/108/other/142970
-rw-r--r--results/classifier/108/other/142903440
-rw-r--r--results/classifier/108/other/1429841134
20 files changed, 1419 insertions, 0 deletions
diff --git a/results/classifier/108/other/142 b/results/classifier/108/other/142
new file mode 100644
index 00000000..c742d44f
--- /dev/null
+++ b/results/classifier/108/other/142
@@ -0,0 +1,16 @@
+performance: 0.721
+device: 0.699
+network: 0.494
+other: 0.325
+permissions: 0.302
+PID: 0.208
+semantic: 0.203
+graphic: 0.156
+socket: 0.155
+vnc: 0.154
+files: 0.135
+debug: 0.121
+boot: 0.084
+KVM: 0.053
+
+qemu -readconfig/-writeconfig cannot handle quotes in values
diff --git a/results/classifier/108/other/1420 b/results/classifier/108/other/1420
new file mode 100644
index 00000000..ebd0a4e4
--- /dev/null
+++ b/results/classifier/108/other/1420
@@ -0,0 +1,54 @@
+graphic: 0.851
+device: 0.736
+files: 0.591
+performance: 0.559
+PID: 0.555
+socket: 0.532
+debug: 0.440
+permissions: 0.363
+semantic: 0.349
+vnc: 0.280
+network: 0.255
+other: 0.252
+boot: 0.165
+KVM: 0.084
+
+Missing path for pkg-config on amd64 debian based distros
+Description of problem:
+This error occurs when attempting to configure qemu from git :
+```error
+ERROR: glib-2.56 gthread-2.0 is required to compile QEMU
+```
+
+Although it seems to be as simple as "_just install the dev lib!!!_" it is not that simple.
+
+1. First of all, my system already has the library installed :
+   ```sh
+   dpkg -l | grep libglib2.0-dev
+   ii  libglib2.0-dev:amd64                          2.74.4-1                            amd64        Development files for the GLib library
+   ii  libglib2.0-dev-bin                            2.74.4-1                            amd64        Development utilities for the GLib library
+   ```
+1. Second, the file required by _pkg-config_ does exist aswell :
+   ```sh
+   ls /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc -l
+   -rw-r--r-- 1 root root 240 dez 27 20:42 /usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc
+   ```
+1. Finally, the real problem is that pkg-config is not able to identify it **unless** you specify the _x86-64_ dir :
+   - Default usage. It fails.
+      ```sh
+      pkg-config --modversion gthread-2.0
+      Package gthread-2.0 was not found in the pkg-config search path.
+      Perhaps you should add the directory containing `gthread-2.0.pc'
+      to the PKG_CONFIG_PATH environment variable
+      Package 'gthread-2.0', required by 'virtual:world', not found
+      ```
+   - Fixed usage (temp)
+      ```sh
+      env PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/lib/x86_64-linux-gnu/pkgconfig/" pkg-config --modversion gthread-2.0
+      2.74.4
+      ```
+Steps to reproduce:
+1. clone qemu (master)
+2. try to run _configure_
+Additional information:
+Of course it seems to be a problem related to the program _pkg-config_ itself, or even by the distro's package, but it totally prevents any build of qemu in a debian-based distro, with architecture _amd64_.
diff --git a/results/classifier/108/other/1422 b/results/classifier/108/other/1422
new file mode 100644
index 00000000..a7f26f8c
--- /dev/null
+++ b/results/classifier/108/other/1422
@@ -0,0 +1,30 @@
+permissions: 0.734
+network: 0.649
+PID: 0.638
+device: 0.638
+graphic: 0.627
+socket: 0.597
+other: 0.592
+files: 0.560
+vnc: 0.554
+semantic: 0.542
+KVM: 0.535
+performance: 0.496
+debug: 0.472
+boot: 0.417
+
+/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q'
+Description of problem:
+Qemu 7.2.0 doesn't build on powerpc64le.
+Steps to reproduce:
+Build qemu.
+Additional information:
+```
+FAILED: libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o 
+cc -m64 -mlittle-endian -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/pixman-1 -I/usr/local/include -I/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/include -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -MF libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o.d -o libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -c ../tcg/tcg.c
+In file included from ../tcg/tcg.c:432:
+/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q'
+    asm("mr  %%r6, %1\n\t"
+        ^
+1 error generated.
+```
diff --git a/results/classifier/108/other/1422285 b/results/classifier/108/other/1422285
new file mode 100644
index 00000000..d0088da8
--- /dev/null
+++ b/results/classifier/108/other/1422285
@@ -0,0 +1,122 @@
+other: 0.922
+debug: 0.914
+semantic: 0.896
+performance: 0.889
+permissions: 0.887
+socket: 0.882
+PID: 0.879
+graphic: 0.878
+device: 0.872
+files: 0.868
+network: 0.858
+vnc: 0.851
+boot: 0.851
+KVM: 0.821
+
+The guest will be destroyed when hot plug the VF to guest for the second time.
+
+Environment:
+------------
+Host OS (ia32/ia32e/IA64):ia32e
+Guest OS (ia32/ia32e/IA64):ia32e
+Guest OS Type (Linux/Windows):linux
+kvm.git Commit: 6557bada461afeaa920a189fae2cff7c8fdce39f
+qemu.kvm Commit: cd2d5541271f1934345d8ca42f5fafff1744eee7
+Host Kernel Version:3.19.0-rc3
+Hardware:Haswell_EP,Ivytown_EP
+
+
+Bug detailed description:
+--------------------------
+create guest , then hot plug the VF to the guest for the second time, the guest will be destroyed.
+
+note:
+1. hot plug the device to guest with vfio, the guest works fine
+2.this should be a qemu bug:
+kvm      +  qemu     = result
+6557bada +  cd2d5541 = bad
+6557bada +  a805ca54 = good
+
+
+Reproduce steps:
+----------------
+1. qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow
+2. echo "device_add pci-assign,host=03:10.1,id=nic" >/dev/pts/2
+3. cat /dev/pts/2 &
+4. echo "device_del nic" >/dev/pts/2
+5. echo "device_add pci-assign,host=03:10.0,id=nic" >/dev/pts/2
+
+Current result:
+----------------
+guest will be destroyed when hot plug the vf to guest for the second time.
+
+Expected result:
+----------------
+guest works fine when hot plug the vf to guest for the second time
+
+Basic root-causing log:
+----------------------
+[root@vt-hsw2 cathy]# qemu-system-x86_64 -enable-kvm -m 2G -net none -monitor pty rhel6u5.qcow 
+char device redirected to /dev/pts/2 (label compat_monitor0)
+Segmentation fault (core dumped)
+
+
+some dmesg log:
+
+pci-stub 0000:03:10.1: kvm deassign device
+pci-stub 0000:03:10.1: enabling device (0000 -> 0002)
+qemu-system-x86[9894]: segfault at 0 ip           (null) sp 00007fa73df0cae8 error 14
+pci-stub 0000:03:10.1: kvm assign device
+
+the first bad commit is:
+commit ec6f25e788ef57ce1e9f734984ef8885172fd9e2
+Merge: 007c99f 9ef1473
+Author: Peter Maydell <email address hidden>
+Date:   Tue Feb 3 21:37:16 2015 +0000
+
+    Merge remote-tracking branch 'remotes/rth/tags/pull-tg-s390-20150203' into staging
+    
+    s390 translator bug fixes
+    
+    # gpg: Signature made Tue 03 Feb 2015 20:39:15 GMT using RSA key ID 4DD0279B
+    # gpg: Good signature from "Richard Henderson <email address hidden>"
+    # gpg:                 aka "Richard Henderson <email address hidden>"
+    # gpg:                 aka "Richard Henderson <email address hidden>"
+    
+    * remotes/rth/tags/pull-tg-s390-20150203:
+      target-s390x: fix and optimize slb* and slbg* computation of carry/borrow flag
+      target-s390x: support OC and NC in the EX instruction
+      disas/s390.c: Remove unused variables
+      target-s390x: Mark check_privileged() as !CONFIG_USER_ONLY
+      target-s390: Implement ECAG
+      target-s390: Implement LURA, LURAG, STURG
+      target-s390: Fix STURA
+      target-s390: Fix STIDP
+      target-s390: Implement EPSW
+      target-s390: Implement SAM specification exception
+    
+    Signed-off-by: Peter Maydell <email address hidden>
+
+please ignore comment 1.
+
+the first bad commit:
+
+commit 374f2981d1f10bc4307f250f24b2a7ddb9b14be0
+Author: Paolo Bonzini <email address hidden>
+Date:   Fri May 17 12:37:03 2013 +0200
+
+    memory: protect current_map by RCU
+    
+    Replace the flat_view_mutex with RCU, avoiding futex contention for
+    dataplane on large systems and many iothreads.
+    
+    Reviewed-by: Fam Zheng <email address hidden>
+    Signed-off-by: Paolo Bonzini <email address hidden>
+
+
+
+kvm.git + qemu.git:4ff6f8e6_3d30395f
+host kernel:4.0.0_rc1
+test on Haswell_EP
+when hot plug the vf to guest for the second time, the guest works fine.
+
diff --git a/results/classifier/108/other/1423 b/results/classifier/108/other/1423
new file mode 100644
index 00000000..5c9417cc
--- /dev/null
+++ b/results/classifier/108/other/1423
@@ -0,0 +1,28 @@
+graphic: 0.913
+device: 0.907
+PID: 0.791
+semantic: 0.726
+debug: 0.632
+permissions: 0.629
+boot: 0.621
+performance: 0.610
+files: 0.567
+vnc: 0.549
+other: 0.522
+socket: 0.475
+network: 0.423
+KVM: 0.103
+
+QEMU 6.2.0 fullscreen problem
+Description of problem:
+After running the command above, clicking on "Try Ubuntu" and adjusting the guest display resolution in GNOME to the native resolution, pressing ctrl+alt+f yields a "fullscreen" that only covers the QEMU window but not the entire host screen. This is not the case when switching to fullscreen while the boot screen is active or running `qemu-system-x86_64 -display gtk,full-screen=on`. 
+
+The problem also occurs when replacing `-device qxl-vga` by `-device VGA,vgamem_mb=64`. The problem however does not occur when using `-device virtio-vga` instead of `-device qxl-vga` or `-display sdl` instead of `-display gtk`.
+Steps to reproduce:
+1. Run the command above
+2. Click "Try Ubuntu"
+3. Set guest resolution to native resolution (1920x1200 in my case)
+4. Move the window a bit off the corners to observe the effect
+5. Press ctrl+alt+f
+Additional information:
+The bug has also been [reported here](https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2000739).
diff --git a/results/classifier/108/other/1423528 b/results/classifier/108/other/1423528
new file mode 100644
index 00000000..96aa094b
--- /dev/null
+++ b/results/classifier/108/other/1423528
@@ -0,0 +1,48 @@
+device: 0.801
+graphic: 0.517
+semantic: 0.501
+PID: 0.439
+performance: 0.350
+other: 0.349
+KVM: 0.324
+network: 0.313
+boot: 0.239
+permissions: 0.232
+socket: 0.217
+debug: 0.151
+files: 0.135
+vnc: 0.120
+
+ setting unsupported timeout for i6300esb watchdog causes hw reset
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778291
+Version: 2.1
+
+systemd utilizes existing watchdog hardware and set's a 10min timer on reboot.
+The i6300esb under qemu doesn't like such a timeout, and immediately resets the hardware:
+
+The last message one gets is
+[    9.402243] i6300esb: Unexpected close, not stopping watchdog!
+
+
+The linked bug report contains information how this bug can easily be reproduced.
+With any image using a recent enough systemd as PID 1 you should be able to reproduce it by running
+
+qemu-system-x86_64 -curses -enable-kvm -device i6300esb -watchdog-action reset -hda <image with systemd>
+
+
+I'm uncertain if this is a qemu or kernel/driver bug. If the latter, please re-assign the bug as necessary.
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+There's nothing changed in i6300esb about this issue. I can reproduce it exactly the same way with current qemu 5.1-tobe
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/112
+
+
diff --git a/results/classifier/108/other/1423668 b/results/classifier/108/other/1423668
new file mode 100644
index 00000000..52b242ba
--- /dev/null
+++ b/results/classifier/108/other/1423668
@@ -0,0 +1,29 @@
+device: 0.693
+graphic: 0.520
+socket: 0.480
+network: 0.449
+vnc: 0.445
+semantic: 0.395
+performance: 0.383
+KVM: 0.282
+permissions: 0.221
+PID: 0.204
+boot: 0.160
+debug: 0.145
+files: 0.113
+other: 0.061
+
+Unable to set scsi drive serial if it contains spaces.
+
+I am virtualzing a physical server for which I need to set the SCSI/SATA drive serial.  It is comprised of 12 " " spaces then 8 letter/digits.  If I exclude the spaces, the drive serial is not accurate.  If I include the spaces I get the following error.
+
+error: Failed to start domain test1
+error: internal error: driver serial '            ABCD1234' contains unsafe characters
+
+virsh edit
+Centos 7.0
+3.19.0-1.el7.elrepo.x86_64
+QEMU emulator version 1.5.3 (qemu-kvm-1.5.3-60.el7.centos.7), Copyright (c) 2003-2008 Fabrice Bellard
+
+This error message comes from libvirt, not from QEMU, so please report the error there if it still persists: https://libvirt.org/bugs.html
+
diff --git a/results/classifier/108/other/1424 b/results/classifier/108/other/1424
new file mode 100644
index 00000000..58df6acd
--- /dev/null
+++ b/results/classifier/108/other/1424
@@ -0,0 +1,118 @@
+other: 0.828
+debug: 0.778
+vnc: 0.753
+permissions: 0.746
+performance: 0.743
+KVM: 0.740
+semantic: 0.729
+graphic: 0.724
+network: 0.707
+PID: 0.704
+device: 0.691
+socket: 0.669
+boot: 0.643
+files: 0.635
+
+Overflow in xlnx_dp_aux_push_tx_fifo()
+Description of problem:
+Invoking xlnx_dp_aux_push_tx_fifo() 17 times overflow the s->tx_fifo.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x666e0fa2
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x66554466
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+writel 0xfd4a0104 0x6fed53ba
+EOF
+```
+Additional information:
+```
+root@621cbd136b6f:~/bugs/metadata/xlnx_dp-07# bash -x xlnx_dp-07.videzzo 
++ DEFAULT_INPUT_MAXSIZE=10000000
++ ./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp -max_len=10000000 -detect_leaks=0 ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized
+==47609==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x564c9e37c2b0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 2128347645
+INFO: Loaded 1 modules   (600768 inline 8-bit counters): 600768 [0x564ca198f000, 0x564ca1a21ac0), 
+INFO: Loaded 1 PC tables (600768 PCs): 600768 [0x564ca1063b10,0x564ca198e710), 
+./qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *.core*, *.v_blend*, *.av_buffer_manager*, *.audio*
+This process will fuzz the following MemoryRegions:
+  * xlnx.v-dp.core[0] (size 3b0)
+  * xlnx.v-dp.v_blend[0] (size 1e0)
+  * xlnx.v-dp.audio[0] (size 50)
+  * xlnx.v-dp.av_buffer_manager[0] (size 238)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_READ, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.core, EVENT_TYPE_MMIO_WRITE, 0xfd4a0000 +0x3b0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_READ, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.v_blend, EVENT_TYPE_MMIO_WRITE, 0xfd4aa000 +0x1e0, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_READ, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.av_buffer_manager, EVENT_TYPE_MMIO_WRITE, 0xfd4ab000 +0x238, 4,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_READ, 0xfd4ac000 +0x50, 1,4
+  * xlnx.v-dp.audio, EVENT_TYPE_MMIO_WRITE, 0xfd4ac000 +0x50, 1,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 510Mb
+Running: ./poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp-crash-8070de484ac8d4d9bfff9b439311058e05b8b40f.minimized
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp: ../util/fifo8.c:43: void fifo8_push_all(Fifo8 *, const uint8_t *, uint32_t): Assertion `fifo->num + num <= fifo->capacity' failed.
+==47609== ERROR: libFuzzer: deadly signal
+    #0 0x564c998420fe in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x564c99790d71 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x564c99769ca6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x564c99769d72 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x564c99769d72 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f8ef929941f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f8ef90ab00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f8ef90ab00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f8ef908a858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f8ef908a728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f8ef909bfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x564c9e1cdbb3 in fifo8_push_all /root/videzzo/videzzo_qemu/qemu/out-san/../util/fifo8.c:43:5
+    #12 0x564c9a189c13 in xlnx_dp_aux_push_tx_fifo /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:467:5
+    #13 0x564c9a1842f2 in xlnx_dp_write /root/videzzo/videzzo_qemu/qemu/out-san/../hw/display/xlnx_dp.c:857:9
+    #14 0x564c9d491e93 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:493:5
+    #15 0x564c9d4917d1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:555:18
+    #16 0x564c9d4900f6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/memory.c:1515:16
+    #17 0x564c9d5209ce in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2825:23
+    #18 0x564c9d50e77b in flatview_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2867:12
+    #19 0x564c9d50e238 in address_space_write /root/videzzo/videzzo_qemu/qemu/out-san/../softmmu/physmem.c:2963:18
+    #20 0x564c99882d48 in qemu_writel /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1096:5
+    #21 0x564c998810b3 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1245:28
+    #22 0x564c9e37772f in videzzo_dispatch_event /root/videzzo/videzzo.c:1140:5
+    #23 0x564c9e36eaad in __videzzo_execute_one_input /root/videzzo/videzzo.c:288:9
+    #24 0x564c9e36e854 in videzzo_execute_one_input /root/videzzo/videzzo.c:329:9
+    #25 0x564c9988a08c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/out-san/../tests/qtest/videzzo/videzzo_qemu.c:1520:12
+    #26 0x564c9e37c57b in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1910:18
+    #27 0x564c9976a816 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #28 0x564c9974d444 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #29 0x564c997583ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #30 0x564c997449d6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #31 0x7f8ef908c082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #32 0x564c99744a2d in _start (/root/bugs/metadata/xlnx_dp-07/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-dp+0x3453a2d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/results/classifier/108/other/1424237 b/results/classifier/108/other/1424237
new file mode 100644
index 00000000..3b8cfeec
--- /dev/null
+++ b/results/classifier/108/other/1424237
@@ -0,0 +1,71 @@
+permissions: 0.888
+graphic: 0.850
+other: 0.845
+semantic: 0.790
+KVM: 0.789
+vnc: 0.779
+device: 0.775
+debug: 0.770
+socket: 0.759
+PID: 0.751
+network: 0.715
+performance: 0.691
+boot: 0.687
+files: 0.661
+
+missing manpage for bridge.conf
+
+There's currently no (easy) way to figure out the form of content of `/etc/qemu/bridge.conf`. Some howtos (e.g. https://wiki.archlinux.org/index.php/QEMU#Bridged_networking_using_qemu-bridge-helper) mention `bridge.conf.sample` which is not available according to `apt-file` and the official wiki at wiki.qemu.org doesn't mention the file at all, it seems necessary, though, because specification of `-net nic -net bridge,br=bridge0` fails with `failed to get mtu of bridge `bridge0': No such device` (can't be investigated further because setup is completely unclear).
+
+ProblemType: Bug
+DistroRelease: Ubuntu 14.10
+Package: qemu 2.1+dfsg-4ubuntu6.4
+Uname: Linux 3.19.0-031900-generic x86_64
+ApportVersion: 2.14.7-0ubuntu8.2
+Architecture: amd64
+CurrentDesktop: Unity
+Date: Sat Feb 21 19:39:07 2015
+EcryptfsInUse: Yes
+InstallationDate: Installed on 2015-01-26 (25 days ago)
+InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
+KvmCmdLine:
+ COMMAND         STAT  EUID  RUID   PID  PPID %CPU COMMAND
+ kvm-irqfd-clean S<       0     0  1026     2  0.0 [kvm-irqfd-clean]
+ qemu-system-x86 Sl+      0     0 25905 25904 11.9 qemu-system-x86_64 -boot c -hda ubuntu.img -m 2048 -smp 16 -enable-kvm -vnc :0,abc -k de -drive file=/dev/sda14,if=ide -net nic -net bridge,br=bridge0
+ kvm-pit/25905   S        0     0 25948     2  0.0 [kvm-pit/25905]
+MachineType: LENOVO 20221
+ProcEnviron:
+ TERM=xterm
+ PATH=(custom, no user)
+ XDG_RUNTIME_DIR=<set>
+ LANG=de_DE.UTF-8
+ SHELL=/bin/bash
+ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-031900-generic root=UUID=ac20c93a-0ec5-445a-98cd-941f0fbc0e50 ro rootflags=subvol=@
+SourcePackage: qemu
+UpgradeStatus: No upgrade log present (probably fresh install)
+dmi.bios.date: 07/12/2013
+dmi.bios.vendor: LENOVO
+dmi.bios.version: 71CN51WW(V1.21)
+dmi.board.asset.tag: No Asset Tag
+dmi.board.name: INVALID
+dmi.board.vendor: LENOVO
+dmi.board.version: 31900003WIN8 STD MLT
+dmi.chassis.asset.tag: No Asset Tag
+dmi.chassis.type: 10
+dmi.chassis.vendor: LENOVO
+dmi.chassis.version: Lenovo IdeaPad Z500 Touch
+dmi.modalias: dmi:bvnLENOVO:bvr71CN51WW(V1.21):bd07/12/2013:svnLENOVO:pn20221:pvrLenovoIdeaPadZ500Touch:rvnLENOVO:rnINVALID:rvr31900003WIN8STDMLT:cvnLENOVO:ct10:cvrLenovoIdeaPadZ500Touch:
+dmi.product.name: 20221
+dmi.product.version: Lenovo IdeaPad Z500 Touch
+dmi.sys.vendor: LENOVO
+
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/113
+
+
diff --git a/results/classifier/108/other/1425 b/results/classifier/108/other/1425
new file mode 100644
index 00000000..8bb75a93
--- /dev/null
+++ b/results/classifier/108/other/1425
@@ -0,0 +1,99 @@
+other: 0.943
+permissions: 0.929
+device: 0.900
+debug: 0.895
+performance: 0.891
+semantic: 0.889
+boot: 0.877
+files: 0.868
+graphic: 0.861
+PID: 0.844
+network: 0.832
+socket: 0.827
+KVM: 0.805
+vnc: 0.756
+
+Assertion failed in transfer_fifo()
+Description of problem:
+In transfer_fifo(), fifo32_pop() fails since less than 32 bytes are in the fifo.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio -audio none
+writel 0xff070000 0x0f73720a
+writel 0xff07003c 0x1f37ee63
+EOF
+```
+Additional information:
+```
+==31717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+INFO: found LLVMFuzzerCustomMutator (0x55871da359f0). Disabling -len_control by default.
+INFO: Running with entropic power schedule (0xFF, 100).
+INFO: Seed: 1734665286
+INFO: Loaded 1 modules   (618606 inline 8-bit counters): 618606 [0x558720b94000, 0x558720c2b06e), 
+INFO: Loaded 1 PC tables (618606 PCs): 618606 [0x558720222e60,0x558720b93540), 
+/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: Running 1 inputs 1 time(s) each.
+INFO: Reading pre_seed_input if any ...
+INFO: Executing pre_seed_input if any ...
+Matching objects by name , *xlnx.zynqmp-can*
+This process will fuzz the following MemoryRegions:
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+  * xlnx.zynqmp-can[1] (size 84)
+  * xlnx.zynqmp-can[0] (size 84)
+This process will fuzz through the following interfaces:
+  * clock_step, EVENT_TYPE_CLOCK_STEP, 0xffffffff +0xffffffff, 255,255
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff070000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_READ, 0xff060000 +0x84, 4,4
+  * xlnx.zynqmp-can, EVENT_TYPE_MMIO_WRITE, 0xff060000 +0x84, 4,4
+INFO: A corpus is not provided, starting from an empty corpus
+#2      INITED cov: 3 ft: 4 corp: 1/1b exec/s: 0 rss: 491Mb
+Running: poc-qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can-crash-97ef02583c679111ba6ad823f573f139fac7c72e
+qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can: ../util/fifo8.c:62: uint8_t fifo8_pop(Fifo8 *): Assertion `fifo->num > 0' failed.
+==31717== ERROR: libFuzzer: deadly signal
+    #0 0x558718e0e10e in __sanitizer_print_stack_trace /root/llvm-project/compiler-rt/lib/asan/asan_stack.cpp:86:3
+    #1 0x558718d5cd81 in fuzzer::PrintStackTrace() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerUtil.cpp:210:38
+    #2 0x558718d35cb6 in fuzzer::Fuzzer::CrashCallback() (.part.0) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:236:18
+    #3 0x558718d35d82 in fuzzer::Fuzzer::CrashCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:208:1
+    #4 0x558718d35d82 in fuzzer::Fuzzer::StaticCrashSignalCallback() /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:207:19
+    #5 0x7f3ad4eba41f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1441f)
+    #6 0x7f3ad4ccc00a in __libc_signal_restore_set /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
+    #7 0x7f3ad4ccc00a in raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
+    #8 0x7f3ad4cab858 in abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79:7
+    #9 0x7f3ad4cab728 in __assert_fail_base /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:92:3
+    #10 0x7f3ad4cbcfd5 in __assert_fail /build/glibc-SzIz7B/glibc-2.31/assert/assert.c:101:3
+    #11 0x55871d6eeac9 in fifo8_pop /root/videzzo/videzzo_qemu/qemu/build-san-6/../util/fifo8.c:62:5
+    #12 0x55871a33f303 in fifo32_pop /root/videzzo/videzzo_qemu/qemu/include/qemu/fifo32.h:137:17
+    #13 0x55871a334bb5 in transfer_fifo /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:455:23
+    #14 0x55871a32d4c0 in can_tx_post_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/net/can/xlnx-zynqmp-can.c:830:9
+    #15 0x558719393dcb in register_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:122:9
+    #16 0x558719397de8 in register_write_memory /root/videzzo/videzzo_qemu/qemu/build-san-6/../hw/core/register.c:203:5
+    #17 0x55871c9e9073 in memory_region_write_accessor /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:492:5
+    #18 0x55871c9e89b1 in access_with_adjusted_size /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:554:18
+    #19 0x55871c9e72d6 in memory_region_dispatch_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/memory.c:1514:16
+    #20 0x55871ca7548e in flatview_write_continue /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2825:23
+    #21 0x55871ca635cb in flatview_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2867:12
+    #22 0x55871ca63088 in address_space_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../softmmu/physmem.c:2963:18
+    #23 0x558718e4e0cb in qemu_writel /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1081:5
+    #24 0x558718e4c544 in dispatch_mmio_write /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1222:28
+    #25 0x55871da313af in videzzo_dispatch_event /root/videzzo/videzzo.c:1122:5
+    #26 0x55871da2872b in __videzzo_execute_one_input /root/videzzo/videzzo.c:272:9
+    #27 0x55871da28600 in videzzo_execute_one_input /root/videzzo/videzzo.c:313:9
+    #28 0x558718e5510c in videzzo_qemu /root/videzzo/videzzo_qemu/qemu/build-san-6/../tests/qtest/videzzo/videzzo_qemu.c:1497:12
+    #29 0x55871da35c92 in LLVMFuzzerTestOneInput /root/videzzo/videzzo.c:1891:18
+    #30 0x558718d36826 in fuzzer::Fuzzer::ExecuteCallback(unsigned char*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:594:17
+    #31 0x558718d19454 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:21
+    #32 0x558718d243fe in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char*, unsigned long)) /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:885:19
+    #33 0x558718d109e6 in main /root/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:30
+    #34 0x7f3ad4cad082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #35 0x558718d10a3d in _start (/root/videzzo/videzzo_qemu/out-san/qemu-videzzo-aarch64-target-videzzo-fuzz-xlnx-zynqmp-can+0x3291a3d)
+
+NOTE: libFuzzer has rudimentary signal handlers.
+      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
+SUMMARY: libFuzzer: deadly signal
+MS: 0 ; base unit: 0000000000000000000000000000000000000000
+```
diff --git a/results/classifier/108/other/1425597 b/results/classifier/108/other/1425597
new file mode 100644
index 00000000..3803d0c4
--- /dev/null
+++ b/results/classifier/108/other/1425597
@@ -0,0 +1,46 @@
+semantic: 0.710
+other: 0.609
+graphic: 0.586
+device: 0.544
+performance: 0.496
+boot: 0.420
+PID: 0.299
+debug: 0.284
+vnc: 0.259
+permissions: 0.252
+files: 0.229
+socket: 0.167
+network: 0.167
+KVM: 0.155
+
+moving window + changing screen resolution = bug
+
+Steps to reproduce:
+1. Run qemu (sdl)
+2. Start moving the window
+3. At that moment the virtualized OS should change its screen resolution (for example, when switching from initial qemu screen to grub)
+
+What I see:
+Window size doesn't change, but internal screen resolution changes, so, image scale stops to be 1:1, now I see virtualized OS in wrong scale.
+
+What I expected to see:
+Window size changes so, that it keeps synchronized with internal resolution (as usual)
+
+This bug preserves at lastest git version at the moment, i. e. 3d30395f7fb3315e4ecf0de4e48790e1326bbd47
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU, using SDL2? Or could we close this ticket nowadays? In case the problem persists, please also specify which host system (Linux? Window manager? Or Windows?) you are using!
+
+The bug is not present in Qemu 2.12 (version reported by dpkg: qemu-system-x86 1:2.12+dfsg-1+b1). There is similar minor bug instead. The new bug doesn't harm me and I am not even sure is this a bug.
+
+So, this is info about new minor bug.
+
+Host is Debian Sid installed today (23 May MSK) with mentioned Qemu 2.12. I run Qemu in X using:
+
+# qemu-system-x86_64 -m 1024 -daemonize -snapshot -drive file=/dev/sda,format=raw,cache=none -kernel /boot/vmlinuz* -initrd /boot/initrd* -append root=/dev/sda
+
+Then I started to move Qemu window using mouse. I kept Qemu window catched by my mouse while guest OS boot. At some moment guest OS (Linux) switched from text mode to framebuffer. Internal screen resolution changed, but Qemu window didn't change its size (I kept moving Qemu window all this time), but likely window content didn't scale (this is as opposed to 3d30395f [3d30395f7fb3315e4ecf0de4e48790e1326bbd47] behavior, 3d30395f scaled window content). So text in window remain concrete (not fluid, as opposed to 3d30395f). Then I tried to resize Qemu window and window size imidiately became normal, i. e. it started to fit content.
+
+All this is acceptable for me. I. e. I see this is nothing wrong when Qemu cannot change its window size when I move Qemu window
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1426 b/results/classifier/108/other/1426
new file mode 100644
index 00000000..e5ceebb6
--- /dev/null
+++ b/results/classifier/108/other/1426
@@ -0,0 +1,53 @@
+PID: 0.864
+device: 0.832
+socket: 0.829
+files: 0.699
+performance: 0.672
+vnc: 0.671
+graphic: 0.668
+network: 0.648
+boot: 0.643
+semantic: 0.609
+other: 0.564
+KVM: 0.552
+permissions: 0.533
+debug: 0.480
+
+On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client
+Description of problem:
+I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client.  
+Windows spice client virtviewer won't start like it does under Linux.  
+The error message indicaes that the spice-server itself failed to open spice sockets
+The registry to handle ```spice://``` URI handler is configured.
+Steps to reproduce:
+1. just run command
+Additional information:
+URI handler in registry is configure using a regestry import file ```spiceproto.reg```
+```
+Windows Registry Editor Version 5.00
+
+[HKEY_CLASSES_ROOT\spice]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice\Extensions]
+[HKEY_CLASSES_ROOT\spice\shell]
+[HKEY_CLASSES_ROOT\spice\shell\open]
+[HKEY_CLASSES_ROOT\spice\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+
+[HKEY_CLASSES_ROOT\spice+unix]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice+unix\Extensions]
+[HKEY_CLASSES_ROOT\spice+unix\shell]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+```
+This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox.
diff --git a/results/classifier/108/other/1426092 b/results/classifier/108/other/1426092
new file mode 100644
index 00000000..47d487e6
--- /dev/null
+++ b/results/classifier/108/other/1426092
@@ -0,0 +1,55 @@
+PID: 0.819
+device: 0.807
+boot: 0.780
+performance: 0.776
+graphic: 0.750
+other: 0.645
+socket: 0.619
+vnc: 0.567
+debug: 0.529
+network: 0.527
+semantic: 0.492
+permissions: 0.473
+KVM: 0.230
+files: 0.163
+
+virtio-balloon-device locks up Guest
+
+Setting arbitrary balloon target values locks up the guest in some cases crashes it, if the target memory is < used +~5% free.  
+Found while testing aggressive memory over-commit, scenarios.
+You get messages like:
+
+[  155.827448] [<c002060c>] (show_stack) from [<c041c518>] (dump_stack+0x6c/0x88)
+[  155.837076] [<c041c518>] (dump_stack) from [<c0091994>] (warn_alloc_failed+0xe0/0x120)
+[  155.847075] [<c0091994>] (warn_alloc_failed) from [<c0094480>] (__alloc_pages_nodemask+0x600/0x91c)
+[  155.859039] [<c0094480>] (__alloc_pages_nodemask) from [<c00da414>] (balloon_page_enqueue+0x20/0xbc)
+[  155.870556] [<c00da414>] (balloon_page_enqueue) from [<c025d794>] (balloon+0x140/0x2cc)
+[  155.881377] [<c025d794>] (balloon) from [<c0043b38>] (kthread+0xd8/0xf4)
+
+page dumped bacause: nonzero _count
+BUG: BAad page state in process Xorg pfn:396e5
+
+Test Environment:
+x86_64
+Ubuntu 13.10, Guest Linux Kernel 3.19, qemu 2.2.0 with following patches applied - balloon OOM enhancement
+commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5
+Author: Raushaniya Maksudova <email address hidden>
+
+Boot guest with '-balloon virtio', -qmp .... -hmp access
+1. sudo info balloon | socat - tcp4-connect:127.0.0.1:4444
+   - or over qmp interface
+{"execute":"qom-get", "arguments": { "path": "/machine/peripheral-anon/device[1]","property": "guest-stats" }}
+{"return": {"stats": {"stat-swap-out": 0, "stat-free-memory": 513454080, "stat-minor-faults": 1261, "stat-major-faults": 0, "stat-total-memory": 526073856, "stat-swap-in": 0}, "last-update": 11109}}
+
+2. Take memory down check free memory using (1)
+3. Issue "sudo echo balloon XXX | socat - tcp4-connect:127.0.0.1:4444" - XXX is value in threshold mentioned above
+   and you get Guest lockup
+
+ARM - samething except '-device virtio-balloon-device' used
+
+Libvirt - virsh setmem causes same issue.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? ... anyway, this rather sounds like a bug with the guest kernel to me, so in case this problem persists, you likely should report this in the kernel bug tracker instead.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1426593 b/results/classifier/108/other/1426593
new file mode 100644
index 00000000..4d553fbd
--- /dev/null
+++ b/results/classifier/108/other/1426593
@@ -0,0 +1,58 @@
+performance: 0.862
+graphic: 0.844
+other: 0.826
+semantic: 0.798
+permissions: 0.780
+device: 0.731
+PID: 0.686
+debug: 0.640
+files: 0.568
+network: 0.561
+vnc: 0.555
+socket: 0.551
+boot: 0.509
+KVM: 0.463
+
+linux-user: doesn't handle guest setting its memory ulimit very small
+
+using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested.
+i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it
+
+building coreutils hangs on "checking whether printf survives out-of-memory conditions"
+
+i have not had time to dig into the build system to isolate the test yet, there were old reports of this bug but i can no longer find them on google.
+
+On 28 February 2015 at 09:01, aaron <email address hidden> wrote:
+> Public bug reported:
+>
+> using the latest build from git (hash 041ccc922ee474693a2869d4e3b59e920c739bc0 ) and all older versions i have tested.
+> i am using an amd64 host with an arm chroot using "qemu-user arm cortex-a8" cpu emulation to run it
+>
+> building coreutils hangs on "checking whether printf survives out-of-
+> memory conditions"
+>
+> i have not had time to dig into the build system to isolate the test
+> yet, there were old reports of this bug but i can no longer find them on
+> google.
+
+Yes, I seem to recall looking at this one before. QEMU's linux-user
+code doesn't try to isolate the guest's memory allocations from
+its own allocations. So if the guest sets the memory limit to
+something very small then the chances are good that this will
+result in one of QEMU's internal allocations failing, and then
+QEMU will probably exit with an error or possibly crash or hang
+(some of our error handling on these allocations is not good).
+
+For this kind of test to work correctly we would need to fake
+the memory limit syscalls rather than just passing them through
+to the host, and then also do all the accounting to track how
+much memory the guest has allocated. That's a fair amount of
+work so it's unlikely this bug will be fixed unless somebody
+who cares about it submits patches, I'm afraid.
+
+-- PMM
+
+
+I've just noticed that this is a duplicate of bug 1163034 (gnutls uses a very similar configure test), so I'm going to mark this one as a dup of that one, since it's older.
+
+
diff --git a/results/classifier/108/other/1428352 b/results/classifier/108/other/1428352
new file mode 100644
index 00000000..e6bdd912
--- /dev/null
+++ b/results/classifier/108/other/1428352
@@ -0,0 +1,65 @@
+semantic: 0.788
+permissions: 0.764
+other: 0.739
+graphic: 0.673
+performance: 0.653
+debug: 0.652
+device: 0.631
+vnc: 0.613
+PID: 0.596
+KVM: 0.595
+network: 0.538
+boot: 0.531
+files: 0.506
+socket: 0.491
+
+SYSRET instruction incorrectly implemented
+
+The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic:
+
+SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *)
+
+Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here:
+
+http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html
+
+[...]
+        SS(SEL) = IA32_STAR[63:48] + 8;
+        SS(PL) = 0x3;
+[...]
+
+In other words, the value of the %ss register is supposed to be loaded from  bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call.
+
+However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this:
+
+        cpu_x86_load_seg_cache(env, R_SS, selector + 8,
+                               0, 0xffffffff,
+                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
+                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
+                               DESC_W_MASK | DESC_A_MASK);
+
+It should look like this:
+
+        cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3,
+                               0, 0xffffffff,
+                               DESC_G_MASK | DESC_B_MASK | DESC_P_MASK |
+                               DESC_S_MASK | (3 << DESC_DPL_SHIFT) |
+                               DESC_W_MASK | DESC_A_MASK);
+
+The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss).
+
+The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.)
+
+This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :)
+
+Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM.
+
+The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware.
+
+- Bill (<email address hidden>)
+
+
+
+If I've got that right, this has been fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ac57622985220de0
+
diff --git a/results/classifier/108/other/1428657 b/results/classifier/108/other/1428657
new file mode 100644
index 00000000..45b26efd
--- /dev/null
+++ b/results/classifier/108/other/1428657
@@ -0,0 +1,176 @@
+other: 0.929
+permissions: 0.869
+performance: 0.855
+graphic: 0.851
+debug: 0.842
+device: 0.819
+vnc: 0.817
+semantic: 0.803
+PID: 0.783
+files: 0.762
+socket: 0.747
+KVM: 0.725
+boot: 0.694
+network: 0.694
+
+qemu-system-arm does not ignore the lowest bit of pc when returning from interrrupt
+
+This was observed in qemu v2.1.3, running a sample app from 
+
+FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo)
+
+In the sample code compiled with arm-none-eabi-gcc , version 4.8.2 (4.8.2-14ubuntu1+6) .
+
+qemu seems to be executing the wrong instrunction after returning from the SVCHandler. The svc handler changes the PSP register and the new stack contains an add return address, which should be allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html). The lowest bit of the address should be ignored, but it seems that qemu executes garbage after returning from the interrupt.
+
+qemu is run like this:
+
+qemu-system-arm -semihosting -machine lm3s6965evb -kernel RTOSDemo.axf -gdb tcp::1234 -S
+
+
+this is the arm-gdb trace
+Program received signal SIGINT, Interrupt.
+IntDefaultHandler () at startup.c:231
+231	{
+(gdb) bt
+#0  IntDefaultHandler () at startup.c:231
+#1  0xfffffffc in ?? ()
+
+(gdb) info registers 
+r0             0x0	0
+r1             0x14b4b4b4	347387060
+r2             0xa5a5a5a5	-1515870811
+r3             0xa5a5a53d	-1515870915
+r4             0xa5a5a5a5	-1515870811
+r5             0xa5a5a5a5	-1515870811
+r6             0xa5a5a5a5	-1515870811
+r7             0x40d00542	1087374658
+r8             0xa5a5a5a5	-1515870811
+r9             0xa5a5a5a5	-1515870811
+r10            0xa5a5a5a5	-1515870811
+r11            0xa5a5a5a5	-1515870811
+r12            0xa5a5a5a5	-1515870811
+sp             0x20008380	0x20008380
+lr             0xfffffffd	-3
+pc             0xc648	0xc648 <IntDefaultHandler>
+cpsr           0x20000173	536871283
+
+this exception occur after running SVC handler code
+
+(gdb) disassemble vPortSVCHandler 
+Dump of assembler code for function vPortSVCHandler:
+   0x0000c24c <+0>:	ldr	r3, [pc, #24]	; (0xc268 <vPortSVCHandler+28>)
+   0x0000c24e <+2>:	ldr	r1, [r3, #0]
+   0x0000c250 <+4>:	ldr	r0, [r1, #0]
+   0x0000c252 <+6>:	ldmia.w	r0!, {r4, r5, r6, r7, r8, r9, r10, r11}
+   0x0000c256 <+10>:	msr	PSP, r0
+   0x0000c25a <+14>:	mov.w	r0, #0
+   0x0000c25e <+18>:	msr	BASEPRI, r0
+   0x0000c262 <+22>:	orr.w	lr, lr, #13
+   0x0000c266 <+26>:	bx	lr
+   0x0000c268 <+28>:	andcs	r2, r0, r12, ror #5
+End of assembler dump.
+
+This stores this stack in PSP register:
+(gdb) x /32 0x200052c8
+0x200052c8:	0xa5a5a5a5	0xa5a5a5a5	0xa5a5a5a5	0xa5a5a5a5
+0x200052d8:	0xa5a5a5a5	0xa5a5a5a5	0xa5a5a5a5	0xa5a5a5a5
+0x200052e8:	0x00000000	0x14b4b4b4	0xa5a5a5a5	0xa5a5a53d
+0x200052f8:	0xa5a5a5a5	0x00000000	0x00003b49	0x21000000
+0x20005308:	0xa5a5a5a5	0xa5a5a5a5	0x200081b8	0x00000058
+0x20005318:	0x00000000	0x00000000	0x00000000	0x00000000
+0x20005328:	0x00000000	0x20005330	0xffffffff	0x20005330
+0x20005338:	0x20005330	0x00000000	0x20005344	0xffffffff
+
+It seems that qemu actually executes 0x00003b49 after the interrupt, but it should execute 0x00003b48
+
+
+
+On 5 March 2015 at 23:15, Anders Esbensen <email address hidden> wrote:
+> Public bug reported:
+>
+> This was observed in qemu v2.1.3, running a sample app from
+>
+> FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo)
+>
+> In the sample code compiled with arm-none-eabi-gcc , version 4.8.2
+> (4.8.2-14ubuntu1+6) .
+>
+> qemu seems to be executing the wrong instrunction after returning from
+> the SVCHandler. The svc handler changes the PSP register and the new
+> stack contains an add return address, which should be
+> allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html).
+> The lowest bit of the address should be ignored, but it seems that qemu
+> executes garbage after returning from the interrupt.
+
+So if I understand you correctly, the guest is executing
+a return-from-exception (via a bx lr instruction where the
+return address is one of the 0xffffffXX special cases), and
+the PC value in the exception frame we're restoring has
+its least significant bit set?
+
+If so, then this is a guest bug. In an exception frame the
+PC must be halfword aligned (ie must have the ls bit clear),
+because the "is this Thumb or not?" information is stored in
+the PSR field in the exception frame. If the LSB of the PC
+is set then the behaviour is UNPREDICTABLE (see the PopStack
+pseudocode in the ARMv7M ARM ARM). Real hardware seems to
+ignore the LSbit, but QEMU's behaviour is architecturally
+permitted and you should really fix your guest code.
+
+(The ARM knowledgebase article you give a link to correctly
+notes that the LSbit in vector table entries and normal
+branch targets is significant, but says nothing about the
+PC in exception frames.)
+
+thanks
+-- PMM
+
+
+Yes the situation I'm describing is the bx 0xfffffffx case.
+
+I see that the article I'm referring to, actually only describes the behaviour of branches and in ISR vector.
+
+Searching a bit more I see this:
+
+Cortex™-M3 Technical Reference Manual	Revision: r1p1
+Home > Programmer’s Model > Registers > General-purpose registers
+2.3.1. General-purpose registers
+
+-Program counter
+Register r15 is the Program Counter (PC).
+Bit [0] is always 0, so instructions are always aligned to word or halfword boundaries.
+
+Which is like you are describing.
+
+So I agree, I should correct my guest code, which I did :-), but shouldn't qemu reflect the behaviour of the implemented hardware?
+So it is "unpredictable" in the same way?
+
+I'will note the FreeRTOS people they have a bad implementation of their SVC handler for Cortex M3
+
+Thanks for the help.
+
+/Anders
+
+
+Proposed patch: http://patchwork.ozlabs.org/patch/449400/ which could use testing.
+
+
+
+I've tested the patch against the FreeRTOS example. An the patch seems 
+to make the example run.
+The FreeRTOS sample now crash for other reasons. But I consider the 
+issue resolved.
+
+/Anders
+
+On 03/12/2015 02:45 PM, Peter Maydell wrote:
+> Proposed patch: http://patchwork.ozlabs.org/patch/449400/ which could
+> use testing.
+>
+
+
+
+The patch described in an earlier comment was applied to master and the fix was in QEMU 2.4.
+
+
diff --git a/results/classifier/108/other/1428958 b/results/classifier/108/other/1428958
new file mode 100644
index 00000000..e1b8a3fe
--- /dev/null
+++ b/results/classifier/108/other/1428958
@@ -0,0 +1,107 @@
+other: 0.684
+vnc: 0.653
+debug: 0.646
+KVM: 0.637
+permissions: 0.621
+boot: 0.620
+performance: 0.620
+device: 0.617
+files: 0.611
+semantic: 0.606
+socket: 0.595
+PID: 0.591
+graphic: 0.574
+network: 0.564
+
+random IO errors / data corruption in VMs (created and executed via virt-manager)
+
+I have recurring problems with VM installation and usage - data on VM disk gets corrupted at some point and it causes all sorts of problems - sometimes I cannot even install base system, other times some .so files are corrupt after isntallation, etc - totally random.
+I use virt-manager to create and run VMs. I have also tried creating VMs via virt-install, result is identical.
+If I use VirtualBox I have no such problems.
+My OS is Fedora 20 upgraded to 21, qemu and libvirt are installed from Fedora official repos.
+
+Here's an example qemu command-line:
+/usr/bin/qemu-system-x86_64
+-machine accel=kvm
+-name fuel
+-S
+-machine pc-i440fx-2.1,accel=kvm,usb=off
+-cpu SandyBridge,+invpcid,+erms,+bmi2,+smep,+avx2,+bmi1,+fsgsbase,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+movbe,+pcid,+pdcm,+xtpr,+fma,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme
+-m 3142
+-realtime mlock=off
+-smp 2,sockets=2,cores=1,threads=1
+-uuid 27693a46-7a50-4a3c-bcaf-bf061ba469ed
+-no-user-config
+-nodefaults
+-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/fuel.monitor,server,nowait
+-mon chardev=charmonitor,id=monitor,mode=control
+-rtc base=utc,driftfix=slew
+-global kvm-pit.lost_tick_policy=discard
+-no-hpet
+-no-shutdown
+-boot menu=on,strict=on
+-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x6.0x7
+-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x6
+-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x6.0x1
+-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x6.0x2
+-device lsi,id=scsi0,bus=pci.0,addr=0xa
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7
+-drive file=/home/virtual-disks/fuel.vdi,if=none,id=drive-virtio-disk0,format=vdi
+-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
+-drive file=/home/dsutyagin/Downloads/iso/MirantisOpenStack-6.0.iso,if=none,id=drive-scsi0-0-0,readonly=on,format=raw
+-device scsi-cd,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0,bootindex=2
+-netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:0d:42:2d,bus=pci.0,addr=0x3
+-netdev tap,fd=25,id=hostnet1,vhost=on,vhostfd=26
+-device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:a4:8c:ef,bus=pci.0,addr=0x4
+-chardev pty,id=charserial0
+-device isa-serial,chardev=charserial0,id=serial0
+-chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/fuel.org.qemu.guest_agent.0,server,nowait
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
+-chardev spicevmc,id=charchannel1,name=vdagent
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0
+-device usb-tablet,id=input0
+-spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on
+-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2
+-device intel-hda,id=sound0,bus=pci.0,addr=0x5 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0
+-chardev spicevmc,id=charredir0,name=usbredir
+-device usb-redir,chardev=charredir0,id=redir0
+-chardev spicevmc,id=charredir1,name=usbredir
+-device usb-redir,chardev=charredir1,id=redir1
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9
+-msg timestamp=on
+
+If this is not a bug, I'd be happy if you help me fix this problem. I am sorry if this is not the proper place to post such a problem.
+
+qemu-system-x86_64 --version
+QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard
+
+qemu-kvm --version
+QEMU emulator version 2.1.3 (qemu-2.1.3-2.fc21), Copyright (c) 2003-2008 Fabrice Bellard
+
+Can you please retry with current qemu.git master? I suspect that this is a duplicate of https://bugs.launchpad.net/qemu/+bug/1422307 and fixed in commit f0ab6f10 (a bug in the code handling VirtualBox's VDI image format).
+
+In general, running VMs with image formats of other hypervisors is not recommended, both for reliability and performance reasons. You may want to consider using qcow2 or raw instead.
+
+I have tried using qcow2 and the problem does not appear anymore. I guess it was a bug with VDI implementation indeed. Please close the ticket. Thank you very much for your help!
+
+On Fri, Mar 06, 2015 at 06:50:30AM -0000, Dmitry Sutyagin wrote:
+> I have recurring problems with VM installation and usage - data on VM disk gets corrupted at some point and it causes all sorts of problems - sometimes I cannot even install base system, other times some .so files are corrupt after isntallation, etc - totally random.
+...
+> -drive file=/home/virtual-disks/fuel.vdi,if=none,id=drive-virtio-disk0,format=vdi
+
+Hi Dmitry,
+A bug that can lead to corruption was recently discovered in the vdi
+image format code in QEMU.
+
+The vdi image format code is only designed to work for
+importing/exporting image files in qemu-img convert.  It is not suitable
+for running guests and achieving good I/O performance.
+
+I recommend using raw or qcow2 image files instead.
+
+Stefan
+
+
+Closing according to comment #2.
+
diff --git a/results/classifier/108/other/1429 b/results/classifier/108/other/1429
new file mode 100644
index 00000000..6611eb40
--- /dev/null
+++ b/results/classifier/108/other/1429
@@ -0,0 +1,70 @@
+other: 0.722
+KVM: 0.632
+vnc: 0.582
+device: 0.564
+permissions: 0.548
+debug: 0.537
+graphic: 0.536
+boot: 0.531
+performance: 0.518
+network: 0.513
+socket: 0.508
+semantic: 0.500
+files: 0.496
+PID: 0.478
+
+Out of bounds in xilinx_spips_write()
+Description of problem:
+The size of TYPE_XILINX_SPIPS's and TYPE_XILINX_QSPIPS's memory regions is
+0x100, but it is set to 0x200. UBSAN captures Out of bounds accesses.
+Steps to reproduce:
+```
+export QEMU=/path/to/qemu-system-aarch64
+export UBSAN_OPTIONS=halt_on_error=1:symbolize=1:print_stacktrace=1
+
+cat << EOF | $QEMU \
+-machine xlnx-zcu102 -monitor none -serial none \
+-display none -nodefaults -qtest stdio
+writew 0xff050108 0x29be
+EOF
+```
+Additional information:
+```
+==852678==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases!
+[I 0.000001] OPENED
+pulseaudio: set_sink_input_volume() failed
+pulseaudio: Reason: Invalid argument
+pulseaudio: set_sink_input_mute() failed
+pulseaudio: Reason: Invalid argument
+qemu-system-aarch64: warning: nic cadence_gem.0 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.1 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.2 has no peer
+qemu-system-aarch64: warning: nic cadence_gem.3 has no peer
+[R +0.323364] writew 0xff050108 0x29be
+../hw/ssi/xilinx_spips.c:1031:22: runtime error: index 66 out of bounds for type 'uint32_t [64]'
+    #0 0x55b7450b6895 in xilinx_spips_write /home/liuqiang/project-videzzo/qemu-devel/build/../hw/ssi/xilinx_spips.c:1031:22
+    #1 0x55b747b29790 in memory_region_write_accessor /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:493:5
+    #2 0x55b747b28c2d in access_with_adjusted_size /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:555:18
+    #3 0x55b747b268f4 in memory_region_dispatch_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/memory.c:1515:16
+    #4 0x55b747c1a071 in flatview_write_continue /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2825:23
+    #5 0x55b747c00d92 in flatview_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2867:12
+    #6 0x55b747c007b8 in address_space_write /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/physmem.c:2963:18
+    #7 0x55b747c49f31 in qtest_process_command /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:528:13
+    #8 0x55b747c42f6e in qtest_process_inbuf /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:802:9
+    #9 0x55b747c5b783 in qtest_read /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/qtest.c:814:5
+    #10 0x55b748c6b602 in qemu_chr_be_write_impl /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:201:9
+    #11 0x55b748c6b74a in qemu_chr_be_write /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char.c:213:9
+    #12 0x55b748c81f6a in fd_chr_read /home/liuqiang/project-videzzo/qemu-devel/build/../chardev/char-fd.c:72:9
+    #13 0x55b7481cbe66 in qio_channel_fd_source_dispatch /home/liuqiang/project-videzzo/qemu-devel/build/../io/channel-watch.c:84:12
+    #14 0x7fbad3de404d in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x5204d)
+    #15 0x55b74923a917 in glib_pollfds_poll /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:297:9
+    #16 0x55b749238017 in os_host_main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:320:5
+    #17 0x55b749237967 in main_loop_wait /home/liuqiang/project-videzzo/qemu-devel/build/../util/main-loop.c:606:11
+    #18 0x55b745858753 in qemu_main_loop /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/runstate.c:739:9
+    #19 0x55b74304cf34 in qemu_default_main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:37:14
+    #20 0x55b74304cfd0 in main /home/liuqiang/project-videzzo/qemu-devel/build/../softmmu/main.c:48:12
+    #21 0x7fbad227a082 in __libc_start_main /build/glibc-SzIz7B/glibc-2.31/csu/../csu/libc-start.c:308:16
+    #22 0x55b742fa271d in _start (/home/liuqiang/project-videzzo/qemu-devel/build/qemu-system-aarch64+0x3dc371d)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/ssi/xilinx_spips.c:1031:22 in
+```
diff --git a/results/classifier/108/other/1429034 b/results/classifier/108/other/1429034
new file mode 100644
index 00000000..4fc8794c
--- /dev/null
+++ b/results/classifier/108/other/1429034
@@ -0,0 +1,40 @@
+graphic: 0.722
+permissions: 0.683
+other: 0.678
+debug: 0.676
+performance: 0.664
+semantic: 0.647
+network: 0.613
+files: 0.604
+device: 0.604
+PID: 0.603
+socket: 0.586
+vnc: 0.569
+boot: 0.564
+KVM: 0.549
+
+qemu abort in qemu_coroutine_enter when multi-thread writing
+
+qemu release version: 2.2.0
+platform: x86_64
+
+qemu would be aborted when there are two threads to write two seperate qcow2 files.
+
+call stack:
+
+#0 0x7ffff5e18989	__GI_raise(sig=sig@entry=6) (../nptl/sysdeps/unix/sysv/linux/raise.c:56)
+#1 0x7ffff5e1a098	__GI_abort() (abort.c:90)
+#2 0x7ffff728c034	qemu_coroutine_enter(co=0x7fffe0004800, opaque=0x0) (qemu-coroutine.c:117)
+#3 0x7ffff727df39	bdrv_co_io_em_complete(opaque=0x7ffff7fd6ae0, ret=0) (block.c:4847)
+#4 0x7ffff7270314	thread_pool_completion_bh(opaque=0x7fffe0006ad0) (thread-pool.c:187)
+#5 0x7ffff726f873	aio_bh_poll(ctx=0x7fffe0001d00) (async.c:82)
+#6 0x7ffff728340b	aio_dispatch(ctx=0x7fffe0001d00) (aio-posix.c:137)
+#7 0x7ffff72837b0	aio_poll(ctx=0x7fffe0001d00, blocking=true) (aio-posix.c:248)
+#8 ??	0x00007ffff72795a8 in bdrv_prwv_co (bs=0x7fffdc0021c0, offset=12071639552, qiov=0x7fffe67fa590, is_write=true, flags=(unknown: 0)) (block.c:2703)
+#9 ??	0x00007ffff727966a in bdrv_rw_co (bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128, is_write=true, flags=(unknown: 0)) (block.c:2726)
+#10 0x7ffff7279758	bdrv_write(bs=0x7fffdc0021c0, sector_num=23577421, buf=0x7fffe4629250 "\234\b\335Ǽ\254\213q\301\366\315=\005oI\301\245=\373\004+2?H\212\025\035+\262\274C;X\301FaP\324\335\061ҝ&Y\316=\347\335\020\365\003goɿ\214\312S=\v2]\373\363C\311\341\334\r5k\346k\204\332\023\264\315陌\230\203J\222u\214\066", nb_sectors=128) (block.c:2760)
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/108/other/1429841 b/results/classifier/108/other/1429841
new file mode 100644
index 00000000..baed7194
--- /dev/null
+++ b/results/classifier/108/other/1429841
@@ -0,0 +1,134 @@
+other: 0.816
+permissions: 0.809
+semantic: 0.759
+device: 0.729
+PID: 0.723
+network: 0.686
+graphic: 0.669
+debug: 0.657
+vnc: 0.653
+files: 0.649
+boot: 0.642
+performance: 0.637
+socket: 0.607
+KVM: 0.588
+
+error "rom: requested regions overlap" for NOLOAD sections
+
+command line:
+qemu-system-arm -semihosting -nographic -monitor null -serial null -no-reboot -kernel build/fw/0HNFcomSLuP1_CUNIT.elf
+
+output:
+rom: requested regions overlap (rom phdr #6: build/fw/0HNFcomSLuP1_CUNIT.elf. free=0x8001effc, addr=0x8001c000)
+rom loading failed
+
+I checked the sections of the .elf file with arm-none-eabi-objdump -h:
+Sections:
+Idx Name          Size      VMA       LMA       File off  Algn
+...
+ 35 .marker_appli 00001000  801ae000  801ae000  00025000  2**0
+                  ALLOC
+ 36 .safe_data    00000014  80200000  8001b000  00020000  2**2
+                  CONTENTS, ALLOC, LOAD, DATA
+ 37 .safe_bss     00000488  80200020  8001b020  00020014  2**2
+                  ALLOC
+ 38 .marker_safe_data 00001000  80201000  8001c000  00029000  2**0
+                  ALLOC
+ 39 .data         000008cc  80202000  8001b600  00022000  2**3
+                  CONTENTS, ALLOC, LOAD, DATA
+ 40 .bss          0000312c  802028d0  8001bed0  000228cc  2**3
+                  ALLOC
+ 41 .marker_data  00001000  80206000  8001f600  00026000  2**0
+                  ALLOC
+ 42 .cunit        00010000  80300000  80119600  00028000  2**0
+                  ALLOC
+ 43 .marker_code  00001000  8001c000  8001c000  00024000  2**0
+                  ALLOC
+...
+
+So I had a look where the values in  the error message could come from:
+0x8001c000: is the "LMA" value of section .marker_safe_data
+0x8001effc: is "Size" + "LMA" of the .bss section (0x0000312c + 0x8001bed0)
+
+So it is correct that (regarding the "LMA" value) the .marker_safe_data section collides with .bss section.
+But actually these sections have no "LOAD" attribute, so I would guess that their "LMA" should not be used anyway.
+Those section should reside at their "VMA" addresses (0x802xxxxx) during runtime but they have no data to load.
+
+Or am I getting something completely wrong?
+Should I give an additional option to qemu?
+
+I got this error with 2.0.0+dfsg-2ubuntu1.10 and 1.0.50-2012.03-0ubuntu2.1
+I didn't get this error (but others) with 0.10.2
+
+
+
+I did a test (with version 2.2.0) to simply not fail out upon this error (removed the "return -1" in function rom_load_all() in file hw/core/loader.c).
+
+With that hack I got the elf file running I'll attach with *this* comment (note that attachment #1 won't run correctly but probably for some other reason as I never had this working anywhere).
+So when I run with my hack:
+qemu-system-arm  -M integratorcp -semihosting -nographic -monitor null -serial null -no-reboot -kernel 0MFWSL_EmoDatauP1_CUNIT.elf
+
+I get:
+rom: requested regions overlap (rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017ae0, addr=0x0000000000016aac)
+rom: requested regions overlap (rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000185e8, addr=0x0000000000017e64) 
+
+     CUnit - A Unit testing framework for C - Version 2.1-0
+     http://cunit.sourceforge.net/
+
+
+Suite: MFWSL_EmoData
+  Test: MFWSL_EmoFileOpen		 ... passed
+  Test: MFWSL_ChkEmosSodHdr		 ... passed
+  Test: MFWSL_ChkEmosFileHdr	 ... passed
+  Test: MFWSL_ChkEmosSodSect	 ... passed
+  Test: MFWSL_ChkEmosFileSect	 ... passed
+  Test: MFWSL_AddEntryToCpyList	 ... passed
+  Test: MFWSL_EmosAvailableForSect ... passed
+  Test: MFWSL_CreateCpyListFromSect ... passed
+  Test: MFWSL_SodEmosActive		 ... passed
+  Test: MFWSL_CreateExtMoList	 ... passed
+  Test: MFWSL_ExtendedEmosActive ... passed
+
+--Run Summary: Type      Total     Ran  Passed  Failed
+               suites        1       1     n/a       0
+               tests        11      11      11       0
+               asserts    2854    2854    2854       0  
+
+...where the last part is the output I expected for a clean run.
+
+regarding the values in the error messages I it looks like:
+free=0x0000000000017ae0 = end of .safe_bss (0x16aac + 0x1034) which is NOLOAD
+addr=0x0000000000016aac = start of .data which is LOAD
+free=0x00000000000185e8 = end of .bss (0x17570 + 0x1078) which is NOLOAD
+addr=0x0000000000017e64 = start of .marker1 which is NOLOAD
+
+Any optinions?
+
+additional info:
+0MFWSL_EmoDatauP1_CUNIT.elf from previous post runs fine with 1.0.50 (Debian 1.0.50-2012.03-0ubuntu2.1) and 0.10.2
+
+To make things more easy I added some debug output to function rom_load_all().
+It prints infos for every rom section is processes:
+
+rom phdr #1: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000000000, size=0x000000000000003c, addr=0x0000000000000000)
+rom phdr #2: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000008a0, size=0x00000000000161c4, addr=0x000000000000003c)
+rom phdr #3: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000016a64, size=0x000000000000107c, addr=0x0000000000016a64)
+rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000016aac, size=0x0000000000001b3c, addr=0x0000000000017ae0)
+rom: requested regions overlap (rom phdr #4: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017ae0, addr=0x0000000000016aac, size=0x0000000000001b3c)
+rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x0000000000017e64, size=0x0000000000000400, addr=0x00000000000185e8)
+rom: requested regions overlap (rom phdr #5: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000000185e8, addr=0x0000000000017e64, size=0x0000000000000400)
+rom phdr #6: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000001152ac, size=0x0000000000000400, addr=0x0000000000018264)
+rom phdr #7: 0MFWSL_EmoDatauP1_CUNIT.elf. free=0x00000000001a7000, size=0x0000000000000400, addr=0x00000000001156ac)
+
+Retest with qemu 2.7.0: issue still occours
+Same fix works for me: removed 'return -1;' in function rom_check_and_register_reset() (line 1030 of file hw/core/loader.c)
+
+This bug is fixed in QEMU master by commits bf1733392ca2 and f33e5e6299288c, which will be in the upcoming QEMU 2.11 release.
+
+(PS: the thing the loader cares about is not elf sections but elf segments in the program header, so the section table and its attributes isn't relevant here, only the program header. In any case your example ELF file loads OK with the bugfixes applied.)
+
+
+Just tested with QEMU 2.10.93 in cygwin: problem does not occour anymore!
+
+Thanks a lot!
+