restructure results

7 files changed, 640 insertions, 0 deletions

diff --git a/results/classifier/zero-shot/108/PID/1133769 b/results/classifier/zero-shot/108/PID/1133769
new file mode 100644
index 00000000..379ff210
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/1133769
@@ -0,0 +1,47 @@
+PID: 0.996
+other: 0.996
+files: 0.993
+semantic: 0.984
+performance: 0.983
+socket: 0.980
+graphic: 0.980
+device: 0.975
+debug: 0.970
+vnc: 0.940
+KVM: 0.932
+permissions: 0.930
+network: 0.929
+boot: 0.810
+
+qtest failures leave orphaned qemu processes hanging around
+
+If a qtest test case fails, it leaves orphaned qemu processes hanging around. On Fedora 18 with qemu.git as of today ( Feb 26 2013), the  patch just forces a test failure
+
+ps axwww | grep qemu | grep -v grep
+$ make check-qtest-x86_64
+  CC    tests/rtc-test.o
+  LINK  tests/rtc-test
+GTESTER check-qtest-x86_64
+
+$ ps axwww | grep qemu | grep -v grep
+$ patch -p1 < force-test-failure.patch
+patching file tests/rtc-test.c
+
+$ make check-qtest-x86_64
+  CC    tests/rtc-test.o
+  LINK  tests/rtc-test
+GTESTER check-qtest-x86_64
+**
+ERROR:tests/rtc-test.c:256:bcd_check_time: assertion failed: (0)
+GTester: last random seed: R02Sf2521dda395a2713128e0cbf86651a21
+make: *** [check-qtest-x86_64] Error 1
+
+$ ps axwww | grep qemu | grep -v grep
+26258 pts/0    Sl     0:00 x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-26256.sock,nowait -qtest-log /dev/null -qmp unix:/tmp/qtest-26256.qmp,nowait -pidfile /tmp/qtest-26256.pid -machine accel=qtest -display none -rtc clock=vm
+
+The problem is that an assertion failure in a test case causes the test program to exit(2) without hitting the qtest cleanup.
+
+I think this has been fixed sometime in the past already. Or can you still reproduce this problem with the latest version of QEMU?
+
+It appears this is fixed, I haven't seen it in a while
+
diff --git a/results/classifier/zero-shot/108/PID/1708551 b/results/classifier/zero-shot/108/PID/1708551
new file mode 100644
index 00000000..69564041
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/1708551
@@ -0,0 +1,157 @@
+PID: 0.955
+permissions: 0.940
+graphic: 0.940
+other: 0.934
+socket: 0.934
+boot: 0.934
+device: 0.929
+performance: 0.928
+network: 0.923
+semantic: 0.918
+files: 0.917
+debug: 0.916
+vnc: 0.899
+KVM: 0.896
+
+macOS Guest Reading USB 3.0 Bus as USB 2.0
+
+Description:
+I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
+
+Parameters:
+QEMU release version: 2.10.0-rc0
+Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
+Command Line: https://pastebin.com/pBSYbrW1
+Host: Arch Linux
+Guest: macOS v10.12.6
+Guest System Info: https://pastebin.com/U1Tihxei
+
+Notes:
+1. Observed sometime after late-May-early-June of this year.
+
+2. Due to [a defect in qemu v2.8 which affected GTK users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent change to macOS' booting process conflicting with qemu v2.9](https://lists.nongnu.org/archive/html/qemu-devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as -rc1 fails to load OVMF right now).
+
+Could you please try to run QEMU without the "-usb" option here? "-usb" automatically creates an EHCI and UHCI controller on the q35 machine, so that might be the reason that your USB devices get connected as USB 2.0 instead.
+
+Doing so returns:
+`qemu-system-x86_64: -device usb-tablet,bus=usb-bus.0: Bus 'usb-bus.0' not found`
+
+> On Aug 4, 2017, at 2:31 AM, Thomas Huth <email address hidden> wrote:
+> 
+> Could you please try to run QEMU without the "-usb" option here? "-usb"
+> automatically creates an EHCI and UHCI controller on the q35 machine, so
+> that might be the reason that your USB devices get connected as USB 2.0
+> instead.
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1708551
+> 
+> Title:
+>  macOS Guest Reading USB 3.0 Bus as USB 2.0
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  Description:
+>  I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
+> 
+>  Parameters:
+>  QEMU release version: 2.10.0-rc0
+>  Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
+>  Command Line: https://pastebin.com/pBSYbrW1
+>  Host: Arch Linux
+>  Guest: macOS v10.12.6
+>  Guest System Info: https://pastebin.com/U1Tihxei
+> 
+>  Notes:
+>  1. Observed sometime after late-May-early-June of this year.
+> 
+>  2. Due to [a defect in qemu v2.8 which affected GTK
+>  users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent
+>  change to macOS' booting process conflicting with qemu
+>  v2.9](https://lists.nongnu.org/archive/html/qemu-
+>  devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as
+>  -rc1 fails to load OVMF right now).
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions
+
+
+Then simply omit the "bus=usb-bus.0" here - the devices then should be put onto the XHCI bus automatically.
+
+Removing the `bus=usb-bus.0` param from everything, [as shown here](https://pastebin.com/x0Cp70XD), boots fine; but completely breaks mouse functionality. To mitigate, i tried passing through a Logitech mousepad I own--in similar fashion to the iPhone; but Host complained about permissions & `libusb` requiring "write access to USB device nodes".
+
+FWIW, I vaguely recall the `usb-tablet` parameter being "a whole thing" with virtual macOS; however, I'll need to check my records to refresh my memory.
+
+
+> On Aug 4, 2017, at 11:29 AM, Thomas Huth <email address hidden> wrote:
+> 
+> Then simply omit the "bus=usb-bus.0" here - the devices then should be
+> put onto the XHCI bus automatically.
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1708551
+> 
+> Title:
+>  macOS Guest Reading USB 3.0 Bus as USB 2.0
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  Description:
+>  I'm having trouble with USB Passthrough. Running `system_profiler SPUSBDataType` on macOS guest confirms that the system "sees" my device, and that qemu is passing *something* through. However, the system sees my connection as USB 2.0, even though i'm passing through XHCI controllers (nec-usb-xhci/qemu-xhci). I suspect this is the reason why my guest is unable to recognize my iPhone in XCode & iTunes.
+> 
+>  Parameters:
+>  QEMU release version: 2.10.0-rc0
+>  Bios: [patched version of OVMF](https://github.com/gsomlo/edk2/tree/macboot)]
+>  Command Line: https://pastebin.com/pBSYbrW1
+>  Host: Arch Linux
+>  Guest: macOS v10.12.6
+>  Guest System Info: https://pastebin.com/U1Tihxei
+> 
+>  Notes:
+>  1. Observed sometime after late-May-early-June of this year.
+> 
+>  2. Due to [a defect in qemu v2.8 which affected GTK
+>  users](https://bugs.launchpad.net/qemu/+bug/1578192), and [a recent
+>  change to macOS' booting process conflicting with qemu
+>  v2.9](https://lists.nongnu.org/archive/html/qemu-
+>  devel/2017-03/msg06366.html), i'm forced to use qemu v2.10.0-rc0 (as
+>  -rc1 fails to load OVMF right now).
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1708551/+subscriptions
+
+
+Ok, could you maybe try something like this instead:
+
+ qemu-system-x86_64 ... -usb \
+    -device qemu-xhci,id=xhci \
+    -device usb-tablet,bus=usb-bus.0 \
+    -device usb-kbd,bus=usb-bus.0 \
+    -device usb-host,bus=xhci.0,vendorid=0x05ac,productid=0x12a8
+
+i.e. use "bus=xhci.0" for the usb-host device?
+
+In doing so, the device is now unseen by the system.
+
+
+xhci doesn't work with macos because macos has a white list of supported xhci controllers and ignores the xhci adapters emulated by qemu.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/146
+
+
diff --git a/results/classifier/zero-shot/108/PID/1760 b/results/classifier/zero-shot/108/PID/1760
new file mode 100644
index 00000000..0c290462
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/1760
@@ -0,0 +1,68 @@
+PID: 0.966
+performance: 0.934
+graphic: 0.920
+device: 0.909
+files: 0.860
+debug: 0.831
+network: 0.727
+permissions: 0.714
+vnc: 0.615
+socket: 0.609
+boot: 0.551
+KVM: 0.516
+semantic: 0.502
+other: 0.134
+
+qemu8-i386 gets wrong arguments for 32-bit old mmap syscall (_NR_mmap = 90)
+Description of problem:
+qemu8-i386 does not decode syscall arguments correctly for system call _NR_mmap = 90 on i386.
+```
+$ strace ./oldmmap
+execve("./oldmmap", ["./oldmmap"], 0x7fff46ba6d40 /* 61 vars */) = 0
+[ Process PID=405233 runs in 32 bit mode. ]
+mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fa7000
+exit(5)                                 = ?
++++ exited with 5 +++
+
+$ build/qemu-i386 -strace ./oldmmap
+405254 mmap(0x40800058,0,PROT_NONE,0,0,0) = 0x3fffb000
+405254 exit(5)
+```
+Steps to reproduce:
+1. gcc -m32 -o oldmmap -nostartfiles -nostdlib oldmmap.S  # build 32-bit executable
+2. strace ./oldmmap  # run under strace
+3. build/qemu-i386 -strace ./oldmmap  # run under "qemu-i386 -strace"
+4. Notice that qemu-i386 did not report the same arguments to the _NR_map syscall as /usr/bin/strace did.
+Additional information:
+```
+$ cat oldmmap.S
+MAP_FIXED=     0x10
+MAP_PRIVATE=   0x02
+MAP_ANONYMOUS= 0x20
+
+PROT_READ=      1
+PROT_WRITE=     2
+PROT_EXEC=      4
+
+_NR_exit = 1
+_NR_mmap = 90  // oldmmap: %ebx -> array of 6 arguments
+
+    .globl _start
+_start:
+    push $0  // offset
+    push $-1  // fd
+    push $MAP_PRIVATE|MAP_ANONYMOUS  // flags
+    push $PROT_READ|PROT_WRITE  // protection
+    push $2<<12  // length
+    push $0  // addr (kernel chooses)
+    mov %esp,%ebx
+    mov $_NR_mmap,%eax
+    int $0x80
+    nop
+
+    mov $5,%ebx
+    mov $_NR_exit,%eax
+    int $0x80
+    hlt
+$ 
+```
diff --git a/results/classifier/zero-shot/108/PID/1821054 b/results/classifier/zero-shot/108/PID/1821054
new file mode 100644
index 00000000..a420fcb6
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/1821054
@@ -0,0 +1,68 @@
+PID: 0.959
+other: 0.943
+semantic: 0.914
+graphic: 0.909
+device: 0.904
+performance: 0.894
+permissions: 0.885
+debug: 0.844
+vnc: 0.818
+socket: 0.761
+KVM: 0.722
+boot: 0.699
+network: 0.697
+files: 0.693
+
+qemu segfault error when using pcie to dual pci adapter
+
+All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
+I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
+
+hmm that's a fun board.
+
+It looks like qemu has segfaulted;
+   1) is this a qemu build you built yourself? If so, exactly which version, built on which distro?
+   2) Could you get a backtrace of qemu crashing  - this might be easiest if your distro records core dumps somewhere.
+
+FYI: I was happy to find the board and I'm hopeful to get it working. My goal is to use old hardware to make a retro gaming machine for my girls to play games I used to play growing up.
+
+1)No its the qemu installed with unraid version 6.6.7, which i believe is qemu 3.0
+2)im willing to get any notes, logs, or dumps you wish. I just need to know how to do it.
+
+I don't know anything about unraid unfortunately; so I suggest you go back to their forums and ask how to get the backtrace.
+
+I have requested additional info in the other forum. While I wait on reply there, i will say, since you dont know it well, that Unraid is a disto built on top of slackware. Are there any basic command line commands that i could run to get the output you requested, or something to keep things moving while i wait on additional info from the other forum.
+
+Hi! Did you ever get a backtrace? ... otherwise I think we have to close this ticket due to insufficient data...
+
+No I never did. I reached out to try and get info on how to run or get a backtrack and never heard anything. I finally gave up and ended up selling the computer since I never got it working how I wanted to. 
+
+> On Nov 25, 2020, at 10:20 AM, Thomas Huth <email address hidden> wrote:
+> 
+> Hi! Did you ever get a backtrace? ... otherwise I think we have to close
+> this ticket due to insufficient data...
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1821054
+> 
+> Title:
+>  qemu segfault error when using pcie to dual pci adapter
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  All the information I have is located in the Unraid forum on post "https://forums.unraid.net/topic/78545-internal-error-qemu-unexpectedly-closed-the-monitor"
+>  I am happy to provide any addition information requested. Please let me know. Reporting bug here based on recommendation by admin in that forum.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1821054/+subscriptions
+
+
+Ok, thanks for getting back. So I'm closing this now due to insufficient data.
+
diff --git a/results/classifier/zero-shot/108/PID/1857811 b/results/classifier/zero-shot/108/PID/1857811
new file mode 100644
index 00000000..fb20509a
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/1857811
@@ -0,0 +1,204 @@
+PID: 0.948
+performance: 0.943
+socket: 0.938
+device: 0.935
+permissions: 0.934
+debug: 0.933
+other: 0.933
+network: 0.920
+files: 0.912
+semantic: 0.907
+graphic: 0.899
+boot: 0.897
+vnc: 0.842
+KVM: 0.816
+
+qemu user static binary seems to lack support for network namespace.
+
+Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message.
+
+Unable to configure loopback interface: Operation not supported
+
+If I disable emerge's network-sandbox which utilizes network namespace, the error disappears.
+
+Could you run qemu unimplemented error trace, by using "export QEMU_LOG=unimp"?
+
+You can also set the QEMU_STRACE="" to see which syscall fails.
+
+I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="".
+
+The interesting part in emerge.log is:
+
+  23473 socket(16,,IPPROTO_IP) = 5
+  23473 bind(5,274886353720,12,0,1,274889671712) = 0
+  23473 sendto(5,275542232672,38,0,274886353960,12) = -1 errno=95 (Operation not supported)
+  23473 close(5) = 0
+  Unable to configure loopback interface: Operation not supported
+
+So you're right 16 is AF_NETLINK
+
+At QEMU level only one function returns  EOPNOTSUPP, the one managing RTM_* operations (RTM_GETLINK, RTM_GETADDR, ...) and it doesn't manage a bunch of them.
+
+Could you provide a step by step example to reproduce the problem?
+
+def _configure_loopback_interface():
+	"""
+	Configure the loopback interface.
+	"""
+
+	# We add some additional addresses to work around odd behavior in glibc's
+	# getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
+	#
+	# For example:
+	#
+	#   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = AI_ADDRCONFIG };
+	#   getaddrinfo("localhost", NULL, &hints, &res);
+	#
+	# This returns no results if there are no non-loopback addresses
+	# configured for a given address family.
+	#
+	# Bug: https://bugs.gentoo.org/690758
+	# Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
+
+	# Avoid importing this module on systems that may not support netlink sockets.
+	from portage.util.netlink import RtNetlink
+
+	try:
+		with RtNetlink() as rtnl:
+			ifindex = rtnl.get_link_ifindex(b'lo')
+			rtnl.set_link_up(ifindex)
+			rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
+			if _has_ipv6():
+				rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
+	except EnvironmentError as e:
+		writemsg("Unable to configure loopback interface: %s\n" % e.strerror, noiselevel=-1)
+
+If I execute _configure_loopback_interface in a qemu-aarch64 chroot, I see the following error.
+
+Unable to configure loopback interface: Operation not supported
+
+https://bugs.gentoo.org/703276 explains the issue.
+
+You can obtain portage source code from https://gentoo.osuosl.org/distfiles/portage-2.3.84.tar.bz2
+
+I've copied the file portage-2.3.84/build/lib.linux-x86_64-3.7/portage/util/netlink.py from portage to my local directory and run the following script:
+
+cat > rtnetlink.py <<EOF
+import socket
+
+__has_ipv6 = None
+
+def _has_ipv6():
+        """
+        Test that both userland and kernel support IPv6, by attempting
+        to create a socket and listen on any unused port of the IPv6
+        ::1 loopback address.
+
+        @rtype: bool
+        @return: True if IPv6 is supported, False otherwise.
+        """
+        global __has_ipv6
+
+        if __has_ipv6 is None:
+                if socket.has_ipv6:
+                        sock = None
+                        try:
+                                # With ipv6.disable=0 and ipv6.disable_ipv6=1, socket creation
+                                # succeeds, but then the bind call fails with this error:
+                                # [Errno 99] Cannot assign requested address.
+                                sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+                                sock.bind(('::1', 0))
+                        except EnvironmentError:
+                                __has_ipv6 = False
+                        else:
+                                __has_ipv6 = True
+                        finally:
+                                # python2.7 sockets do not support context management protocol
+                                if sock is not None:
+                                        sock.close()
+                else:
+                        __has_ipv6 = False
+
+        return __has_ipv6
+
+def _configure_loopback_interface():
+        """
+        Configure the loopback interface.
+        """
+
+        from netlink import RtNetlink
+        try:
+                with RtNetlink() as rtnl:
+                        ifindex = rtnl.get_link_ifindex(b'lo')
+                        rtnl.set_link_up(ifindex)
+                        rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
+                        if _has_ipv6():
+                                rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
+        except EnvironmentError as e:
+                print("Unable to configure loopback interface: %s\n" % e.strerror)
+
+_configure_loopback_interface()
+EOF
+
+And I have no error in an aarch64/ubunut eoan chroot.
+
+sudo QEMU_STRACE= unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
+...
+675051 socket(PF_NETLINK,,NETLINK_ROUTE) = 3
+675051 bind(3,{nl_family=AF_NETLINK,nl_pid=0,nl_groups=0}, 12) = 0
+675051 sendto(3,274891222784,38,0,274886293096,12) = 38
+...
+
+sudo strace -yyy unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
+
+..
+socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 3<NETLINK:[26260481]>
+bind(3<NETLINK:[26260481]>, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
+sendto(3<NETLINK:[26260481]>, {{len=38, type=0x12 /* NLMSG_??? */, flags=NLM_F_REQUEST, seq=1, pid=0}, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06\x00\x03\x00\x6c\x6f"}, 38, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 38
+...
+
+So I need to know which version you are using (qemu, kernel host).
+
+
+
+qemu-4.0.0
+
+> uname -a
+Linux gentoo 4.19.97-gentoo #3 SMP PREEMPT Mon Feb 10 15:09:44 KST 2020 x86_64 AMD FX(tm)-8300 Eight-Core Processor AuthenticAMD GNU/Linux
+
+Could you run something like "sudo strace -yyy unshare --net chroot ..." with your failing binary to see what returns the host kernel?
+
+Can you rephrase your question? I don't know what to do with your question.
+
+I need the strace result of _configure_loopback_interface in a qemu-aarch64 chroot.
+
+But as strace cannot be started in the chroot you must strace the "chroot" command and its children.
+
+So something like "sudo strace -yyy chroot <your chroot directory> <your test path>"
+
+I just called _configure_loopback_interface in a qemu-aarch64 chroot, and the error is not reproducible with qemu-4.2.0. Has it been fixed?
+
+Yes, it's fixed in v4.2.0, and with the help of your test program I've bisect to the fix:
+
+commit 1645fb5a1e537f85eda744bfa6e9d3dda047ba28
+Author: Shu-Chun Weng <email address hidden>
+Date:   Thu Oct 17 17:19:20 2019 -0700
+
+    Fix unsigned integer underflow in fd-trans.c
+    
+    In any of these `*_for_each_*` functions, the last entry in the buffer (so the
+    "remaining length in the buffer" `len` is equal to the length of the
+    entry `nlmsg_len`/`nla_len`/etc) has size that is not a multiple of the
+    alignment, the aligned lengths `*_ALIGN(*_len)` will be greater than `len`.
+    Since `len` is unsigned (`size_t`), it underflows and the loop will read
+    pass the buffer.
+    
+    This may manifest as random EINVAL or EOPNOTSUPP error on IO or network
+    system calls.
+    
+    Signed-off-by: Shu-Chun Weng <email address hidden>
+    Reviewed-by: Laurent Vivier <email address hidden>
+    Message-Id: <email address hidden>
+    Signed-off-by: Laurent Vivier <email address hidden>
+
+
diff --git a/results/classifier/zero-shot/108/PID/2423 b/results/classifier/zero-shot/108/PID/2423
new file mode 100644
index 00000000..ef57e3b7
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/2423
@@ -0,0 +1,49 @@
+PID: 0.960
+performance: 0.877
+graphic: 0.868
+other: 0.796
+device: 0.779
+permissions: 0.701
+semantic: 0.674
+debug: 0.645
+vnc: 0.508
+socket: 0.498
+network: 0.492
+boot: 0.448
+files: 0.386
+KVM: 0.264
+
+`qemu -serial stdio` leaves stdout in non-blocking mode
+Description of problem:
+When `-serial stdio` is used, qemu exits leaving stdout in non-blocking mode. Although it [attempts](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L52) to restore stdin to blocking mode, it misses that stdout also gets O_NONBLOCK by [qemu_chr_open_fd](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-stdio.c#L116) ([here](https://gitlab.com/qemu-project/qemu/-/blob/1a2d52c7fcaeaaf4f2fe8d4d5183dccaeab67768/chardev/char-fd.c#L215)). It causes the next applications in the script misbehave because they get unexpected EAGAIN on write to stdout.
+Steps to reproduce:
+Run the following script:
+
+```
+#!/usr/bin/env bash
+
+qemu-system-x86_64 -nodefaults -display none -no-reboot -serial stdio &
+PID="$!"
+sleep 5
+kill "$PID"
+wait "$PID"
+echo "EXITING $?"
+
+sleep 5
+seq 1 400000
+```
+
+The seq command will be interrupted prematurely:
+
+```
+...
+5143
+5144
+5145⏎                                                                                                                                                                                                                wResource temporarily unavailable
+write: Resource temporarily unavailable
+write: Resource temporarily unavailable
+```
+
+When run from fish shell, it will also start misbehaving when running next commands (fish bug report: https://github.com/fish-shell/fish-shell/issues/10600).
+Additional information:
+Expect a patch from me soon.
diff --git a/results/classifier/zero-shot/108/PID/655 b/results/classifier/zero-shot/108/PID/655
new file mode 100644
index 00000000..1731ff8d
--- /dev/null
+++ b/results/classifier/zero-shot/108/PID/655
@@ -0,0 +1,47 @@
+PID: 0.989
+device: 0.968
+files: 0.948
+graphic: 0.942
+semantic: 0.936
+permissions: 0.892
+vnc: 0.884
+performance: 0.868
+network: 0.853
+socket: 0.852
+debug: 0.832
+KVM: 0.828
+other: 0.822
+boot: 0.745
+
+Java crashes on s390x VM with SIGILL/ILL_PRVOPC at '__kernel_getcpu+0x8'
+Description of problem:
+The `java` command fails with the following message:
+
+```console
+$ /usr/lib/jvm/java-17-openjdk-s390x/bin/java --version
+#
+# A fatal error has been detected by the Java Runtime Environment:
+#
+# SIGILL (0x4) at pc=0x000003ff9e4fe6f4, pid=2883, tid=2884
+#
+# JRE version: (17.0+35) (build )
+# Java VM: OpenJDK 64-Bit Server VM (17+35-Ubuntu-120.04, mixed
+# mode, sharing, tiered, compressed oops, compressed class ptrs,
+# serial gc, linux-s390x)
+# Problematic frame:
+# C [linux-vdso64.so.1+0x6f8] __kernel_getcpu+0x8
+#
+# Core dump will be written. Default location: Core dumps may
+# be processed with "/usr/share/apport/apport %p %s %c %d %P %E"
+# (or dumping to /home/ubuntu/core.2883)
+#
+# An error report file with more information is saved as:
+# /home/ubuntu/hs_err_pid2883.log
+#
+#
+Aborted (core dumped)
+```
+Steps to reproduce:
+1. Run `java --version`
+Additional information:
+The corresponding log file is attached as the file [hs_err_pid2883.log](/uploads/1631b6a0f0aad2f77c4928ed6bb540c6/hs_err_pid2883.log).