add 18th iteration of classifier

1 files changed, 92 insertions, 0 deletions

diff --git a/results/classifier/118/all/1716292 b/results/classifier/118/all/1716292
new file mode 100644
index 000000000..f6f4a78d3
--- /dev/null
+++ b/results/classifier/118/all/1716292
@@ -0,0 +1,92 @@
+network: 0.952
+virtual: 0.951
+semantic: 0.951
+debug: 0.949
+PID: 0.945
+device: 0.943
+register: 0.942
+permissions: 0.940
+ppc: 0.940
+graphic: 0.937
+arm: 0.936
+performance: 0.936
+assembly: 0.935
+user-level: 0.934
+files: 0.933
+vnc: 0.933
+architecture: 0.932
+TCG: 0.923
+socket: 0.922
+risc-v: 0.917
+x86: 0.897
+hypervisor: 0.896
+mistranslation: 0.884
+VMM: 0.881
+peripherals: 0.877
+boot: 0.869
+KVM: 0.841
+kernel: 0.833
+i386: 0.707
+
+User mode emulation returns wrong value for write(fd, NULL, 0)
+
+QEMU version: latest master (fcea73709b966a7ded9efa7b106ea50c7fe9025c)
+OS version: Ubuntu 14.04.3
+Configured with: ../configure --target-list=x86_64-linux-user
+
+QEMU Linux usermode emulation does not handle write() syscalls with zero length and a null pointer correctly: on Linux this returns 0, but in emulation this returns -1.
+
+I ran into this while using an aarch64 abuild-tar from Alpine Linux in user-mode emulation; here's the minimized reproduction test case:
+
+zhuowei@zhuowei-tablet:/tmp$ cat writezerobytes.c
+#include <stdio.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+int main() {
+	ssize_t ret = write(STDOUT_FILENO, NULL, 0);
+	fprintf(stderr, "write returned %ld\n", ret);
+	return 0;
+}
+zhuowei@zhuowei-tablet:/tmp$ gcc -o writezerobytes writezerobytes.c
+zhuowei@zhuowei-tablet:/tmp$ uname -a
+Linux zhuowei-tablet 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11 12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
+zhuowei@zhuowei-tablet:/tmp$ ./writezerobytes 
+write returned 0        
+zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 ./writezerobytes
+write returned -1
+zhuowei@zhuowei-tablet:/tmp$ /media/zhuowei/redhd/docs/repos/qemu/build4/x86_64-linux-user/qemu-x86_64 --version
+qemu-x86_64 version 2.10.50 (v2.10.0-471-gfcea737-dirty)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+This happens for me also, with qemu version 2.12.0 (Debian 1:2.12+dfsg-3).
+
+An initial patch was proposed here: https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg08073.html
+
+Discussion pointed out some problems, and the patch languished and was not accepted.
+
+Here is a summary of the changes needed for it to be more likely for the patch to be accepted: https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg03964.html
+
+ - change from "ret = 0" to something like "ret = get_errno(safe_write(arg1, NULL, 0))"
+ - change TARGET_NR_read to do the same, instead of its current short-circuit behaviour for count==0
+ - check pread64/pwrite64 to see if they need a similar change as well
+
+
+
+On 09/07/2018 06:51 AM, Tony Garnock-Jones wrote:
+> ** Patch added: "0001-Bring-linux-user-write-2-handling-into-line-with-lin.patch"
+>     https://bugs.launchpad.net/qemu/+bug/1716292/+attachment/5186008/+files/0001-Bring-linux-user-write-2-handling-into-line-with-lin.patch
+
+While a developer can chase a URL, our CI tools can't.  Can you please 
+also send that patch directly to <email address hidden>, so that it gets 
+the same level of review as other patches?
+
+-- 
+Eric Blake, Principal Software Engineer
+Red Hat, Inc.           +1-919-301-3266
+Virtualization:  qemu.org | libvirt.org
+
+
+Fix has been committed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=58cfa6c2e6eb51b23cc98
+