add 18th iteration of classifier

author: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:00 +0000
committer: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:33 +0000
commit: 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree: b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/vnc
parent: b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download: emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz
emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip
36 files changed, 2243 insertions, 0 deletions
diff --git a/results/classifier/118/vnc/1004050 b/results/classifier/118/vnc/1004050
new file mode 100644
index 00000000..c92502d2
--- /dev/null
+++ b/results/classifier/118/vnc/1004050
@@ -0,0 +1,71 @@
+vnc: 0.832
+boot: 0.810
+ppc: 0.803
+peripherals: 0.734
+device: 0.722
+architecture: 0.700
+graphic: 0.691
+user-level: 0.684
+PID: 0.671
+semantic: 0.527
+performance: 0.495
+debug: 0.468
+x86: 0.445
+register: 0.440
+arm: 0.395
+socket: 0.387
+risc-v: 0.380
+kernel: 0.379
+permissions: 0.379
+VMM: 0.346
+TCG: 0.346
+mistranslation: 0.313
+i386: 0.300
+network: 0.256
+virtual: 0.241
+hypervisor: 0.207
+files: 0.194
+assembly: 0.154
+KVM: 0.130
+
+qemu-system-ppc64 by default has non-working keyboard
+
+Compile qemu from git and do:
+
+  ./ppc64-softmmu/qemu-system-ppc64
+
+(ie. no parameters).  It boots to an OpenBIOS prompt.  However the keyboard doesn't work.  After ~10 keypresses, qemu just says:
+
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+
+There is no indication inside the guest that OpenBIOS is seeing keyboard events.
+
+Also there's no indication of what type of keyboard devices are available, nor what we should use.
+
+I have also experienced the same issue with qemu-system-ppc64. It appears that ppc64 is not able to communicate with the USB controller. This issue is not seen with with qemu-system-ppc.  
+
+tboyes@tboyes-dev:~/qemu$ qemu-system-ppc64 -serial stdio -m 1024 -net nic -net user debian-ppc.qcow2 -cdrom debian-6.0.5-powerpc-netinst.iso  -boot d
+VNC server running on `127.0.0.1:5901'
+C>> annot manage 'OHCI USB controller' PCI device type 'usb':
+>>  106b 3f (c 3 10)
+
+>> =============================================================
+>> OpenBIOS 1.0 [May 30 2012 16:55]
+>> Configuration device id QEMU version 1 machine id 3
+>> CPUs: 1
+>> Memory: 1024M
+>> UUID: 00000000-0000-0000-0000-000000000000
+>> CPU type PowerPC,970FX
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+usb-kbd: warning: key event queue full
+
+
+
+
+AFAIK an OHCI driver has been added to OpenBIOS in 2014, so marking this bug as fixed now. If you still have issues with OpenBIOS, please report them to the OpenBIOS project instead of the QEMU bug tracker, thanks!
+
diff --git a/results/classifier/118/vnc/11357571 b/results/classifier/118/vnc/11357571
new file mode 100644
index 00000000..eb64c6bb
--- /dev/null
+++ b/results/classifier/118/vnc/11357571
@@ -0,0 +1,72 @@
+vnc: 0.950
+graphic: 0.915
+performance: 0.806
+device: 0.763
+network: 0.705
+semantic: 0.694
+PID: 0.681
+ppc: 0.632
+peripherals: 0.629
+socket: 0.600
+debug: 0.572
+boot: 0.571
+architecture: 0.568
+risc-v: 0.550
+x86: 0.534
+i386: 0.520
+permissions: 0.517
+KVM: 0.516
+mistranslation: 0.516
+hypervisor: 0.508
+VMM: 0.505
+kernel: 0.480
+TCG: 0.462
+register: 0.454
+files: 0.453
+user-level: 0.433
+arm: 0.405
+assembly: 0.389
+virtual: 0.376
+
+[Qemu-devel] [BUG] VNC: client won't send FramebufferUpdateRequest if job in flight is aborted
+
+Hi Gerd, Daniel.
+
+We noticed that if VncSharePolicy was configured with 
+VNC_SHARE_POLICY_FORCE_SHARED mode and
+multiple vnc clients opened vnc connections, some clients could go blank screen 
+at high probability.
+This problem can be reproduced when we regularly reboot suse12sp3 in graphic 
+mode both
+with RealVNC and noVNC client.
+
+Then we dig into it and find out that some clients go blank screen because they 
+don't
+send FramebufferUpdateRequest any more. One step further, we notice that each 
+time
+the job in flight is aborted one client go blank screen.
+
+The bug is triggered in the following procedure.
+Guest reboot => graphic mode switch => graphic_hw_update =>  vga_update_display
+=> vga_draw_graphic (full_update = 1) => dpy_gfx_replace_surface => 
+vnc_dpy_switch =>
+vnc_abort_display_jobs (client may have job in flight) => job removed from the 
+queue
+If one client has vnc job in flight, *vnc_abort_display_jobs* will wait until 
+its job is abandoned.
+This behavior is done in vnc_worker_thread_loop when 'if (job->vs->ioc == NULL 
+|| job->vs->abort == true)'
+branch is taken.
+
+As we can see, *vnc_abort_display_jobs* is intended to do some optimization to 
+avoid unnecessary client update.
+But if client sends FramebufferUpdateRequest for some graphic area and its 
+FramebufferUpdate response job
+is abandoned, the client may wait for the response and never send new 
+FramebufferUpdateRequest, which may
+case the client go blank screen forever.
+
+So I am wondering whether we should drop the *vnc_abort_display_jobs*  
+optimization  or do some trick here
+to push the client to send new FramebufferUpdateRequest. Do you have any idea ?
+
diff --git a/results/classifier/118/vnc/1136477 b/results/classifier/118/vnc/1136477
new file mode 100644
index 00000000..18c16b9b
--- /dev/null
+++ b/results/classifier/118/vnc/1136477
@@ -0,0 +1,47 @@
+vnc: 0.885
+graphic: 0.726
+device: 0.713
+permissions: 0.653
+semantic: 0.634
+network: 0.506
+socket: 0.490
+mistranslation: 0.489
+ppc: 0.442
+risc-v: 0.431
+user-level: 0.389
+register: 0.385
+architecture: 0.385
+performance: 0.378
+hypervisor: 0.364
+debug: 0.362
+kernel: 0.331
+i386: 0.318
+files: 0.302
+PID: 0.286
+arm: 0.275
+virtual: 0.254
+peripherals: 0.243
+x86: 0.235
+VMM: 0.230
+boot: 0.211
+assembly: 0.197
+TCG: 0.185
+KVM: 0.159
+
+qemu doesn't sanitize command line options carrying plaintext passwords
+
+A slight security problem exists with qemu's lack of sanitization of argv[], for cases where the user may have specified a plaintext password for spice/vnc authorization.  (Yes, it's not great to use this facility, but it's convenient and not grotesquely unsafe, were it not for this bug.)  It would be nice if those plaintext passwords were nuked from the command line, so a subsequent "ps awux" didn't show them for all to see.
+
+See also https://bugzilla.redhat.com/show_bug.cgi?id=916279
+
+Hi,
+
+Thanks for submitting this report.  I've removed the security label from the bug after reading through the comments and the referenced bug.  Modifying argv is not terribly portable and I think a reasonable person would expect that a password specified on the command line would be visible through a ps.
+
+Patches would certainly be considered but I don't consider this a security issue.  Just a request for an enhancement.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1321028 b/results/classifier/118/vnc/1321028
new file mode 100644
index 00000000..81dd818c
--- /dev/null
+++ b/results/classifier/118/vnc/1321028
@@ -0,0 +1,115 @@
+vnc: 0.899
+device: 0.894
+boot: 0.889
+graphic: 0.887
+risc-v: 0.887
+register: 0.883
+debug: 0.875
+semantic: 0.874
+permissions: 0.872
+peripherals: 0.870
+socket: 0.868
+network: 0.866
+architecture: 0.863
+ppc: 0.862
+kernel: 0.858
+files: 0.857
+assembly: 0.852
+TCG: 0.842
+PID: 0.842
+hypervisor: 0.842
+KVM: 0.841
+arm: 0.836
+VMM: 0.829
+mistranslation: 0.827
+virtual: 0.805
+user-level: 0.793
+performance: 0.761
+x86: 0.755
+i386: 0.693
+
+qemu-system-ppc : file  systems are not shutting down clean 
+
+
+
+
+Launching a VM that has been shutdown gracefully ( via init 0)  typically requires fsck to run when it is started ;
+This indications data integrity issues;
+
+
+ The symptom can be seen by observing the fsck running when the VM restarted.
+
+Install 14-04-LTS to a VM  and the issue can be seen ;
+
+
+
+(trusty)vnc@jade-rev4:/home2/qemu$ cat vm1/go.sh
+mymac="52:54:00:12:34:10"
+T=` echo $mymac | cut -d: -f5,6 | sed s/\://`
+mytap="tap$T"
+
+
+tunctl  -d $mytap
+tunctl  -t $mytap
+
+ /usr/bin/qemu-system-ppc -M ppce500 -nographic -kernel jade-kernel.bin \
+		-initrd jade-initrd-2.0.bin -m 1G -enable-kvm  \
+		-drive file=jade-ubuntu-14.04.raw,if=virtio \
+		-net nic,vlan=0,macaddr=$mymac \
+		-net tap,vlan=0,ifname=$mytap,script=/usr/local/bin/qemu-ifup \
+		-append "console=ttyS0 ssgyboot=break" \
+	 	-no-shutdown -no-reboot -name `basename $fp`
+
+ProblemType: Bug
+DistroRelease: Ubuntu 14.04
+Package: qemu-system-ppc 2.0.0~rc1+dfsg-0ubuntu3.1
+ProcVersionSignature: Ubuntu 3.13.0-24.46-powerpc-e500mc 3.13.9
+Uname: Linux 3.13.0-24-powerpc-e500mc ppc
+ApportVersion: 2.14.1-0ubuntu3
+Architecture: powerpc
+Date: Mon May 19 17:01:14 2014
+ProcEnviron:
+ TERM=xterm
+ PATH=(custom, no user)
+ LANG=en_US.UTF-8
+ SHELL=/bin/bash
+SourcePackage: qemu
+UpgradeStatus: Upgraded to trusty on 2014-04-29 (20 days ago)
+
+
+
+Can you explain what "ssgyboot=break" tells the kernel to do?
+
+Could you upload the guest's /var/log/syslog after reboot?
+
+Please show
+
+echo $?
+
+immediately after the qemu-system-ppc command has exited?
+
+1. ssgyboot-break has no effect in the VM  kernel; It is only used by jade-initrd-2.0.bin  ; 
+
+  kernel cmdline:
+
+[    0.000000] pcpu-alloc: s28800 r8192 d16256 u53248 alloc=13*4096
+[    0.000000] pcpu-alloc: [0] 0
+[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pag
+es: 260608
+[    0.000000] Kernel command line: (host)/boot/vmlinux-3.13.0-24-powerpc-e500mc
+ root=/dev/vda1 ro quiet splash vt.handoff=7
+
+2: see attached file . 
+
+3. VM's do not exit from qemu-system-ppc ; see defect :   1317603 . 
+
+
+
+/var/log/syslog   attached as syslog.onboot when file system is dirty ;
+
+Since the VM terminated ; the device should have been umounted ;
+
+I am thinking since the VM hasn't terminated due to defect 1317603 ,  qemu-system-ppc has to be terminated with kill  <pid>  which is not kill -9  ; I could see some inconsistencies with virtio device file not being sync'ed ; but the VM did unmount it;  
+
+
+
diff --git a/results/classifier/118/vnc/1339 b/results/classifier/118/vnc/1339
new file mode 100644
index 00000000..c982f5fe
--- /dev/null
+++ b/results/classifier/118/vnc/1339
@@ -0,0 +1,46 @@
+vnc: 0.948
+risc-v: 0.937
+device: 0.931
+socket: 0.857
+graphic: 0.827
+network: 0.820
+PID: 0.809
+register: 0.729
+files: 0.719
+permissions: 0.668
+VMM: 0.601
+architecture: 0.599
+ppc: 0.584
+performance: 0.583
+kernel: 0.583
+TCG: 0.572
+arm: 0.571
+debug: 0.558
+mistranslation: 0.532
+virtual: 0.532
+x86: 0.524
+boot: 0.487
+hypervisor: 0.486
+semantic: 0.476
+i386: 0.475
+KVM: 0.423
+peripherals: 0.378
+user-level: 0.295
+assembly: 0.275
+
+RVV vfncvt.rtz.x.f.w Assertion failed
+Description of problem:
+when execute 
+``` 
+vsetvli        t0,       x0,         e16,      m1
+vfncvt.rtz.x.f.w v0, v4
+```
+report error:
+
+qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped)
+Steps to reproduce:
+1. write the code
+2. compile
+3. excute
+Additional information:
+
diff --git a/results/classifier/118/vnc/1354279 b/results/classifier/118/vnc/1354279
new file mode 100644
index 00000000..a2fd5ed9
--- /dev/null
+++ b/results/classifier/118/vnc/1354279
@@ -0,0 +1,100 @@
+vnc: 0.938
+x86: 0.911
+architecture: 0.909
+kernel: 0.897
+graphic: 0.874
+KVM: 0.867
+network: 0.863
+performance: 0.826
+socket: 0.819
+device: 0.818
+hypervisor: 0.808
+ppc: 0.767
+user-level: 0.741
+peripherals: 0.737
+virtual: 0.729
+PID: 0.727
+semantic: 0.663
+register: 0.661
+debug: 0.647
+i386: 0.629
+permissions: 0.618
+risc-v: 0.570
+mistranslation: 0.537
+VMM: 0.495
+arm: 0.461
+boot: 0.439
+files: 0.423
+TCG: 0.385
+assembly: 0.341
+
+The guest will be destroyed after hot remove the VF from the guest. 
+
+Environment:
+------------
+Host OS (ia32/ia32e/IA64):ia32e
+Guest OS (ia32/ia32e/IA64):ia32e
+Guest OS Type (Linux/Windows):Linux
+kvm.git Commit:9f6226a762c7ae02f6a23a3d4fc552dafa57ea23
+qemu.git Commit:5a7348045091a2bc15d85bb177e5956aa6114e5a
+Host Kernel Version:3.16.0-rc1
+Hardware:Romley_EP, Ivytown_EP,Haswell_EP
+
+
+Bug detailed description:
+--------------------------
+hot add the VF to the guest, then hot remove the VF from the guest, the guest will be destroyed.
+
+note:
+1. when hot add the VF with vfio, the hot remove the VF from the guest, the guest works fine.
+2. this shoule be a qemu bug:
+kvm       +   qemu    = result
+9f6226a7  +  5a734804 = bad
+9f6226a7  +  9f862687 = good
+
+
+
+Reproduce steps:
+----------------
+1. create guest
+qemu-system-x86_64 --enable-kvm -m 1024 -smp 4 -net none rhel6u5.qcow -monitor pty
+2. hot add the vf to guest
+echo "device_add pci-assign,host=05:10.0,id=nic" >/dev/pts/x
+cat /dev/pts/x
+3. hot remove the VF froem guest
+echo "device_del nic" >/dev/pts/x
+
+Current result:
+----------------
+the guest willl be destroyed after hot remove the VF from the guest
+
+Expected result:
+----------------
+the guest works fine after hot remove the VF from the guest
+
+
+Basic root-causing log:
+----------------------
+[root@vt-snb9 qemu.git]# qemu-system-x86_64 -enable-kvm -m 1024 -smp 2 -net none rhel6u5.qcow -monitor pty
+VNC server running on `::1:5900'
+**
+ERROR:qom/object.c:725:object_unref: assertion failed: (obj->ref > 0)
+Aborted (core dumped)
+
+the first bad commit is:
+commit 22a893e4f55344f96e1aafc66f5fedc491a5ca97
+Author: Paolo Bonzini <email address hidden>
+Date:   Wed Jun 11 10:58:06 2014 +0200
+
+    memory: MemoryRegion: replace owner field with QOM parent
+    
+    The two are now the same.
+    
+    Reviewed-by: Peter Crosthwaite <email address hidden>
+    Signed-off-by: Paolo Bonzini <email address hidden>
+
+test on Ivytown_EP
+kvm.git + qemu.git: c77dcacb_0e4a7737
+kernel version: 3.16.0
+after hot remove the VF from the guest, the guest works fine.
+
diff --git a/results/classifier/118/vnc/1391942 b/results/classifier/118/vnc/1391942
new file mode 100644
index 00000000..e4b59350
--- /dev/null
+++ b/results/classifier/118/vnc/1391942
@@ -0,0 +1,87 @@
+vnc: 0.974
+user-level: 0.927
+ppc: 0.915
+debug: 0.915
+network: 0.915
+mistranslation: 0.912
+semantic: 0.911
+device: 0.902
+performance: 0.898
+arm: 0.895
+PID: 0.889
+permissions: 0.885
+files: 0.885
+x86: 0.877
+graphic: 0.831
+register: 0.827
+architecture: 0.826
+peripherals: 0.812
+hypervisor: 0.808
+risc-v: 0.807
+socket: 0.805
+VMM: 0.797
+assembly: 0.794
+KVM: 0.762
+TCG: 0.737
+i386: 0.735
+kernel: 0.726
+virtual: 0.692
+boot: 0.675
+
+Unnecessary events option of the trace argument with UST backend
+
+When running configure with the --enable-trace-backends=ust option the user should not have to specify a the "events" and "file" options because they are not used with that tracing framework.
+
+Right now, in order the use this option the need to specify a dummy events file.
+
+This fails:
+$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512               
+qemu-system-x86_64: -trace -m: Invalid parameter '-m'
+
+This works:
+$> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512
+VNC server running on `127.0.0.1:5900'
+
+I am using version:
+$> qemu-system-x86_64 --version 
+QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard
+
+On Wed, Nov 12, 2014 at 04:01:38PM -0000, Francis Deslauriers wrote:
+> When running configure with the --enable-trace-backends=ust option and compiling. 
+> The user should not have to specify a the "events" and "file" options because they are not used with that tracing framework.
+> 
+> Right now, in order the use this option the need to specify a dummy
+> events file.
+> 
+> This fails:
+> $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace -m 512
+> qemu-system-x86_64: -trace -m: Invalid parameter '-m'
+> 
+> This works:
+> $> qemu-system-x86_64 -hda debian_wheezy_amd64_standard.qcow2 -trace events=dummy-events.txt -m 512
+> VNC server running on `127.0.0.1:5900'
+> 
+> I am using version:
+> $> qemu-system-x86_64 --version
+> QEMU emulator version 2.1.90, Copyright (c) 2003-2008 Fabrice Bellard
+
+What happens when you pass no -trace option?
+
+Stefan
+
+
+It works without the -trace option.
+
+Want I meant with this post is that the "events" argument of the "-trace" option has no effect in the case of using LTTng UST as the tracing backend because the events are enabled from the LTTng tracer itself.
+ 
+Is there some way I can make an argument optional or conditional to a tracing framework?
+
+Thanks,
+
+Francis
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1453612 b/results/classifier/118/vnc/1453612
new file mode 100644
index 00000000..60cfa1ba
--- /dev/null
+++ b/results/classifier/118/vnc/1453612
@@ -0,0 +1,51 @@
+vnc: 0.963
+graphic: 0.690
+device: 0.683
+socket: 0.658
+network: 0.550
+performance: 0.513
+register: 0.488
+risc-v: 0.474
+VMM: 0.455
+architecture: 0.439
+i386: 0.424
+mistranslation: 0.414
+permissions: 0.405
+user-level: 0.393
+hypervisor: 0.380
+PID: 0.376
+semantic: 0.357
+files: 0.357
+x86: 0.356
+debug: 0.350
+ppc: 0.332
+peripherals: 0.323
+boot: 0.279
+arm: 0.261
+virtual: 0.209
+TCG: 0.167
+kernel: 0.146
+assembly: 0.145
+KVM: 0.141
+
+set_password command of monitor has poor feedback on failure
+
+running `set_password vnc NkkmEz5icvTAGo6MECzBVEUxP` in qemu monitor started with `-monitor stdio` gives feedback `Could not set password` which is unhelpful because it doesn't specify the reason of the failure.
+
+experienced with 2.3.0
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1455912 b/results/classifier/118/vnc/1455912
new file mode 100644
index 00000000..0dde18ab
--- /dev/null
+++ b/results/classifier/118/vnc/1455912
@@ -0,0 +1,70 @@
+vnc: 0.847
+device: 0.702
+x86: 0.690
+network: 0.659
+semantic: 0.611
+ppc: 0.587
+performance: 0.567
+user-level: 0.557
+mistranslation: 0.555
+graphic: 0.523
+architecture: 0.431
+boot: 0.334
+kernel: 0.318
+debug: 0.315
+register: 0.309
+virtual: 0.308
+arm: 0.301
+VMM: 0.275
+peripherals: 0.257
+files: 0.237
+permissions: 0.231
+risc-v: 0.207
+TCG: 0.181
+PID: 0.178
+hypervisor: 0.167
+socket: 0.157
+assembly: 0.099
+KVM: 0.067
+i386: 0.044
+
+vnc websocket option not properly parsed when running on commandline
+
+All of my vms are started with a simple script on the command line.  
+Starting with Qemu 2.3.0, the option "-vnc host:port,websocket" is no longer working.
+
+Previously if I said listen on Tor:17,websocket it would function correctly.  Now it's kicking an error:
+
+
+qemu-system-x86_64: -vnc tor:17,websocket: Failed to start VNC server on `(null)': address resolution failed for tor:on: Servname not supported for ai_socktype
+
+The error leads me to believe it's not parsing the command line options for the "vnc" option correctly.  If I leave off ",websocket" it works correctly.  I've even tried, replacing the hostname with an IP address, and using the alternate form " -display vnc=tor:17,webscoket". It reports the same error.
+
+Someone has had a similar issue with the port portion of the display as a string and not an integer (so it's looking in /etc/services etc):
+
+http://stackoverflow.com/questions/23079017/servname-not-supported-for-ai-socktype
+
+
+I have more information about the bug.  The host I'm running this on is called "tor' (no, it has nothing to do with an onion router, its an old nickname and something I've been calling my main dev host for years). Its IP is 10.16.0.5.  If I designate the command line option  as "-vnc tor:11,websocket=5711" or "-vnc 10.16.0.5:11,websocket=5711" it appears to work fine.
+
+I have to include the specific IP I wish it to listen on because this host has a lot of different interfaces, and I don't want it listening on all interfaces.  So there's still an issue with it resolving the "short" name in local dns to the local IP, and listening only on that IP with the abbreviated option.  It's still not parsed correctly.
+
+On another host, with much fewer interfaces and addresses, a simple "-vnc :80,websocket" works fine without modification.   Same version of Qemu, the ArchLinux x86_64 package for 2.3.0-2.
+
+
+
+This is an accidental regression caused by
+
+      commit 4db14629c38611061fc19ec6927405923de84f08
+      Author: Gerd Hoffmann <email address hidden>
+      Date:   Tue Sep 16 12:33:03 2014 +0200
+    
+        vnc: switch to QemuOpts, allow multiple servers
+
+
+
+https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg00583.html
+
+Dan's patch linked in comment #4 went into git as commit 1b1aeb5828c978a, so this has been fixed (with the fix going into the 2.9.0 release).
+
+
diff --git a/results/classifier/118/vnc/1486278 b/results/classifier/118/vnc/1486278
new file mode 100644
index 00000000..8d060b4a
--- /dev/null
+++ b/results/classifier/118/vnc/1486278
@@ -0,0 +1,53 @@
+x86: 0.994
+vnc: 0.982
+i386: 0.967
+permissions: 0.927
+device: 0.896
+network: 0.879
+socket: 0.844
+graphic: 0.802
+mistranslation: 0.775
+user-level: 0.755
+ppc: 0.742
+architecture: 0.729
+PID: 0.707
+performance: 0.677
+semantic: 0.657
+hypervisor: 0.625
+debug: 0.555
+virtual: 0.531
+kernel: 0.523
+arm: 0.489
+VMM: 0.463
+peripherals: 0.459
+boot: 0.455
+register: 0.417
+TCG: 0.371
+risc-v: 0.365
+KVM: 0.308
+files: 0.257
+assembly: 0.207
+
+'info vnc' monitor command does not show websocket information
+
+Steps to reproduce^
+1. run
+ qemu-system-x86_64  -vnc  0.0.0.0:1,websocket=5701 -nographic -monitor stdio
+
+2. then type 
+ (qemu) info vnc
+3.  see
+     address: 0.0.0.0:5901
+        auth: none
+Client: none
+
+There is no information about websocket parameters, but 'netstat -nltp' shows me:
+ ...
+tcp        0      0 0.0.0.0:5701            0.0.0.0:*               LISTEN      27073/qemu-system-x
+....
+
+I think this has been fixed in QEMU v2.10.0 with this commit here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0a9667ecdb6d7da90a2ef64
+
+Thanks! This is presumed fixed in Ubuntu also then, since 18.04 onwards shipped a qemu version higher than 2.10.0. If this is wrong, please reopen.
+
diff --git a/results/classifier/118/vnc/1548 b/results/classifier/118/vnc/1548
new file mode 100644
index 00000000..5df468b2
--- /dev/null
+++ b/results/classifier/118/vnc/1548
@@ -0,0 +1,68 @@
+vnc: 0.948
+x86: 0.794
+device: 0.723
+mistranslation: 0.642
+ppc: 0.641
+graphic: 0.609
+semantic: 0.603
+PID: 0.594
+socket: 0.573
+debug: 0.504
+risc-v: 0.485
+i386: 0.452
+network: 0.443
+register: 0.401
+kernel: 0.388
+hypervisor: 0.348
+TCG: 0.325
+VMM: 0.312
+virtual: 0.293
+user-level: 0.282
+performance: 0.278
+arm: 0.252
+architecture: 0.249
+files: 0.179
+peripherals: 0.171
+boot: 0.171
+permissions: 0.168
+KVM: 0.101
+assembly: 0.082
+
+8.0.0rc0 Regression: vnc fails with Segmentation fault
+Description of problem:
+On connecting with `gvncviewer localhost:05` the qemu process fails with
+```
+Segmentation fault
+```
+`gvncviewer localhost:05` prints
+```
+Connected to server
+Error: Server closed the connection
+Disconnected from server
+```
+Steps to reproduce:
+1. Enter `qemu-system-x86_64 -m 1536 -display vnc=:05 -k de -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso` in first terminal
+2. Enter `gvncviewer localhost:05` in second terminal
+Additional information:
+Final output of `git bisect`:
+```
+385ac97f8fad0e6980c5dfea71132d5ecfb16608 is the first bad commit
+commit 385ac97f8fad0e6980c5dfea71132d5ecfb16608
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Tue Jan 17 15:24:40 2023 +0400
+
+    ui: keep current cursor with QemuConsole
+    
+    Keeping the current cursor around is useful, not only for VNC, but for
+    other displays. Let's move it down, see the following patches for other
+    usages.
+    
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
+
+ include/ui/console.h | 1 +
+ ui/console.c         | 8 ++++++++
+ ui/vnc.c             | 7 ++-----
+ ui/vnc.h             | 1 -
+ 4 files changed, 11 insertions(+), 6 deletions(-)
+```
diff --git a/results/classifier/118/vnc/1637447 b/results/classifier/118/vnc/1637447
new file mode 100644
index 00000000..5a702f8d
--- /dev/null
+++ b/results/classifier/118/vnc/1637447
@@ -0,0 +1,47 @@
+vnc: 0.903
+network: 0.884
+device: 0.865
+socket: 0.784
+risc-v: 0.733
+performance: 0.699
+semantic: 0.673
+architecture: 0.631
+register: 0.617
+graphic: 0.616
+kernel: 0.605
+files: 0.586
+ppc: 0.553
+boot: 0.494
+arm: 0.483
+virtual: 0.465
+VMM: 0.414
+mistranslation: 0.409
+i386: 0.358
+TCG: 0.355
+PID: 0.354
+debug: 0.333
+x86: 0.325
+hypervisor: 0.307
+permissions: 0.296
+KVM: 0.295
+user-level: 0.278
+peripherals: 0.242
+assembly: 0.137
+
+VNC/RFB: QEMU reports incorrect name (length)
+
+If the name of a machine (as set with the -name argument) has a length longer than 1024, (RFB) VNC clients will not receive a correct RFB ServerInit message.
+
+I suspect this is the problem:
+
+https://github.com/qemu/qemu/blob/master/ui/vnc.c#L2463
+
+The return value of snprintf is used as the value for the name-length field in the ServerInit message.
+This is problematic for names that were truncated to 1024, as the length will now be bigger than the actual name.
+
+I think a quick fix would be to simply report min(size,1024) to the client...
+
+The right fix here is to switch to use g_strdup_printf and avoid a fixed length stack buffer entirely.
+
+Fix has been committed: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=97efe4f961dcf5a0126
+
diff --git a/results/classifier/118/vnc/1661176 b/results/classifier/118/vnc/1661176
new file mode 100644
index 00000000..ff15d30a
--- /dev/null
+++ b/results/classifier/118/vnc/1661176
@@ -0,0 +1,39 @@
+vnc: 0.961
+mistranslation: 0.900
+network: 0.861
+device: 0.814
+graphic: 0.761
+performance: 0.753
+semantic: 0.633
+user-level: 0.593
+architecture: 0.547
+virtual: 0.529
+peripherals: 0.497
+ppc: 0.433
+risc-v: 0.428
+socket: 0.401
+register: 0.391
+i386: 0.371
+kernel: 0.370
+PID: 0.319
+TCG: 0.300
+hypervisor: 0.296
+debug: 0.290
+VMM: 0.287
+assembly: 0.284
+permissions: 0.248
+x86: 0.245
+arm: 0.240
+boot: 0.201
+files: 0.098
+KVM: 0.091
+
+[2.8.0] Under VNC CTRL-ALT-2 doesn't get to the monitor
+
+With version 2.6.2 I could access the monitor via VNC by pressing CTRL-ALT-2, while CTRL-ALT-3 brought me to the "serial0 console". CTRL-ALT-1 brought me back to the VGA console.
+Since 2.8.0 CTRL-ALT-2 brings me to the "serial0 console" and CTRL-ALT-3 to the "parallel0 console". The monitor is not available any more, to any CTRL-ALT-1stROW.
+
+Can you still reproduce your issue with the latest version of QEMU (currently v4.2.0)? Please also always add the way how you launched QEMU (ie. the command line parameters)
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1686 b/results/classifier/118/vnc/1686
new file mode 100644
index 00000000..def88798
--- /dev/null
+++ b/results/classifier/118/vnc/1686
@@ -0,0 +1,73 @@
+vnc: 0.986
+kernel: 0.974
+architecture: 0.966
+boot: 0.961
+performance: 0.943
+device: 0.930
+virtual: 0.928
+graphic: 0.904
+peripherals: 0.849
+x86: 0.845
+risc-v: 0.842
+network: 0.837
+PID: 0.825
+KVM: 0.818
+ppc: 0.817
+i386: 0.750
+permissions: 0.704
+register: 0.702
+socket: 0.699
+debug: 0.653
+arm: 0.646
+user-level: 0.632
+semantic: 0.619
+TCG: 0.614
+VMM: 0.560
+hypervisor: 0.547
+files: 0.514
+mistranslation: 0.453
+assembly: 0.320
+
+VPS does not boots with CPU Model QEMU64 or KVM64
+Description of problem:
+
+Steps to reproduce:
+1. Boot the VPS using AlmaLinux 9 ISO / image and it boots to kernel panic
+Additional information:
+VNC shows this message :
+
+[ 1.749935] do_exit.cold+0x14/0x9f
+
+[1.7502581 do_group_exit+0x33/0xa0
+
+1.7506001 _x64_sys_exit_group+0x14/0x20
+
+1.7510081 do_syscall 64+0x5c/0x90
+
+[1.751361] ? syscall_exit_to_user_mode+0x12/0x30
+
+[1.7517911 ? do_syscall_64+0x69/0x90
+
+[1.752131] ? do_user_addr_fault+0x1d8/0x698
+
+[1.7525091 ? exc_page_fault+0x62/0x150 1.752896] entry_SYSCALL_64_after_hwframe+ +0x63/0xcd
+
+[1.753612] RIP: 0033:0x7fb0e95b62d1
+
+[ 1.7539561 Code: c3 of 1f 84 00 00 00 00 00 f3 Of le fa be e7 00 00 00 ba 3c 00 00 00 eb Od 89 de Of 05 48 3d 00 fe ff ff 77 1c f4 89 fe of 05 <48> 3d 00 fe ff ff 76 e7 f7 d8 89 05 ff fe 00 00 eb dd of 1f 44 00
+
+[ 1.755047] RSP: 002b:00007ffe484df 288 EFLAGS: 00000246 ORIG_RAX: 00000000000
+
+000e7
+
+[ 1.755590] RAX: fffff ffffda RBX: 00007fb0e95b0f30 RCX: 00007fb0e95b62d1 1.756100] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 000000000000007f
+
+[1.756565] RBP: 00007ffe484df410 R08: 00007ffe484dedf9 R09: 0000000000000000
+
+[ 1.757034] R10: 00000000ffffffff R11: 0000000000000246 R12: 00007fb0e958f000
+
+[ 1.7574981 R13: 0000002300000007 R14: 0000000000000007 R15: 00007ffe484df420
+
+[ 1.7579921 Kernel Offset: 0x3aa00000 from Oxffffffff81000000 (relocation ran ge: 0xffffffff80000000-0xffffffffbfffffff)
+
+[ 1.7589051---[ end Kernel panic code=0x00007f00 --- not syncing: Attempted to kill init! exit
diff --git a/results/classifier/118/vnc/170 b/results/classifier/118/vnc/170
new file mode 100644
index 00000000..77e9634e
--- /dev/null
+++ b/results/classifier/118/vnc/170
@@ -0,0 +1,31 @@
+vnc: 0.867
+device: 0.813
+network: 0.810
+risc-v: 0.565
+performance: 0.490
+debug: 0.459
+arm: 0.410
+semantic: 0.390
+i386: 0.277
+architecture: 0.264
+ppc: 0.251
+socket: 0.188
+virtual: 0.188
+graphic: 0.188
+boot: 0.176
+x86: 0.173
+TCG: 0.160
+PID: 0.134
+register: 0.129
+permissions: 0.118
+assembly: 0.114
+mistranslation: 0.104
+VMM: 0.100
+user-level: 0.039
+peripherals: 0.017
+kernel: 0.007
+files: 0.005
+KVM: 0.002
+hypervisor: 0.002
+
+Request to add something like "Auth failed from IP" log report for built-in VNC server
diff --git a/results/classifier/118/vnc/1715186 b/results/classifier/118/vnc/1715186
new file mode 100644
index 00000000..4e6e134a
--- /dev/null
+++ b/results/classifier/118/vnc/1715186
@@ -0,0 +1,82 @@
+vnc: 0.970
+socket: 0.959
+debug: 0.934
+performance: 0.839
+network: 0.826
+ppc: 0.797
+VMM: 0.765
+device: 0.760
+graphic: 0.752
+user-level: 0.742
+semantic: 0.732
+kernel: 0.729
+register: 0.717
+risc-v: 0.716
+KVM: 0.673
+hypervisor: 0.660
+arm: 0.643
+PID: 0.608
+architecture: 0.603
+permissions: 0.596
+i386: 0.595
+x86: 0.573
+files: 0.572
+TCG: 0.540
+boot: 0.537
+peripherals: 0.524
+virtual: 0.465
+assembly: 0.398
+mistranslation: 0.376
+
+websockets: Improve error messages 
+
+Since 2.9 / 07e95cd529af345fdeea230913f68eff5b925bb6 , whenever the VNC websocket server finds an error with the incoming connection request, it just closes the socket with no further information.
+
+This makes figuring out what's wrong with the request nearly impossible.
+
+I would be nice if:
+
+* HTTP 400 were returned to the client, with an appropriate error message
+* Maybe something written to the log as well?
+
+Currently, I'm resorting to looking at my request and the websocket source and hoping I can figure out what's wrong.
+
+At very least we should also use 404 if given a invalid path
+
+Will be included  for 2.11 in 
+
+commit 3a3f8705962c8c8a47a9b981ffd5aab7274ad508
+Author: Daniel P. Berrange <email address hidden>
+Date:   Wed Sep 6 11:38:36 2017 +0100
+
+    io: include full error message in websocket handshake trace
+    
+    When the websocket handshake fails it is useful to log the real
+    error message via the trace points for debugging purposes.
+    
+    Fixes bug: #1715186
+    
+    Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
+    Signed-off-by: Daniel P. Berrange <email address hidden>
+
+commit f69a8bde29354493ff8aea64cc9cb3b531d16337
+Author: Daniel P. Berrange <email address hidden>
+Date:   Wed Sep 6 11:33:17 2017 +0100
+
+    io: send proper HTTP response for websocket errors
+    
+    When any error occurs while processing the websockets handshake,
+    QEMU just terminates the connection abruptly. This is in violation
+    of the HTTP specs and does not help the client understand what they
+    did wrong. This is particularly bad when the client gives the wrong
+    path, as a "404 Not Found" would be very helpful.
+    
+    Refactor the handshake code so that it always sends a response to
+    the client unless there was an I/O error.
+    
+    Fixes bug: #1715186
+    
+    Reviewed-by: Philippe Mathieu-Daudé <email address hidden>
+    Signed-off-by: Daniel P. Berrange <email address hidden>
+
+
diff --git a/results/classifier/118/vnc/1732671 b/results/classifier/118/vnc/1732671
new file mode 100644
index 00000000..1a68ba3a
--- /dev/null
+++ b/results/classifier/118/vnc/1732671
@@ -0,0 +1,48 @@
+vnc: 0.964
+network: 0.888
+socket: 0.871
+device: 0.785
+virtual: 0.775
+mistranslation: 0.768
+semantic: 0.682
+graphic: 0.678
+architecture: 0.632
+register: 0.594
+performance: 0.575
+files: 0.509
+ppc: 0.507
+user-level: 0.479
+risc-v: 0.458
+kernel: 0.456
+hypervisor: 0.452
+permissions: 0.434
+PID: 0.434
+VMM: 0.421
+debug: 0.381
+KVM: 0.378
+boot: 0.365
+peripherals: 0.356
+TCG: 0.354
+assembly: 0.299
+arm: 0.292
+i386: 0.254
+x86: 0.215
+
+vnc websocket compatibility issue
+
+WebSocket support in VNC should allow access from VNC client through upgraded WebSocket connection. This feature is not working in IE 11/Edge with noVNC HTML5 client, in contrast to that in Firefox/Safari, etc.
+
+The reason that IE 11/Edge fails to accept the connection upgrade is that the value equality of the `Upgrade` header field is checked in a strict case-sensitive manner in QEMU side, however, the IE/Edge does not send the exactly same string value `websocket` but a capital letter `W` instead.
+
+Defined in section 4.2.1 of rfc6455, the upgrade header field shall be treated case-insensitively.
+
+A patch shall be made in `io/channel-websock.c`, converting the value of upgrade string to lowercase before comparison is made with QIO_CHANNEL_WEBSOCK_UPGRADE_WEBSOCKET, to allow case-insensitive comparison in the process.
+
+Which version of QEMU did you test this against ?  It should be fixed in current GIT master AFAIK
+
+I think it should have been fixed in 33badfd.
+
+Sorry for the noise.
+
+No problem, it is a valid bug report, since we've not actually released the fix yet, so changing status.
+
diff --git a/results/classifier/118/vnc/1752646 b/results/classifier/118/vnc/1752646
new file mode 100644
index 00000000..524a64c0
--- /dev/null
+++ b/results/classifier/118/vnc/1752646
@@ -0,0 +1,58 @@
+vnc: 0.938
+graphic: 0.866
+performance: 0.815
+device: 0.814
+network: 0.790
+register: 0.722
+kernel: 0.715
+architecture: 0.678
+files: 0.677
+semantic: 0.668
+mistranslation: 0.660
+peripherals: 0.640
+permissions: 0.601
+ppc: 0.594
+user-level: 0.506
+risc-v: 0.493
+PID: 0.490
+virtual: 0.439
+debug: 0.421
+boot: 0.413
+TCG: 0.411
+socket: 0.387
+i386: 0.374
+VMM: 0.342
+x86: 0.326
+hypervisor: 0.319
+arm: 0.318
+assembly: 0.273
+KVM: 0.131
+
+Freezing VNC screen on some the UEFI framebuffer applications
+
+Hi folks!
+
+I use TianCore (UEFI) formware on the qemu (master version last commit a6e0344).
+When kernel/linux is start, it using UEFI Framebuffer. Then I run UEFI application (which writes directly to the framebuffer) my VNS screen is freezing. Then I restart vnclient I see only one frame.
+
+When I run application, I getting in the file hw/display/vga.c on function 'vga_ioport_write' some commands, it change "s->ar_index" from 0x20 -> 0x10 
+
+In the function vga_update_display:
+1751         if (!(s->ar_index & 0x20)) {
+1752             graphic_mode = GMODE_BLANK;
+1753         } else {
+
+And I got GMODE_BLANK mode. If I patch it:
+1751         if (0) {
+
+my VNC not freezing.
+
+From "Hardware Level VGA and SVGA Video Programming Information Page" I saw, what ar_index is 0x3C0 (Attribute Controller Data Write Register), 0x20(5-bit) is PAS -- Palette Address Source
+
+If there is a output via the UEFI framebuffer, does the difference have a PAS or not? Why do we need to pause the output if the PAS is exposed? Especially when the application outputs via framebuffer.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1795100 b/results/classifier/118/vnc/1795100
new file mode 100644
index 00000000..3853e52b
--- /dev/null
+++ b/results/classifier/118/vnc/1795100
@@ -0,0 +1,79 @@
+vnc: 0.920
+x86: 0.905
+socket: 0.895
+graphic: 0.768
+network: 0.731
+user-level: 0.719
+device: 0.633
+performance: 0.625
+ppc: 0.622
+semantic: 0.609
+architecture: 0.607
+mistranslation: 0.586
+PID: 0.512
+files: 0.487
+risc-v: 0.483
+register: 0.452
+permissions: 0.447
+virtual: 0.426
+boot: 0.396
+arm: 0.382
+kernel: 0.365
+i386: 0.356
+debug: 0.288
+TCG: 0.263
+KVM: 0.191
+assembly: 0.133
+peripherals: 0.124
+hypervisor: 0.111
+VMM: 0.077
+
+VNC unix-domain socket unlink()ed prematurely
+
+With qemu 3.0.0 (I don't believe this happened with previous
+versions), if I tell it `-vnc unix:/path/to/vnc.sock`, qemu will
+unlink() that file when the first client disconnects, meaning that
+once I disconnect, I can't ever reconnect without restarting the VM.
+
+A stupid testcase demonstrating the issue:
+
+In terminal A:
+
+    $ qemu-system-x86_64 -vnc unix:$PWD/vnc.sock
+
+In terminal B:
+
+    $ ls vnc.sock
+    vnc.sock
+    $ socat STDIO UNIX-CONNECT:vnc.sock <<<''
+    RFB 003.008
+    $ ls vnc.sock
+    ls: cannot access 'vnc.sock': No such file or directory
+
+I have determined that the offending unlink() call is the one in
+io/channel-socket.c:qio_channel_socket_close().  That call was first
+introduced in commit d66f78e1eaa832f73c771d9df1b606fe75d52a50, which
+first appeared in version 3.0.0.
+
+This type of premature unlink() does not happen on monitor.sock with
+`-monitor unix:/path/to/monitor.sock,server,nowait`.
+
+I am not familiar enough with the QIO subsystem to suggest a fix that
+fixes VNC, but preserves the QMP fix targeted in the offending commit.
+
+This is still a problem with 3.1.0.
+
+Added Daniel to the bug.
+
+It only affects VNC, not chardevs because the chardevs fail to call qio_channel_close() and just rely on finalize() cleaning up the open socket. To fix this we just need to made the code conditional on it being a listener socket
+
+  if (qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_LISTEN)) {
+   ...
+  }
+
+Patch proposed at
+
+https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02774.html
+
+Fix merged to git master  https://git.qemu.org/?p=qemu.git;a=commit;h=feff02089113839d233e40a9bd7134241de12d1d
+
diff --git a/results/classifier/118/vnc/1802465 b/results/classifier/118/vnc/1802465
new file mode 100644
index 00000000..93f69679
--- /dev/null
+++ b/results/classifier/118/vnc/1802465
@@ -0,0 +1,97 @@
+vnc: 0.903
+KVM: 0.902
+virtual: 0.890
+mistranslation: 0.887
+x86: 0.841
+performance: 0.839
+device: 0.805
+files: 0.777
+user-level: 0.746
+boot: 0.712
+hypervisor: 0.706
+semantic: 0.694
+ppc: 0.647
+architecture: 0.558
+graphic: 0.553
+permissions: 0.524
+VMM: 0.521
+network: 0.496
+socket: 0.453
+PID: 0.422
+risc-v: 0.396
+debug: 0.392
+peripherals: 0.385
+kernel: 0.353
+register: 0.346
+TCG: 0.343
+arm: 0.326
+i386: 0.226
+assembly: 0.222
+
+typing string via VNC is unreliable
+
+QEMU version is 3.0.0
+
+# Description
+
+The problem is that, when typing string through VNC, it can be unreliable -- sometimes some key strokes get skipped, sometimes get swapped, sometimes get repeated.  There's no problem when typing through VNC on physical hardware.
+
+# Steps to reproduce
+
+1. Launch virtual machine by:
+
+    qemu-kvm -display vnc=:1 -m 2048 opensuse-leap-15.qcow2
+
+2. Connect to VNC by:
+
+    vncviewer -Shared :5901
+
+3. Simulate a series of key strokes by "vncdotool" [1]:
+
+    vncdotool -s 127.0.0.1::5901 typefile strings_to_be_typed.txt
+
+4. Usually after a few hundred keys are typed, something goes wrong.
+
+I attached a screenshot that it mistypes " hello" to "h ello".
+
+[1] https://github.com/sibson/vncdotool
+
+
+
+In my case the problem is quite subtle. 
+Nearly every time we send the key strokes, the guest os keeps receiving space or tab or new line character. And ending part of the text is truncated, where the truncated part is fixed depending on the keystrokes we are sending. 
+Additionally, the keystrokes are mis-ordered at a higher frequency than 1 out of a few hundreds as you said. 
+
+In brief,
+- Repeatedly receiving space, tab or new line character as ending
+- Truncation regarding ending part of key strokes
+- characters are mis-ordered, lost, repeated 
+
+A question is, how can you make character transaction faster with vncdotool? In my case, vncdotool is typing fairly slow. 
+
+I found this debian bug report quite useful, what do you think? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758881
+
+Re-producing procedures
+---
+
+I re-produced the problem in a slightly different way since your method seems not working for me. 
+
+> qemu-img create tumbleweed.img 40G
+> qemu-system-x86_64 -drive file=tumbleweed.img,if=virtio -boot d -cdrom openSUSE-Tumbleweed-DVD-x86_64-Snapshot20181119-Media.iso -m 2048 --enable-kvm -display vnc=:1
+> qemu-system-x86_64 -drive file=tumbleweed.img,if=virtio  -m 4G --enable-kvm -display vnc=:1
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1806040 b/results/classifier/118/vnc/1806040
new file mode 100644
index 00000000..1b473dbd
--- /dev/null
+++ b/results/classifier/118/vnc/1806040
@@ -0,0 +1,59 @@
+vnc: 0.889
+device: 0.867
+kernel: 0.848
+graphic: 0.841
+virtual: 0.824
+x86: 0.811
+network: 0.782
+ppc: 0.737
+PID: 0.735
+user-level: 0.708
+permissions: 0.701
+files: 0.701
+performance: 0.687
+mistranslation: 0.683
+VMM: 0.681
+hypervisor: 0.675
+architecture: 0.672
+TCG: 0.656
+debug: 0.642
+assembly: 0.637
+semantic: 0.634
+risc-v: 0.621
+peripherals: 0.610
+register: 0.605
+i386: 0.589
+socket: 0.586
+KVM: 0.576
+boot: 0.536
+arm: 0.465
+
+Nested VMX virtualization error on last Qemu versions
+
+Recently updated Qemu on a Sony VAIO sve14ag18m with Ubuntu Bionic 4.15.0-38 from Git
+
+After launching a few VMs, noticed that i could not create Snapshot due to this error:
+"Nested VMX virtualization does not support live migration yet"
+
+I've created a new Windows 7 X64 machine with this compilation of Qemu and the problem persisted, so it's not because of the old machines.
+
+I launch Qemu with this params (I use them for malware analisys adn re...):
+qemu-system-x86_64 -monitor stdio -display none -m 4096 -smp cpus=4 -usbdevice tablet -drive file=VM.img,index=0,media=disk,format=qcow2,cache=unsafe -net nic,macaddr="...." -net bridge,br=br0 -cpu host,-hypervisor,kvm=off -vnc 127.0.0.1:0 -enable-kvm 
+
+
+Deleting the changes made on this commit solved the problem, but I dont have idea what is this for, so... xDD 
+https://github.com/qemu/qemu/commit/d98f26073bebddcd3da0ba1b86c3a34e840c0fb8
+
+Hi,
+
+the kernel you are using should not have nested virtualization enabled by default.  Are you by chance using nested virtualization of some other virtual machines?  If so, it's enough to add "-vmx" at the end of "-cpu host,-hypervisor,kvm=off".
+
+If you are not sure of the answer, please check if your /etc/modprobe.conf file, or any file in your /etc/modprobe.d directory, contains the line "options kvm_intel nested=1".
+
+Thanks!
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/1988 b/results/classifier/118/vnc/1988
new file mode 100644
index 00000000..4bcb6b99
--- /dev/null
+++ b/results/classifier/118/vnc/1988
@@ -0,0 +1,56 @@
+x86: 0.948
+vnc: 0.920
+graphic: 0.901
+network: 0.837
+device: 0.829
+VMM: 0.821
+mistranslation: 0.757
+PID: 0.740
+semantic: 0.714
+files: 0.687
+TCG: 0.686
+ppc: 0.678
+debug: 0.654
+risc-v: 0.636
+virtual: 0.601
+kernel: 0.595
+socket: 0.585
+architecture: 0.578
+i386: 0.548
+arm: 0.536
+register: 0.532
+performance: 0.479
+boot: 0.435
+permissions: 0.433
+peripherals: 0.376
+user-level: 0.328
+hypervisor: 0.308
+assembly: 0.200
+KVM: 0.165
+
+8.2.0rc0 Regression: '-display vnc' opens gtk display as well
+Description of problem:
+A VNC display is requested, but a GTK frontend is opened as well. A VNC client is able to connect.
+Steps to reproduce:
+1. /configure --enable-fdt=internal --target-list=x86_64-softmmu
+2. make 
+3. build/qemu-system-x86_64 -display vnc=:05 -k de
+Additional information:
+git bisect finally shows
+```
+484629fc8141eaa257f961b5e5e310a1bbd0f1a2 is the first bad commit
+commit 484629fc8141eaa257f961b5e5e310a1bbd0f1a2
+Author: Marc-André Lureau <marcandre.lureau@redhat.com>
+Date:   Wed Oct 25 17:21:17 2023 +0400
+
+    vl: simplify display_remote logic
+    
+    Bump the display_remote variable when the -vnc option is parsed, just
+    like -spice.
+    
+    Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Reviewed-by: Thomas Huth <thuth@redhat.com>
+
+ system/vl.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+```
diff --git a/results/classifier/118/vnc/2001 b/results/classifier/118/vnc/2001
new file mode 100644
index 00000000..b6e0d2db
--- /dev/null
+++ b/results/classifier/118/vnc/2001
@@ -0,0 +1,73 @@
+x86: 0.936
+vnc: 0.929
+device: 0.924
+network: 0.880
+hypervisor: 0.879
+boot: 0.877
+kernel: 0.874
+peripherals: 0.846
+architecture: 0.838
+performance: 0.835
+PID: 0.829
+graphic: 0.824
+risc-v: 0.781
+files: 0.776
+TCG: 0.774
+assembly: 0.764
+VMM: 0.754
+ppc: 0.746
+KVM: 0.732
+socket: 0.724
+arm: 0.705
+mistranslation: 0.695
+i386: 0.691
+register: 0.679
+permissions: 0.650
+user-level: 0.646
+debug: 0.592
+virtual: 0.567
+semantic: 0.496
+
+qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster.
+Description of problem:
+qemu_img convert and drive mirror migrate the same raw disk to rbd volume, will get the different USED size in ceph cluster.
+Steps to reproduce:
+create raw and qcow2 disk
+
+1. qemu-img create -f raw lvm_volume_1.raw 12G
+2. qemu-img create -f qcow2 lvm_volume_1.qcow2 12G
+
+   install a centos OS
+
+3. qemu-system-x86_64 -m 4096 -drive file=lvm_volume_1.qcow2,format=qcow2,index=0 -nographic -cdrom CentOS-8.3.2011-x86_64-dvd1.iso -vnc :25
+
+   convert the qcow2 OS disk to q raw OS disk
+
+4. qemu-img convert -f qcow2 -O raw ./lvm_volume_1.qcow2 ./lvm_volume_1.raw
+
+   create a qemu-rbd process
+
+5. qemu-nbd --fork  -x node1 -p 1238 rbd:cephpool- test/volume_1:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx
+
+   boot the raw OS disk
+
+6. qemu-system-x86_64 -hda ./lvm_volume_1.raw -m 4096 -smp 4 -vnc :25 -monitor stdio
+   
+   migrate the raw OS disk to a ceph volume
+
+7. drive_mirror -n  -f #block125 nbd:localhost:1238:exportname=node1 raw
+   
+   check the rbd volume USED size in ceph cluster
+   "rbd du cephpool-test/volume_1"
+   the ceph rbd volume PROVISION and USED are the same size
+
+   convert the raw OS disk to a ceph volume
+
+8. qemu-img convert -n -f raw -O raw ./lvm_volume_1.raw rbd:cephpool- 
+test/volume_2:id=xxx:key=xxx:mon_host=xxx:auth_supported=cephx
+
+   check the rbd volume USED size in ceph cluster 
+   "rbd du cephpool-test/volume_2"
+   the ceph rbd volume PROVISION and USED are different PROVISION > USED
+Additional information:
+
diff --git a/results/classifier/118/vnc/2171 b/results/classifier/118/vnc/2171
new file mode 100644
index 00000000..4e38361b
--- /dev/null
+++ b/results/classifier/118/vnc/2171
@@ -0,0 +1,55 @@
+vnc: 0.961
+ppc: 0.960
+device: 0.954
+graphic: 0.949
+virtual: 0.922
+PID: 0.909
+socket: 0.854
+mistranslation: 0.843
+kernel: 0.828
+risc-v: 0.807
+VMM: 0.799
+semantic: 0.698
+files: 0.694
+debug: 0.677
+performance: 0.645
+boot: 0.644
+architecture: 0.550
+TCG: 0.499
+register: 0.472
+network: 0.457
+arm: 0.443
+KVM: 0.434
+x86: 0.392
+hypervisor: 0.381
+i386: 0.369
+permissions: 0.319
+user-level: 0.168
+assembly: 0.108
+peripherals: 0.057
+
+VPS Disk space over use
+Description of problem:
+\# qemu-img info -U v1001-dluw9EHRDbmMd8fQ-CACjC7FWnMhISeDM.qcow2
+
+file format: qcow2
+
+virtual size: 800G (858993459200 bytes)
+
+disk size: **812G**
+
+cluster_size: 65536
+
+Format specific information:
+
+compat: 1.1
+
+lazy refcounts: false
+
+refcount bits: 16
+
+corrupt: false
+
+Disk size is using beyond the Virtual size.
+
+How is that even possible ?
diff --git a/results/classifier/118/vnc/2311 b/results/classifier/118/vnc/2311
new file mode 100644
index 00000000..c7a46c2b
--- /dev/null
+++ b/results/classifier/118/vnc/2311
@@ -0,0 +1,45 @@
+vnc: 0.874
+graphic: 0.874
+ppc: 0.857
+performance: 0.799
+socket: 0.685
+semantic: 0.658
+network: 0.653
+permissions: 0.643
+device: 0.642
+register: 0.619
+architecture: 0.584
+VMM: 0.580
+kernel: 0.574
+files: 0.492
+peripherals: 0.480
+debug: 0.480
+risc-v: 0.424
+boot: 0.374
+TCG: 0.368
+hypervisor: 0.342
+x86: 0.334
+PID: 0.317
+i386: 0.289
+arm: 0.284
+KVM: 0.248
+mistranslation: 0.231
+assembly: 0.206
+user-level: 0.191
+virtual: 0.145
+
+Possible dereference of NULL
+Description of problem:
+There is possible dereference of NULL using macro QEMU_LOCK_GUARD(&q->lock) in:
+1) /block/nvme.c line [326](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/block/nvme.c#L326)
+2) /include/qemu/ratelimit.h line [45](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L45)
+3) /include/qemu/ratelimit.h line [88](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/ratelimit.h#L88)
+
+
+The QEMU_MAKE_LOCKABLE(x) macro provides a special case (line [71](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L71) of the lockable.h) if NULL gets into it. Then the macro will return NULL, which will get to the input of the qemu_lockable_auto_lock() function, then to the qemu_lockable_lock() function, where NULL dereference will occur (line [95](https://github.com/qemu/qemu/blob/5da72194df36535d773c8bdc951529ecd5e31707/include/qemu/lockable.h#L95)).
+
+It turns out that the NULL case is provided, but not handled properly. I think a NULL check should be added.
+
+Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
+
+Author A. Burke.
diff --git a/results/classifier/118/vnc/2490 b/results/classifier/118/vnc/2490
new file mode 100644
index 00000000..15d6d906
--- /dev/null
+++ b/results/classifier/118/vnc/2490
@@ -0,0 +1,81 @@
+vnc: 0.824
+user-level: 0.818
+graphic: 0.813
+hypervisor: 0.800
+risc-v: 0.798
+boot: 0.794
+device: 0.783
+performance: 0.779
+peripherals: 0.777
+architecture: 0.776
+x86: 0.775
+register: 0.773
+PID: 0.770
+permissions: 0.752
+KVM: 0.750
+socket: 0.749
+VMM: 0.744
+debug: 0.743
+semantic: 0.726
+ppc: 0.720
+i386: 0.717
+network: 0.701
+assembly: 0.684
+mistranslation: 0.670
+files: 0.668
+kernel: 0.653
+virtual: 0.632
+arm: 0.603
+TCG: 0.597
+
+Windows: virtio-vga-gl no longer works with current virglrenderer version
+Description of problem:
+Error occurs, when executing QEMU with virtio-vga-gl device using current virglrenderer:
+First the boot screen is shown as expected.
+After a short while the screen shows and keeps showing "virtio-vga-gl: Display output is not active."
+Console logs:
+```
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+qemu: GtkGLArea console lacks DMABUF support.
+Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden
+Realize gdk gl context failed: GL-Kontext kann nicht erstellt werden
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+virtio_gpu_virgl_process_cmd: ctrl 0x103, error 0x1203
+```
+Steps to reproduce:
+1. Prepare current Msys2/Ucrt64 environment including virglrenderer 1.0.1 by installing QEMU as described in https://www.qemu.org/download/#windows
+2. `wget https://download.opensuse.org/distribution/leap/15.3/live/openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso`
+3. `qemu-system-x86_64.exe -m 1024 -display gtk,gl=on -device virtio-vga-gl -cdrom openSUSE-Leap-15.3-GNOME-Live-x86_64-Media.iso`
+Additional information:
+virglrenderer may use certain D3D features starting with virglrenderer 1.0.0, see https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1103 for details
+
+Given virglrenderer >= 1.0.0, QEMU activates these D3D features since https://gitlab.com/qemu-project/qemu/-/commit/c1600f84ce011a056c9c432c8ad8d77f7f8b9e6f.
+
+But the current QEMU implementation is broken when using these D3D features. 
+
+git bisect finishes with:
+```
+574b64aa6754ba491f51024c5a823a674d48a658 is the first bad commit
+commit 574b64aa6754ba491f51024c5a823a674d48a658
+Author: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+Date:   Mon Jan 29 10:39:21 2024 +0300
+
+    virtio-gpu: Correct virgl_renderer_resource_get_info() error check
+
+    virgl_renderer_resource_get_info() returns errno and not -1 on error.
+    Correct the return-value check.
+
+    Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
+    Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
+    Message-Id: <20240129073921.446869-1-dmitry.osipenko@collabora.com>
+    Cc: qemu-stable@nongnu.org
+    Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
+    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+
+ contrib/vhost-user-gpu/virgl.c | 6 +++---
+ hw/display/virtio-gpu-virgl.c  | 2 +-
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+```
diff --git a/results/classifier/118/vnc/2492 b/results/classifier/118/vnc/2492
new file mode 100644
index 00000000..fffe929d
--- /dev/null
+++ b/results/classifier/118/vnc/2492
@@ -0,0 +1,50 @@
+vnc: 0.973
+device: 0.852
+network: 0.803
+architecture: 0.786
+PID: 0.785
+graphic: 0.730
+ppc: 0.722
+socket: 0.711
+semantic: 0.657
+debug: 0.639
+arm: 0.600
+register: 0.574
+performance: 0.524
+files: 0.506
+mistranslation: 0.488
+risc-v: 0.479
+permissions: 0.467
+kernel: 0.461
+user-level: 0.449
+VMM: 0.405
+i386: 0.387
+hypervisor: 0.361
+x86: 0.351
+TCG: 0.338
+boot: 0.334
+peripherals: 0.331
+virtual: 0.210
+assembly: 0.167
+KVM: 0.026
+
+Unable to disable gvnc dependency during build
+Description of problem:
+The qtest tests will pick up a copy of gvnc if it happens to be installed and there does not appear
+to be any way of disabling the dependency to ensure a reproducible build. We tripped over this in
+bulk builds on OpenBSD.
+Steps to reproduce:
+1. Install gvnc
+2. Build QEMU
+Additional information:
+From tests/qtest/meson.build
+
+```
+if vnc.found()
+  gvnc = dependency('gvnc-1.0', method: 'pkg-config', required: false)
+  if gvnc.found()
+    qtests += {'vnc-display-test': [gvnc]}
+    qtests_generic += [ 'vnc-display-test' ]
+  endif
+endif
+```
diff --git a/results/classifier/118/vnc/2608 b/results/classifier/118/vnc/2608
new file mode 100644
index 00000000..bb4305ce
--- /dev/null
+++ b/results/classifier/118/vnc/2608
@@ -0,0 +1,39 @@
+vnc: 0.981
+network: 0.972
+device: 0.925
+graphic: 0.895
+virtual: 0.837
+performance: 0.789
+boot: 0.707
+semantic: 0.641
+socket: 0.579
+debug: 0.577
+register: 0.546
+user-level: 0.499
+PID: 0.443
+risc-v: 0.333
+peripherals: 0.325
+arm: 0.314
+mistranslation: 0.312
+assembly: 0.276
+permissions: 0.249
+files: 0.210
+VMM: 0.172
+architecture: 0.152
+x86: 0.139
+kernel: 0.132
+ppc: 0.113
+TCG: 0.086
+hypervisor: 0.039
+i386: 0.017
+KVM: 0.007
+
+Black screen in Windows XP
+Description of problem:
+When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again.
+
+This problem never happened on 9.0.1 and below, so is a regression in 9.1.0
+Steps to reproduce:
+1. Start the Windows XP installer
+2. Connect to VNC
+3. Screen stays black
diff --git a/results/classifier/118/vnc/2646 b/results/classifier/118/vnc/2646
new file mode 100644
index 00000000..b20ce846
--- /dev/null
+++ b/results/classifier/118/vnc/2646
@@ -0,0 +1,55 @@
+x86: 0.971
+architecture: 0.942
+vnc: 0.923
+device: 0.919
+boot: 0.840
+ppc: 0.839
+kernel: 0.816
+PID: 0.812
+permissions: 0.810
+performance: 0.764
+hypervisor: 0.743
+files: 0.695
+mistranslation: 0.683
+peripherals: 0.682
+socket: 0.680
+graphic: 0.668
+register: 0.647
+user-level: 0.637
+TCG: 0.610
+semantic: 0.594
+VMM: 0.565
+risc-v: 0.563
+network: 0.536
+debug: 0.488
+i386: 0.444
+arm: 0.412
+KVM: 0.382
+virtual: 0.379
+assembly: 0.321
+
+osx 10.6.8 guest on x86-64 macos 10.12 host can't boot on HVF, boots on tcg
+Description of problem:
+for some reason HVF acceleration does not work with mac-on-mac. Haiku beta5 (x64), win10 x64, Debian netinstall 12.7.0 - all works.
+Steps to reproduce:
+```
+1. get 10.6.8 image from archive.org
+2. bin/qemu-system-x86_64 -device isa-applesmc,osk="well_known_string" -usb -M pc-q35-2.11 -device usb-kbd -device usb-tablet -m 1536 -smp 1 -cpu Penryn,vendor=GenuineIntel,+ssse3,+sse4.1,+sse4.2 -L /opt/local/share/qemu -device ac97 -vnc :3 --no-reboot -accel hvf  -boot c  -bios usr/share/edk2-ovmf-x64/OVMF_CODE.fd -hda osx-10.6-xcode-compressed-efi.qcow2 -d unimp
+audio: Could not create a backend for voice `ac97.pi'
+audio: Could not create a backend for voice `ac97.mc'
+audio: Could not create a backend for voice `ac97.pi'
+audio: Could not create a backend for voice `ac97.mc'
+ahci: IRQ#0 level:1
+ahci: IRQ#0 level:1
+
+{many more of those}
+```
+and at this point qemu quits. 
+
+without --no-reboot it reboots
+
+tried both UEFI boot (using https://github.com/khronokernel/khronokernel.github.io/blob/master/Binaries/OpenCore/EFI-LEGACY.img.zip?raw=true , currently integrated into hdd image) and Clover-5160-X64.iso 
+
+if I remove -accel hvf and replace it with accel tcg guest boots.
+
+i tried to capture moment when it reboots on video but I can't catch anything :(
diff --git a/results/classifier/118/vnc/351 b/results/classifier/118/vnc/351
new file mode 100644
index 00000000..8e56bcfa
--- /dev/null
+++ b/results/classifier/118/vnc/351
@@ -0,0 +1,31 @@
+vnc: 0.949
+mistranslation: 0.935
+virtual: 0.837
+performance: 0.740
+peripherals: 0.712
+device: 0.685
+debug: 0.628
+network: 0.450
+user-level: 0.407
+graphic: 0.266
+semantic: 0.219
+boot: 0.168
+risc-v: 0.109
+register: 0.080
+ppc: 0.065
+KVM: 0.063
+VMM: 0.056
+TCG: 0.056
+PID: 0.046
+permissions: 0.028
+assembly: 0.019
+i386: 0.017
+arm: 0.007
+kernel: 0.006
+socket: 0.005
+files: 0.005
+hypervisor: 0.003
+x86: 0.001
+architecture: 0.001
+
+German keyboard vnc issue
diff --git a/results/classifier/118/vnc/759 b/results/classifier/118/vnc/759
new file mode 100644
index 00000000..4951bce4
--- /dev/null
+++ b/results/classifier/118/vnc/759
@@ -0,0 +1,42 @@
+vnc: 0.947
+graphic: 0.889
+device: 0.874
+network: 0.863
+x86: 0.853
+virtual: 0.727
+performance: 0.704
+semantic: 0.683
+permissions: 0.683
+PID: 0.537
+mistranslation: 0.524
+peripherals: 0.439
+risc-v: 0.437
+architecture: 0.436
+i386: 0.412
+files: 0.408
+register: 0.405
+boot: 0.359
+user-level: 0.339
+arm: 0.335
+debug: 0.312
+socket: 0.286
+VMM: 0.279
+KVM: 0.254
+ppc: 0.249
+TCG: 0.182
+hypervisor: 0.155
+assembly: 0.126
+kernel: 0.070
+
+Copy&Paste does not work on VNC
+Description of problem:
+Cannot copy&paste between host and guest when vnc is used (gtk works fine).
+Steps to reproduce:
+1. Build qemu 6.2-rc2 using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-fuse --enable-fuse-lseek
+```
+2. Run the above qemu command using vnc server. Connect to the VM desktop using `vncviewer :5900` where vncviewer is downloaded from [here](https://www.realvnc.com/en/connect/download/viewer/).
+3. Try to copy and paste something in the terminal between host and guest. It doesn't work.
+Additional information:
+I'm following [this article](https://www.kraxel.org/blog/2021/05/qemu-cut-paste/) which says copy&paste is supported on vnc.
diff --git a/results/classifier/118/vnc/772 b/results/classifier/118/vnc/772
new file mode 100644
index 00000000..9b7dfee4
--- /dev/null
+++ b/results/classifier/118/vnc/772
@@ -0,0 +1,42 @@
+x86: 0.965
+vnc: 0.939
+virtual: 0.939
+graphic: 0.910
+device: 0.881
+KVM: 0.875
+permissions: 0.832
+semantic: 0.808
+architecture: 0.776
+ppc: 0.764
+VMM: 0.764
+PID: 0.741
+risc-v: 0.680
+boot: 0.680
+register: 0.672
+files: 0.669
+debug: 0.663
+hypervisor: 0.639
+performance: 0.639
+peripherals: 0.631
+socket: 0.586
+i386: 0.560
+network: 0.546
+assembly: 0.533
+mistranslation: 0.530
+kernel: 0.501
+TCG: 0.474
+arm: 0.429
+user-level: 0.373
+
+Pop!_OS 20.10 host + RHEL 8.5 guest = Oh no! Something has gone wrong.
+Description of problem:
+Whenever starting the Qemu VM, there is an error covering the whole desktop "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again." After clicking the "Log Out" button and waiting for hours, the guest RHEL may or may not recover, based on your luck and other qemu options used.
+Steps to reproduce:
+1. Build qemu using the following `./configure` options:
+```
+--prefix=$HOME/.bin --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-vte --enable-xkbcommon --enable-sdl --enable-spice --enable-spice-protocol --enable-virglrenderer --enable-opengl --enable-guest-agent --enable-avx2 --enable-avx512f --enable-hax --enable-system --enable-linux-user --enable-libssh --enable-linux-aio --enable-linux-io-uring --enable-modules --enable-gio --enable-fuse --enable-fuse-lseek
+```
+2. Install Red Hat Enterprise Linux 8.5 in qemu
+3. Run qemu using the above command line.
+Additional information:
+![image](/uploads/6ccb8dabb1022b548975e63b389a037a/image.png)
diff --git a/results/classifier/118/vnc/779 b/results/classifier/118/vnc/779
new file mode 100644
index 00000000..6eee9914
--- /dev/null
+++ b/results/classifier/118/vnc/779
@@ -0,0 +1,43 @@
+vnc: 0.961
+socket: 0.953
+network: 0.919
+graphic: 0.868
+virtual: 0.847
+device: 0.841
+debug: 0.704
+mistranslation: 0.667
+boot: 0.638
+VMM: 0.591
+PID: 0.585
+semantic: 0.578
+risc-v: 0.569
+performance: 0.506
+KVM: 0.494
+register: 0.484
+TCG: 0.404
+arm: 0.344
+kernel: 0.340
+permissions: 0.313
+ppc: 0.282
+i386: 0.256
+architecture: 0.256
+user-level: 0.246
+x86: 0.191
+hypervisor: 0.185
+peripherals: 0.130
+files: 0.107
+assembly: 0.056
+
+VNC server not work
+Description of problem:
+I've created a sandbox guest with kata containers. The VM started successfully, but vnc server not listen unix socket.
+
+`root@bootstrap02:~# netstat -anp | grep 1989153`  
+`unix  3      [ ]         STREAM     CONNECTED     369610592 1989153/qemu-system  /run/vc/vm/bash/qmp.sock`  
+`root@bootstrap02:~# lsof -p 1989153 | grep unix`  
+`qemu-syst 1989153 root  108u     unix 0xffff912740d3b800        0t0  369610592 /run/vc/vm/bash/qmp.sock type=STREAM`
+Steps to reproduce:
+1.Create Linux sandbox guest VM  
+2.connect vnc server
+Additional information:
+
diff --git a/results/classifier/118/vnc/824074 b/results/classifier/118/vnc/824074
new file mode 100644
index 00000000..b6b643fa
--- /dev/null
+++ b/results/classifier/118/vnc/824074
@@ -0,0 +1,41 @@
+vnc: 0.981
+network: 0.767
+graphic: 0.760
+device: 0.756
+risc-v: 0.603
+mistranslation: 0.526
+socket: 0.484
+architecture: 0.464
+register: 0.454
+peripherals: 0.448
+VMM: 0.438
+i386: 0.419
+semantic: 0.413
+performance: 0.394
+kernel: 0.391
+arm: 0.365
+x86: 0.344
+hypervisor: 0.280
+ppc: 0.269
+boot: 0.261
+debug: 0.260
+PID: 0.251
+TCG: 0.248
+files: 0.240
+user-level: 0.223
+virtual: 0.219
+permissions: 0.200
+KVM: 0.146
+assembly: 0.111
+
+Provide runtime option to expose the supported list of keymaps for vnc
+
+As discussed in the ganeti group[1], I'm opening this bug to request that qemu provides a runtime command or switch to list the supported keymaps for vnc.
+
+ [1] - http://groups.google.com/group/ganeti/browse_thread/thread/dd524f5311d8d79e
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/974229 b/results/classifier/118/vnc/974229
new file mode 100644
index 00000000..10ef6729
--- /dev/null
+++ b/results/classifier/118/vnc/974229
@@ -0,0 +1,157 @@
+vnc: 0.917
+permissions: 0.903
+debug: 0.899
+ppc: 0.893
+graphic: 0.886
+semantic: 0.875
+register: 0.875
+PID: 0.870
+KVM: 0.864
+device: 0.841
+performance: 0.836
+peripherals: 0.827
+hypervisor: 0.822
+assembly: 0.808
+architecture: 0.790
+user-level: 0.775
+mistranslation: 0.768
+VMM: 0.767
+risc-v: 0.760
+kernel: 0.740
+virtual: 0.740
+TCG: 0.723
+network: 0.713
+arm: 0.710
+socket: 0.654
+boot: 0.654
+files: 0.629
+x86: 0.535
+i386: 0.330
+
+qemu-kvm-1.0: segfault using vnc-console => not threadsafe!
+
+after failure using qemu-kvm-0.14.1 I've tried v1.0, but there's a problem if compiled with vnc-thread-support:
+
+Program received signal SIGSEGV, Segmentation fault.
+0x0000000000000000 in ?? ()
+(gdb) bt
+#0  0x0000000000000000 in ?? ()
+#1  0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3)
+    at iohandler.c:124
+#2  0x00007f3ac4964387 in main_loop_wait (nonblocking=0) at main-loop.c:463
+#3  0x00007f3ac4958fb1 in main_loop () at /opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:1482
+#4  0x00007f3ac495e1ec in main (argc=68, argv=0x7fff1237a088, envp=0x7fff1237a2b0)
+    at /opt/workspace/oneiric64/qemu-kvm-1.0/vl.c:3523
+(gdb) up
+#1  0x00007f3ac48ca10a in qemu_iohandler_poll (readfds=0x7fff12379ac0, writefds=0x7fff12379b40, xfds=0x7fff12379bc0, ret=3)
+    at iohandler.c:124
+124	                ioh->fd_write(ioh->opaque);
+
+(gdb) print *ioh
+$4 = {fd = 29, fd_read_poll = 0, fd_read = 0x7f3ac49de158 <vnc_client_read>, fd_write = 0, deleted = 0, 
+  opaque = 0x7f3ac7978d50, next = {le_next = 0x7f3ac6add2e0, le_prev = 0x7f3ac52bde90}}
+
+
+ok, how could that happen?
+loooking deeper at the code and backtraces shows, that iohandler.c:124 is called within the main-loop, while iohandler.c:77 is called within the vnc-thread-loop
+
+mmmh, but where the hell is the threadsafe-locking of the ioh-structure????
+
+I didn't found anything...
+
+the resetting in line 77 is called from vnc_client_write_plain(), where following code can be found:
+
+===================
+   if (vs->output.offset == 0) {
+        qemu_set_fd_handler2(vs->csock, NULL, vnc_client_read, NULL, vs);
+    }
+===================
+
+why should the function-ptrs should be zeroed?
+
+further tracing shows, that the vnc-thread sometimes seems to exits normally and a new one is started (I haven't verified that), but this would be a reason for zeroing function-ptrs, which may point to code inside the thread, which will exit...
+
+but why should this be done? and why there's no threadsafe-modification of the structure?
+
+well: disabling vnc-thread at configure-state leads into a normal running machine, but threading would be nice here...
+
+so a quick fix could be, to drop the call above and make the vnc-thread staying for the whole session, but I don't know all mechanisms of vnc-support within kvm.
+but a better solution would be usage of clean locking-mechanisms
+
+Thanks for reporting this bug.
+
+Since vnc-thread-support is not compiled into the qemu-kvm package, the bug is invalid there.  I will mark it as affecting the upstream QEMU project.   Note you'll want to use git://git.qemu.org/qemu.git as the upstream code base.
+
+puh, it did take a while, but meanwhile another segfault has occured, which has nothing to do with the above one. due to the long time, it took to happen, it might not be as reproducible as needed for efficient debugging, at least I've currently no further time for this. I'll now try V0.15.1 and hope, it will work well for me.
+
+some gdb-info of the current segfault, if there's someone, who want to have a look at:
+
+Program received signal SIGSEGV, Segmentation fault.
+[Switching to Thread 0x7fe086c46700 (LWP 30362)]
+0x00007fe08c0639fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+
+(gdb) thread apply all bt
+
+Thread 6 (Thread 0x7fdfa2ecf700 (LWP 30793)):
+#0  0x00007fe08c3963cb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+#1  0x00007fe08f581c79 in cond_timedwait (cond=0x7fe08fed6b20, mutex=0x7fe08fed6ae0, ts=0x7fdfa2ecee10)
+    at posix-aio-compat.c:104
+#2  0x00007fe08f5823f0 in aio_thread (unused=0x0) at posix-aio-compat.c:334
+#3  0x00007fe08c391efc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
+#4  0x00007fe08c0cc59d in __cmsg_nxthdr () from /lib/x86_64-linux-gnu/libc.so.6
+#5  0x0000000000000000 in ?? ()
+
+Thread 5 (Thread 0x7fe087648700 (LWP 30361)):
+#0  0x00007fe08c399a73 in pwrite64 () from /lib/x86_64-linux-gnu/libpthread.so.0
+#1  0x00007fe08f58201f in handle_aiocb_rw_linear (aiocb=0x7fe093c98e50, 
+    buf=0x7fe093e05600 "\004\063\377\211t$\b\213\064$\213\034\272G\205\333\017\204\246") at posix-aio-compat.c:216
+#2  0x00007fe08f58212d in handle_aiocb_rw (aiocb=0x7fe093c98e50) at posix-aio-compat.c:251
+#3  0x00007fe08f582573 in aio_thread (unused=0x0) at posix-aio-compat.c:362
+#4  0x00007fe08c391efc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
+#5  0x00007fe08c0cc59d in __cmsg_nxthdr () from /lib/x86_64-linux-gnu/libc.so.6
+#6  0x0000000000000000 in ?? ()
+
+Thread 4 (Thread 0x7fe086c46700 (LWP 30362)):
+#0  0x00007fe08c0639fc in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+#1  0x00007fe08c3851c0 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
+#2  0x00007fe086c45990 in ?? ()
+#3  0x00007fe08c39bc20 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0
+#4  0x00007fe086c469c0 in ?? ()
+#5  0x0000000000000000 in ?? ()
+
+Thread 3 (Thread 0x7fe086445700 (LWP 30363)):
+#0  0x00007fe08c0c4747 in getmntent_r () from /lib/x86_64-linux-gnu/libc.so.6
+#1  0x0000000000000000 in ?? ()
+
+Thread 2 (Thread 0x7fdfa36d0700 (LWP 30388)):
+#0  0x00007fe08c3963cb in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
+#1  0x00007fe08f581c79 in cond_timedwait (cond=0x7fe08fed6b20, mutex=0x7fe08fed6ae0, ts=0x7fdfa36cfe10)
+    at posix-aio-compat.c:104
+#2  0x00007fe08f5823f0 in aio_thread (unused=0x0) at posix-aio-compat.c:334
+#3  0x00007fe08c391efc in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
+#4  0x00007fe08c0cc59d in __cmsg_nxthdr () from /lib/x86_64-linux-gnu/libc.so.6
+#5  0x0000000000000000 in ?? ()
+
+Thread 1 (Thread 0x7fe08f3cd7a0 (LWP 30158)):
+#0  0x00007fe08c0c5613 in getttyent () from /lib/x86_64-linux-gnu/libc.so.6
+#1  0x00000000000f4140 in ?? ()
+#2  0x00007fff62c7e3d0 in ?? ()
+#3  0x0000001d8f675e5c in ?? ()
+#4  0x00000000000003e8 in ?? ()
+#5  0x0000000062c7e3c0 in ?? ()
+#6  0x0000000062c7e440 in ?? ()
+#7  0x0000000162c7e4c0 in ?? ()
+#8  0x000000003c080980 in ?? ()
+#9  0x0000000000000000 in ?? ()
+(gdb) 
+
+all done on a ubuntu-11.10 64bit, last configure-options were:
+'./configure' '--target-list=x86_64-softmmu i386-softmmu x86_64-linux-user i386-linux-user' '--prefix=/usr' '--interp-prefix=/etc/qemu-binfmt/%M' '--disable-blobs' '--disable-strip' '--audio-drv-list=pa,alsa,sdl,oss' '--enable-vnc-sasl' '--enable-docs' '--enable-vhost-net' '--enable-attr'  '--enable-linux-aio' '--enable-uuid' '--enable-nptl' '--enable-kvm-device-assignment' '--enable-kvm-pit' '--enable-kvm' '--enable-curses' '--enable-vnc-png' '--enable-vnc-tls' '--audio-card-list=ac97,es1370,sb16,cs4231a,adlib,gus,hda' '--enable-user' '--enable-system' '--enable-linux-user' '--enable-bsd-user' '--enable-guest-base' '--enable-darwin-user' --enable-debug
+
+the segfault occures while installing a larger app within winxp+sp3 near the possible end of setup
+
+
+The QEMU versions mentioned in this ticket are quite old already ... can you still reproduce this with the latest version of QEMU? If so, please also provide the exact command line parameters that you used to start QEMU, and the steps you took afterwards to get to the crash? Thanks!
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/vnc/981 b/results/classifier/118/vnc/981
new file mode 100644
index 00000000..74e54395
--- /dev/null
+++ b/results/classifier/118/vnc/981
@@ -0,0 +1,40 @@
+vnc: 0.925
+graphic: 0.899
+socket: 0.878
+network: 0.797
+device: 0.770
+mistranslation: 0.714
+x86: 0.678
+architecture: 0.558
+semantic: 0.500
+debug: 0.323
+PID: 0.203
+performance: 0.183
+boot: 0.178
+ppc: 0.164
+files: 0.140
+permissions: 0.131
+user-level: 0.098
+i386: 0.098
+TCG: 0.091
+register: 0.085
+virtual: 0.067
+arm: 0.061
+risc-v: 0.061
+VMM: 0.045
+peripherals: 0.034
+hypervisor: 0.022
+assembly: 0.012
+kernel: 0.009
+KVM: 0.005
+
+VNC UNIX sockets are not deleted
+Description of problem:
+After exiting QEMU a unix VNC socket file is left behind. Upon termination I would expect it to remove the socket file like it does for example with a monitor unix socket.
+Steps to reproduce:
+```
+   rm -f foo.socket
+   qemu-system-x86_64 -vnc unix:foo.socket
+   # Exit QEMU
+   ls foo.socket
+   ```
author	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:00 +0000
committer	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:33 +0000
commit	9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree	b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/vnc
parent	b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download	emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz emulator-bug-study-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip