add deepseek and gemma results

72 files changed, 2638 insertions, 0 deletions

diff --git a/results/classifier/gemma3:12b/socket/1020484 b/results/classifier/gemma3:12b/socket/1020484
new file mode 100644
index 00000000..4aa3fe34
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1020484
@@ -0,0 +1,4 @@
+
+RFE: Support spice via unix domain socket
+
+According to the man page, spice can be only used via TCP/IP in opposite to VNC, which can also be configured to listen on a unix domain socket. To make it easy to use spice without exposing the interface, please support unix domain sockets as well. I can try  to provide a patch, if you can point me to the source code where TCP/IP socket is opened.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1055 b/results/classifier/gemma3:12b/socket/1055
new file mode 100644
index 00000000..fe95dc42
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1055
@@ -0,0 +1,17 @@
+
+QEMU does not close listening socket for incoming migration when post-copy migration breaks
+Description of problem:
+QEMU keeps listening on the incoming port even after breaking a post-copy
+migration using "migrate-pause" QMP command. And even once migration is
+finished after recovering it "migrate-recover" using a different port number.
+If "migrate-recover" is called with a URI specifying the original port (which
+is still in LISTEN state), QEMU reports "Failed to find an available port:
+Address already in use".
+Steps to reproduce:
+1. start migration
+2. wait for the first iteration to finish
+3. switch to post-copy using "migrate-start-postcopy"
+3. break migration with "migrate-pause"
+4. check lsof -p $QEMU_PID
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/socket/1064631 b/results/classifier/gemma3:12b/socket/1064631
new file mode 100644
index 00000000..1c917b50
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1064631
@@ -0,0 +1,14 @@
+
+Feature request: tls for chardev socket (telnet,tcp,udp)
+
+Hello,
+
+it would be nice if chardev socket (telnet,tcp,udp) could have tls support as vnc does.
+
+This way we could have encrypted access to virtual character devices over network,
+for example in setup: conserver -> socat+tls <-> qemu+chardev+tls.
+
+The best would be both direction - server even client, so even the client should
+trust remote server (trustfile, fingeprint...?).
+
+Thank you.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1075272 b/results/classifier/gemma3:12b/socket/1075272
new file mode 100644
index 00000000..bf9ee5bb
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1075272
@@ -0,0 +1,14 @@
+
+socket type mapping wrong for mips app-level emulation
+
+linux-user/syscall.c's do_socket function contains socket type remapping to work around the nonsensically-permuted MIPS socket types. However, it fails to account for the SOCK_NONBLOCK and SOCK_CLOEXEC flags that may be or'd onto the type. Thus, a call from the application such as:
+
+socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
+
+will fail to have the type permutation performed, and will be passed to the system as:
+
+socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP)
+
+resulting in EPROTONOSUPPORT.
+
+To fix this, the flag bits should be masked off of the type before the permutation. They also need remapping themselves (since MIPS uses different values for these flags bits).
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1075339 b/results/classifier/gemma3:12b/socket/1075339
new file mode 100644
index 00000000..ad8e3a4d
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1075339
@@ -0,0 +1,4 @@
+
+linux-user emulation of setsockopt ignores optlen
+
+setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1090726 b/results/classifier/gemma3:12b/socket/1090726
new file mode 100644
index 00000000..f5ece7ba
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1090726
@@ -0,0 +1,49 @@
+
+qemu does not generate guest cpu topology properly
+
+Adding the option
+
+-smp 12,sockets=2,cores=6,threads=1
+
+exposes
+
+
+Machine (12GB)
+  Socket #0
+        L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0)
+        L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1)
+        L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2)
+        L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3)
+        L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4)
+        L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5)
+        L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6)
+        L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7)
+  Socket #1
+      L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8)
+      L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9)
+      L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10)
+      L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11)
+
+
+Rather than:
+
+Machine (12GB)
+  Socket #0
+        L2 L#0 (512KB) + L1 L#0 (64KB) + Core L#0 + PU L#0 (P#0)
+        L2 L#1 (512KB) + L1 L#1 (64KB) + Core L#1 + PU L#1 (P#1)
+        L2 L#2 (512KB) + L1 L#2 (64KB) + Core L#2 + PU L#2 (P#2)
+        L2 L#3 (512KB) + L1 L#3 (64KB) + Core L#3 + PU L#3 (P#3)
+        L2 L#4 (512KB) + L1 L#4 (64KB) + Core L#4 + PU L#4 (P#4)
+        L2 L#5 (512KB) + L1 L#5 (64KB) + Core L#5 + PU L#5 (P#5)
+  Socket #1
+        L2 L#6 (512KB) + L1 L#6 (64KB) + Core L#6 + PU L#6 (P#6)
+        L2 L#7 (512KB) + L1 L#7 (64KB) + Core L#7 + PU L#7 (P#7)
+        L2 L#8 (512KB) + L1 L#8 (64KB) + Core L#8 + PU L#8 (P#8)
+        L2 L#9 (512KB) + L1 L#9 (64KB) + Core L#9 + PU L#9 (P#9)
+        L2 L#10 (512KB) + L1 L#10 (64KB) + Core L#10 + PU L#10 (P#10)
+        L2 L#11 (512KB) + L1 L#11 (64KB) + Core L#11 + PU L#11 (P#11)
+
+
+Here is a cpuid dump from inside the guest and dump from more recent version of cpuid, in which you can see a bit more detail. The later contains data for a single CPU, because the others are the same.
+
+Reproducible on qemu 1.0 and 1.2. with guest os Fedora 17, Debian 6, Debian Squeeze and Windows 2008 R2.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1156632 b/results/classifier/gemma3:12b/socket/1156632
new file mode 100644
index 00000000..07b6c70a
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1156632
@@ -0,0 +1,25 @@
+
+not receiving RESET event after system_reset command causes QMP connection to die
+
+I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection:
+
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) close socket
+7) Connect to socket -> connection refused
+
+However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events:
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) Receive reply (is a RESET event)
+7) Receive reply (is a RESET event)
+8) close socket
+9) Connect to socket -> ok
+
+I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU?
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1264 b/results/classifier/gemma3:12b/socket/1264
new file mode 100644
index 00000000..b21c8e62
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1264
@@ -0,0 +1,2 @@
+
+socket chardev loses data when remote end closes the connection
diff --git a/results/classifier/gemma3:12b/socket/1316 b/results/classifier/gemma3:12b/socket/1316
new file mode 100644
index 00000000..9d43c587
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1316
@@ -0,0 +1,2 @@
+
+qemu.qmp.protocol.ConnectError: Failed to establish connection: AF_UNIX path too long (on Darwin)
diff --git a/results/classifier/gemma3:12b/socket/1327608 b/results/classifier/gemma3:12b/socket/1327608
new file mode 100644
index 00000000..c8711422
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1327608
@@ -0,0 +1,24 @@
+
+monitor socked path is cut a 105 characters
+
+Starting a VM like so:
+
+/usr/bin/qemu-system-x86_64 -machine accel=kvm -monitor unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor,server,nowait -name gentoo-summerschool -chardev socket,id=monitor,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/monitor.sock,server,nowait -monitor chardev:monitor -chardev socket,id=serial0,path=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/console.sock,server,nowait -serial chardev:serial0 -enable-kvm -cpu kvm64 -smp 2 -netdev tap,id=net0,script=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/qemu-ifup.bash -device e1000,netdev=net0,mac=00:00:00:00:00:02 -drive id=disk,file=/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img,if=none -device ahci,id=ahci -device ide-drive,drive=disk,bus=ahci.0 -m 2048 -vga qxl -spice port=2002,addr=192.168.4.2,password=NO-thats-not-my-pwd -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent
+
+
+The path: 
+
+unix:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor
+
+...is cut like so when I try to shutdown:
+
+pink ~ # echo system_powerdown | socat - UNIX-CONNECT:/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschool/gentoo-summerschool.img.monitor
+2014/06/08 06:39:01 socat[2344] E connect(3, AF=1 "/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/lv-gentoosummerschool/gentoo-summerschoo", 110): No such file or directory
+pink ~ # 
+
+
+It does work with a sorter path like: 
+pink ~ # echo system_powerdown | socat - UNIX-CONNECT:'/srv/localfs/Samsung_SSD_840_PRO_Series_S1AXNSAF320206J/vg-virt/my.img.monitor' 
+QEMU 1.5.3 monitor - type 'help' for more information
+(qemu) system_powerdown
+(qemu) pink ~ #
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1353149 b/results/classifier/gemma3:12b/socket/1353149
new file mode 100644
index 00000000..92a1c4c8
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1353149
@@ -0,0 +1,20 @@
+
+qemu 2.1.0 fails to start if number of cores is greater than 1.
+
+qemu (kvm) 2.1.0 (built from sources) fails to start if number of cores is greater than 1.
+
+relevant part of commandline arguments:
+
+/usr/bin/qemu-system-x86_64 -name test3 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Westmere -m 4096 -realtime mlock=off -smp 1,maxcpus=4,sockets=1,cores=4,threads=1
+
+the error reported is:
+
+qemu-system-x86_64: /home/asavah/pkgbuild/qemu-2.1.0/hw/i386/smbios.c:825: smbios_get_tables: Assertion `smbios_smp_sockets >= 1' failed.
+2014-08-05 21:45:35.825+0000: shutting down
+
+however setting 4 sockets with 1 core each allows me to start the machine just fine.
+
+the system is debian wheezy
+Linux hostname 3.16.0-hostname2 #2 SMP Mon Aug 4 17:02:16 EEST 2014 x86_64 GNU/Linux
+
+libvirt 1.2.7 (built from sources)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1381879 b/results/classifier/gemma3:12b/socket/1381879
new file mode 100644
index 00000000..56fc25aa
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1381879
@@ -0,0 +1,34 @@
+
+can not run vm with a serial port
+
+environment:
+server: centOS 6.5, 3.14.19, x86_64
+qemu-kvm: QEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2), Copyright (c) 2003-2008 Fabrice Bellard
+qemu-system-x86_64 :QEMU emulator version 1.2.0 (qemu-kvm-1.2.0), Copyright (c) 2003-2008 Fabrice Bellard
+virt-manager: 0.9.0
+
+VM: centOS 6.5, 3.12.30, x86_64
+
+reproduce step:
+1. add serial device
+2. select device type: unix socket
+                 device parameters: path=/dev/ttyS0
+                                                       mode=client mode(connect)
+3. run the VM
+
+phenomenon:
+Error starting domain: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use
+qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed
+
+
+Traceback (most recent call last):
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
+    callback(asyncjob, *args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
+    callback(*args, **kwargs)
+  File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup
+    self._backend.create()
+  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 678, in create
+    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
+libvirtError: internal error process exited while connecting to monitor: qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: socket bind failed: Address already in use
+qemu-kvm: -chardev socket,id=charserial0,path=/dev/ttyS0,server,nowait: chardev: opening backend "socket" failed
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1426 b/results/classifier/gemma3:12b/socket/1426
new file mode 100644
index 00000000..51c2b1c7
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1426
@@ -0,0 +1,39 @@
+
+On windows, display spice-app is not able to initialize, start spice-server and consequently can't use spice-client
+Description of problem:
+I want to try windows spice-client / virt-viewer.exe (v11.0.256) instead of gtk client.  
+Windows spice client virtviewer won't start like it does under Linux.  
+The error message indicaes that the spice-server itself failed to open spice sockets
+The registry to handle ```spice://``` URI handler is configured.
+Steps to reproduce:
+1. just run command
+Additional information:
+URI handler in registry is configure using a regestry import file ```spiceproto.reg```
+```
+Windows Registry Editor Version 5.00
+
+[HKEY_CLASSES_ROOT\spice]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice\Extensions]
+[HKEY_CLASSES_ROOT\spice\shell]
+[HKEY_CLASSES_ROOT\spice\shell\open]
+[HKEY_CLASSES_ROOT\spice\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+
+[HKEY_CLASSES_ROOT\spice+unix]
+"URL Protocol"=""
+
+[HKEY_CLASSES_ROOT\spice+unix\DefaultIcon]
+@="C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe,1"
+
+[HKEY_CLASSES_ROOT\spice+unix\Extensions]
+[HKEY_CLASSES_ROOT\spice+unix\shell]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open]
+[HKEY_CLASSES_ROOT\spice+unix\shell\open\command] 
+@="\"C:\\Program Files\\VirtViewer v11.0-256\\bin\\remote-viewer.exe\" \"%1\""
+```
+This URI handler is working, and can be seen to work by typing ```spice://abcdefg``` in firefox.
diff --git a/results/classifier/gemma3:12b/socket/1471 b/results/classifier/gemma3:12b/socket/1471
new file mode 100644
index 00000000..9d99e130
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1471
@@ -0,0 +1,17 @@
+
+16fc5726a6 breaks curl SSL connections
+Description of problem:
+`./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk` should work, just as `./qemu-aarch64 /path/to/curl-aarch64 https://news.bbc.co.uk` does. However, commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4 broke this (determined via `git bisect`).
+Steps to reproduce:
+1. Checkout and build `qemu` commit 16fc5726a6e296b3f63acec537c299c1dc49d6c4
+2. On an aarch64 host system, download the amd64 build of `curl` from https://github.com/moparisthebest/static-curl/releases/tag/v7.87.0
+3. Run `./qemu-x86_64 /path/to/curl-amd64 https://news.bbc.co.uk`
+4. Observe the following error message:
+
+```
+curl: (35) error:1416D07B:SSL routines:tls_process_key_exchange:bad signature
+```
+
+Note that the `aarch64` equivalent works just fine. As does the previous commit using `amd64`. 
+
+Also note, this bug is also present at current tip (13356edb87506c148b163b8c7eb0695647d00c2a).
diff --git a/results/classifier/gemma3:12b/socket/1472083 b/results/classifier/gemma3:12b/socket/1472083
new file mode 100644
index 00000000..ccabf8f6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1472083
@@ -0,0 +1,28 @@
+
+Qemu 2.1.2 hang when stop command
+
+Qemu 2.1.2, Linux kernel 3.13.6, this is the stack.
+
+#0  in ppoll () from /lib/x86_64-linux-gnu/libc.so.6
+#1  in qemu_poll_ns (fds=0x7fa82a8de380, nfds=1, timeout=-1) at qemu-timer.c:314
+#2  in aio_poll (ctx=0x7fa82a8b5000, blocking=true) at aio-posix.c:250
+#3  in bdrv_drain_all () at block.c:1924
+#4  in do_vm_stop (state=RUN_STATE_PAUSED) at /qemu-2.1.2/cpus.c:544
+#5  in vm_stop (state=RUN_STATE_PAUSED) at /qemu-2.1.2/cpus.c:1227
+#6  in qmp_stop (errp=0x7ffffb6dcaf8) at qmp.c:98
+#7  in qmp_marshal_input_stop (mon=0x7fa82a8e0970, qdict=0x7fa830295020, ret=0x7ffffb6dcb48) at qmp-marshal.c:2806
+#8  in qmp_call_cmd (mon=0x7fa82a8e0970, cmd=0x7fa8290558a0, params=0x7fa830295020)  at /qemu-2.1.2/monitor.c:5038
+#9  in handle_qmp_command (parser=0x7fa82a8e0a28, tokens=0x7fa82a8d9b50) at /qemu-2.1.2/monitor.c:5104
+#10 in json_message_process_token (lexer=0x7fa82a8e0a30, token=0x7fa830122b60, type=JSON_OPERATOR, x=39, y=17865) at qobject/json-streamer.c:87
+#11 in json_lexer_feed_char (lexer=0x7fa82a8e0a30, ch=125 '}', flush=false) at qobject/json-lexer.c:303
+#12 in json_lexer_feed (lexer=0x7fa82a8e0a30, buffer=0x7ffffb6dcdb0 "}\315m\373\377\177", size=1) at qobject/json-lexer.c:356
+#13 in json_message_parser_feed (parser=0x7fa82a8e0a28, buffer=0x7ffffb6dcdb0 "}\315m\373\377\177", size=1) at qobject/json-streamer.c:111
+#14 in monitor_control_read (opaque=0x7fa82a8e0970, buf=0x7ffffb6dcdb0 "}\315m\373\377\177", size=1) at /qemu-2.1.2/monitor.c:5125
+#15 in qemu_chr_be_write (s=0x7fa82a8c2020, buf=0x7ffffb6dcdb0 "}\315m\373\377\177", len=1) at qemu-char.c:213
+#16 in tcp_chr_read (chan=0x7fa82a8c4ba0, cond=G_IO_IN, opaque=0x7fa82a8c2020) at qemu-char.c:2729
+#17 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
+#18 in glib_pollfds_poll () at main-loop.c:190
+#19 in os_host_main_loop_wait (timeout=24000000) at main-loop.c:235
+#20 in main_loop_wait (nonblocking=0) at main-loop.c:484
+#21 in main_loop () at vl.c:2034
+#22 in main (argc=55, argv=0x7ffffb6de338, envp=0x7ffffb6de4f8) at vl.c:4583
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1478360 b/results/classifier/gemma3:12b/socket/1478360
new file mode 100644
index 00000000..7d21d45b
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1478360
@@ -0,0 +1,133 @@
+
+Cant compile on ubuntu 14.04 x64
+
+./configure --static
+Install prefix    /usr/local
+BIOS directory    /usr/local/share/qemu
+binary directory  /usr/local/bin
+library directory /usr/local/lib
+module directory  /usr/local/lib/qemu
+libexec directory /usr/local/libexec
+include directory /usr/local/include
+config directory  /usr/local/etc
+local state directory   /usr/local/var
+Manual directory  /usr/local/share/man
+ELF interp prefix /usr/gnemul/qemu-%M
+Source path       /home/slobodan/qemu
+C compiler        cc
+Host C compiler   cc
+C++ compiler      c++
+Objective-C compiler cc
+ARFLAGS           rv
+CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -g 
+QEMU_CFLAGS       -I/usr/include/pixman-1    -Werror -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common  -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all -I/usr/include/p11-kit-1     -I/usr/include/libpng12  
+LDFLAGS           -Wl,--warn-common -m64 -static -g 
+make              make
+install           install
+python            python -B
+smbd              /usr/sbin/smbd
+module support    no
+host CPU          x86_64
+host big endian   no
+target list        aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu microblazeel-softmmu mips-softmmu mips64-softmmu mips64el-softmmu mipsel-softmmu moxie-softmmu or32-softmmu ppc-softmmu ppc64-softmmu ppcemb-softmmu s390x-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu tricore-softmmu unicore32-softmmu x86_64-softmmu xtensa-softmmu xtensaeb-softmmu aarch64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user i386-linux-user m68k-linux-user microblaze-linux-user microblazeel-linux-user mips-linux-user mips64-linux-user mips64el-linux-user mipsel-linux-user mipsn32-linux-user mipsn32el-linux-user or32-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user ppc64le-linux-user s390x-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc32plus-linux-user sparc64-linux-user unicore32-linux-user x86_64-linux-user
+tcg debug enabled no
+gprof enabled     no
+sparse enabled    no
+strip binaries    yes
+profiler          no
+static build      yes
+pixman            system
+SDL support       no
+GTK support       yes
+GNUTLS support    yes
+GNUTLS hash       yes
+GNUTLS gcrypt     yes
+GNUTLS nettle     no ()
+VTE support       no
+curses support    no
+curl support      no
+mingw32 support   no
+Audio drivers     oss
+Block whitelist (rw) 
+Block whitelist (ro) 
+VirtFS support    no
+VNC support       yes
+VNC TLS support   no
+VNC SASL support  no
+VNC JPEG support  yes
+VNC PNG support   yes
+xen support       no
+brlapi support    no
+bluez  support    yes
+Documentation     no
+GUEST_BASE        yes
+PIE               no
+vde support       no
+netmap support    no
+Linux AIO support no
+ATTR/XATTR support yes
+Install blobs     yes
+KVM support       yes
+RDMA support      no
+TCG interpreter   no
+fdt support       yes
+preadv support    yes
+fdatasync         yes
+madvise           yes
+posix_madvise     yes
+sigev_thread_id   yes
+uuid support      yes
+libcap-ng support no
+vhost-net support yes
+vhost-scsi support yes
+Trace backends    nop
+spice support     no
+rbd support       no
+xfsctl support    no
+nss used          no
+libusb            no
+usb net redir     no
+OpenGL support    no
+libiscsi support  no
+libnfs support    no
+build guest agent yes
+QGA VSS support   no
+QGA w32 disk info no
+seccomp support   no
+coroutine backend ucontext
+coroutine pool    yes
+GlusterFS support no
+Archipelago support no
+gcov              gcov
+gcov enabled      no
+TPM support       yes
+libssh2 support   no
+TPM passthrough   yes
+QOM debugging     yes
+vhdx              yes
+lzo support       no
+snappy support    no
+bzip2 support     no
+NUMA host support no
+tcmalloc support  no
+
+:~/qemu$ make
+  GEN   config-host.h
+  GEN   qemu-options.def
+  GEN   qmp-commands.h
+  GEN   qapi-types.h
+  GEN   qapi-visit.h
+  GEN   qapi-event.h
+  GEN   trace/generated-events.h
+  GEN   trace/generated-tracers.h
+  GEN   trace/generated-tcg-tracers.h
+  GEN   trace/generated-helpers-wrappers.h
+  GEN   trace/generated-helpers.h
+  GEN   tests/test-qapi-types.h
+  GEN   tests/test-qapi-visit.h
+  GEN   tests/test-qmp-commands.h
+  GEN   tests/test-qapi-event.h
+  CC    tests/qemu-iotests/socket_scm_helper.o
+  LINK  tests/qemu-iotests/socket_scm_helper
+c++: error: unrecognized command line option ‘-R’
+make: *** [tests/qemu-iotests/socket_scm_helper] Error 1
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1495 b/results/classifier/gemma3:12b/socket/1495
new file mode 100644
index 00000000..2454b0d8
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1495
@@ -0,0 +1,7 @@
+
+MacOS fails check-unit for test-io-channel-command for some reason
+Description of problem:
+While adding the socat dependency to the CI system it triggers a failure on the ARM MacOS build, eg: https://gitlab.com/stsquad/qemu/-/jobs/3769189709
+Steps to reproduce:
+1. install socat
+2. make check-unit
diff --git a/results/classifier/gemma3:12b/socket/1504513 b/results/classifier/gemma3:12b/socket/1504513
new file mode 100644
index 00000000..cb0ec207
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1504513
@@ -0,0 +1,26 @@
+
+Socket leak on each call to qemu_socket()
+
+On any host platform where SOCK_CLOEXEC is defined (Linux at least), a socket is leaked on each call to qemu_socket() AND the socket returned hasn't been created with the desired SOCK_CLOEXEC attribute.  The qemu_socket routine is:
+
+Line 272 of util/osdep.c:
+/*
+ * Opens a socket with FD_CLOEXEC set
+ */
+int qemu_socket(int domain, int type, int protocol)
+{
+    int ret;
+
+#ifdef SOCK_CLOEXEC
+    ret = socket(domain, type | SOCK_CLOEXEC, protocol);
+    if (ret != -1 || errno != EINVAL) {
+        return ret;
+    }
+#endif
+    ret = socket(domain, type, protocol);
+    if (ret >= 0) {
+        qemu_set_cloexec(ret);
+    }
+
+    return ret;
+}
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1542965 b/results/classifier/gemma3:12b/socket/1542965
new file mode 100644
index 00000000..9367f38a
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1542965
@@ -0,0 +1,6 @@
+
+Failed to set NBD socket ubuntu 15.10 & nbd client 3.10
+
+Running command to mount using nbd fails
+with error
+/build/qemu-YZq7uh/qemu-2.3+dfsg/nbd.c:nbd_init():L670: Failed to set NBD socket
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1549 b/results/classifier/gemma3:12b/socket/1549
new file mode 100644
index 00000000..b85147d3
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1549
@@ -0,0 +1,96 @@
+
+8.0.0rc0 Regression: spicy windows doesn't open
+Description of problem:
+Soon after start the qemu process outputs 
+```
+qemu-system-x86_64.exe: fd=900 is not a socket, AIO implementation is missing
+qemu-system-x86_64.exe: fd=800 is not a socket, AIO implementation is missing
+```
+On connecting with `spicy -h localhost -p 5905 --spice-debug` spicy stops progress after writing this line
+```
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
+```
+Steps to reproduce:
+1. Start qemu with `qemu-system-x86_64 -m 1536 -vga qxl -spice port=5905,addr=127.0.0.1,disable-ticketing=on -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first MSYS2 MinGW64 terminal
+2. Start spice with `spicy -h localhost -p 5905 --spice-debug` in second MSYS2 MinGW64 terminal
+Additional information:
+Final output of `git bisect`
+```
+abe34282b088499f4e86fff9bb6d6dafd57ae1d0 is the first bad commit
+commit abe34282b088499f4e86fff9bb6d6dafd57ae1d0
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Tue Feb 21 16:47:59 2023 +0400
+
+    win32: avoid mixing SOCKET and file descriptor space
+
+    Until now, a win32 SOCKET handle is often cast to an int file
+    descriptor, as this is what other OS use for sockets. When necessary,
+    QEMU eventually queries whether it's a socket with the help of
+    fd_is_socket(). However, there is no guarantee of conflict between the
+    fd and SOCKET space. Such conflict would have surprising consequences,
+    we shouldn't mix them.
+
+    Also, it is often forgotten that SOCKET must be closed with
+    closesocket(), and not close().
+
+    Instead, let's make the win32 socket wrapper functions return and take a
+    file descriptor, and let util/ wrappers do the fd/SOCKET conversion as
+    necessary. A bit of adaptation is necessary in io/ as well.
+
+    Unfortunately, we can't drop closesocket() usage, despite
+    _open_osfhandle() documentation claiming transfer of ownership, testing
+    shows bad behaviour if you forget to call closesocket().
+
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
+    Message-Id: <20230221124802.4103554-15-marcandre.lureau@redhat.com>
+
+ include/sysemu/os-win32.h |   4 +-
+ io/channel-watch.c        |   6 +-
+ util/aio-win32.c          |   9 +-
+ util/oslib-win32.c        | 219 +++++++++++++++++++++++++++++++++++++++-------
+ 4 files changed, 197 insertions(+), 41 deletions(-)
+```
+Complete spicy output
+```
+$ spicy -h localhost -p 5905 --spice-debug
+(spicy.exe:5584): GSpice-DEBUG: 18:43:52.890: ../spice-gtk-0.42/src/spice-session.c:288 New session (compiled from package spice-gtk 0.42)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.872: ../spice-gtk-0.42/src/spice-session.c:292 Supported channels: main, display, inputs, cursor, playback, record, smartcard, usbredir, webdav
+(spicy.exe:5584): GSpice-WARNING **: 18:43:53.877: SpiceSession:gl-scanout is only available on Unix
+(spicy.exe:5584): GSpice-WARNING **: 18:43:53.881: UsbDk driver is not installed
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.908: ../spice-gtk-0.42/src/usb-device-manager.c:393 auto-connect filter set to 0x03,-1,-1,-1,0|-1,-1,-1,-1,1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.913: ../spice-gtk-0.42/src/usb-backend.c:440 spice_usb_backend_new >>
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.918: ../spice-gtk-0.42/src/usb-backend.c:462 spice_usb_backend_new <<
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.995: ../spice-gtk-0.42/src/usb-backend.c:207 adding 04F2:B43C at 1:1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:53.998: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C26 at 3:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.000: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C2D at 1:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.003: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:B728 at 1:4
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.006: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e280, usblib dev 00000148d27a2590
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.010: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8086:8C31 at 2:0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.014: ../spice-gtk-0.42/src/usb-backend.c:207 adding 05E3:0608 at 3:5
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.017: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8008 at 1:5
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.020: ../spice-gtk-0.42/src/usb-backend.c:207 adding 0BDA:0129 at 1:3
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.023: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e140, usblib dev 00000148d27a2b30
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.027: ../spice-gtk-0.42/src/usb-backend.c:207 adding 8087:8000 at 3:4
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.030: ../spice-gtk-0.42/src/usb-backend.c:207 adding 045E:00DB at 3:1
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.033: ../spice-gtk-0.42/src/usb-backend.c:207 adding 17EF:6019 at 3:2
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.035: ../spice-gtk-0.42/src/usb-backend.c:158 created dev 00000148d2a9e190, usblib dev 00000148d27a5460
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/tools/spicy.c:1881 connection_new (1)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.074: ../spice-gtk-0.42/src/usb-backend.c:469 handle_libusb_events >>
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.081: ../spice-gtk-0.42/src/spice-session.c:1835 no migration in progress
+Spice-INFO: 18:43:54.086: ../spice-gtk-0.42/src/channel-main.c:342:spice_main_set_property: SpiceMainChannel::color-depth has been deprecated. Property is ignored
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.090: ../spice-gtk-0.42/src/spice-channel.c:142 main-1:0: spice_channel_constructed
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.093: ../spice-gtk-0.42/src/spice-session.c:2330 main-1:0: new main channel, switching
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.097: ../spice-gtk-0.42/tools/spicy.c:1758 new channel (#0)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.099: ../spice-gtk-0.42/tools/spicy.c:1761 new main channel
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.102: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:b728 (00000148d2a9e280)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.105: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 0bda:0129 (00000148d2a9e140)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.108: ../spice-gtk-0.42/src/usb-device-manager.c:800 device added 17ef:6019 (00000148d2a9e190)
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.113: ../spice-gtk-0.42/src/spice-channel.c:2763 main-1:0: Open coroutine starting 00000148d2a403f0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.116: ../spice-gtk-0.42/src/spice-channel.c:2587 main-1:0: Started background coroutine 00000148d2a402b0
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.120: ../spice-gtk-0.42/src/spice-session.c:2267 main-1:0: Using plain text, port 5905
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.124: ../spice-gtk-0.42/src/spice-session.c:2198 open host localhost:5905
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.136: ../spice-gtk-0.42/src/spice-session.c:2120 main-1:0: connecting 000000010f1ffc90...
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.402: ../spice-gtk-0.42/src/spice-session.c:2104 main-1:0: connect ready
+(spicy.exe:5584): GSpice-DEBUG: 18:43:54.406: ../spice-gtk-0.42/src/spice-channel.c:1415 main-1:0: channel type 1 id 0 num common caps 1 num caps 1
+```
diff --git a/results/classifier/gemma3:12b/socket/1553 b/results/classifier/gemma3:12b/socket/1553
new file mode 100644
index 00000000..5a4b82dd
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1553
@@ -0,0 +1,13 @@
+
+Build error: implicit declaration of function 'qemu_close_to_socket'
+Description of problem:
+When build the latest master code with MSYS2 on Windows 10, GCC reports:
+../ui/spice-core.c: In function 'watch_remove':
+../ui/spice-core.c:152:5: error: implicit declaration of function 'qemu_close_to_socket' [-Werror=implicit-function-declaration]
+  152 |     qemu_close_to_socket(watch->fd);
+      |     ^~~~~~~~~~~~~~~~~~~~
+../ui/spice-core.c:152:5: error: nested extern declaration of 'qemu_close_to_socket' [-Werror=nested-externs]
+Steps to reproduce:
+1. ./configure --enable-sdl --enable-gtk --target-list=arm-softmmu,aarch64-softmmu
+2. cd build
+3. make
diff --git a/results/classifier/gemma3:12b/socket/1581695 b/results/classifier/gemma3:12b/socket/1581695
new file mode 100644
index 00000000..e2569a29
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1581695
@@ -0,0 +1,19 @@
+
+getifaddrs: Address family not supported by protocol
+
+Calling ip addr fails with the following error message:
+Cannot open netlink socket: Address family not supported by protocol
+
+
+My use case is running a docker raspberry pi arm container on Ubuntu 14.04 x64 with qemu-static.
+
+My steps to reproduce are the following:
+
+# docker pull philipz/rpi-raspbian:latest
+# docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static philipz/rpi-raspbian bash
+root@3b4ddc174279:/# ip addr
+Cannot open netlink socket: Address family not supported by protocol
+
+A fix or an workaround would be awesome.
+
+note: we are also working with a embedded arm distro which has no package manager available, would be nice if the workaround would not depend on apt-get
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1586756 b/results/classifier/gemma3:12b/socket/1586756
new file mode 100644
index 00000000..ebd2e853
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1586756
@@ -0,0 +1,53 @@
+
+"-serial unix:" option of qemu-system-arm is broken in qemu 2.6.0
+
+I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 works fine).
+Occasionally, a part of the output of qemu disappears in the bug.
+
+It looks like following commit is the cause:
+
+char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange <email address hidden>)
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9
+
+In this commit, UNIX socket is set to non-blocking mode, but qemu_chr_fe_write function doesn't handle EAGAIN.
+You should fix code like that:
+
+---
+diff --git a/qemu-char.c b/qemu-char.c
+index b597ee1..0361d78 100644
+--- a/qemu-char.c
++++ b/qemu-char.c
+@@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, const uint8_t *buf, int
+ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
+ {
+     int ret;
++    int offset = 0;
+ 
+     if (s->replay && replay_mode == REPLAY_MODE_PLAY) {
+         int offset;
+@@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
+     }
+ 
+     qemu_mutex_lock(&s->chr_write_lock);
+-    ret = s->chr_write(s, buf, len);
++
++    while (offset < len) {
++    retry:
++        ret = s->chr_write(s, buf, len);
++        if (ret < 0 && errno == EAGAIN) {
++            g_usleep(100);
++            goto retry;
++        }
++
++        if (ret <= 0) {
++            break;
++        }
++
++        offset += ret;
++    }
+ 
+     if (ret > 0) {
+         qemu_chr_fe_write_log(s, buf, ret);
+---
+
+Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9".
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1605443 b/results/classifier/gemma3:12b/socket/1605443
new file mode 100644
index 00000000..cd41f234
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1605443
@@ -0,0 +1,12 @@
+
+QEMU epoll for i386-linux-user on arm host is broken in 2.6
+
+I'm trying to get wine running on qemu-i386 on arm.
+
+I found that 2.5.1 is OK, but 2.6 is not.
+
+By bisecting, I found commit 928bed6a057cedd6110e634865e021a24029785a is the problem.
+
+I reverted this commit, and then epoll is OK now.
+
+It seems that the commit broke epoll of qemu-i386 on arm.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1612908 b/results/classifier/gemma3:12b/socket/1612908
new file mode 100644
index 00000000..5addf283
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1612908
@@ -0,0 +1,8 @@
+
+qom-[list,tree,get,set] don't accept tcp endpoint arg
+
+Hi, 
+
+I'm using origin/master [6bbbb0ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. 
+
+I have a patch to fix this issue that I can submit to the developer list.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1643619 b/results/classifier/gemma3:12b/socket/1643619
new file mode 100644
index 00000000..25856ef2
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1643619
@@ -0,0 +1,33 @@
+
+netlink broken on big-endian mips
+
+Debian QEMU version 2.7.0, but the bug also appears in current git master (commit c36ed06e9159)
+
+As the summary says, netlink is completely broken on big-endian mips running qemu-user.
+
+Running 'ip route' from within a Debian chroot with QEMU simply hangs. Running amd64 strace on qemu-mips-static shows that it's waiting for a netlink response from the kernel which never comes.
+
+[...]
+[pid 11249] socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
+[pid 11249] setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
+[pid 11249] setsockopt(3, SOL_SOCKET, SO_RCVBUF, [1048576], 4) = 0
+[pid 11249] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
+[pid 11249] getsockname(3, {sa_family=AF_NETLINK, nl_pid=11249, nl_groups=00000000}, [12]) = 0
+[pid 11249] time([1479745823])          = 1479745823
+[pid 11249] sendto(3, {{len=671088640, type=0x1a00 /* NLMSG_??? */, flags=NLM_F_REQUEST|NLM_F_MULTI|0x100, seq=539046744, pid=0}, "\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\35\0\0\0\1"}, 40, 0, NULL, 0) = 40
+[pid 11249] recvmsg(3,
+
+Notice the len in the buffer passed to the kernel is 0x28000000 which looks byteswapped.
+
+Removing the call to fd_trans_unregister in the NR_socket syscall in do_syscall fixes this for me, but I don't understand why the fd translation was immediately unregistered after being registered just before in do_socket - presumably it was added for a reason.
+
+--- a/linux-user/syscall.c
++++ b/linux-user/syscall.c
+@@ -9331,7 +9331,6 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
+ #ifdef TARGET_NR_socket
+     case TARGET_NR_socket:
+         ret = do_socket(arg1, arg2, arg3);
+-        fd_trans_unregister(ret);
+         break;
+ #endif
+ #ifdef TARGET_NR_socketpair
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1668273 b/results/classifier/gemma3:12b/socket/1668273
new file mode 100644
index 00000000..8fda6a39
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1668273
@@ -0,0 +1,65 @@
+
+DoS possible on - a QEMU process using userspace SLIRP?
+
+Steps to reproduce:
+
+- Launch a VM using QEMU:
+
+$ qemu-system-x86_64 -machine accel=kvm \
+                     -hda Fedora-Cloud-Base-25-1.3.x86_64.qcow2 \
+                     -m 2G \
+                     -smp 2 \
+                     -vnc :8 \
+                     -boot dc \
+                     -vga std \
+                     -cpu host \
+                     -net nic,vlan=0 \
+                     -net user,vlan=0,hostfwd=tcp::10024-:22,hostfwd=tcp::8082-:80
+
+- SSH into the VM, install httpd, start httpd
+
+$ ssh -p 10024 root@localhost 'dnf install -y httpd && systemctl start httpd'
+
+- Compile and run the following Java program:
+
+$ cat <<EOF > URLConnectionReader.java
+import java.net.*;
+import java.io.*;
+
+public class URLConnectionReader {
+    public static void main(String[] args) throws Exception {
+        int i = 0;
+        while (i < 1024) {
+            URL this_is_404 = new URL("http://localhost:8082/blah");
+            URLConnection yc = this_is_404.openConnection();
+            try {
+                BufferedReader in = new BufferedReader(new InputStreamReader(
+                            yc.getInputStream()));
+                String inputLine;
+                while ((inputLine = in.readLine()) != null)
+                    System.out.println(inputLine);
+                in.close();
+            } catch (Exception e) {
+                //HttpURLConnection urlConnection = (HttpURLConnection) yc;
+                //urlConnection.disconnect();
+            }
+            i++;
+        }
+        Thread.sleep(1000000000);
+    }
+}
+
+$ javac URLConnectionReader.java
+
+$ java URLConnectionReader &
+
+The java program tries to open a lot of HTTP connections, but never calls disconnect() on any.
+
+- Take a look at the list of open FDs of the qemu process:
+
+$ ls -tl /proc/${qemu-pid}/fd
+
+$ lsof -p ${qemu-pid}
+All of the TCP connections will be stuck at FIN_WAIT2
+
+The VM becomes unresponsive. Neither SSH or VNC works on this.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1701808 b/results/classifier/gemma3:12b/socket/1701808
new file mode 100644
index 00000000..318fa8b2
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1701808
@@ -0,0 +1,17 @@
+
+stack smashing in or after recvmsg system call in aarch64 user mode
+
+A program that invokes recvmsg aborts with "*** stack smashing detected ***" when run in qemu-aarch64 (user mode), but works fine when running on native aarch64 hardware.
+
+How to reproduce:
+$ aarch64-linux-gnu-gcc-5 -O -Wall /media/develdata/devel/qemu-bug/testpassfd.c -static -DEXTRA_SPACE=0
+$ QEMU_LD_PREFIX=/usr/aarch64-linux-gnu ~/inst-qemu/2.9.0/bin/qemu-aarch64 ./a.out
+*** stack smashing detected ***: ./a.out terminated
+qemu: uncaught target signal 6 (Aborted) - core dumped
+
+On native aarch64 hardware:
+$ ./a.out 
+$ echo $?
+0
+
+The parameter EXTRA_SPACE can be used to add additional space to the array that receives the recvmsg data. With -DEXTRA_SPACE=9 (or larger), the program runs fine. Which suggests that recvmsg is storing up to 9 bytes more than allowed in memory.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1711602 b/results/classifier/gemma3:12b/socket/1711602
new file mode 100644
index 00000000..ef97b8b0
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1711602
@@ -0,0 +1,28 @@
+
+--copy-storage-all failing with qemu 2.10
+
+We fixed an issue around disk locking already in regard to qemu-nbd [1], but there still seem to be issues.
+
+$ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.196/system
+error: internal error: qemu unexpectedly closed the monitor: 2017-08-18T12:10:29.800397Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
+2017-08-18T12:10:48.545776Z qemu-system-x86_64: load of migration failed: Input/output error
+
+Source libvirt log for the guest:
+2017-08-18 12:09:08.251+0000: initiating migration
+2017-08-18T12:09:08.809023Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer
+2017-08-18T12:09:08.809481Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer
+
+Target libvirt log for the guest:
+2017-08-18T12:09:08.730911Z qemu-system-x86_64: load of migration failed: Input/output error
+2017-08-18 12:09:09.010+0000: shutting down, reason=crashed
+
+Given the timing it seems that the actual copy now works (it is busy ~10 seconds on my environment which would be the copy).
+Also we don't see the old errors we saw before, but afterwards on the actual take-over it fails.
+
+Dmesg has no related denials as often apparmor is in the mix.
+
+Need to check libvirt logs of source [2] and target [3] in Detail.
+
+[1]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02200.html
+[2]: http://paste.ubuntu.com/25339356/
+[3]: http://paste.ubuntu.com/25339358/
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1713328 b/results/classifier/gemma3:12b/socket/1713328
new file mode 100644
index 00000000..47407fc6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1713328
@@ -0,0 +1,10 @@
+
+Unable to C-a in -nographic if -serial telnet
+
+qemu-system-i386 (version 2.6.1, running on Linux/x86_64) started with:
+
+qemu-system-i386 -m 64M -machine type=pc -rtc base=localtime,clock=host -nographic -serial telnet:127.0.0.1:1234,server,nowait -net nic,model=ne2k_pci -net user,hostfwd=tcp:127.0.0.1:2200-:22,tftp=/
+
+does not accept the escape key (C-a) to perform functions such as switching from monitor to console. Verified both in GNU screen and in the Linux console.
+
+If '-serial telnet:127.0.0.1:1234,server,nowait' is removed from the command line, the escape key is accepted (and Qemu doesn't enter the monitor immediately).
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1754605 b/results/classifier/gemma3:12b/socket/1754605
new file mode 100644
index 00000000..fcab3cf2
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1754605
@@ -0,0 +1,15 @@
+
+ppc64 migration bad_dest test is failed with failed to connect to socket
+
+On ppc64le machine the following test failed.
+
+# QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/migration-test V=1
+/ppc64/migration/deprecated: OK
+/ppc64/migration/bad_dest: qemu-system-ppc64: Failed to connect socket: Connection refused
+OK
+/ppc64/migration/postcopy/unix: OK
+
+Head is at f6d81cdec807bb85325afedb536b17c5331483c7
+configured with options: configure --target-list=ppc64-softmmu
+
+This test case is added through 2c9bb29703caa8fd31078cc38b3b53762557c27c
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1777 b/results/classifier/gemma3:12b/socket/1777
new file mode 100644
index 00000000..43d0c748
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1777
@@ -0,0 +1,2 @@
+
+Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console
diff --git a/results/classifier/gemma3:12b/socket/1781280 b/results/classifier/gemma3:12b/socket/1781280
new file mode 100644
index 00000000..466ec5ee
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1781280
@@ -0,0 +1,10 @@
+
+QEMU ignores all but the first control message sent over a Unix socket
+
+I've written a test program that sends both an SCM_CREDENTIALS and an SCM_RIGHTS cmsg in the same sendmsg call. On native x86-64, armv6 and armv7 Linux, this works as expected (the recvmsg receives both control messages). On QEMU (both qemu-x86_64 and qemu-arm), only the first message is received.
+
+I've traced the problem back to a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13500
+
+This means that writing control messages into an uninitialized buffer makes CMSG_NXTHDR erroneously return NULL even though there's still space inside the allocated buffer. QEMU's logic inside `target_to_host_cmsg` is a bit questionable here, since it stops encoding cmsgs as soon as *either* the host or the target buffer reaches its end, so we lose the target's cmsgs when the host's buffer runs out. However, the host buffer should *never* reach its end before the target buffer does, so an assertion might be more useful there. Anyway, the actual fix for this bug is simply zeroing out the buffer created for the host. I've attached a patch doing that and verified that it fixes the issue.
+
+The test program I used can be found here: https://gist.github.com/jonas-schievink/cb6e6584a055539d2113f22d91068e2d
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1807052 b/results/classifier/gemma3:12b/socket/1807052
new file mode 100644
index 00000000..f9af0216
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1807052
@@ -0,0 +1,226 @@
+
+Qemu hangs during migration
+
+Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9
+Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9
+
+When this VM is running on source server:
+
+/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-testvm/master-key.aes -machine pc-q35-3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 3b00b788-ee91-4e45-80a6-c7319da71225 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-pci-bridge,id=pci.3,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device piix3-usb-uhci,id=usb,bus=pci.3,addr=0x1 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pci.4,addr=0x0 -drive file=/dev/zvol/datastore/vm/testvm-vda,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2,write-cache=on -drive if=none,id=drive-sata0-0-4,media=cdrom,readonly=on -device ide-cd,bus=ide.4,drive=drive-sata0-0-4,id=sata0-0-4,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:b7:a1,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -s -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
+
+I try to migrate it and the disks to the other side:
+
+virsh migrate --live --undefinesource --persistent --verbose --copy-storage-all testvm qemu+ssh://wasvirt1/system
+
+We get to 99% then hang with both sides in the pause state.
+
+Source server is stuck here:
+(gdb) bt full
+#0  0x00007f327994f3c1 in ppoll () at /lib64/libc.so.6
+#1  0x000000000086167b in qemu_poll_ns (fds=<optimized out>, nfds=nfds@entry=1, timeout=<optimized out>) at util/qemu-timer.c:322
+#2  0x0000000000863302 in aio_poll (ctx=0x21044e0, blocking=blocking@entry=true) at util/aio-posix.c:629
+        node = <optimized out>
+        i = <optimized out>
+        ret = 0
+        progress = <optimized out>
+        timeout = <optimized out>
+        start = <optimized out>
+        __PRETTY_FUNCTION__ = "aio_poll"
+#3  0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:62
+        waited_ = <optimized out>
+        wait_ = 0x2ba563c
+        ctx_ = 0x2109bb0
+        bs_ = 0x2ba2400
+        client = 0x31287e0
+        client = <optimized out>
+        request = {handle = 0, from = 0, len = 0, flags = 0, type = 2}
+#4  0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:965
+        client = <optimized out>
+        request = {handle = 0, from = 0, len = 0, flags = 0, type = 2}
+#5  0x00000000007de5ca in nbd_close (bs=<optimized out>) at block/nbd.c:491
+        s = 0x31287e0
+#6  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3352
+        ban = <optimized out>
+        ban_next = <optimized out>
+        child = <optimized out>
+        next = <optimized out>
+#7  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3560
+#8  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:4616
+#9  0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3359
+        ban = <optimized out>
+        ban_next = <optimized out>
+        child = <optimized out>
+        next = <optimized out>
+#10 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3560
+#11 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:4616
+#12 0x0000000000785784 in block_job_remove_all_bdrv (job=job@entry=0x2f32570) at blockjob.c:200
+        c = 0x23bac30
+        l = 0x20dd330 = {0x23bac30, 0x2b89410}
+#13 0x00000000007ceb5f in mirror_exit (job=0x2f32570, opaque=0x7f326407a350) at block/mirror.c:700
+        s = 0x2f32570
+        bjob = 0x2f32570
+        data = 0x7f326407a350
+        bs_opaque = 0x30d5600
+        replace_aio_context = <optimized out>
+        src = 0x2131080
+        target_bs = 0x2af96f0
+        mirror_top_bs = 0x210eb70
+        local_err = 0x0
+#14 0x0000000000786452 in job_defer_to_main_loop_bh (opaque=0x7f32640786a0) at job.c:973
+        data = 0x7f32640786a0
+        job = <optimized out>
+        aio_context = 0x2109bb0
+#15 0x000000000085fd3f in aio_bh_poll (ctx=ctx@entry=0x21044e0) at util/async.c:118
+---Type <return> to continue, or q <return> to quit---
+        bh = <optimized out>
+        bhp = <optimized out>
+        next = 0x2ea86e0
+        ret = 1
+        deleted = false
+#16 0x00000000008631b0 in aio_dispatch (ctx=0x21044e0) at util/aio-posix.c:436
+#17 0x000000000085fc1e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:261
+        ctx = <optimized out>
+#18 0x00007f327f17d797 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
+#19 0x00000000008622ed in main_loop_wait () at util/main-loop.c:215
+        context = 0x2104900
+        pfds = <optimized out>
+        context = 0x2104900
+        ret = 1
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#20 0x00000000008622ed in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:238
+        context = 0x2104900
+        ret = 1
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#21 0x00000000008622ed in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#22 0x0000000000595dee in main_loop () at vl.c:1866
+#23 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 71
+        optarg = 0x7ffdfc94df69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7ffdfc94d864 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x0
+        userconfig = <optimized out>
+---Type <return> to continue, or q <return> to quit---
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdfc94c170}
+        __func__ = "main"
+
+Strace shows:
+ppoll([{fd=9, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8
+
+Which points to this:
+
+ls -al /proc/2286/fd/9
+lrwx------    1 root     users           64 Dec  5 13:04 /proc/2286/fd/9 -> anon_inode:[eventfd]
+
+The dest side is stuck here:
+
+(gdb) bt full
+#0  0x00007f21f070d3c1 in ppoll () at /lib64/libc.so.6
+#1  0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999926258) at util/qemu-timer.c:334
+        ts = {tv_sec = 2, tv_nsec = 999926258}
+Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.:
+#2  0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233
+        context = 0x2142900
+        ret = <optimized out>
+        ret = -1295041038
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#3  0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = -1295041038
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#4  0x0000000000595dee in main_loop () at vl.c:1866
+#5  0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 73
+        optarg = 0x7ffdd6ee8f69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7ffdd6ee8854 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x7ffdd6ee8f0a "defer"
+        userconfig = <optimized out>
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdd6ee6630}
+---Type <return> to continue, or q <return> to quit---
+        __func__ = "main"
+
+Strace show this over and over
+ppoll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=27, events=POLLIN}], 9, {0, 594527977}, NULL, 8) = 0 (Timeout)
+
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/10 -> anon_inode:[eventfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/21 -> socket:[42631161]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/22 -> socket:[42631165]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/23 -> socket:[42631167]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/24 -> socket:[42631168]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/27 -> socket:[42690422]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/6 -> anon_inode:[eventfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/7 -> anon_inode:[signalfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/9 -> anon_inode:[eventfd]
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1816819 b/results/classifier/gemma3:12b/socket/1816819
new file mode 100644
index 00000000..a39dde82
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1816819
@@ -0,0 +1,52 @@
+
+Chardev websocket stops listening after first connection disconnects
+
+Using qemu option:
+ -chardev socket,id=websock0,websocket,port=13042,host=127.0.0.1,server,nowait -serial chardev:websock0
+
+To have a websocket listening chardev. After the first connection disconnects (that does a full websocket handshake), subsequent connections aren't accepted. See below for a reproducing session kindly provided by Daniel:
+
+$ telnet localhost 13042
+Trying ::1...
+telnet: connect to address ::1: Connection refused
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+GET / HTTP/1.1
+Upgrade: websocket
+Connection: Upgrade
+Host: localhost:%s
+Origin: http://localhost
+Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw==
+Sec-WebSocket-Version: 13
+Sec-WebSocket-Protocol: binary
+
+HTTP/1.1 101 Switching Protocols
+Server: QEMU VNC
+Date: Wed, 20 Feb 2019 16:52:04 GMT
+Upgrade: websocket
+Connection: Upgrade
+Sec-WebSocket-Accept: b3DnPh7O8hyYE5sIjQxl/c1J+S8=
+Sec-WebSocket-Protocol: binary
+
+sfsd
+�&�only binary frames may be fragmentedConnection closed by foreign host.
+
+$ telnet localhost 13042
+Trying ::1...
+telnet: connect to address ::1: Connection refused
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+GET / HTTP/1.1
+Upgrade: websocket
+Connection: Upgrade
+Host: localhost:%s
+Origin: http://localhost
+Sec-WebSocket-Key: o9JHNiS3/0/0zYE1wa3yIw==
+Sec-WebSocket-Version: 13
+Sec-WebSocket-Protocol: binary
+
+
+
+...no response.....
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1823790 b/results/classifier/gemma3:12b/socket/1823790
new file mode 100644
index 00000000..6b3400d3
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1823790
@@ -0,0 +1,22 @@
+
+QEMU mishandling of SO_PEERSEC forces systemd into tight loop
+
+While building Debian images for embedded ARM target systems I detected that QEMU seems to force newer systemd daemons into a tight loop.
+
+My setup is the following:
+
+Host machine: Ubuntu 18.04, amd64
+LXD container: Debian Buster, arm64, systemd 241
+QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 1:3.1+dfsg-7)
+
+To easily reproduce the issue I have created the following repository:
+https://github.com/lueschem/edi-qemu
+
+The call where systemd gets looping is the following:
+2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 (Numerical result out of range)
+
+Furthermore I also verified that the issue is not related to LXD.
+The same behavior can be reproduced using systemd-nspawn.
+
+This issue reported against systemd seems to be related:
+https://github.com/systemd/systemd/issues/11557
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1829779 b/results/classifier/gemma3:12b/socket/1829779
new file mode 100644
index 00000000..2eb9024f
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1829779
@@ -0,0 +1,36 @@
+
+qemu-system-arm and qemu-system-aarch64 QMP hangs after kernel boots
+
+After booting a Linux kernel on both arm and aarch64, the QMP sockets gets unresponsive. Initially, this was thought to be limited to "quit" commands, but it reproduced with others (such as in this
+reproducer).  This is a partial log output:
+    
+   >>> {'execute': 'qmp_capabilities'}
+   <<< {'return': {}}
+   Booting Linux on physical CPU 0x0000000000 [0x410fd034]
+   Linux version 4.18.16-300.fc29.aarch64 (<email address hidden>) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:12:22 UTC 2018
+   ...
+   Policy zone: DMA32
+   Kernel command line: printk.time=0 console=ttyAMA0
+   >>> {'execute': 'stop'}
+   <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470173}, 'event': 'STOP'}
+   <<< {'return': {}}
+   >>> {'execute': 'cont'}
+   <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470849}, 'event': 'RESUME'}
+   <<< {'return': {}}
+   >>> {'execute': 'stop'}
+    
+Sometimes it takes just the first "stop" command.  Overall, I was able to reproduce 100% of times when applied on top of 6d8e75d41c58892ccc5d4ad61c4da476684c1c83.
+
+The reproducer test can be seen/fetched at:
+ - https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df
+
+And test results from Travis CI can be seen at:
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669
+
+For convenience purposes, here's qemu-system-aarch64 launching and hanging on the first "stop":
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3615
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3645
+
+And here's qemu-system-arm hanging the very same way:
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3780
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3800
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1837 b/results/classifier/gemma3:12b/socket/1837
new file mode 100644
index 00000000..72846ad8
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1837
@@ -0,0 +1,36 @@
+
+Support IP_MULTICAST_IF socket option in linux-user
+Additional information:
+I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet.
+
+Here's some source code that demonstrates the failure:
+```
+#include <sys/socket.h>
+#include <arpa/inet.h>
+#include <netinet/ip.h>
+#include <unistd.h>
+#include <assert.h>
+#include <stdio.h>
+
+int main()
+{
+    int fd, ret;
+    struct in_addr addr = {htonl(INADDR_LOOPBACK)};
+
+    fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
+    assert(fd >= 0);
+    ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
+    if (ret < 0)
+    {
+        perror("setsockopt failed");
+        return 1;
+    }
+    close(fd);
+    printf("Success!\n");
+    return 0;
+}
+```
+
+When run under qemu, it gives the error `setsockopt failed: Protocol not available`.
+
+It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch.
diff --git a/results/classifier/gemma3:12b/socket/1840252 b/results/classifier/gemma3:12b/socket/1840252
new file mode 100644
index 00000000..50b19dae
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1840252
@@ -0,0 +1,61 @@
+
+Infinite loop over  ERANGE from getsockopt
+
+Host system: Ubuntu 18.04.3 AMD64
+Qemu Version: qemu-arm-static --version
+qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.17)
+
+Emulated System: 
+Root file system taken from RaspberryPi 3 image
+ubuntu-18.04.3-preinstalled-server-armhf+raspi3.img
+from http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.3-preinstalled-server-armhf+raspi3.img.xz.
+
+Then using system-nspawn with with /usr/bin/qemu-arm-static copied in.
+
+When executing commands like 
+  dpkg -i (--force-all) <...>.deb
+or
+  tar tvf ..
+or
+  tar xvf ..
+the hosting qemu-arm-static process goes into an infinite loop of getsockopt calls of the form:
+getsockopt(12, SOL_SOCKET, SO_PEERSEC, 0x7fff7cac49d8, [4]) = -1 ERANGE (Numerical result out of range)
+I assume that this is because of an infinite retry without checking the actual error code of the call.
+
+strace:
+openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/librt.so.1", O_RDONLY|O_CLOEXEC) = 12
+read(12, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\20\30\0\0004\0\0\0"..., 512) = 512
+lseek(12, 21236, SEEK_SET)              = 21236
+read(12, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1240) = 1240
+lseek(12, 20856, SEEK_SET)              = 20856
+read(12, "A2\0\0\0aeabi\0\1(\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 51) = 51
+fstat(12, {st_mode=S_IFREG|0644, st_size=22476, ...}) = 0
+mmap(0x7f419952c000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_DENYWRIT
+E, -1, 0) = 0x7f419952c000
+mmap(0x7f419952c000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0) = 0x
+7f419952c000
+mprotect(0x7f4199531000, 61440, PROT_NONE) = 0
+mmap(0x7f4199540000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x4000)
+ = 0x7f4199540000
+close(12)                               = 0
+mprotect(0x7f4199540000, 4096, PROT_READ) = 0
+mprotect(0x7f4199578000, 8192, PROT_READ) = 0
+mmap(0x7f419957b000, 28672, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) 
+= 0x7f419957b000
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], NULL, 8) = 0
+rt_sigprocmask(SIG_SETMASK, [HUP USR1 USR2 PIPE ALRM CHLD TSTP URG VTALRM PROF WINCH IO], NULL, 8
+) = 0
+access("/etc/systemd/dont-synthesize-nobody", F_OK) = -1 ENOENT (No such file or directory)
+getpid()                                = 26
+socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 12
+getsockopt(12, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
+setsockopt(12, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
+setsockopt(12, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0
+getsockopt(12, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
+setsockopt(12, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
+setsockopt(12, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0
+connect(12, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 29) = 0
+getsockopt(12, SOL_SOCKET, SO_PEERCRED, {pid=0, uid=0, gid=0}, [12]) = 0
+getsockopt(12, SOL_SOCKET, SO_PEERSEC, 0x7fff7cac49d8, [4]) = -1 ERANGE (Numerical result out of 
+range)
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1843590 b/results/classifier/gemma3:12b/socket/1843590
new file mode 100644
index 00000000..c76393b6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1843590
@@ -0,0 +1,24 @@
+
+NBD tests  use hardcoded port 10810
+
+QEMU v3.1.0
+
+$ ./configure --block-drv-rw-whitelist=qcow2,raw,file,host_device,nbd,iscsi,rbd,blkdebug,luks,null-co,nvme,copy-on-read,throttle,vxhs,gluster [...]
+
+$ ./check -v -nbd 001 002 003 004 005 008 009 010 011 021 032 033 045 077 094 104 119 123 132 143 145 147 151 152 162 181 184 194 205 208 218 222
+[...]
+104         - output mismatch (see 104.out.bad)
+--- tests/qemu-iotests/104.out	2018-12-11 17:44:35.000000000 +0000
++++ tests/qemu-iotests/104.out.bad	2019-09-11 11:59:11.822058653 +0000
+@@ -6,7 +6,7 @@
+ file format: IMGFMT
+ virtual size: 1.0K (1024 bytes)
+ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1234
+-image: TEST_DIR/t.IMGFMT
+-file format: IMGFMT
+-virtual size: 1.5K (1536 bytes)
++Failed to find an available port: Address already in use
++qemu-img: Could not open 'nbd:127.0.0.1:10810': Failed to connect socket: Connection refused
++./common.rc: line 203: kill: (28391) - No such process
+ ***done
+Failed 1 of 32 tests
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1862619 b/results/classifier/gemma3:12b/socket/1862619
new file mode 100644
index 00000000..417e398b
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1862619
@@ -0,0 +1,15 @@
+
+"-serial telnet::xxxx,server" causes "Device 'serial0' is in use"
+
+I start qemu version 4.2.50 in a first terminal :
+
+$ sudo ./qemu-system-hppa -boot d -serial telnet::4441,server -drive if=scsi,bus=0,index=6,file=./hpux.img,format=raw -serial mon:stdio -D /tmp/foo -nographic -m 512 -d nochain -cdrom ./HPUX_9.05_Installation_Disc_S700.iso -D /tmp/foo -net nic,model=tulip  -net tap
+
+qemu-system-hppa: -serial telnet::4441,server: info: QEMU waiting for connection on: disconnected:telnet:0.0.0.0:4441,server
+
+In another terminal, I launch "telnet localhost 4441"
+
+And in the qemu window I have the following error:
+
+Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:220:
+qemu-system-hppa: Device 'serial0' is in use
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1867601 b/results/classifier/gemma3:12b/socket/1867601
new file mode 100644
index 00000000..af9527c1
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1867601
@@ -0,0 +1,16 @@
+
+test-char not concurrent with unix socket
+
+'make check-unit' might fail when running multiple tests in parallel.
+
+Apparently occurred on OSX CI:
+https://travis-ci.org/github/philmd/qemu/jobs/662357430
+
+Guess is same unix path used:
+
+static SocketAddress unixaddr = {
+    .type = SOCKET_ADDRESS_TYPE_UNIX,
+    .u.q_unix.path = (char *)"test-char.sock",
+};
+
+Note, other tests in this file use g_dir_make_tmp().
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1881 b/results/classifier/gemma3:12b/socket/1881
new file mode 100644
index 00000000..d32c1b07
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1881
@@ -0,0 +1,16 @@
+
+netdev-socket test_stream_unix() is unreliable
+Description of problem:
+test_stream_unix is unreliable and causes random CI job failures such as this one:
+https://gitlab.com/qemu-project/qemu/-/jobs/5020899550
+
+```
+576/839 ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n") ERROR         
+576/839 qemu:qtest+qtest-sh4 / qtest-sh4/netdev-socket                            ERROR          62.85s   killed by signal 6 SIGABRT
+>>> MALLOC_PERTURB_=249 QTEST_QEMU_BINARY=./qemu-system-sh4 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_IMG=./qemu-img /home/gitlab-runner/builds/-LCfcJ2T/0/qemu-project/qemu/build/tests/qtest/netdev-socket --tap -k
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+**
+ERROR:../tests/qtest/netdev-socket.c:293:test_stream_unix: assertion failed (resp == expect): ("st0: index=0,type=stream,connection error\r\n" == "st0: index=0,type=stream,unix:/tmp/netdev-socket.UW5IA2/stream_unix\r\n")
+(test program exited with status code -6)
+```
diff --git a/results/classifier/gemma3:12b/socket/1890395 b/results/classifier/gemma3:12b/socket/1890395
new file mode 100644
index 00000000..5cfd7449
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1890395
@@ -0,0 +1,137 @@
+
+qmp/hmp: crash if client closes socket too early
+
+Qemu crashes on qmp/hmp command if client closes connection before reading the whole response from the socket.
+
+Reproducer:
+
+1. Start arbitrary vm via qemu
+2. Send e.g. hmp command 'info mem'
+3. Abort before whole response came back
+
+
+Stack Trace:
+
+Stack trace of thread 6493:
+#0  0x0000559902fd2d30 object_get_class (qemu-system-x86_64)
+#1  0x0000559903071020 qio_channel_create_watch (qemu-system-x86_64)
+#2  0x000055990305f437 qemu_chr_fe_add_watch (qemu-system-x86_64)
+#3  0x0000559902f7340d monitor_flush_locked (qemu-system-x86_64)
+#4  0x0000559902f7360e monitor_flush_locked (qemu-system-x86_64)
+#5  0x0000559902f74342 qmp_send_response (qemu-system-x86_64)
+#6  0x0000559902f74409 monitor_qmp_respond (qemu-system-x86_64)
+#7  0x0000559902f74bc0 monitor_qmp_bh_dispatcher (qemu-system-x86_64)
+#8  0x00005599030c37be aio_bh_call (qemu-system-x86_64)
+#9  0x00005599030c6dd0 aio_dispatch (qemu-system-x86_64)
+#10 0x00005599030c369e aio_ctx_dispatch (qemu-system-x86_64)
+#11 0x00007f5b6d37f417 g_main_context_dispatch (libglib-2.0.so.0)
+#12 0x00005599030c5e0a glib_pollfds_poll (qemu-system-x86_64)
+#13 0x0000559902dd75df main_loop (qemu-system-x86_64)
+#14 0x0000559902c59f49 main (qemu-system-x86_64)
+#15 0x00007f5b6bfeab97 __libc_start_main (libc.so.6)
+#16 0x0000559902c5d38a _start (qemu-system-x86_64)
+
+#0  0x0000559902fd2d30 in object_get_class (obj=obj@entry=0x0) at ./qom/object.c:909
+#1  0x0000559903071020 in qio_channel_create_watch (ioc=0x0, condition=(G_IO_OUT | G_IO_HUP)) at ./io/channel.c:281
+        klass = <optimized out>
+        __func__ = "qio_channel_create_watch"
+        ret = <optimized out>
+#2  0x000055990305f437 in qemu_chr_fe_add_watch (be=be@entry=0x559905a7f460, cond=cond@entry=(G_IO_OUT | G_IO_HUP), func=func@entry=0x559902f734b0 <monitor_unblocked>, user_data=user_data@entry=0x559905a7f460) at ./chardev/char-fe.c:367
+        s = 0x5599055782c0
+        src = <optimized out>
+        tag = <optimized out>
+        __func__ = "qemu_chr_fe_add_watch"
+#3  0x0000559902f7340d in monitor_flush_locked (mon=mon@entry=0x559905a7f460) at ./monitor/monitor.c:140
+        rc = 219264
+        len = 3865832
+        buf = 0x7f5afc00e480 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"...
+#4  0x0000559902f7360e in monitor_flush_locked (mon=0x559905a7f460) at ./monitor/monitor.c:160
+        i = 3865830
+        c = <optimized out>
+#5  0x0000559902f7360e in monitor_puts (mon=mon@entry=0x559905a7f460, str=0x7f5aa1eda010 "{\"return\": \"ffff9eb480000000-ffff9eb480099000 ", '0' <repeats 11 times>, "99000 -rw\\r\\nffff9eb480099000-ffff9eb48009b000 ", '0' <repeats 12 times>, "2000 -r-\\r\\nffff9eb48009b000-ffff9eb486800000 0000000006765000 -rw\\r\\nffff9eb4868000"...) at ./monitor/monitor.c:167
+        i = 3865830
+        c = <optimized out>
+#6  0x0000559902f74342 in qmp_send_response (mon=0x559905a7f460, rsp=<optimized out>) at ./monitor/qmp.c:119
+        data = <optimized out>
+        json = 0x559906c88380
+#7  0x0000559902f74409 in monitor_qmp_respond (rsp=0x559905bbf740, mon=0x559905a7f460) at ./monitor/qmp.c:132
+        old_mon = <optimized out>
+        rsp = 0x559905bbf740
+        error = <optimized out>
+#8  0x0000559902f74409 in monitor_qmp_dispatch (mon=0x559905a7f460, req=<optimized out>) at ./monitor/qmp.c:161
+        old_mon = <optimized out>
+        rsp = 0x559905bbf740
+        error = <optimized out>
+#9  0x0000559902f74bc0 in monitor_qmp_bh_dispatcher (data=<optimized out>) at ./monitor/qmp.c:234
+        id = <optimized out>
+        rsp = <optimized out>
+        need_resume = true
+        mon = 0x559905a7f460
+        __PRETTY_FUNCTION__ = "monitor_qmp_bh_dispatcher"
+#10 0x00005599030c37be in aio_bh_call (bh=0x559905571b40) at ./util/async.c:89
+        bh = 0x559905571b40
+        bhp = <optimized out>
+        next = 0x5599055718f0
+        ret = 1
+        deleted = false
+#11 0x00005599030c37be in aio_bh_poll (ctx=ctx@entry=0x5599055706f0) at ./util/async.c:117
+        bh = 0x559905571b40
+        bhp = <optimized out>
+        next = 0x5599055718f0
+        ret = 1
+        deleted = false
+#12 0x00005599030c6dd0 in aio_dispatch (ctx=0x5599055706f0) at ./util/aio-posix.c:459
+#13 0x00005599030c369e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ./util/async.c:260
+        ctx = <optimized out>
+#14 0x00007f5b6d37f417 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
+#15 0x00005599030c5e0a in glib_pollfds_poll () at ./util/main-loop.c:219
+        context = 0x559905652420
+        pfds = <optimized out>
+        context = 0x559905652420
+        ret = 1
+        mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800}
+#16 0x00005599030c5e0a in os_host_main_loop_wait (timeout=14451267) at ./util/main-loop.c:242
+        context = 0x559905652420
+        ret = 1
+        mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800}
+#17 0x00005599030c5e0a in main_loop_wait (nonblocking=<optimized out>) at ./util/main-loop.c:518
+        mlpoll = {state = 0, timeout = 4294967295, pollfds = 0x559905651800}
+#18 0x0000559902dd75df in main_loop () at ./vl.c:1810
+#19 0x0000559902c59f49 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ./vl.c:4466
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x55990318bc94 "cad"
+        boot_once = <optimized out>
+        ds = <optimized out>
+        opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 100
+        optarg = 0x7ffe0ca05e74 "timestamp=on"
+        loadvm = 0x0
+        cpu_option = 0x7ffe0ca05d42 "SandyBridge-IBRS,-kvm_steal_time,+pcid,+ssbd,+spec-ctrl,+md-clear"
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        incoming = 0x0
+        userconfig = <optimized out>
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = 0x0
+        trace_file = <optimized out>
+        maxram_size = <optimized out>
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe0ca03540}
+        plugin_list = {tqh_first = 0x0, tqh_circ = {tql_next = 0x0, tql_prev = 0x7ffe0ca03550}}
+        __func__ = "main"
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1892684 b/results/classifier/gemma3:12b/socket/1892684
new file mode 100644
index 00000000..3fa72528
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1892684
@@ -0,0 +1,25 @@
+
+curl and wget segfaults when link has redirects
+
+Hello,
+
+I've been using qemu-user-static with aarch64 docker images and faced the problem
+using binares from the following release: https://github.com/multiarch/qemu-user-static/releases/tag/v5.0.0-2.
+
+curl and wget fails with segmentation fault when trying to fetch something from the link
+that has some redirects.
+
+In order to reproduce you can run the following:
+
+1) Register qemu on x86_64 machine
+   docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
+2) Run arm64v8 docker image and try to run wget or curl
+   docker run --rm -it arm64v8/ubuntu bash
+   $ apt update
+   $ apt install curl wget
+   $ curl -L http://erratique.ch/software/astring/releases/astring-0.8.3.tbz
+   $ wget  http://erratique.ch/software/astring/releases/astring-0.8.3.tbz
+
+This error cannot be reproduced with binaries from eariler release https://github.com/multiarch/qemu-user-static/releases/tag/v4.2.0-7.
+curl and wget work fine with the given link and don't fail with segfault when using
+older qemu-user-static binaries
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/1898084 b/results/classifier/gemma3:12b/socket/1898084
new file mode 100644
index 00000000..559b0d09
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/1898084
@@ -0,0 +1,24 @@
+
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
+
+I have a virtual raspberry py that I am running qemu 5.1.0 for MacOS.
+
+Here is the command line I used:
+
+qemu-system-arm \
+  -M versatilepb \
+  -cpu arm1176 \
+  -m 256 \
+  -drive file=2020-08-20-raspios-buster-armhf-lite.img,if=none,index=0,media=disk,format=raw,id=disk0 \
+  -device virtio-blk-pci,drive=disk0,disable-modern=on,disable-legacy=off \
+  -net nic -net user,hostfwd=tcp::5022-:22 \
+  -dtb versatile-pb-buster-5.4.51.dtb \
+  -kernel kernel-qemu-5.4.51-buster \
+  -append "root=/dev/vda2 panic=1" \
+  -no-reboot \
+  -serial stdio
+
+When trying to ssh from another machine while docker was running inside the VM, I got the following error:
+
+Assertion failed: (buf_len != 0), function soread, file /private/tmp/qemu-20200813-13289-1g95loa/qemu-5.1.0/slirp/src/socket.c, line 183
+../boot.sh: line 12:  8592 Abort trap: 6
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/2065579 b/results/classifier/gemma3:12b/socket/2065579
new file mode 100644
index 00000000..b86b29a7
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2065579
@@ -0,0 +1,77 @@
+
+[UBUNTU 22.04] OS guest boot issues on 9p filesystem
+
+=== Reported by <email address hidden> - 2024-05-13 03:53:01 ===
+
+---Problem Description---
+OS guest boot issues on 9p filesystem due to unix domain sockets open failure
+ 
+Contact Information = <email address hidden> 
+ 
+Machine Type = 3931-7G4 
+ 
+---uname output---
+5.15.0-92-generic #102-Ubuntu SMP Wed Jan 10 09:35:24 UTC 2024 s390x s390x s390x GNU/Linux
+ 
+---Steps to Reproduce---
+ #!/bin/bash
+
+# Cleanup target dir
+[ -d ./target ] && rm -rf target
+mkdir target
+
+# Add configuration updates
+mkdir -p ./target/etc/initramfs-tools/
+echo 9p >> ./target/etc/initramfs-tools/modules
+echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules
+
+# Add the test script
+cat > ./target/test_init << EOF
+#!/bin/bash
+
+echo "Test for unix domain sockets"
+
+nc -Ul /socket &
+sleep 1
+echo "Sockets work" | nc -UN /socket || echo "Sockets fail"
+
+echo o > /proc/sysrq-trigger
+sleep 999
+EOF
+chmod 700 ./target/test_init
+
+# Create an Ubuntu 23.10 around it
+echo "Creating Ubuntu target OS"
+debootstrap --variant=minbase\
+            --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \
+            --exclude=man,bash-completion \
+            mantic ./target > /dev/null || exit 1
+
+# Run the test in 9p forwarded filesystem
+echo "Running OS in qemu"
+qemu-system-s390x \
+  -m 8192 \
+  -smp 4 \
+  -nodefaults -nographic -no-reboot -no-user-config \
+  -kernel ./target/boot/vmlinuz \
+  -initrd ./target/boot/initrd.img \
+  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \
+  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \
+  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
+  -device virtio-serial-ccw -device sclpconsole,chardev=console \
+  -chardev stdio,id=console,signal=off 
+
+ 
+---Debugger---
+A debugger is not configured
+
+Userspace rpm: qemu-(current).deb 
+ 
+Userspace tool common name: qemu 
+
+Userspace tool obtained from project website:  na 
+ 
+The userspace tool has the following bit modes: both 
+ 
+*Additional Instructions for <email address hidden>:
+-Attach ltrace and strace of userspace application.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/2197 b/results/classifier/gemma3:12b/socket/2197
new file mode 100644
index 00000000..d37eb06a
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2197
@@ -0,0 +1,59 @@
+
+qemu user space emulator handles syscall `setsockopt()` with `optlen=0` incorrectly
+Description of problem:
+Note that despite I have only tested with the parameters/environments above, this problem probably **affects ALL architectures on Linux**.
+
+When user program calls `setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0)`, qemu intercepts the syscall and returns `-1` with `errno = ENOMEM`, which should have completed successfully returning zero.
+Steps to reproduce:
+1. compile this code to binary executable:
+```c
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <linux/if_alg.h>
+
+int create_alg(const char *alg)
+{
+        struct sockaddr_alg salg;
+        int sk;
+
+        sk = socket(PF_ALG, SOCK_SEQPACKET | SOCK_CLOEXEC, 0);
+        if (sk < 0)
+                return -1;
+
+        memset(&salg, 0, sizeof(salg));
+        salg.salg_family = AF_ALG;
+        strcpy((char *) salg.salg_type, "hash");
+        strcpy((char *) salg.salg_name, alg);
+
+        if (bind(sk, (struct sockaddr *) &salg, sizeof(salg)) < 0) {
+                close(sk);
+                return -1;
+        }
+
+        return sk;
+}
+
+int main() {
+        int fd = create_alg("hmac(sha1)");
+        char buf[10];
+        int ret = setsockopt(fd, SOL_ALG, ALG_SET_KEY, NULL, 0);
+        if(ret < 0){
+                perror("err");
+        }
+        else{
+                puts("SUCCESS!");
+        }
+        return 0;
+}
+```
+2. run it in any qemu user space emulator
+
+On real Linux kernel, this program outputs a `SUCCESS!` while in qemu it prints `err: Cannot allocate memory`.
+
+The error is neither informative nor intuitive and could be misleading for user programs.
+Additional information:
+I already have a patch which fixes the issue and I'm willing to send it to mailing list as soon as I have done the testing.
diff --git a/results/classifier/gemma3:12b/socket/2230 b/results/classifier/gemma3:12b/socket/2230
new file mode 100644
index 00000000..f6c83e48
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2230
@@ -0,0 +1,142 @@
+
+Problems running x86_64 programs on loongarch64 platform
+Description of problem:
+There is also a running service program on the platform, and **gate_svr** program needs to communicate with it. The following problem occurs:
+```
+ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+Bail out! ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+```
+The following is the log：
+```
+[root@localhost bin]# ./gate_svr -y 0 -g 1 -p 18700 -i 127.0.0.1 -l 127.0.0.1,18082
+V4.3.20.1-build-20240126.210622
+NdsGate : start
+yan_lis:0
+unix_domain_name=/tmp/test_1.ss
+conf dir: /root/sql_proxy/gate/conf
+
+
+indicate port:18700
+indicate ipv6_support:0
+indicate link-ctl:127.0.0.1,18082
+
+directory:/root/operating/oci_test/bin
+processname:gate_svr
+model_path_in:/root/operating/oci_test/conf/in model_path_out:/root/operating/oci_test/conf/out
+tr: 写入错误: 断开的管道
+tr: 写入错误
+
+----------------------------------------------------------------------
+
+Create SGA, shmid = 53608511
+----------------------------------------------------------------------
+
+Attach SGA, shmid = 53608511, sga_address = 0xffb5700000
+----------------------------------------------------------------------
+
+Init SGA, shmid = 53608511, sga_address = 0xffb5700000,ret = 0
+----------------------------------------------------------------------
+tr: 写入错误: 断开的管道
+tr: 写入错误
+fc_shmid:50003996 
+tr: 写入错误: 断开的管道
+tr: 写入错误
+ai_shmid:50036765 
+/tmp/alarm_report_log is exist, no need create
+NdsGate : start thread->>anhua_lock_detecter sucess! shmid_t=53608511 loop_time=3
+new NCSocket sk_:6
+-------------Detect Mutex-----------
+mypid = 20953
+ControllerClient::startConnect ip:127.0.0.1, port:18082
+connect success, socket:6
+NdsGate : connect to controller ok, send handshake packet ...sk:6 
+check cen_time_enable 0 0
+NdsGate : handshake ok, gate id is 1
+get_node_name->gid=1,node_name=configuration_1
+shm get ok, config_store len: 9924
+
+
+start config init...
+
+----------------------------------------------------------------------
+Ƥ׃½㏶א...
+
+~~~~~~~~~~~~~~~~~~~~~~log1
+~~~~~~~~~~~~~~~~~~~~~~log2
+~~~~~~~~~~~~~~~~~~~~~~log3
+~~~~~~~~~~~~~~~~~~~~~~log4
+~~~~~~~~~~~~~~~~~~~~~~log5
+~~~~~~~~~~~~~~~~~~~~~~log6
+~~~~~~~~~~~~~~~~~~~~~~log7
+~~~~~~~~~~~~~~~~~~~~~~log8
+Ƥ׃½㏶ºŊ±: 0.000000(s)
+
+
+----------------------------------------------------------------------
+
+
+log file name->./nds.log_0
+g_ai_check=0
+nds_config_rule_database_creatºŊ±: 0.000000(s)
+nds_config_app_rule_database_creatºŊ±: 0.000000(s)
+nds_config_real_database_creatºŊ±: 0.000000(s)
+nds_config_virtual_database_creatºŊ±: 0.000000(s)
+nds_config_app_creatºŊ±: 0.000000(s)
+nds_config_app_server_createºŊ±: 0.000000(s)
+
+
+app-vdb-ip config list:
+
+
+inner_list=1
+default_list=2
+
+----------------------------------------------------------------------
+
+Start attach, shmid = 53608511
+----------------------------------------------------------------------
+
+Attach SGA, shmid = 53608511, sga_address = 0xff65000000
+----------------------------------------------------------------------
+1
+
+Load rules, shmid = 53608511, sga_address = 0xff65000000,ret = -1
+2----------------------------------------------------------------------
+
+SqlEngine_AppRulesMap ret=0
+
+----------------------------------------------------------------------
+gate disconnect from ctl ok
+
+ctl config trans_mode=1
+getReadBufferLength bev is null !! sock:-646169440
+
+gate_net_name:bond1
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress_excluded' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress_excluded'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress_excluded' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress_excluded'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+grep: /etc/keepalived/keepalived.conf: 没有那个文件或目录
+
+get_bond_ip->cmd=grep -w -A 2 'virtual_ipaddress' /etc/keepalived/keepalived.conf|grep bond1|grep -v 'virtual_ipaddress'|awk '{print $1}'
+
+listen_ip(ipv4):0.0.0.0
+
+gate_epoll_start...
+**
+ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+Bail out! ERROR:../plugins/core.c:220:qemu_plugin_vcpu_init_hook: assertion failed: (success)
+```
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/socket/2254 b/results/classifier/gemma3:12b/socket/2254
new file mode 100644
index 00000000..8d7d9188
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2254
@@ -0,0 +1,2 @@
+
+UNCHECKED_FUNC_RES.LIB.STRICT in /io/channel-socket.c
diff --git a/results/classifier/gemma3:12b/socket/2292 b/results/classifier/gemma3:12b/socket/2292
new file mode 100644
index 00000000..2cbd890b
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2292
@@ -0,0 +1,20 @@
+
+UNIX socket path is too long
+Description of problem:
+At [Unikraft](https://unikraft.org) we facilitate the construction and also runtime lifecycle management of ultra-lightweight virtual machine unikernels.  We have developed [`kraft`](https://github.com/unikraft/kraftkit), an open-source tool which facilitates this across a number of different virtual machine monitors, [including QEMU](https://github.com/unikraft/kraftkit/tree/staging/machine/qemu).
+
+We are receiving increased reports of the following error from our users:
+
+```
+could not start and wait for QEMU process: qemu-system-x86_64: -qmp unix:/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock,server,nowait: UNIX socket path '/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock' is too long
+```
+
+We systematically build the relevant QEMU process command line and arguments with flags [via our Go SDK](https://github.com/unikraft/kraftkit/blob/staging/machine/qemu/v1alpha1.go#L180-L229) and include what has become an erroneously long UNIX path for the QAPI control socket which we use to manage instantiated VM instances.
+
+This issue tracks the increasing of maximum path length for the `-qmp` (and maybe other) flags which accept paths.
+Steps to reproduce:
+1. Install [`kraft`](https://github.com/unikraft/kraftkit), [Unikraft](https://unikraft.org)'s companion command-line client;
+2. Update KraftKit's config file to include an arbitrarily long path for `runtime_dir` by editing `~/.config/kraftkit/config.yaml`;
+3. Start a QEMU unikernel instance with `kraft run --arch x86_64 --plat qemu unikraft.org/helloworld:latest`
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/socket/2337 b/results/classifier/gemma3:12b/socket/2337
new file mode 100644
index 00000000..2ed2073d
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2337
@@ -0,0 +1,63 @@
+
+Os boot issues on 9p filesystem due to unix domain sockets open failure
+Description of problem:
+Unix filesystem API is broken, unix domain socket special files return an error at open()
+Steps to reproduce:
+Simple script. Tries to use netcat to get data through a local unix domain socket file   
+```
+#!/bin/bash
+
+# Cleanup target dir
+[ -d ./target ] && rm -rf target
+mkdir target
+
+# Add configuration updates
+mkdir -p ./target/etc/initramfs-tools/
+echo 9p >> ./target/etc/initramfs-tools/modules
+echo 9pnet_virtio >> ./target/etc/initramfs-tools/modules
+
+# Add the test script
+cat > ./target/test_init << EOF
+#!/bin/bash
+
+echo "Test for unix domain sockets"
+
+nc -Ul /socket &
+sleep 1
+echo "Sockets work" | nc -UN /socket || echo "Sockets fail"
+
+echo o > /proc/sysrq-trigger
+sleep 999
+EOF
+chmod 700 ./target/test_init
+
+# Create an Ubuntu 23.10 around it
+echo "Creating Ubuntu target OS"
+debootstrap --variant=minbase\
+            --include=udev,kmod,initramfs-tools,systemd,netcat-openbsd,linux-image-generic \
+            --exclude=man,bash-completion \
+            mantic ./target > /dev/null || exit 1
+
+# Run the test in 9p forwarded filesystem
+echo "Running OS in qemu"
+qemu-system-s390x \
+  -m 8192 \
+  -smp 4 \
+  -nodefaults -nographic -no-reboot -no-user-config \
+  -kernel ./target/boot/vmlinuz \
+  -initrd ./target/boot/initrd.img \
+  -append 'root=fsRoot rw rootfstype=9p rootflags=trans=virtio,version=9p2000.L,msize=512000,cache=mmap,posixacl console=ttysclp0 init=/test_init quiet' \
+  -fsdev local,security_model=passthrough,multidevs=remap,id=fsdev-fsRoot,path=./target \
+  -device virtio-9p-pci,id=fsRoot,fsdev=fsdev-fsRoot,mount_tag=fsRoot \
+  -device virtio-serial-ccw -device sclpconsole,chardev=console \
+  -chardev stdio,id=console,signal=off 
+```
+Additional information:
+Test output:
+```
+Test for unix domain sockets
+qemu-system-s390x: 9p: broken or compromised client detected; attempt to open special file (i.e. neither regular file, nor directory)
+nc: No such device or address
+nc: /socket: No such file or directory
+Sockets fail
+```
diff --git a/results/classifier/gemma3:12b/socket/2346 b/results/classifier/gemma3:12b/socket/2346
new file mode 100644
index 00000000..f615a4e6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2346
@@ -0,0 +1,73 @@
+
+Undefined behavior error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type
+Description of problem:
+When compiling QEMU with --extra-cflags=-fsanitize=undefined and --extra-cflags=-fno-sanitize-recover=undefined on a system that has Clang v17 or newer (e.g. on Fedora 39 or Fedora 40), the unit tests abort with an undefined behavior error.
+Steps to reproduce:
+1. ``./configure --cc=clang --extra-cflags=-fsanitize=undefined --extra-cflags=-fno-sanitize-recover=undefined --target-list=x86_64-softmmu``
+2. ``make -j$(nproc)``
+3. ``make check-unit``
+Additional information:
+test-io-channel-socket aborts with:
+
+```
+ 74/103 qemu:unit / test-io-channel-socket               ERROR            0.15s   killed by signal 6 SIGABRT
+>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=163 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-io-channel-socket --tap -k
+―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+qapi/qapi-clone-visitor.c:188:5: runtime error: call to function visit_type_SocketAddress through pointer to incorrect function type 'bool (*)(struct Visitor *, const char *, void **, struct Error **)'
+/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:487: note: visit_type_SocketAddress defined here
+    #0 0x5642aa2f7f3b in qapi_clone qapi/qapi-clone-visitor.c:188:5
+    #1 0x5642aa2c8ce5 in qio_channel_socket_listen_async io/channel-socket.c:285:18
+    #2 0x5642aa2b8903 in test_io_channel_setup_async tests/unit/test-io-channel-socket.c:116:5
+    #3 0x5642aa2b8204 in test_io_channel tests/unit/test-io-channel-socket.c:179:9
+    #4 0x5642aa2b8129 in test_io_channel_ipv4 tests/unit/test-io-channel-socket.c:323:5
+    #5 0x7f01212c0bbf  (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #6 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #7 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #8 0x7f01212c0b2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #9 0x7f01212c10c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #10 0x7f01212c115f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #11 0x5642aa2b72ec in main tests/unit/test-io-channel-socket.c:613:12
+    #12 0x7f0120d2d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #13 0x7f0120d2d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #14 0x5642aa28cd04 in _start (tests/unit/test-io-channel-socket+0x69d04) (BuildId: eeaee2b8d62ce3aa77ab8b447916a40defd78dc6)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior qapi/qapi-clone-visitor.c:188:5 
+
+(test program exited with status code -6)
+```
+
+And ``test-char`` aborts with:
+
+```
+ 99/103 qemu:unit / test-char                            ERROR            0.12s   killed by signal 6 SIGABRT
+>>> G_TEST_BUILDDIR=/tmp/qemu-ubsan/tests/unit ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=197 G_TEST_SRCDIR=tests/unit /tmp/qemu-ubsan/tests/unit/test-char --tap -k
+―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― ✀  ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
+stderr:
+qapi/qapi-clone-visitor.c:202:5: runtime error: call to function visit_type_InetSocketAddress_members through pointer to incorrect function type 'bool (*)(struct Visitor *, void *, struct Error **)'
+/tmp/qemu-ubsan/qapi/qapi-visit-sockets.c:65: note: visit_type_InetSocketAddress_members defined here
+    #0 0x55ee1d20ad60 in qapi_clone_members qapi/qapi-clone-visitor.c:202:5
+    #1 0x55ee1d24a993 in socket_address_flattenutil/qemu-sockets.c
+    #2 0x55ee1d1f26f6 in qmp_chardev_open_udp chardev/char-udp.c:199:34
+    #3 0x55ee1d1f5254 in qemu_char_open chardev/char.c:271:9
+    #4 0x55ee1d1f5254 in chardev_new chardev/char.c:968:5
+    #5 0x55ee1d1f45fd in qemu_chardev_new chardev/char.c:998:11
+    #6 0x55ee1d1f45fd in qemu_chr_new_from_opts chardev/char.c:657:11
+    #7 0x55ee1d1f49ac in qemu_chr_new_noreplay chardev/char.c:703:11
+    #8 0x55ee1d1f4aed in qemu_chr_new_permit_mux_mon chardev/char.c:731:11
+    #9 0x55ee1d1b45b8 in char_udp_test_internal tests/unit/test-char.c:590:15
+    #10 0x7f3dd421abbf  (/lib64/libglib-2.0.so.0+0x8bbbf) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #11 0x7f3dd421ab2f  (/lib64/libglib-2.0.so.0+0x8bb2f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #12 0x7f3dd421b0c9 in g_test_run_suite (/lib64/libglib-2.0.so.0+0x8c0c9) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #13 0x7f3dd421b15f in g_test_run (/lib64/libglib-2.0.so.0+0x8c15f) (BuildId: 795136df3faa85587229ddc59d709f81d6f697df)
+    #14 0x55ee1d1af6bd in main tests/unit/test-char.c:1579:12
+    #15 0x7f3dd3c3d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #16 0x7f3dd3c3d14a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2a14a) (BuildId: b098f1c75a76548bb230d8f551eae07a2aeccf06)
+    #17 0x55ee1d184e34 in _start (/tmp/qemu-ubsan/tests/unit/test-char+0x78e34) (BuildId: afdf2ec9875e3011d3ff99174ec137dc79fff74e)
+
+SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior .qapi/qapi-clone-visitor.c:202:5 
+
+(test program exited with status code -6)
+```
+
+This undefined behavior could likely also trigger issues with CFI or certain compilers/architectures like emscripten, so we should try to avoid this. See also https://github.com/systemd/systemd/issues/29972 or https://github.com/python/cpython/issues/111178 for discussions in other projects, and https://gitlab.com/qemu-project/qemu/-/issues/2345 for a similar problem in the QEMU lockable code.
diff --git a/results/classifier/gemma3:12b/socket/2390 b/results/classifier/gemma3:12b/socket/2390
new file mode 100644
index 00000000..30b064d3
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2390
@@ -0,0 +1,64 @@
+
+linux-user: Qemu handles `getsockopt` with NULL `optval` incorrectly
+Description of problem:
+In short call to `getsockopt(_, SOL_TCP, TCP_KEEPIDLE, NULL, _)` behaves differently on RISC-V Qemu than on x64 Linux. 
+On Linux syscall returns 0, but on Qemu it fails with `"Bad address"`.
+Apparently Qemu `getsockopt` implementation is more conservative about NULL `optval` argument than kernel implementation. However man permits passing NULL [link](https://man7.org/linux/man-pages/man2/setsockopt.2.html):
+
+>  For getsockopt(), optlen is a value-result argument, initially
+       containing the size of the buffer pointed to by optval, and
+       modified on return to indicate the actual size of the value
+       returned.  **If no option value is to be supplied** or returned,
+       **optval may be NULL.**"
+
+For me it sounds like accepting NULL without error (and x64 confirms that interpretation).
+Steps to reproduce:
+1. Use below toy program `getsockopt.c` and compile it without optimizations like:
+```
+    gcc -Wall -W -std=gnu11 -pedantic  getsockopt.c -o getsockopt
+```
+
+```
+#include <stdlib.h>
+#include <unistd.h>
+#include <errno.h>
+#include <stdio.h>
+#include <netinet/in.h>
+#include <sys/socket.h>
+#include <netinet/tcp.h>
+
+static void fail_on_error(int error, const char *msg) {
+    if (error < 0) {
+        perror(msg);
+        exit(errno);
+    }
+}
+
+int main(int argc, char **argv) {
+     int socketfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP);
+     fail_on_error(socketfd, "socket error");
+     uint8_t *option_value = NULL;
+     int32_t len = 0;
+     int32_t *option_len = &len;
+     socklen_t opt_len = (socklen_t)*option_len;
+     int status = getsockopt(socketfd, SOL_TCP, TCP_KEEPIDLE, option_value, &opt_len);
+     fail_on_error(status, "getsockopt error");
+     return 0;
+}
+```
+
+
+2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
+```
+root@57646f544f3a:/runtime/programs# ./getsockopt-x64
+root@57646f544f3a:/runtime/programs# ./getsockopt-riscv
+getsockopt error: Bad address
+```
+Additional information:
+I don't think issue is platform specific assuming Qemu `getsockopt` implementation that is actually running is here:
+[link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2522)
+
+Looking at sources, I'm not sure why Qemu can't simply forward everything to kernel space 
+instead doing extra sanity checks together with `optval` dereference attempt that eventually fails in one of `put_user*_` function: [link](https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2753) 
+
+Anyway, I think that interpretation of man quote is rather straightforward and Qemu `getsockopt` implementation should follow it.
diff --git a/results/classifier/gemma3:12b/socket/2410 b/results/classifier/gemma3:12b/socket/2410
new file mode 100644
index 00000000..1f0b7864
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2410
@@ -0,0 +1,93 @@
+
+linux-user: `Setsockopt` with IP_OPTIONS returns "Protocol not available" error
+Description of problem:
+It seems that call to `setsockopt(sd, SOL_IP, IP_OPTIONS,_)` behaves differently on RISC-V Qemu than on x64 Linux. 
+On Linux syscall returns 0, but on Qemu it fails with `Protocol not available`.
+According [man](https://man7.org/linux/man-pages/man7/ip.7.html) `IP_OPTIONS` on `SOCK_STREAM` socket "should work".
+Steps to reproduce:
+1. Use below toy program `setsockopt.c` and compile it without optimizations like:
+```
+    gcc -Wall -W -Wextra -std=gnu17 -pedantic setsockopt.c -o setsockopt
+```
+
+```
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <arpa/inet.h>
+#include <netinet/in.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+int main() {
+    {
+        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+        if(sd < 0) {
+            perror("Opening stream socket error");
+            exit(1);
+        }
+        else
+            printf("Opening stream socket....OK.\n");
+
+        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
+        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
+
+        if (err < 0) {
+            perror("Connect error");
+            close(sd);
+        }
+        else
+            printf("Connect...OK.\n");
+    }
+    {
+        int sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+        if(sd < 0) {
+            perror("Opening stream socket error");
+            exit(1);
+        }
+        else
+            printf("Opening stream socket....OK.\n");
+
+        char option[4] = {0};
+        if(setsockopt(sd, SOL_IP, IP_OPTIONS, (char *)option, sizeof(option)) < 0) {
+            perror("setsockopt error");
+            close(sd);
+            exit(1);
+        }
+        else
+            printf("setsockopt...OK.\n");
+
+        struct sockaddr_in local_address = {AF_INET, htons(1234), {inet_addr("255.255.255.255")}, {0}};
+        int err = connect(sd, (struct sockaddr*)&local_address, (socklen_t)16);
+
+        if (err < 0) {
+            perror("Connect error");
+            close(sd);
+        }
+        else
+            printf("Connect...OK.\n");
+    }
+    return 0;
+}
+```
+
+
+2. Run program on Qemu and compare output with output from x64 build. In my case it looks like:
+```
+root@AMDC4705:~/runtime/connect$ ./setsockopt-x64
+Opening stream socket....OK.
+Connect error: Network is unreachable
+Opening stream socket....OK.
+setsockopt...OK.
+Connect error: Network is unreachable
+
+root@AMDC4705:/runtime/connect# ./setsockopt-riscv
+Opening stream socket....OK.
+Connect error: Network is unreachable
+Opening stream socket....OK.
+setsockopt error: Protocol not available
+```
+Additional information:
+In above demo option `value` is quite artificial. However I tried passing many different `option` arguments (with same `SOL_IP` + `IP_OPTIONS` combination) but always ended up with `setsockopt` failure. 
+From the other hand on x64 it worked fine. Then I realized that appropriate path in Qemu was unimplemented: https://github.com/qemu/qemu/blob/master/linux-user/syscall.c#L2141
diff --git a/results/classifier/gemma3:12b/socket/2592 b/results/classifier/gemma3:12b/socket/2592
new file mode 100644
index 00000000..ed59686e
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2592
@@ -0,0 +1,38 @@
+
+qemu-aarch64 cannot properly support some python functions from the `time` module
+Description of problem:
+When a function is run in python (for example, `time.time()`), python returns the following error:
+```
+Traceback (most recent call last):
+  File "<string>", line 1, in <module>
+OSError: [Errno 0] Error
+```
+I am absolutely sure that this problem is related to `qemu-aarch64`, because the same python build works perfectly in aarch64 machine. In addition, python for arm architecture with `qemu-arm` does not have such a problem.
+Steps to reproduce:
+Note, this instruction specifies the stage of installation of that very python. But since it is compiled for Termux, you will have to use some scripts.
+1. Create a simple codespace environment.
+2. Run the following commands through the terminal:
+```
+git clone https://github.com/termux-pacman/glibc-packages
+cd glibc-packages
+./get-build-package.sh
+sudo mkdir /data
+sudo chown codespace /data
+sudo chgrp codespace /data
+sudo apt update
+sudo apt install patchelf
+./scripts/setup-cgct.sh
+```
+3. Run the following command. Note that the installation phase will start there. You should stop the script when the installation phase is complete.
+```
+./build-package.sh -I -w --library glibc gpkg/gobject-introspection
+```
+4. Install standard qemu via apt.
+5. Run the following command:
+```
+qemu-aarch64 /data/data/com.termux/files/usr/glibc/bin/python3.12 -c "import time; time.time()"
+```
+Additional information:
+- For some reason this error only occurs in the environment from GitHub. On my computer this error does not occur.
+ - Here is a log of one of the github actions, which shows an attempt to compile packages with python on different architectures - https://github.com/termux-pacman/glibc-packages/actions/runs/11023254502.  
+For reference, I use qemu for more flexible compilation of packages. And in github actions, qemu is installed here - https://github.com/termux-pacman/glibc-packages/blob/main/.github/workflows/build.yml#L35.
diff --git a/results/classifier/gemma3:12b/socket/2720 b/results/classifier/gemma3:12b/socket/2720
new file mode 100644
index 00000000..49d1d7d9
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2720
@@ -0,0 +1,71 @@
+
+migration failure from qemu 7.1.0 to qemu 9.2.0+ with multifd capability enabled
+Description of problem:
+Enabling multifd when doing migration from qemu 7.1.0 to 9.2.0+ causes the migration to fail.
+The migration status reported is:
+
+```
+Migration status: failed (Unable to write to socket: Broken pipe)
+```
+
+I could reproduce on qemu 9.2.0 and from a build from master. The migration is successful if I don't enable multifd.
+
+I could not reproduce this issue migrating from 7.1.0 to 9.1.2.
+Steps to reproduce:
+Minimal setup to reproduce below, running both qemu instances on the same host.
+
+1. Start qemu instance receiving the migration:
+
+```
+$ qemu-system-x86_64 -version
+QEMU emulator version 9.2.50 (v9.2.0-28-ga5ba0a7e4e)
+
+$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -incoming defer -net none -trace 'migration*'
+[...]
+(qemu) migrate_set_capability multifd on
+(qemu) migrate_set_parameter multifd-channels 4
+(qemu) migrate_incoming tcp:0:12345
+[...]
+(qemu) migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x5619735b1800 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972dff670 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972dad800 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972c9d670 ioctype=qio-channel-socket
+migration_socket_incoming_accepted
+migration_set_incoming_channel ioc=0x561972c7b270 ioctype=qio-channel-socket
+
+```
+
+2. Start the qemu instance that will be used to initiate the migration with multifd enabled, and initiate the migration
+
+```
+$ qemu-system-x86_64 -version
+QEMU emulator version 7.1.0 (v7.1.0)
+
+$ qemu-system-x86_64 -M pc-q35-7.1 -m 16G -nographic -net none -trace 'migration*'
+[...]
+(qemu) migrate_set_capability multifd on
+(qemu) migrate_set_parameter multifd-channels 4
+(qemu) migrate -d tcp:0:12345
+(qemu) migration_socket_outgoing_connected hostname=0
+migration_set_outgoing_channel ioc=0x558ea2051400 ioctype=qio-channel-socket hostname=0 err=(nil)
+migration_bitmap_sync_start
+migration_bitmap_sync_end dirty_pages 0
+migration_thread_setup_complete
+migration_bitmap_clear_dirty rb pc.ram start 0x0 size 0x40000000 page 0x0
+migration_thread_after_loop
+qemu-system-x86_64: Unable to write to socket: Broken pipe
+(qemu) info migrate
+globals:
+store-global-state: on
+only-migratable: off
+send-configuration: on
+send-section-footer: on
+decompress-error-check: on
+clear-bitmap-shift: 18
+Migration status: failed (Unable to write to socket: Broken pipe)
+total time: 0 ms
+```
diff --git a/results/classifier/gemma3:12b/socket/284 b/results/classifier/gemma3:12b/socket/284
new file mode 100644
index 00000000..46d584f6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/284
@@ -0,0 +1,2 @@
+
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
diff --git a/results/classifier/gemma3:12b/socket/2925 b/results/classifier/gemma3:12b/socket/2925
new file mode 100644
index 00000000..2a2897cb
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/2925
@@ -0,0 +1,26 @@
+
+Cannot exec certain QMP guest commands using unix socket but Virsh can
+Description of problem:
+There are two channels configured to communicate the guest. 
+ - a) qemu.guest_agent.0
+ - b) unix socket: -qmp unix:/tmp/qmp_win7-101.sock,server,nowait
+
+
+**For unix socket connection, certain commands like ```guest-info``` and other guest functions are missing.** However, invoking guest-xx functions successfully in Virsh (through qemu.guest_agent.0).
+Steps to reproduce:
+```
+$sudo socat unix-connect:/tmp/qmp_win7-101.sock readline
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 4}, "package": "qemu-kvm-4.2.0-59.module_el8.5.0+1063+c9b9feff.1"}, "capabilities": ["oob"]}}
+
+{"execute":"qmp_capabilities"}
+{"return": {}}
+
+{"execute": "guest-info"}
+{"error": {"class": "CommandNotFound", "desc": "The command guest-info has not been found"}}
+```
+
+I checked ```/etc/sysconfig/qemu-ga``` and unmarked blacklist functions, but it did not solve this problem.
+```
+# original contents of qemu-ga
+#BLACKLIST_RPC=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status
+```
diff --git a/results/classifier/gemma3:12b/socket/347 b/results/classifier/gemma3:12b/socket/347
new file mode 100644
index 00000000..d9477d86
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/347
@@ -0,0 +1,2 @@
+
+Forward host UNIX socket to guest TCP port
diff --git a/results/classifier/gemma3:12b/socket/602 b/results/classifier/gemma3:12b/socket/602
new file mode 100644
index 00000000..a826183c
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/602
@@ -0,0 +1,14 @@
+
+Failure to translate host to target errno in IP_RECVERR, IPV6_RECVERR emulation
+Description of problem:
+In translated IP_RECVERR (and IPV6_RECVERR) control messages, the `ee_errno` is not translated, so host errnos are observed on guests.  E.g., `ECONNREFUSED` is 111 on x86_64 host, but expected to be 146 in MIPS ABI.
+Steps to reproduce:
+1. https://cirrus-ci.com/task/5914289870471168
+Additional information:
+The bugs are on [lines 1970 and 2014 here](https://github.com/qemu/qemu/blob/211364c21e7f757ae1acf4e72b5df39c498fb88b/linux-user/syscall.c#L1970-L2014).
+
+The fix is something like:
+
+```
+__put_user(host_to_target_errno(errh->ee.ee_errno), &target_errh->ee.ee_errno);
+```
diff --git a/results/classifier/gemma3:12b/socket/607 b/results/classifier/gemma3:12b/socket/607
new file mode 100644
index 00000000..21d14140
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/607
@@ -0,0 +1,60 @@
+
+socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
+Description of problem:
+
+Steps to reproduce:
+1. Run Qemu command line 
+2. Start console in virt-manager
+Additional information:
+_/var/log/libvirt/qemu_
+
+```
+2021-09-08 13:08:22.003+0000: starting up libvirt version: 7.6.0, qemu version: 6.1.0, kernel: 5.4.143-1-MANJARO, hostname: pjehrsohmehj
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/bin \
+HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-81-Vagrant_default/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=Vagrant_default,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-81-Vagrant_default/master-key.aes"}' \
+-machine pc-i440fx-6.1,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram \
+-cpu Snowridge,ss=on,vmx=on,hypervisor=on,tsc-adjust=on,mpx=on,rdpid=on,md-clear=on,stibp=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,rdctl-no=on,ibrs-all=on,skip-l1dfl-vmentry=on,mds-no=on,pschange-mc-no=on,clwb=off,gfni=off,cldemote=off,movdiri=off,movdir64b=off,core-capability=off,split-lock-detect=off \
+-m 512 \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":536870912}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,cores=1,threads=1 \
+-uuid cde944bb-cfc2-473b-b605-580382c3f944 \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=32,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc \
+-no-shutdown \
+-boot strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/Zelec-VAGRANTSLASH-manjarolinux_vagrant_box_image_20210901.1551100290_box.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":true,"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
+-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/Vagrant_default.img","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1 \
+-netdev tap,fd=34,id=hostnet0,vhost=on,vhostfd=35 \
+-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:cf:27:78,bus=pci.0,addr=0x5 \
+-chardev pty,id=charserial0 \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-audiodev id=audio1,driver=none \
+-vnc 127.0.0.1:0,audiodev=audio1 \
+-k en-us \
+-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/0 (label charserial0)
+2021-09-08T13:08:22.188784Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
+2021-09-08T13:08:22.188905Z qemu-system-x86_64: warning: host doesn't support requested feature: MSR(490H).vmx-entry-load-perf-global-ctrl [bit 13]
+qemu-system-x86_64: ../qemu-6.1.0/util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
+2021-09-08 13:08:28.059+0000: shutting down, reason=crashed
+2
+```
diff --git a/results/classifier/gemma3:12b/socket/676029 b/results/classifier/gemma3:12b/socket/676029
new file mode 100644
index 00000000..b73c5d48
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/676029
@@ -0,0 +1,19 @@
+
+Silently fail with wrong vde socket dir
+
+Hi,
+
+Using qemu 0.12.5, kvm silently fail with exit code 1 when using -net vde and a wrong path for sock. Actually, the sock option is mean to be the socket dir of the vde_switch, not the socket itself.
+
+With -net vde,sock=/var/run/vde/vde0/ctl , strace ends with the following messages :
+
+connect(7, {sa_family=AF_FILE, path="/var/run/vde/vde0/ctl/ctl"}, 110) = -1 ENOTDIR (Not a directory)
+close(7)                                = 0
+close(8)                                = 0
+exit_group(1)                           = ?
+root ~# 
+
+Please add a meaningful message.
+
+Regards,
+Étienne
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/717929 b/results/classifier/gemma3:12b/socket/717929
new file mode 100644
index 00000000..41e7898c
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/717929
@@ -0,0 +1,24 @@
+
+Serial communication between VMs problematic
+
+Hello,
+
+I want to setup serial communication between VM hosts but I have found it quite difficult...:
+
+...because when trying unix sockets:
+
+- host A has serial device as unix socket (bind)
+- host B has serial device as client of unix socket
+- host A is down thus not unix socket does exist
+- host B can't be started because cannot read the socket:
+
+error: Failed to start domain opd1s02
+error: internal error Process exited while reading console log output: char device redirected to /dev/pts/0
+connect(unix:/tmp/test.sock): Connection refused
+chardev: opening backend "socket" failed
+
+Can that work like the cable is not plugged in? So host B can start and when the socket would exist it would connect to it?
+
+...and when using pty and host device combination one cannot predict pty device under /dev/pts, it would be nice if would be possible to define exact device name.
+
+Tested on Fedora 14.
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/764 b/results/classifier/gemma3:12b/socket/764
new file mode 100644
index 00000000..b4ba6672
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/764
@@ -0,0 +1,46 @@
+
+qemu-system-x86 crash (reason: use after free in socket_reconnect_timeout when reconnecting vhost-user dev)
+Description of problem:
+(gdb) bt<br/>
+#0  0x00007f205976b78b in raise () from /usr/lib64/libc.so.6<br/>
+#1  0x00007f205976cab1 in abort () from /usr/lib64/libc.so.6<br/>
+#2  0x00007f205976404a in ?? () from /usr/lib64/libc.so.6<br/>
+#3  0x00007f20597640c2 in __assert_fail () from /usr/lib64/libc.so.6<br/>
+#4  0x00007f20594ea556 in **qemu_mutex_lock_impl**(mutex=<optimized out>, file=<optimized out>, line=<optimized out>)<br/>
+#5  0x00007f205957a4ef in **socket_reconnect_timeout** (opaque=<optimized out>)<br/>
+#6  0x00007f205993b68d in ?? () from /usr/lib64/libglib-2.0.so.0<br/>
+#7  0x00007f205993aba4 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0<br/>
+#8  0x00007f20594e5d49 in glib_pollfds_poll () at /usr/src/debug/qemu-4.1.0-666.x86_64/util/main-loop.c:218<br/>
+#9  0x00007f20594e5dc2 in os_host_main_loop_wait (timeout=<optimized out>)<br/>
+#10 0x00007f20594e5f5d in main_loop_wait (nonblocking=nonblocking@entry=0)<br/>
+... ...<br/>
+#14 0x0000560919e13180 in main (argc=80, argv=0x7ffebc1d0598, envp=0x7ffebc1d0820)<br/>
+
+at the moment, chr had be free by hot unplug vhost-user dev<br/>
+
+I think the bug cause reason as following:<br/>
+1. when vhost-user dev is connecting state, io-task-worker thread will try call tcp_chr_connect_client_async <br/>
+ again and again to reconnect.<br/>
+2. if reconnect fail, io-task-worker thread will switch to main-thread to handle error, and main-thread will <br/> 
+call qemu_chr_socket_restart_timer again to reconnect again. <br/>
+
+3. But, if a hot unplug operation insert to main-thread before io-task-worker switch to main-thread,<br/>
+   the qemu_chr_socket_restart_timer->socket_reconnect_timeout process will use the released chardev and <br/>
+   trigger qemu crash
+
+in short, the primary cause of this bug is io-task-worker reconnect process and <br/>
+main-thread hot unplug vhost-user-dev process in a race.<br/>
+Steps to reproduce:
+1. in qio_task_thread_worker func, add sleep in the following position: <br/>
+      &emsp;task->thread->completion = g_idle_source_new(); <br/>
+      &emsp;g_source_set_callback(task->thread->completion,<br/>
+                          qio_task_thread_result, task, NULL);<br/>
+      &emsp;**sleep(8);**<br/>
+      &emsp;g_source_attach(task->thread->completion,<br/>
+                    task->thread->context);<br/>
+      &emsp;g_source_unref(task->thread->completion);  <br/>
+2. kill spdk proces or dpdk process, qemu will reconnect to the disconnected vhost-user dev of spdk or dpdk <br/>
+3. hot unplug the disconnected vhost-user dev when reconnect logic goto upper sleep position <br/>
+4. qemu_chr_socket_restart_timer will use the chr after free, and trigger qemu crash
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/socket/833 b/results/classifier/gemma3:12b/socket/833
new file mode 100644
index 00000000..6d0fcb93
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/833
@@ -0,0 +1,43 @@
+
+linux-user: sendmsg fails to send messages without iov
+Description of problem:
+When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux.
+
+A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526
+
+A message without data but only ancillary data is used to set the IV.
+Steps to reproduce:
+See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`).
+
+(Test case is to be considered GPL, as I've copied bits from `ell`)
+
+Native:
+```
+$ strace -esendmsg ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+
+Qemu (observe missing sendmsg call):
+```
+$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+For a practical reproducer:
+
+1. Compile and run `ell`'s `test-cipher` test case:
+
+```
+$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher 
+TEST: unsupported
+TEST: aes
+TEST: aes_ctr
+test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed.
+Aborted (core dumped)
+```
+
+A strace will look similar.
diff --git a/results/classifier/gemma3:12b/socket/834 b/results/classifier/gemma3:12b/socket/834
new file mode 100644
index 00000000..e612e98c
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/834
@@ -0,0 +1,60 @@
+
+linux-user: fails to deliver signals raised during pselect
+Description of problem:
+When run via qemu a program which blocks signals but unmasks them during `pselect` does not catch these signals when returning from `pselect`.
+
+Used as reference on expected behavior: [The new pselect() system call](https://lwn.net/Articles/176911/)
+Steps to reproduce:
+A minimal test case below mimics behavior as encountered in the test suite of `p11-kit` ([link](https://github.com/p11-glue/p11-kit)) (which attempts to catch `SIGTERM` in a similar way and results in lingering processes after running the test suite).
+
+```C
+#include <stdio.h>
+#include <unistd.h>
+#include <signal.h>
+#include <sys/select.h>
+
+static void handler(int sig)
+{
+	puts("SIGNAL");
+}
+
+int main(int argc, char *argv[])
+{
+	struct sigaction sa;
+
+	fd_set rfds;
+	sigset_t emptyset, blockset;
+
+	sigemptyset (&blockset);
+	sigemptyset (&emptyset);
+	sigaddset (&blockset, SIGUSR1);
+
+	sa.sa_handler = handler;
+	sigemptyset(&sa.sa_mask);
+	sa.sa_flags = 0;
+	sigaction(SIGUSR1, &sa, NULL);
+
+	sigprocmask (SIG_BLOCK, &blockset, NULL);
+
+	FD_ZERO(&rfds);
+
+	while(1) {
+		pselect(0, &rfds, NULL, NULL, NULL, &emptyset);
+	}
+
+	return 0;
+}
+```
+
+Running this without qemu should print _SIGNAL_ when sent `SIGUSR1`:
+
+```
+$ ./a.out &
+[1] 1683587
+$ kill -USR1 %1
+$ SIGNAL
+```
+
+When run with `qemu-x86_64` however, it does not (also qemu's `-strace` confirms the signal isn't received whereas a strace of qemu shows it's in fact delivered).
+
+The pselect call itself _is_ interrupted, but the signal goes missing.
diff --git a/results/classifier/gemma3:12b/socket/845 b/results/classifier/gemma3:12b/socket/845
new file mode 100644
index 00000000..a4df35c4
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/845
@@ -0,0 +1,60 @@
+
+Heap-use-after-free in remote_object_finalize
+Description of problem:
+While I was working with `QIOChannel` in my downstream QEMU fork, I looked at `hw/remote/remote-obj.c` as a usage example.
+
+I did the same thing to `remote_object_finalize` function in order to free the QIOChannel when the connection closed:
+
+```c
+    if (o->ioc) {
+        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+        qio_channel_close(o->ioc, NULL);
+    }
+
+    object_unref(OBJECT(o->ioc));
+```
+
+After the connection is closed for a while, my program SIGSEGV:
+
+```
+Thread 2 Crashed:
+0   qemu-system-aarch64           	0x000000010164513c qemu_coroutine_get_aio_context + 12 (qemu-coroutine.c:203)
+1   qemu-system-aarch64           	0x000000010145ad82 qio_channel_restart_read + 50
+2   qemu-system-aarch64           	0x0000000101614c8a aio_dispatch_handler + 378 (aio-posix.c:332)
+3   qemu-system-aarch64           	0x0000000101613fad aio_dispatch_handlers + 125 (aio-posix.c:372)
+4   qemu-system-aarch64           	0x0000000101613ef3 aio_dispatch + 51 (aio-posix.c:383)
+5   qemu-system-aarch64           	0x0000000101631e18 aio_ctx_dispatch + 104 (async.c:307)
+6   libglib-2.0.0.dylib           	0x000000010284b90c g_main_context_dispatch + 364
+7   qemu-system-aarch64           	0x0000000101644728 glib_pollfds_poll + 88 (main-loop.c:233)
+8   qemu-system-aarch64           	0x0000000101644170 os_host_main_loop_wait + 128 (main-loop.c:256)
+9   qemu-system-aarch64           	0x000000010164403c main_loop_wait + 188 (main-loop.c:530)
+10  qemu-system-aarch64           	0x00000001012f3014 qemu_main_loop + 36 (runstate.c:721)
+11  qemu-system-aarch64           	0x0000000100c25e38 qemu_main + 40 (main.c:51)
+12  qemu-system-aarch64           	0x0000000100c7b1f4 call_qemu_main + 52 (cocoa.m:1746)
+13  qemu-system-aarch64           	0x000000010161a459 qemu_thread_start + 185 (qemu-thread-posix.c:521)
+14  libsystem_pthread.dylib       	0x00007fff6a6e2109 _pthread_start + 148
+15  libsystem_pthread.dylib       	0x00007fff6a6ddb8b thread_start + 15
+```
+
+So apparently, there is a dangling pointer of the QIOChannel in AIOContext.
+
+And indeed, that caused by the fact that when the fd read/write is blocked, it sets the fd handlers to the AIO context before yielding the coroutine (https://gitlab.com/qemu-project/qemu/-/blob/master/io/channel.c#L544).
+
+So after the fd is closed, the AIO still dispatches the fd readable event when the main loop dispatches again, using the dangling QIOChannel pointer (When the fd is reused I think).
+
+I suggest adding a `qio_channel_detach_aio_context()` call before the channel is shutdown in `remote-obj.c`, or before the fd is closed in `qio_channel_close()` in `io/channel.c`
+
+```c
+
+    if (o->ioc) {
+        qio_channel_detach_aio_context(o->ioc);
+        qio_channel_shutdown(o->ioc, QIO_CHANNEL_SHUTDOWN_BOTH, NULL);
+        qio_channel_close(o->ioc, NULL);
+    }
+
+    object_unref(OBJECT(o->ioc));
+```
+
+This bug might have slipped through the cracks because `mpqemu_remote_msg_loop_co` issues a shutdown request immediately after an I/O error occured on the QIOChannel.
+Additional information:
+
diff --git a/results/classifier/gemma3:12b/socket/872 b/results/classifier/gemma3:12b/socket/872
new file mode 100644
index 00000000..801a0d68
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/872
@@ -0,0 +1,2 @@
+
+linux-user getsockopt(fd, SOL_SOCKET, SO_ERROR) returns host errno to target
diff --git a/results/classifier/gemma3:12b/socket/885 b/results/classifier/gemma3:12b/socket/885
new file mode 100644
index 00000000..8c92b741
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/885
@@ -0,0 +1,2 @@
+
+linux-user: `getsockopt` on `SO_RCVTIMEO_NEW`/`SO_SNDTIMEO_NEW` writes unexpected `int`
diff --git a/results/classifier/gemma3:12b/socket/916720 b/results/classifier/gemma3:12b/socket/916720
new file mode 100644
index 00000000..60e579e2
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/916720
@@ -0,0 +1,11 @@
+
+select fails on windows because a non-socket fd is in the rfds set
+
+The select call in file main_loop.c at line 460 fails on windows because a non-socket fd is in the rfds set. As a result, gdb remote connections will never be accepted by qemu. The select function returns with -1. WSAGetLastError returns code 10038 (WSAENOTSOCK).
+
+I start qemu as follows:
+qemu-system-arm -cpu cortex-m3 -M lm3s6965evb -nographic -monitor null -serial null -semihosting -kernel test1.elf -S -gdb tcp:127.0.0.1:2200
+
+qemu is configure with:
+CFLAGS="-O4 -march=i686"
+configure --target-list="i386-softmmu arm-softmmu sparc-softmmu ppc-softmmu" --prefix=/home/qemu/install --cc=mingw32-gcc --host-cc=mingw32-gcc --audio-drv-list="dsound sdl" --audio-card-list="ac97 es1370 sb16 cs4231a adlib gus"
\ No newline at end of file
diff --git a/results/classifier/gemma3:12b/socket/988128 b/results/classifier/gemma3:12b/socket/988128
new file mode 100644
index 00000000..983229f6
--- /dev/null
+++ b/results/classifier/gemma3:12b/socket/988128
@@ -0,0 +1,29 @@
+
+smbd crashes when called with "smb ports = 0"
+
+The smb.conf generated by qemu-kvm contains a "smb ports = 0" directive. This
+causes at least version 3.6.4 of Samba to crash with
+
+[0] vostro:/tmp/qemu-smb.6836-0# smbd -i -s smb.conf
+Unable to setup corepath for smbd: Operation not permitted
+smbd version 3.6.4 started.
+Copyright Andrew Tridgell and the Samba Team 1992-2011
+open_sockets_smbd: No sockets available to bind to.
+===============================================================
+Abnormal server exit: open_sockets_smbd() failed
+===============================================================
+BACKTRACE: 6 stack frames:
+ #0 smbd(log_stack_trace+0x1a) [0x7fe50c14f8ba]
+ #1 smbd(+0x6a0743) [0x7fe50c3bd743]
+ #2 smbd(+0x6a0a41) [0x7fe50c3bda41]
+ #3 smbd(main+0xa52) [0x7fe50be26d42]
+ #4 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7fe508ac0ead]
+ #5 smbd(+0x10a6b9) [0x7fe50be276b9]
+
+Changing "smb ports" to a non-privilileged port works around the issue.
+
+I'd like to help fix this, but I am not sure what qemu-kvm's intention is here.
+Zero is not a valid port, and the smb.conf manpage does not describe any
+special meaning of zero here. I found that previous versions of samba apparently
+did not bind to any port if zero was specified - but in that case, how is
+qemu communicating with samba?
\ No newline at end of file