4 files changed, 191 insertions, 0 deletions
diff --git a/results/classifier/108/other/1357 b/results/classifier/108/other/1357
new file mode 100644
index 000000000..6d3640f26
--- /dev/null
+++ b/results/classifier/108/other/1357
@@ -0,0 +1,24 @@
+device: 0.793
+performance: 0.770
+graphic: 0.686
+other: 0.559
+semantic: 0.490
+network: 0.434
+vnc: 0.381
+debug: 0.306
+boot: 0.278
+socket: 0.223
+PID: 0.217
+permissions: 0.205
+KVM: 0.140
+files: 0.140
+
+qemu-img should generate VMDK with an EOS marker when `has_marker` flag enabled
+Additional information:
+I generate a empty volume with capacity 1G and try to deploy it as a part of OVF. This would fail. 
+
+But when I append an EOS marker to that VMDK, which is actually a zeroed sector, the deployed procedure succeeded.
+
+This case merely happened if VMDK has data, since `qemu-img` always write at least one grain(64 KB). So the padding part will be recognized as  EOS marker.
+
+I have written a temporary patch for this and it works fine for me. I'm glad to send it for review.
diff --git a/results/classifier/108/other/1357175 b/results/classifier/108/other/1357175
new file mode 100644
index 000000000..029eae73c
--- /dev/null
+++ b/results/classifier/108/other/1357175
@@ -0,0 +1,40 @@
+device: 0.837
+files: 0.798
+performance: 0.782
+socket: 0.742
+graphic: 0.699
+PID: 0.685
+network: 0.679
+semantic: 0.674
+permissions: 0.650
+boot: 0.604
+other: 0.571
+vnc: 0.549
+debug: 0.515
+KVM: 0.324
+
+qemu fails to build on powerpc64
+
+Qemu fails to build on powerpc64, ELFv1 ABI, since the introduction of the ELFv2 ABI support.  On FreeBSD/powerpc64 I see the following error building HEAD from today (8/14/2014):
+
+In file included from /home/chmeee/qemu-git/tcg/tcg.c:264:
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1737:3: error: #error "Unhandled abi"
+In file included from /home/chmeee/qemu-git/tcg/tcg.c:264:
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: In function 'tcg_target_qemu_prologue':
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: 'LINK_AREA_SIZE' undeclared (first use in this function)
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: (Each undeclared identifier is reported only once
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1766: error: for each function it appears in.)
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:1778: error: 'LR_OFFSET' undeclared (first use in this function)
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c: At top level:
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2579: error: 'LINK_AREA_SIZE' undeclared here (not in a function)
+/home/chmeee/qemu-git/tcg/ppc/tcg-target.c:2605: error: 'LR_OFFSET' undeclared here (not in a function)
+gmake[1]: *** [tcg/tcg.o] Error 1
+
+Triaging old bug tickets ... can you still reproduce this issue with the latest version of QEMU?
+
+It looks like this has been fixed in the intervening 3 years.  I just tried building head on FreeBSD/powerpc64, and was successful.
+
+It looks like this has been fixed in the intervening 3 years.  I just tried building head on FreeBSD/powerpc64, and was successful.
+
+OK, thanks for checking!
+
diff --git a/results/classifier/108/other/1357226 b/results/classifier/108/other/1357226
new file mode 100644
index 000000000..61745fe11
--- /dev/null
+++ b/results/classifier/108/other/1357226
@@ -0,0 +1,82 @@
+other: 0.849
+graphic: 0.819
+boot: 0.807
+debug: 0.774
+device: 0.772
+permissions: 0.766
+semantic: 0.766
+performance: 0.765
+PID: 0.731
+vnc: 0.726
+files: 0.705
+socket: 0.684
+KVM: 0.677
+network: 0.538
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+
+steps to reproduce:
+pbuilder-dist utopic armhf create
+pbuilder-dist utopic armhf login
+apt-get install imagemagick
+convert foo.xpm foo.png
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+(doesn't matter if images are actually there or not)
+
+I'm running into this same problem, and it's making automation of Raspberry Pi builds of my application difficult.
+
+I'm running in a chroot environment:
+3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 armv7l GNU/Linux
+
+Package: qemu
+Version: 1.1.2+dfsg-6a+deb7u11
+
+This may or may not be relevant here, but the mysterious "uncaught target signal 11" error was fixed for maas images (lp:maas-images) build process by increasing the memory to the VMs that were doing the build.  We had been doing the cross/qemu-static building in ~512M vms and that was resulting in somewhat transient failures during 'apt-get update'.  Upping the memory of the vm to 2G made those go away.
+
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Thanks Thomas for assigning to Ubuntu's Qemu which is correct in this case.
+I know there are still issues reported by Locutus to look into, but this one seems expired.
+
+I don't want to appear randomly closing bugs, so I verified with something "old" which today would be Trusty. So there I ran.
+
+$ pbuilder-dist trusty armhf create
+$ pbuilder-dist trusty armhf login
+$ apt-get install imagemagick
+$ convert foo.xpm foo.png (file not there)
+$ convert ./share/pixmaps/display.im6.xpm ./share/pixmaps/display.im6.png (Trusty)
+$ convert ./share/pixmaps/display-im6.q16.xpm ./share/pixmaps/display-im6.q16.png (Artful)
+
+All working, so closing this old bug as invalid now.
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Hi, I am getting the error:
+
+qemu: uncaught target signal 11 (Segmentation fault) - core dumped
+Segmentation fault
+
+When I try to execute a Hello World binary on my amd64 machine, with Hello World built by mips-linux-gnu-g++, using either mips binfmt extensions (./hello) or qemu-mips-static hello. I have libstdc++6:mips installed as well. My source code is as follows:
+
+#include <iostream>
+using std::cout;
+
+int main() {
+    cout << "Hello World!\n";
+    return 0;
+}
+
+Worth noting that this problem only happens with mips cross runs. mips64el and mipsel work just fine.
+
+I happen to be doing this in Debian 10.0.0 Buster stable amd64 on VirtualBox on Ubuntu 19.04 Disco Dingo amd64, but it looks like the same behavior on native Ubuntu hosts as well. I tried increasing guest RAM to 1GiB and 2GiB, with no affect on the runtime error message. Is there a glitch in one of the mips packages?
+
+@mcandre, I think your issue, even though it's also a segfault, is a different one than this bug from 2014, which was about armhf and was verified in comment #4 as no longer happening.
+
+Could you please open a separate bug about what you experienced, including detailed steps to reproduce it? Attaching the core file would also help.
+
+Thanks!
+
+
diff --git a/results/classifier/108/other/1357445 b/results/classifier/108/other/1357445
new file mode 100644
index 000000000..025c5de8f
--- /dev/null
+++ b/results/classifier/108/other/1357445
@@ -0,0 +1,45 @@
+graphic: 0.805
+performance: 0.760
+semantic: 0.707
+files: 0.679
+device: 0.675
+socket: 0.597
+network: 0.575
+PID: 0.568
+vnc: 0.531
+permissions: 0.465
+KVM: 0.354
+debug: 0.322
+boot: 0.280
+other: 0.228
+
+qemu-img: 'amend -o compat=0.10' command failed with segfault on the fuzzed image
+
+qemu-img amend -o compat=0.10' failed with a segmentation fault on the fuzzed image.
+
+Sequence:
+ 1. Unpack the attached archive, make a copy of test.img
+ 2. Put copy.img and backing_img.qed in the same directory
+ 3. Execute
+   qemu-img amend -o compat=0.10 -f qcow2 copy.img
+
+Result: qemu-img was killed by SIGSEGV.
+
+Traces can be found in the attached archive.
+
+qemu.git HEAD 2d591ce2aeebf
+
+
+
+Hi,
+
+being on 2d591ce2aeebf, I rather receive "qemu-img: Error while amending options: File too large". Judging from the traces, though, this issue (the segfault at least) should be fixed by my "[PATCH v3 0/7] block/qcow2: Improve zero cluster expansion" series anyway (when merged eventually).
+
+Max
+
+Hi,
+
+Well, I still (on 2.2.0-rc2) receive "File too large", so I guess that's the fix.
+
+Max
+