9 files changed, 591 insertions, 0 deletions
diff --git a/results/classifier/118/none/142 b/results/classifier/118/none/142
new file mode 100644
index 00000000..94df80b5
--- /dev/null
+++ b/results/classifier/118/none/142
@@ -0,0 +1,31 @@
+performance: 0.721
+device: 0.699
+network: 0.494
+architecture: 0.337
+mistranslation: 0.337
+kernel: 0.329
+arm: 0.324
+permissions: 0.302
+peripherals: 0.296
+ppc: 0.211
+PID: 0.208
+semantic: 0.203
+i386: 0.201
+virtual: 0.180
+hypervisor: 0.179
+x86: 0.167
+register: 0.165
+graphic: 0.156
+socket: 0.155
+vnc: 0.154
+VMM: 0.135
+files: 0.135
+debug: 0.121
+risc-v: 0.119
+TCG: 0.113
+user-level: 0.100
+assembly: 0.085
+boot: 0.084
+KVM: 0.053
+
+qemu -readconfig/-writeconfig cannot handle quotes in values
diff --git a/results/classifier/118/none/1422 b/results/classifier/118/none/1422
new file mode 100644
index 00000000..aa492e31
--- /dev/null
+++ b/results/classifier/118/none/1422
@@ -0,0 +1,45 @@
+permissions: 0.734
+register: 0.711
+network: 0.649
+peripherals: 0.648
+PID: 0.638
+device: 0.638
+graphic: 0.627
+arm: 0.620
+VMM: 0.610
+socket: 0.597
+architecture: 0.572
+risc-v: 0.569
+TCG: 0.566
+files: 0.560
+vnc: 0.554
+semantic: 0.542
+ppc: 0.541
+KVM: 0.535
+user-level: 0.531
+kernel: 0.523
+virtual: 0.497
+performance: 0.496
+x86: 0.479
+debug: 0.472
+i386: 0.457
+assembly: 0.451
+hypervisor: 0.450
+boot: 0.417
+mistranslation: 0.400
+
+/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/118/none/1423668 b/results/classifier/118/none/1423668
new file mode 100644
index 00000000..80d66b60
--- /dev/null
+++ b/results/classifier/118/none/1423668
@@ -0,0 +1,44 @@
+peripherals: 0.696
+device: 0.693
+graphic: 0.520
+socket: 0.480
+x86: 0.472
+network: 0.449
+vnc: 0.445
+mistranslation: 0.410
+ppc: 0.395
+semantic: 0.395
+performance: 0.383
+virtual: 0.374
+architecture: 0.370
+hypervisor: 0.336
+register: 0.312
+KVM: 0.282
+risc-v: 0.238
+permissions: 0.221
+PID: 0.204
+boot: 0.160
+arm: 0.155
+i386: 0.149
+debug: 0.145
+TCG: 0.134
+kernel: 0.132
+VMM: 0.131
+files: 0.113
+user-level: 0.042
+assembly: 0.015
+
+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/118/none/1425597 b/results/classifier/118/none/1425597
new file mode 100644
index 00000000..0559cc01
--- /dev/null
+++ b/results/classifier/118/none/1425597
@@ -0,0 +1,61 @@
+virtual: 0.713
+semantic: 0.710
+user-level: 0.687
+graphic: 0.586
+device: 0.544
+performance: 0.496
+mistranslation: 0.462
+architecture: 0.448
+x86: 0.447
+boot: 0.420
+assembly: 0.411
+kernel: 0.407
+ppc: 0.338
+register: 0.337
+hypervisor: 0.336
+VMM: 0.313
+PID: 0.299
+debug: 0.284
+vnc: 0.259
+permissions: 0.252
+peripherals: 0.246
+files: 0.229
+risc-v: 0.202
+socket: 0.167
+network: 0.167
+arm: 0.165
+KVM: 0.155
+i386: 0.154
+TCG: 0.137
+
+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/118/none/1426472 b/results/classifier/118/none/1426472
new file mode 100644
index 00000000..6f37a430
--- /dev/null
+++ b/results/classifier/118/none/1426472
@@ -0,0 +1,68 @@
+boot: 0.579
+graphic: 0.565
+device: 0.387
+performance: 0.382
+i386: 0.260
+ppc: 0.245
+PID: 0.200
+semantic: 0.199
+register: 0.196
+socket: 0.174
+permissions: 0.160
+user-level: 0.145
+architecture: 0.132
+files: 0.122
+vnc: 0.118
+x86: 0.113
+network: 0.111
+mistranslation: 0.111
+risc-v: 0.109
+hypervisor: 0.103
+debug: 0.101
+TCG: 0.063
+arm: 0.060
+peripherals: 0.060
+kernel: 0.058
+VMM: 0.053
+virtual: 0.051
+assembly: 0.026
+KVM: 0.018
+
+Recent regression: segfault on startup with -snapshot
+
+As of git revision 041ccc922ee474693a2869d4e3b59e920c739bc0, qemu segfaults on startup when I try to boot a hard disk image with the -snapshot option.
+
+To reproduce:
+
+  wget http://wiki.qemu.org/download/linux-0.2.img.bz2
+  bunzip2 linux-0.2.img.bz2 
+  qemu-system-i386 -hda linux-0.2.img -snapshot
+
+When I run this, qemu-system-i386 crashes with a segmentation fault. This is on a Debian 7 amd64 host.
+
+git bisect implicates the following commit:
+
+commit a464982499b2f637f6699e3d03e0a9d2e0b5288b
+Author: Paolo Bonzini <email address hidden>
+Date:   Wed Feb 11 17:15:18 2015 +0100
+
+    rcu: run RCU callbacks under the BQL
+
+    This needs to go away sooner or later, but one complication is the
+    complex VFIO data structures that are modified in instance_finalize.
+    Take a shortcut for now.
+
+    Reviewed-by: Michael Roth <email address hidden>
+    Tested-by: Michael Roth <email address hidden>
+    Signed-off-by: Paolo Bonzini <email address hidden>
+
+I believe this was resolved in:
+
+commit 6b49809c597331803ea941eadda813e5bb4e8fe2
+Author: Paolo Bonzini <email address hidden>
+Date:   Fri Feb 27 19:58:23 2015 +0100
+
+    cpus: fix deadlock and segfault in qemu_mutex_lock_iothread
+
+The problem cannot be reproduced in qemu.git/master (fc85cf4a8199a657fdfd5fb902f1835973406454).
+
diff --git a/results/classifier/118/none/1428352 b/results/classifier/118/none/1428352
new file mode 100644
index 00000000..840d2db0
--- /dev/null
+++ b/results/classifier/118/none/1428352
@@ -0,0 +1,80 @@
+semantic: 0.788
+permissions: 0.764
+hypervisor: 0.682
+peripherals: 0.675
+graphic: 0.673
+mistranslation: 0.665
+performance: 0.653
+assembly: 0.653
+debug: 0.652
+user-level: 0.639
+arm: 0.635
+device: 0.631
+ppc: 0.619
+architecture: 0.615
+vnc: 0.613
+register: 0.607
+PID: 0.596
+KVM: 0.595
+VMM: 0.583
+TCG: 0.559
+risc-v: 0.552
+network: 0.538
+x86: 0.532
+boot: 0.531
+virtual: 0.530
+kernel: 0.514
+files: 0.506
+i386: 0.493
+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/118/none/1428958 b/results/classifier/118/none/1428958
new file mode 100644
index 00000000..faeb768e
--- /dev/null
+++ b/results/classifier/118/none/1428958
@@ -0,0 +1,122 @@
+risc-v: 0.766
+VMM: 0.710
+user-level: 0.709
+virtual: 0.668
+x86: 0.664
+vnc: 0.653
+debug: 0.646
+hypervisor: 0.643
+TCG: 0.643
+KVM: 0.637
+register: 0.630
+arm: 0.630
+permissions: 0.621
+boot: 0.620
+performance: 0.620
+i386: 0.617
+device: 0.617
+files: 0.611
+semantic: 0.606
+assembly: 0.602
+ppc: 0.600
+peripherals: 0.597
+architecture: 0.597
+socket: 0.595
+PID: 0.591
+kernel: 0.582
+graphic: 0.574
+network: 0.564
+mistranslation: 0.551
+
+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/118/none/1429 b/results/classifier/118/none/1429
new file mode 100644
index 00000000..d3fb718d
--- /dev/null
+++ b/results/classifier/118/none/1429
@@ -0,0 +1,85 @@
+peripherals: 0.646
+KVM: 0.632
+hypervisor: 0.625
+TCG: 0.619
+virtual: 0.613
+user-level: 0.611
+mistranslation: 0.610
+ppc: 0.606
+register: 0.582
+vnc: 0.582
+device: 0.564
+x86: 0.563
+risc-v: 0.555
+permissions: 0.548
+VMM: 0.547
+debug: 0.537
+graphic: 0.536
+boot: 0.531
+architecture: 0.527
+performance: 0.518
+arm: 0.514
+network: 0.513
+socket: 0.508
+i386: 0.501
+semantic: 0.500
+files: 0.496
+assembly: 0.493
+kernel: 0.482
+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/118/none/1429034 b/results/classifier/118/none/1429034
new file mode 100644
index 00000000..bea73571
--- /dev/null
+++ b/results/classifier/118/none/1429034
@@ -0,0 +1,55 @@
+user-level: 0.726
+graphic: 0.722
+peripherals: 0.686
+permissions: 0.683
+debug: 0.676
+performance: 0.664
+architecture: 0.657
+semantic: 0.647
+arm: 0.627
+TCG: 0.613
+network: 0.613
+hypervisor: 0.613
+risc-v: 0.611
+mistranslation: 0.610
+virtual: 0.607
+files: 0.604
+device: 0.604
+PID: 0.603
+ppc: 0.595
+kernel: 0.591
+socket: 0.586
+register: 0.585
+assembly: 0.583
+vnc: 0.569
+boot: 0.564
+x86: 0.559
+VMM: 0.553
+KVM: 0.549
+i386: 0.386
+
+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.]
+