summary refs log tree commit diff stats
path: root/results/classifier/108/other/721
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/72145
-rw-r--r--results/classifier/108/other/72179346
-rw-r--r--results/classifier/108/other/721825111
3 files changed, 202 insertions, 0 deletions
diff --git a/results/classifier/108/other/721 b/results/classifier/108/other/721
new file mode 100644
index 00000000..7bf51f8b
--- /dev/null
+++ b/results/classifier/108/other/721
@@ -0,0 +1,45 @@
+other: 0.819
+vnc: 0.811
+KVM: 0.807
+debug: 0.800
+network: 0.800
+semantic: 0.778
+permissions: 0.776
+files: 0.767
+device: 0.766
+graphic: 0.760
+performance: 0.760
+socket: 0.747
+PID: 0.747
+boot: 0.733
+
+Build failed at libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+Steps to reproduce:
+1. Download and build from source
+
+```
+wget https://download.qemu.org/qemu-6.1.0.tar.xz
+tar xvJf qemu-6.1.0.tar.xz
+cd qemu-6.1.0
+./configure
+make
+```
+Additional information:
+```
+[2150/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_dirtyrate.c.o
+[2151/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_ram.c.o
+[2152/9644] Compiling C object libqemu-alpha-softmmu.fa.p/target_alpha_fpu_helper.c.o
+[2153/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_translate-all.c.o
+[2154/9644] Compiling C object libqemu-alpha-softmmu.fa.p/migration_target.c.o
+[2155/9644] Compiling C object libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+FAILED: libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o
+gcc -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -I../dtc/libfdt -I../capstone/include/capstone -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/valgrind -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch -std=gnu11 -O2 -g -isystem /home/intel/Sources/qemu-6.1.0/linux-headers -isystem linux-headers -iquote . -iquote /home/intel/Sources/qemu-6.1.0 -iquote /home/intel/Sources/qemu-6.1.0/include -iquote /home/intel/Sources/qemu-6.1.0/disas/libvixl -iquote /home/intel/Sources/qemu-6.1.0/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -m64 -mcx16 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-trapping-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake -fPIE -isystem../linux-headers -isystemlinux-headers -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -MF libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o.d -o libqemu-aarch64-softmmu.fa.p/accel_tcg_cputlb.c.o -c ../accel/tcg/cputlb.c
+during GIMPLE pass: fab
+In file included from /home/intel/Sources/qemu-6.1.0/include/qemu/osdep.h:37,
+                 from ../accel/tcg/cputlb.c:20:
+../accel/tcg/atomic_common.c.inc: In function ‘helper_atomic_fetch_andb’:
+/home/intel/Sources/qemu-6.1.0/include/exec/helper-head.h:21:27: internal compiler error: in optimize_atomic_bit_test_and, at tree-ssa-ccp.c:3245
+   21 | #define HELPER(name) glue(helper_, name)
+      |                           ^~~~~~~
+/home/intel/Sources/qemu-6.1.0/include/qemu/compiler.h:35:21: note: in definition of macro ‘xglue’
+   35 | #define xglue(x, y) x
diff --git a/results/classifier/108/other/721793 b/results/classifier/108/other/721793
new file mode 100644
index 00000000..2cdd2db4
--- /dev/null
+++ b/results/classifier/108/other/721793
@@ -0,0 +1,46 @@
+performance: 0.871
+graphic: 0.801
+device: 0.746
+network: 0.634
+socket: 0.588
+semantic: 0.587
+boot: 0.525
+PID: 0.482
+files: 0.479
+debug: 0.424
+vnc: 0.398
+other: 0.355
+permissions: 0.331
+KVM: 0.176
+
+QEMU freezes on startup (100% CPU utilization)
+
+0.12.5 was the last version of QEMU that runs ok and boots any os image.
+
+0.13.0-0.14.0 just freeze, and the only thing I see is a black screen and both of them make it use 100% of CPU also.
+Both kernels 2.6.35.11 and 2.6.37.1 with and without PAE support.
+
+tested commands:
+
+W2000:
+$ qemu -m 256 -localtime -net nic,model=rtl8139 -net tap -usbdevice host:0e21:0750 /var/opt/vm/w2000.img
+W2000:
+$ qemu /var/opt/vm/w2000.img
+OpenBSD 4.8:
+$ qemu -cdrom ~/cd48.iso -boot d empty-qcow2.img
+
+tried to use `-M pc-0.12` selector, different audio cards (I've found it caused infinite loop on startup once) -- no luck.
+tried to use recent seabios from git -- still no luck.
+
+attached strace log of 0.14.0.
+
+everything was tested on HP mini 311C with Intel Atom N270.
+
+
+
+
+
+QEMU 0.15.0 fixes the problem.
+
+Closing as "Fix released" according to comment #3
+
diff --git a/results/classifier/108/other/721825 b/results/classifier/108/other/721825
new file mode 100644
index 00000000..66468020
--- /dev/null
+++ b/results/classifier/108/other/721825
@@ -0,0 +1,111 @@
+other: 0.968
+semantic: 0.961
+boot: 0.935
+device: 0.934
+performance: 0.929
+PID: 0.926
+vnc: 0.916
+debug: 0.875
+graphic: 0.843
+files: 0.816
+permissions: 0.804
+network: 0.793
+KVM: 0.756
+socket: 0.741
+
+VDI block driver bugs
+
+Chunqiang Tang reports the following issues with the VDI block driver, these are present in QEMU 0.14:
+
+"Bug 1. The most serious bug is caused by race condition in updating a new 
+bmap entry in memory and on disk. Considering the following operation 
+sequence. 
+  O1: VM issues a write to sector X
+  O2: VDI allocates a new bmap entry and updates in-memory s->bmap
+  O3: VDI writes data to disk
+  O4: The disk I/O for writing sector X fails
+  O5: VDI reports error to VM and returns.
+
+Note that the bmap entry is updated in memory, but not persisted on disk. 
+Now consider another write that immediately follows:
+  P1: VM issues a write to sector X+1, which locates in the same block as 
+the previously used sector X.
+  P2: s->bmap already has one entry for the block, and hence VDI writes 
+data directly without persisting the new s->bmap entry on disk.
+  P3: The write disk I/O succeeds
+  P4: VDI report success to VM, but the bitmap entry is still not 
+persisted on disk.
+
+Now suppose the VM powers off gracefully (i.e., the QEMU process quits) 
+and reboots. The second write to sector X+1, which is reported as finished 
+successfully, is simply lost, because the corresponding in-memory s->bmap 
+entry is never persisted on disk. This is exactly what FVD's testing tool 
+discovers. After the block device is closed and then re-opened, disk 
+content verification fails.
+
+This is just one example of the problem. Race condition plus host crash 
+also causes problems. Consider another example below.
+  Q1: VM issues a write to sector X
+  Q2: VDI allocates a new bmap entry and updates in-memory s->bmap
+  Q3: VDI writes sector X to disk and waits for the callback
+  Q4: VM issues a write to another sector X+1, which is in the same block 
+as sector X.
+  Q5: VDI sees the bitmap entry in s->bmap is already allocated, and 
+writes sector X+1 to disk.
+  Q6: Write to sector X+1 finishes, and VDI's callback is invoked.
+  Q7: VDI acknowledges to the VM the completion of writing sector X+1
+  Q8: After observing the completion of writing sector X+1, VM issues a 
+flush to ensure that sector X+1 is persisted on disk.
+  Q9: VDI finishes the flush and acknowledge the completion of the 
+operation.
+  Q10: ... (some other arbitrary operations, but the disk I/O for writing 
+sector X is still not finished....)
+  Q11: The host crashes
+
+Now the new bitmap entry is not persisted on disk, while both writing to 
+sector X+1 and the flush has been acknowledged as finished. Sector X+1 is 
+lost, which is a corruption. This problem exists even if it uses O_DSYNC. 
+The root cause of the problem is that, if a request updates in-memory 
+s->bmap, another request that sees this update assumes that the update is 
+already persisted on disk, which is not.
+
+Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are 
+several cases of the code below on failure handling path without setting 
+error return code, which mistakenly reports failure as success. This 
+mistake is caught by FVD when doing image content validation.
+       if (acb->hd_aiocb == NULL) {
+           /* missing     ret = -EIO; */
+            goto done; 
+        } 
+
+Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, 
+vdi_aio_cancel does not perform a complete clean up and there are several 
+related bugs. First, memory buffer is not freed, acb->orig_buf and 
+acb->block_buffer. Second, acb->bh is not cancelled. Third, 
+vdi_aio_setup() does not initialize acb->bh to NULL so that when a request 
+acb is cancelled and then later reused for another request, its acb->bh != 
+NULL and the new request fails in  vdi_schedule_bh(). This is caught by 
+FVD's testing tool, when it observes that no I/O failure is injected but 
+VDI reports a failed I/O request, which indicates a bug in the driver."
+
+http://permalink.gmane.org/gmane.comp.emulators.qemu/94340
+
+Is this still an issue with the latest version of QEMU, or could we close this bug nowadays?
+
+On Fri, May 19, 2017 at 8:36 PM, Thomas Huth <email address hidden> wrote:
+> Is this still an issue with the latest version of QEMU, or could we
+> close this bug nowadays?
+
+A quick check of block/vdi.c shows that error handling is still
+lacking.  Updates to in-memory data structures are not reverted if the
+write to disk fails.
+
+Let's leave this in case someone is interested in fixing the bugs
+sometime.  VDI is not used heavily and typically in read-only mode so
+these bugs are not urgent.
+
+
+Hi Stefan (Weil) - this bug is now assigned to you since more than 10 years ... do you still plan to tackle it at some point in time? If not, I'd suggest to unassign it. Also, it's been four years again since the last comment ... should we maybe close this as "Wont Fix" ?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+