summary refs log tree commit diff stats
path: root/results/classifier/108/other/1355
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/135516
-rw-r--r--results/classifier/108/other/135564437
-rw-r--r--results/classifier/108/other/135569766
3 files changed, 119 insertions, 0 deletions
diff --git a/results/classifier/108/other/1355 b/results/classifier/108/other/1355
new file mode 100644
index 00000000..811d2c11
--- /dev/null
+++ b/results/classifier/108/other/1355
@@ -0,0 +1,16 @@
+debug: 0.832
+device: 0.795
+performance: 0.670
+network: 0.549
+graphic: 0.520
+semantic: 0.350
+socket: 0.293
+boot: 0.255
+permissions: 0.174
+vnc: 0.147
+files: 0.135
+other: 0.120
+PID: 0.028
+KVM: 0.016
+
+qemu-system-x86_64: Issue while setting TUNSETSTEERINGEBPF: Invalid argument with fd: 13, prog_fd: -1
diff --git a/results/classifier/108/other/1355644 b/results/classifier/108/other/1355644
new file mode 100644
index 00000000..01da55c9
--- /dev/null
+++ b/results/classifier/108/other/1355644
@@ -0,0 +1,37 @@
+graphic: 0.805
+device: 0.544
+semantic: 0.465
+performance: 0.381
+boot: 0.296
+permissions: 0.268
+other: 0.249
+network: 0.246
+socket: 0.235
+debug: 0.229
+PID: 0.212
+vnc: 0.196
+files: 0.180
+KVM: 0.036
+
+windows7 reboot bluesreen 0x0000005c
+
+I have met sevaral blue screen with 0x0000005c(0x0000010b,0x00000003,0x00000000,0x00000000) after windows7 reboot.
+It always happens just before the windows iron animation appears.
+
+my qemu version is qemu-2.1.0
+my guest os is windows7 32bits sp1
+
+my qemu commandline is 
+./x86_64-softmmu/qemu-system-x86_64 -m 2048 -hda system.inst -spice port=5940,disable-ticketing -monitor stdio --enable-kvm
+
+This bug  doesn't happen always,and i don‘t know how to reproduce it.
+
+But i have a special way to produce such a bluescreen.
+I set nmi dump on and set windows to collect dump file and set auto reboot after system fail on. 
+Then i send a nmi to guest, and then after collecting dump file , windows will auto reboot and then such a blue screen happens.
+And this can be  reproduced always.
+
+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/1355697 b/results/classifier/108/other/1355697
new file mode 100644
index 00000000..718ff8ea
--- /dev/null
+++ b/results/classifier/108/other/1355697
@@ -0,0 +1,66 @@
+graphic: 0.863
+semantic: 0.766
+performance: 0.762
+device: 0.734
+PID: 0.714
+permissions: 0.692
+other: 0.653
+socket: 0.642
+vnc: 0.638
+KVM: 0.627
+network: 0.619
+files: 0.617
+boot: 0.552
+debug: 0.472
+
+qemu-img: Segfault on a fuzzed image with large values of L1/L2 entries
+
+'qemu-img check -r all/leaks' failed with a segmentation fault on the fuzzed image with L1/L2 entry values having UINT64 border values.
+
+Sequence:
+ 1. Unpack the attached archive, make a copy of test.img
+ 2. Put copy.img and backing_img.raw in the same directory
+ 3. Execute
+   
+qemu-img check -f qcow2 -r all copy.img
+
+Result: qemu-img was killed by SIGSEGV.
+
+The qemu-img execution log can be found in the attached archive.
+
+
+qemu.git HEAD 2d591ce2aeebf
+
+
+
+Hi,
+
+This issue has at least been partially fixed in master (5f77ef69a195098baddfdc6d189f1b4a94587378):
+
+$ ./qemu-img check -f qcow2 -r all copy.img
+Warning: cluster offset=0xfffffffffe0000 is after the end of the image file, can't properly check refcounts.
+Warning: cluster offset=0x100000000000000 is after the end of the image file, can't properly check refcounts.
+ERROR l2_offset=fffffffffffe00: Table is not cluster aligned; L1 entry corrupted
+Repairing cluster 0 refcount=0 reference=1
+Repairing cluster 1 refcount=0 reference=1
+qcow2: Marking image as corrupt: Preventing invalid write on metadata (overlaps with refcount table); further corruption events will be suppressed
+Repairing cluster 21 refcount=0 reference=1
+
+4 errors were found on the image.
+Data may be corrupted, or further writes to the image may corrupt it.
+
+2 internal errors have occurred during the check.
+Image end offset: 2883584
+
+I'm still working towards the repair function actually doing its job.
+
+Thank you for your report,
+
+Max
+
+Hi,
+
+Okay, so this image has the same “issue” (it's intentionally broken, so it's not really an issue) as the one in bug 1355738: There are corrupted L2 entries which are impossible for qemu to repair. Therefore, we could only ask the user to use qemu-img convert and that's all we can do. Therefore, I'm marking this fixed as well.
+
+Max
+