diff options
Diffstat (limited to 'results/classifier/gemma3:12b/vnc')
74 files changed, 2021 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/vnc/1087974 b/results/classifier/gemma3:12b/vnc/1087974 new file mode 100644 index 00000000..3331111b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1087974 @@ -0,0 +1,5 @@ + +[regression] vnc tight png produces garbled output + +VNC Tight PNG compression did work fine two or three month ago but don't anymore. Now when Tight PNG is used parts of the desktop are shown but they are scrambled together. +I have always tested this feature against QEMU git with noVNC by only allowing Tight PNG compression. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1089005 b/results/classifier/gemma3:12b/vnc/1089005 new file mode 100644 index 00000000..f8155ec6 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1089005 @@ -0,0 +1,21 @@ + +Qemu does not shutdown with vnc enabled on OS X + +I am running OS X 10.8.2 and Qemu 1.3.50 from your git repository. + +Running + + qemu-system-i386 <image> + +works fine. I can quit the process using ctrl-c. + +When I try to use + + qemu-system-i386 -vnc :<port> <image> + +ctrl-c does nothing and I have to kill the process trough the activity monitor. +Furthermore terminating the process from my java program does not work either. +I have also posted a question on Stackoverflow: http://stackoverflow.com/questions/13798367/qemu-does-not-shutdown-with-vnc-enabled-on-os-x + +Thanks +Leander \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1089496 b/results/classifier/gemma3:12b/vnc/1089496 new file mode 100644 index 00000000..9ffd6bd7 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1089496 @@ -0,0 +1,61 @@ + +qemu doesn't set vnc port correctly + +Qemu Version: 1.1.1 + +In the past it was possible to set the port for vnc with: +-vnc :1 +That would mean the port would be 5901, Starting from 5900 plus the given number. However, it was also possible to set the port directly with a custom given port. Usually i set the port to something like 5801. With qemu-1.1.1 (and maybe prior versions too, i usually use spice) that's not possible anymore. For example: +-vnc 192.168.1.1:5804 +Here the 'real' port would be 11704 (that's 5900 + 5804). I'm sure that worked correctly in the past and i'm pretty sure it's easy to fix. + +Would be nice if we can fix that. + +System Info: +Portage 2.1.11.31 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r3, 3.5.7-gentoo x86_64) +================================================================= +System uname: Linux-3.5.7-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1 +Timestamp of tree: Wed, 12 Dec 2012 05:15:01 +0000 +ld GNU ld (GNU Binutils) 2.22 +app-shells/bash: 4.2_p37 +dev-lang/python: 2.7.3-r2, 3.2.3 +dev-util/cmake: 2.8.9 +dev-util/pkgconfig: 0.27.1 +sys-apps/baselayout: 2.1-r1 +sys-apps/openrc: 0.11.8 +sys-apps/sandbox: 2.5 +sys-devel/autoconf: 2.68 +sys-devel/automake: 1.11.6 +sys-devel/binutils: 2.22-r1 +sys-devel/gcc: 4.5.4 +sys-devel/gcc-config: 1.7.3 +sys-devel/libtool: 2.4-r1 +sys-devel/make: 3.82-r3 +sys-kernel/linux-headers: 3.6 (virtual/os-headers) +sys-libs/glibc: 2.15-r3 +Repositories: gentoo x-local x11 sunrise virtualization +ACCEPT_KEYWORDS="amd64" +ACCEPT_LICENSE="* -@EULA" +CBUILD="x86_64-pc-linux-gnu" +CFLAGS="-O2 -pipe -march=native -fopenmp" +CHOST="x86_64-pc-linux-gnu" +CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" +CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" +CXXFLAGS="-O2 -pipe -march=native -fopenmp" +DISTDIR="/usr/portage/distfiles" +FCFLAGS="-O2 -pipe" +FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" +FFLAGS="-O2 -pipe" +GENTOO_MIRRORS=" http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ http://gentoo.mirror.web4u.cz/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.ynet.sk/pub" +LANG="de_DE.utf8" +LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp" +MAKEOPTS="-j12" +PKGDIR="/usr/portage/packages" +PORTAGE_CONFIGROOT="/" +PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" +PORTAGE_TMPDIR="/var/tmp" +PORTDIR="/usr/portage" +PORTDIR_OVERLAY="/mnt/data/public/overlays/local /mnt/data/public/overlays/layman/x11 /mnt/data/public/overlays/layman/sunrise /mnt/data/public/overlays/layman/virtualization" +SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/" +USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="i386 x86_64 mips arm ppc ppc64" QEMU_USER_TARGETS="i386 x86_64 mips arm ppc ppc64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" +Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1099403 b/results/classifier/gemma3:12b/vnc/1099403 new file mode 100644 index 00000000..5bcf6b38 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1099403 @@ -0,0 +1,10 @@ + +High CPU utilization in vnc mode + +We start a gentoo guest using ./x86-64-softmmu/qemu-x86-64 -hda <disk>.qcow2 -vnc :6. + +Then we start a vncviewer session to this guest from a remote computer. In this session, we start a video. After starting the video, the CPU utilization of the guest (the qemu-x86-64 process) increases to about 90%. The high CPU utilization persists even after closing the vncviewer session. + +However, the CPU usage while running a video inside a gentoo guest (without a remote computer connecting via vncviewer) is only 20-30%. So we suspect the high CPU usage to be due to the vncserver code running inside QEMU which has to do a lot of work to send the framebuffer updates to the client. + +My question is why does the usage not decrease when the remote vncviewer is disconnected? On simple computers (no virtual guests), the CPU usage of vncserver decreases drastically when the vncviewer client is disconnected. Why does this not happen in the vncserver provided by QEMU (through -vnc :6). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1158 b/results/classifier/gemma3:12b/vnc/1158 new file mode 100644 index 00000000..cc635463 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1158 @@ -0,0 +1,2 @@ + +Error in setting VNC password diff --git a/results/classifier/gemma3:12b/vnc/1162227 b/results/classifier/gemma3:12b/vnc/1162227 new file mode 100644 index 00000000..6a030f02 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1162227 @@ -0,0 +1,17 @@ + +Mouse works badly when connecting to host via vnc + +Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. +Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. + +I saw this bug in the following configurations: +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow +* A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: +qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda +* A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: +qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow + +Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". + +Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1339 b/results/classifier/gemma3:12b/vnc/1339 new file mode 100644 index 00000000..778d5dbc --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1339 @@ -0,0 +1,17 @@ + +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/gemma3:12b/vnc/1388735 b/results/classifier/gemma3:12b/vnc/1388735 new file mode 100644 index 00000000..4828e574 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1388735 @@ -0,0 +1,12 @@ + +QEMU no longer allows to use full TCP port range for VNC + +After upgrade to QEMU version 2.1.0 (Debian 2.1+dfsg-4ubuntu6), I am no longer able to use any TCP port for VNC display. +For example, if I need to assign VNC server a TCP port 443, I used to run: +# qemu-system-x86_64 -vnc :-5457 +qemu-system-x86_64: Failed to start VNC server on `:-1000': can't convert to a number:-5457 +expected behavior: as any VNC software, take port base of 5900, substract 5457 display number, and use TCP port 443 + +I ask to change vnc port conversion routine to allow input values in range of all TCP ports, from 1 to 65535. + +I really depend on ability to use full TCP range for VNC port numbers, and inablity to do so in new version of QEMU is very disappointing. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1414222 b/results/classifier/gemma3:12b/vnc/1414222 new file mode 100644 index 00000000..3741f982 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1414222 @@ -0,0 +1,21 @@ + +qemu-system-i386: -vnc localhost:0,to=99,id=default: Invalid parameter 'to' + +git-bisect pints to: + +4db14629c38611061fc19ec6927405923de84f08 is the first bad commit +commit 4db14629c38611061fc19ec6927405923de84f08 +Author: Gerd Hoffmann <email address hidden> +Date: Tue Sep 16 12:33:03 2014 +0200 + + vnc: switch to QemuOpts, allow multiple servers + + This patch switches vnc over to QemuOpts, and it (more or less + as side effect) allows multiple vnc server instances. + + Signed-off-by: Gerd Hoffmann <email address hidden> + +:040000 040000 70020c79b463eaff4b91c8c7f985240d1d1914f0 354a3a125e7b82a1699ce4e0cfc5055662bd3466 M include +:100644 100644 0b4f131936052ed6062ba4b2b9434da0c2cce959 963305c26917a930f37d916df66b319d6558d281 M qmp.c +:040000 040000 e7933d52124ae48100893eed8e14cbe46f80b936 30fa5966f5c8362d6db6730a7091bbde7780d4d8 M ui +:100644 100644 9fb32c13df1c14daf8304184c6503d16bff7afce 983259bc9f7064b446da358a316a31a31731a223 M vl.c \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1453608 b/results/classifier/gemma3:12b/vnc/1453608 new file mode 100644 index 00000000..196e6852 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1453608 @@ -0,0 +1,6 @@ + +explain what pcsys_monitor in manpage + +The specification of vnc passwords seems to have changed. `man qemu-system-x86_64` mentions `set_password` to be used in `pcsys_monitor`. Both are are not further mentioned in the man page and misteriously inexisting in both the web and the source root (as far as `grep -r -I 'pcsys_monitor' .` is concerned). That's too vage to be usable. + +experienced with 2.3.0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1453612 b/results/classifier/gemma3:12b/vnc/1453612 new file mode 100644 index 00000000..df7b8757 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1453612 @@ -0,0 +1,6 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1455912 b/results/classifier/gemma3:12b/vnc/1455912 new file mode 100644 index 00000000..528a5e29 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1455912 @@ -0,0 +1,12 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1484925 b/results/classifier/gemma3:12b/vnc/1484925 new file mode 100644 index 00000000..80cbd436 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1484925 @@ -0,0 +1,25 @@ + +Segfault with custom vnc client + +Hey, + +I'm using Citrix XenServer 6.5. I worte a script that uses noVNC to connect to the rfb console via xapi. When I use GRML and try to boot it, the QEMU process segfaults and kills my VM. This happens when the screen resizes and the kernel is loading: + +recvfrom(3, "\3\1\0\0\0\0\2\200\1\220\3\0\2\200\0\0\0P\1\220", 4096, 0, NULL, NULL) = 20 +--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb28000} --- + +I can see in the child process the following message, right before the parent Segfaults: +read(4, "cirrus: blanking the screen line_offset=0 height=480\n", 53) = 53 + +This issue only happens, when I have my custom php/novnc-client connected. I also tried the nodejs/novnc package from xen-orchestra - same result. Using the stock client from Citrix XenCenter it works just fine. So I think it is related to noVNC. I hope this is just a bug and not exploitable to force a VM to crash or execute code. + +XenServer launches the qemu with the following command line: + +qemu-dm-25 --syslog -d 25 -m 2048 -boot dc -serial pty -vcpus 1 -videoram 4 -vncunused -k en-us -vnc 127.0.0.1:1 -usb -usbdevice tablet -net nic,vlan=0,macaddr=8a:43:e2:b1:57:df,model=rtl8139 -net tap,vlan=0,bridge=xenbr0,ifname=tap25.0 -acpi -monitor pty + +XenServer 6.5 is using the following version: +# /usr/lib64/xen/bin/qemu-dm -help +QEMU PC emulator version 0.10.2, Copyright (c) 2003-2008 Fabrice Bellard + +Greetings +Uli Stärk \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1486278 b/results/classifier/gemma3:12b/vnc/1486278 new file mode 100644 index 00000000..c0632d7c --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1486278 @@ -0,0 +1,18 @@ + +'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 +.... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1502884 b/results/classifier/gemma3:12b/vnc/1502884 new file mode 100644 index 00000000..0c43728a --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1502884 @@ -0,0 +1,15 @@ + +Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option! + +Hi, + +A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM. + +This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous. + +This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not. + + +For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client. + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1548 b/results/classifier/gemma3:12b/vnc/1548 new file mode 100644 index 00000000..1718db82 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1548 @@ -0,0 +1,39 @@ + +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/gemma3:12b/vnc/1583784 b/results/classifier/gemma3:12b/vnc/1583784 new file mode 100644 index 00000000..4acb73f2 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1583784 @@ -0,0 +1,21 @@ + +qio_task_free segfault websocket + +When connecting with websocket and tls to a vnc-ws port I get segfault + +==15252== Process terminating with default action of signal 11 (SIGSEGV): dumping core +==15252== Access not within mapped region at address 0x0 +==15252== at 0x1: ??? +==15252== by 0x56E1E2: qio_task_free (task.c:58) +==15252== by 0x56E42B: qio_task_complete (task.c:145) +==15252== by 0x56DBB8: qio_channel_websock_handshake_send (channel-websock.c:289) +==15252== by 0x7B3F689: g_main_dispatch (gmain.c:3154) +==15252== by 0x7B3F689: g_main_context_dispatch (gmain.c:3769) +==15252== by 0x50D42A: glib_pollfds_poll (main-loop.c:213) +==15252== by 0x50D42A: os_host_main_loop_wait (main-loop.c:258) +==15252== by 0x50D42A: main_loop_wait (main-loop.c:506) +==15252== by 0x28A8D1: main_loop (vl.c:1934) +==15252== by 0x28A8D1: main (vl.c:4656) + +qemu 2.6.0 +linux x64 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1586194 b/results/classifier/gemma3:12b/vnc/1586194 new file mode 100644 index 00000000..14c2b020 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1586194 @@ -0,0 +1,47 @@ + +VNC reverse broken in qemu 2.6.0 + +Hi all, + +I recently tried to upgrade from Qemu 2.4.1 to 2.6.0, but found some problems with VNC reverse connections. + +1) In "-vnc 172.16.1.3:5902,reverse" used to mean "connect to port 5902" + That seems to have changed changed since 2.4.1, the thing after the IP address is now interpreted + as a display number. If that change was intentional, the man-page needs to be fixed. + +2) After subtracting 5900 from that port number (-vnc 172.16.1.3:2,reverse), I ran into a segfault. + +---8<--- +Program received signal SIGSEGV, Segmentation fault. +qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +33 return socket_sockaddr_to_address(&ioc->localAddr, +(gdb) bt +#0 qio_channel_socket_get_local_address (ioc=0x0, errp=errp@entry=0x7fffffffe118) at io/channel-socket.c:33 +#1 0x000055555594c0f5 in vnc_init_basic_info_from_server_addr (errp=0x7fffffffe118, info=0x555558f35990, + ioc=<optimized out>) at ui/vnc.c:146 +#2 vnc_server_info_get (vd=0x7fffecc4b010) at ui/vnc.c:223 +#3 0x000055555595192a in vnc_qmp_event (vs=0x555558f41f30, vs=0x555558f41f30, event=QAPI_EVENT_VNC_CONNECTED) + at ui/vnc.c:279 +#4 vnc_connect (vd=vd@entry=0x7fffecc4b010, sioc=sioc@entry=0x555558f34c00, skipauth=skipauth@entry=false, + websocket=websocket@entry=false) at ui/vnc.c:2994 +#5 0x00005555559520d8 in vnc_display_open (id=id@entry=0x555556437650 "default", errp=errp@entry=0x7fffffffe228) + at ui/vnc.c:3773 +#6 0x0000555555952fd3 in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, errp=<optimized out>) + at ui/vnc.c:3868 +#7 0x0000555555a011da in qemu_opts_foreach (list=<optimized out>, func=0x555555952fa0 <vnc_init_func>, opaque=0x0, + errp=0x0) at util/qemu-option.c:1116 +#8 0x00005555556dcfbe in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4592 +--->8--- + +A git bisect shows that this happens since + +---8<--- +commit 98481bfcd661daa3c160cc87a297b0e60a307788 +Author: Eric Blake <email address hidden> +Date: Mon Oct 26 16:34:45 2015 -0600 + + vnc: Hoist allocation of VncBasicInfo to callers +--->8--- + +TIA + Andi \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1589272 b/results/classifier/gemma3:12b/vnc/1589272 new file mode 100644 index 00000000..800036de --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1589272 @@ -0,0 +1,81 @@ + +qemu-system-x86_64: There is no option group 'vnc' + +build qemu from git (6b3532b20b787cbd697a68b383232f5c3b39bd1e) + +with this options: + +./configure \ + --python=/usr/bin/python2 \ + --prefix=/usr \ + --sysconfdir=/etc \ + --localstatedir=/var \ + --libexecdir=/usr/lib/qemu \ + --target-list=i386-softmmu,x86_64-softmmu,i386-linux-user,x86_64-linux-user \ + --audio-drv-list='pa alsa' \ + --enable-linux-aio \ + --enable-seccomp \ + --enable-tpm \ + --enable-modules \ + --disable-sdl \ + --disable-gtk \ + --disable-spice \ + --disable-rbd \ + --disable-libiscsi \ + --disable-libnfs \ + --disable-smartcard \ + --disable-glusterfs \ + --disable-docs \ + --disable-vnc{,-sasl,-jpeg,-png} \ + --disable-guest-agent + +i get: + +└───╼ qemu-system-x86_64 +qemu-system-x86_64: There is no option group 'vnc' +Segment Fault (core dumped) + +└───╼ coredumpctl info 12932 + PID: 12932 (qemu-system-x86) + UID: 1000 (sl1pkn07) + GID: 100 (users) + Signal: 11 (SEGV) + Timestamp: dom 2016-06-05 18:05:51 CEST (17s ago) + Command Line: qemu-system-x86_64 + Executable: /usr/bin/qemu-system-x86_64 + Control Group: /user.slice/user-1000.slice/session-c1.scope + Unit: session-c1.scope + Slice: user-1000.slice + Session: c1 + Owner UID: 1000 (sl1pkn07) + Boot ID: 5b205159fa6b4c25946fad7087bd366f + Machine ID: c20ee0c57658685bfedf50384b0e3ec0 + Hostname: sL1pKn07 + Coredump: /var/lib/systemd/coredump/core.qemu-system-x86.1000.5b205159fa6b4c25946fad7087bd366f.12932.1465142751000000000000.lz4 + Message: Process 12932 (qemu-system-x86) of user 1000 dumped core. + + Stack trace of thread 12932: + #0 0x000055b269c2e245 qemu_opts_foreach (qemu-system-x86_64) + #1 0x000055b2698fb6b5 main (qemu-system-x86_64) + #2 0x00007fafc4e5a741 __libc_start_main (libc.so.6) + #3 0x000055b269900eb9 _start (qemu-system-x86_64) + + Stack trace of thread 12934: + #0 0x00007fafc51e80af pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) + #1 0x000055b269c21b19 qemu_cond_wait (qemu-system-x86_64) + #2 0x000055b26992bff4 qemu_tcg_cpu_thread_fn (qemu-system-x86_64) + #3 0x00007fafc51e2484 start_thread (libpthread.so.0) + #4 0x00007fafc4f216dd __clone (libc.so.6) + + Stack trace of thread 12933: + #0 0x00007fafc51eaebc __lll_lock_wait (libpthread.so.0) + #1 0x00007fafc51e4b45 pthread_mutex_lock (libpthread.so.0) + #2 0x000055b269c21a39 qemu_mutex_lock (qemu-system-x86_64) + #3 0x000055b26992bf51 qemu_mutex_lock_iothread (qemu-system-x86_64) + #4 0x000055b269c30430 call_rcu_thread (qemu-system-x86_64) + #5 0x00007fafc51e2484 start_thread (libpthread.so.0) + #6 0x00007fafc4f216dd __clone (libc.so.6) + +builded with GCC 6.1.1 + +greetings \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1589923 b/results/classifier/gemma3:12b/vnc/1589923 new file mode 100644 index 00000000..75ed9793 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1589923 @@ -0,0 +1,91 @@ + +https websockets not working in 2.5 or 2.6 + +% gdb --args ./x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 + +GNU gdb (GDB) 7.11 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-pc-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from ./x86_64-softmmu/qemu-system-x86_64...done. +(gdb) run +Starting program: /home/ben/qemu/qemu-2.6.0/x86_64-softmmu/qemu-system-x86_64 -vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +[New Thread 0x7fffe16f6700 (LWP 12767)] +[New Thread 0x7fffde2d4700 (LWP 12768)] +[New Thread 0x7fffd3fff700 (LWP 12769)] +Initializing VNC server with x509 no auth +Client sioc=0x55555874d6b0 ws=1 auth=1 subauth=0 +New client on socket 0x55555874d6b0 +vnc_set_share_mode/0x55555874d6b0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +Handshake failed TLS handshake failed: The TLS connection was non-properly terminated. +Closing down client sock: protocol error +vnc_set_share_mode/0x55555779f510: connecting -> disconnected +Client sioc=0x55555873c6a0 ws=1 auth=1 subauth=0 +New client on socket 0x55555873c6a0 +vnc_set_share_mode/0x55555873c6a0: undefined -> connecting +TLS Websocket connection required +Start TLS WS handshake process +TLS handshake complete, starting websocket handshake +Websocket negotiate starting +Websock handshake complete, starting VNC protocol +Write Plain: Pending output 0x555557b91c60 size 4096 offset 12. Wait SSF 0 +Wrote wire 0x555557b91c60 12 -> 12 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +0x0000000000000001 in ?? () +(gdb) thread apply all bt + +Thread 4 (Thread 0x7fffd3fff700 (LWP 12769)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=cond@entry=0x5555587267e0, + mutex=mutex@entry=0x555558726810) at util/qemu-thread-posix.c:123 +#2 0x00005555559770ab in vnc_worker_thread_loop (queue=queue@entry=0x5555587267e0) + at ui/vnc-jobs.c:228 +#3 0x00005555559775e8 in vnc_worker_thread (arg=0x5555587267e0) at ui/vnc-jobs.c:335 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 3 (Thread 0x7fffde2d4700 (LWP 12768)): +#0 0x00007fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a20bd9 in qemu_cond_wait (cond=<optimized out>, +---Type <return> to continue, or q <return> to quit--- + emu_global_mutex>) at util/qemu-thread-posix.c:123 +#2 0x0000555555715edf in qemu_tcg_wait_io_event (cpu=0x5555564ee840) at /home/ben/qemu/qemu-2.6.0/cpus.c:1015 +#3 qemu_tcg_cpu_thread_fn (arg=<optimized out>) at /home/ben/qemu/qemu-2.6.0/cpus.c:1161 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7fffe16f6700 (LWP 12767)): +#0 0x00007fffea438229 in syscall () from /usr/lib/libc.so.6 +#1 0x0000555555a20ee8 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=ev@entry=0x55555641ece4 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000555555a2f2ae in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250 +#4 0x00007fffef354474 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007fffea43c69d in clone () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7ffff7f5bb00 (LWP 12763)): +#0 0x0000000000000001 in ?? () +#1 0x00005555559efb53 in qio_task_free (task=0x555558212140) at io/task.c:58 +#2 0x00005555559efd89 in qio_task_complete (task=task@entry=0x555558212140) at io/task.c:145 +#3 0x00005555559ef5aa in qio_channel_websock_handshake_send (ioc=0x55555873c6a0, condition=<optimized out>, + user_data=0x555558212140) at io/channel-websock.c:289 +#4 0x00007fffecf59c8a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#5 0x000055555598a6b3 in glib_pollfds_poll () at main-loop.c:213 +#6 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258 +#7 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 +#8 0x00005555556e1fbd in main_loop () at vl.c:1934 +#9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4656 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1594861 b/results/classifier/gemma3:12b/vnc/1594861 new file mode 100644 index 00000000..f827ac70 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1594861 @@ -0,0 +1,329 @@ + +QEMU crashes when slow VNC client disconnects + +QEMU (at least 2.6.0 and today's git origin/master 6f1d2d1c5ad20d464705b17318cb7ca495f8078a) crashes when a slow VNC client disconnects during a time of busy VNC updates, with: +qemu_mutex_lock: Invalid argument + +This is easily repeatable: + - Start up a QEMU with the Finnix 1.10 CD-ROM, as below + - vnclient host:0 -shared (remote X11-based vnc client, to make it "slow") + - On the Finnix command line, run: "while :; do ls -laRC /; done" to generate screen updates + - Close the vncclient + - QEMU crashes on locking an already free'd mutex (note that the VNC state's share_mode is DISCONNECTED) + + + +# gdb qemu-system-x86_64 +GNU gdb (GDB) 7.11.1 +Copyright (C) 2016 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. Type "show copying" +and "show warranty" for details. +This GDB was configured as "x86_64-pc-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<http://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: +<http://www.gnu.org/software/gdb/documentation/>. +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from qemu-system-x86_64...done. +(gdb) run -cdrom finnix-110.iso -m 1G -vga cirrus -usbdevice tablet -net nic,model=e1000 -net user -rtc base=localtime,clock=host -enable-kvm -vnc :0,share=ignore -monitor stdio +Starting program: qemu-system-x86_64 -cdrom finnix-110.iso -m 1G -vga cirrus -usbdevice tablet -net nic,model=e1000 -net user -rtc base=localtime,clock=host -enable-kvm -vnc :0,share=ignore -monitor stdio +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/usr/lib/libthread_db.so.1". +[New Thread 0x7ffff1ca2700 (LWP 25717)] +Failed to initialize module: /usr/lib/qemu/block-dmg.so +Note: only modules from the same build can be loaded. +[New Thread 0x7ffff129d700 (LWP 25718)] +QEMU 2.6.50 monitor - type 'help' for more information +(qemu) [New Thread 0x7ffff08ba700 (LWP 25719)] +[New Thread 0x7fffaabff700 (LWP 25721)] +[Thread 0x7ffff129d700 (LWP 25718) exited] +[New Thread 0x7ffff129d700 (LWP 25724)] +[Thread 0x7ffff129d700 (LWP 25724) exited] +[New Thread 0x7ffff129d700 (LWP 25728)] +qemu: qemu_mutex_lock: Invalid argument + +Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted. +0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +(gdb) thread apply all backtrace + +Thread 7 (Thread 0x7ffff129d700 (LWP 25728)): +#0 0x00007ffff634b5f5 in do_futex_wait () from /usr/lib/libpthread.so.0 +#1 0x00007ffff634b6bf in __new_sem_wait_slow () from /usr/lib/libpthread.so.0 +#2 0x00007ffff634b772 in sem_timedwait () from /usr/lib/libpthread.so.0 +#3 0x0000555555a7fcb7 in qemu_sem_timedwait (sem=sem@entry=0x555556518c38, ms=ms@entry=10000) + at util/qemu-thread-posix.c:245 +#4 0x00005555559f281c in worker_thread (opaque=0x555556518bd0) at thread-pool.c:92 +#5 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#6 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 5 (Thread 0x7fffaabff700 (LWP 25721)): +#0 0x00007ffff634903f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 +#1 0x0000555555a7fb69 in qemu_cond_wait (cond=cond@entry=0x555556541790, mutex=mutex@entry=0x5555565417c0) + at util/qemu-thread-posix.c:123 +#2 0x00005555559ecb4b in vnc_worker_thread_loop (queue=queue@entry=0x555556541790) at ui/vnc-jobs.c:228 +#3 0x00005555559ed088 in vnc_worker_thread (arg=0x555556541790) at ui/vnc-jobs.c:335 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 4 (Thread 0x7ffff08ba700 (LWP 25719)): +#0 0x00007ffff4979277 in ioctl () from /usr/lib/libc.so.6 +#1 0x00005555557d3484 in kvm_vcpu_ioctl (cpu=cpu@entry=0x55555651f2d0, type=type@entry=44672) + at kvm-all.c:2057 +#2 0x00005555557d353d in kvm_cpu_exec (cpu=cpu@entry=0x55555651f2d0) + at kvm-all.c:1907 +#3 0x00005555557c1ea4 in qemu_kvm_cpu_thread_fn (arg=0x55555651f2d0) + at cpus.c:1078 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 2 (Thread 0x7ffff1ca2700 (LWP 25717)): +#0 0x00007ffff497c7f9 in syscall () from /usr/lib/libc.so.6 +#1 0x0000555555a7fe75 in futex_wait (val=<optimized out>, ev=<optimized out>) at util/qemu-thread-posix.c:292 +#2 qemu_event_wait (ev=ev@entry=0x55555646bb64 <rcu_call_ready_event>) at util/qemu-thread-posix.c:399 +#3 0x0000555555a8e26e in call_rcu_thread (opaque=<optimized out>) at util/rcu.c:250 +#4 0x00007ffff6343424 in start_thread () from /usr/lib/libpthread.so.0 +#5 0x00007ffff4980cbd in clone () from /usr/lib/libc.so.6 + +Thread 1 (Thread 0x7ffff7f94a80 (LWP 25713)): +#0 0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +#1 0x00007ffff48cd72a in abort () from /usr/lib/libc.so.6 +#2 0x000055555579290b in error_exit (err=<optimized out>, + msg=msg@entry=0x555555b59d30 <__func__.14707> "qemu_mutex_lock") at util/qemu-thread-posix.c:39 +#3 0x0000555555a7faa0 in qemu_mutex_lock (mutex=mutex@entry=0x555556566568) at util/qemu-thread-posix.c:66 +#4 0x00005555559da91f in vnc_lock_output (vs=0x55555655a320) at ui/vnc-jobs.h:62 +#5 vnc_client_write (vs=0x55555655a320) at ui/vnc.c:1361 +#6 vnc_client_io (ioc=<optimized out>, condition=<optimized out>, opaque=0x55555655a320) at ui/vnc.c:1483 +#7 0x00007ffff53a6dba in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 +#8 0x00005555559fa6eb in glib_pollfds_poll () at main-loop.c:213 +#9 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:258 +#10 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 +#11 0x00005555557974a4 in main_loop () at vl.c:1925 +#12 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4628 +(gdb) thread 1 +[Switching to thread 1 (Thread 0x7ffff7f94a80 (LWP 25713))] +#0 0x00007ffff48cc2a8 in raise () from /usr/lib/libc.so.6 +(gdb) frame 5 +#5 vnc_client_write (vs=0x55555655a320) at ui/vnc.c:1361 +1361 vnc_lock_output(vs); +(gdb) set max-value-size 80000 +(gdb) print *vs +$1 = {sioc = 0x555557b1da40, ioc = 0x555557998790, ioc_tag = 0, disconnecting = 0, dirty = {{0, 0, 0}, {0, 0, 0}, { + 1055221925019647, 0, 0}, {1055221925019647, 0, 0}, {773781307523071, 0, 0}, {1125899906842623, 0, 0}, { + 1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {1125899906842623, 0, 0}, { + 1125899906842623, 0, 0}, {1125899906842623, 0, 0}, {71193947300417, 0, 0}, {71193947300433, 0, 0}, { + 71193947300417, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1319379593592831, 0, 0}, {1319379593592831, 0, 0}, { + 1319379593592831, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, { + 2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, {2251799813685247, 0, 0}, { + 106275268473665, 0, 0}, {115071496237889, 0, 0}, {106275268473665, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 381680068419649535, 0, 0}, {381680068419649535, 0, 0}, {309622474381721599, 0, 0}, {576460752303423487, 0, 0}, { + 576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {576460752303423487, 0, 0}, { + 576460752303423487, 0, 0}, {576460752303423487, 0, 0}, {106194469454161, 0, 0}, {36285762154894705, 0, 0}, { + 106194469454161, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {307370399690129407, 0, 0}, {307370399690129407, 0, 0}, + {307370399690129407, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 55615324492583, 0, 0}, {36225287405246247, 0, 0}, {55615324492583, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 451468244688044031, 0, 0}, {451468244688044031, 0, 0}, {451468244688044031, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {569705352862367743, 0, 0}, { + 569705352862367743, 0, 0}, {569705352862367743, 0, 0}, {55546325181303, 0, 0}, {36154780942280567, 0, 0}, { + 55546325181303, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {3406691643129069567, 0, 0}, {3406691643129069567, 0, + 0}, {3406691643129069567, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, + 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, { + 4607182418800017407, 0, 0}, {432929977792532287, 0, 0}, {541438925046353727, 0, 0}, {432929977792532287, 0, 0}, { + 0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {2831620673523154943, 0, 0}, {2831620673523154943, 0, 0}, {2831620673523154943, + 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, { + 4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, 0}, {4607182418800017407, 0, + 0}, {721827755353776959, 0, 0}, {830336702607599423, 0, 0}, {721827755353776959, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 0, 0, 0}, {1543608686381891327, 0, 0}, {1543608686381891327, 0, 0}, {1543045736428470271, 0, 0}, { + 4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, + 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {721970826084188599, + 0, 0}, {253878283546232247, 0, 0}, {145510073780765111, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 1517695344798859263, 0, 0}, {1517695344798859263, 0, 0}, {1515461137171218431, 0, 0}, {4580160821035794431, 0, + 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, + 0, 0}, {4580160821035794431, 0, 0}, {4580160821035794431, 0, 0}, {226043368113417, 0, 0}, {72565387932009739, 0, + 0}, {226043368113417, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1522216674051227647, 0, 0}, {1522216674051227647, + 0, 0}, {1517713074423857151, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, { + 2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, 0}, {2278821411449470975, 0, + 0}, {2278821411449470975, 0, 0}, {638357209941807, 0, 0}, {73127235220875119, 0, 0}, {638357209941807, 0, 0}, { + 0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {1873497444986126335, 0, 0}, {1873497444986126335, 0, 0}, {1873497376266649599, + 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, { + 4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, 0}, {4611686018427387903, 0, + 0}, {36244873060242763, 0, 0}, {115366073929258319, 0, 0}, {36244873060242763, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, + 0, 0}, {1125899872482361343, 0, 0}, {1125899872482361343, 0, 0}, {1125899735043407871, 0, 0}, { + 2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, + 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {2305843009213693951, 0, 0}, {325521969941073283, + 0, 0}, {397861314371603915, 0, 0}, {325521969941073283, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, { + 1121396238495776767, 0, 0}, {1121396238495776767, 0, 0}, {1121396307215253503, 0, 0}, {1143914305352105983, 0, + 0}, {1143914305352105983, 0, 0}, {1143914305352105983, 0, 0}...}, lossy_rect = 0x555557b1da50, + vd = 0x5555585000a0, need_update = 1, force_update = 0, has_dirty = 192431, features = 723, absolute = 1, + last_x = 512, last_y = 384, last_bmask = 0, client_width = 1024, client_height = 768, + share_mode = VNC_SHARE_MODE_DISCONNECTED, vnc_encoding = 7, major = 3, minor = 8, auth = 1, subauth = 0, + challenge = '\000' <repeats 15 times>, tls = 0x0, encode_ws = false, websocket = false, info = 0x555557976a30, + output = {name = 0x0, capacity = 0, offset = 0, avg_size = 4194304, buffer = 0x0}, input = {name = 0x0, + capacity = 0, offset = 0, avg_size = 524288, buffer = 0x0}, write_pixels = 0x5555559daae0 <vnc_write_pixels_copy>, + client_pf = {bits_per_pixel = 32 ' ', bytes_per_pixel = 4 '\004', depth = 24 '\030', rmask = 16711680, + gmask = 65280, bmask = 255, amask = 0, rshift = 16 '\020', gshift = 8 '\b', bshift = 0 '\000', ashift = 24 '\030', + rmax = 255 '\377', gmax = 255 '\377', bmax = 255 '\377', amax = 0 '\000', rbits = 8 '\b', gbits = 8 '\b', + bbits = 8 '\b', abits = 0 '\000'}, client_format = 0, client_be = false, audio_cap = 0x0, as = {freq = 44100, + nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler = 0x5555559dbdc0 <protocol_client_msg>, + read_handler_expect = 1, modifiers_state = '\000' <repeats 255 times>, led = 0x5555572f5c40, abort = false, + initialized = true, output_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, + __kind = -1, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, + __size = '\000' <repeats 16 times>, "\377\377\377\377", '\000' <repeats 19 times>, __align = 0}}, + bh = 0x555557929d00, jobs_buffer = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, tight = { + type = 7, quality = 255 '\377', compression = 9 '\t', pixel24 = 1 '\001', tight = {name = 0x0, capacity = 0, + offset = 0, avg_size = 1890052, buffer = 0x0}, tmp = {name = 0x7fff9c0d3830 "vnc-worker-output", + capacity = 32768, offset = 26162, avg_size = 4194304, buffer = 0x555557786540 "\330R\303\364\377\177"}, zlib = { + name = 0x0, capacity = 0, offset = 0, avg_size = 524288, buffer = 0x0}, gradient = {name = 0x0, capacity = 0, + offset = 0, avg_size = 0, buffer = 0x0}, jpeg = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, + buffer = 0x0}, png = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, levels = {9, 9, 9, 0}, + stream = {{next_in = 0x7fff9c1341f0 "", avail_in = 0, total_in = 282144, + next_out = 0x7fff9c0640fd "\256\022\352]\002\210n\021rg\b\271\v\204\334\361\001", avail_out = 4083, + total_out = 40323, msg = 0x0, state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, + zfree = 0x5555559deb50 <vnc_zlib_zfree>, opaque = 0x7fffaabec3f0, data_type = 0, adler = 1422910222, + reserved = 0}, {next_in = 0x7fff9c134210 "", avail_in = 0, total_in = 3212411, + next_out = 0x7fff9c0640f9 "\377\235&\344\256\022\352]\002\210n\021rg\b\271\v\204\334\361\001", + avail_out = 4087, total_out = 1563572, msg = 0x0, state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, + zfree = 0x5555559deb50 <vnc_zlib_zfree>, opaque = 0x7fffaabec3f0, data_type = 0, adler = 2665424950, + reserved = 0}, {next_in = 0x7fff9c134440 "", avail_in = 0, total_in = 1057759, + next_out = 0x7fff9c064148 ">E\025\322fI \220\262\320\322\024", avail_out = 4008, total_out = 83411, msg = 0x0, + state = 0x0, zalloc = 0x5555559deb40 <vnc_zlib_zalloc>, zfree = 0x5555559deb50 <vnc_zlib_zfree>, + opaque = 0x7fffaabec3f0, data_type = 0, adler = 3032660148, reserved = 0}, {next_in = 0x0, avail_in = 0, + total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0x0, zfree = 0x0, + opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}}, zlib = {zlib = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, tmp = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, stream = { + next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, + zalloc = 0x0, zfree = 0x0, opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, level = 0}, hextile = { + send_tile = 0x5555559df670 <send_hextile_tile_32>}, zrle = {type = 0, fb = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, zrle = {name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, tmp = { + name = 0x0, capacity = 0, offset = 0, avg_size = 0, buffer = 0x0}, zlib = {name = 0x0, capacity = 0, offset = 0, + avg_size = 0, buffer = 0x0}, stream = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, + total_out = 0, msg = 0x0, state = 0x0, zalloc = 0x0, zfree = 0x0, opaque = 0x0, data_type = 0, adler = 0, + reserved = 0}, palette = {pool = {{idx = 0, color = 0, next = {le_next = 0x0, + le_prev = 0x0}} <repeats 256 times>}, size = 0, max = 0, bpp = 0, table = {{ + lh_first = 0x0} <repeats 256 times>}}}, zywrle = {buf = {0 <repeats 4096 times>}}, mouse_mode_notifier = { + notify = 0x5555559db450 <check_pointer_type_change>, node = {le_next = 0x0, + le_prev = 0x5555560586f8 <mouse_mode_notifiers>}}, next = {tqe_next = 0x0, tqe_prev = 0x5555585000a0}} + + + +QEMU build config: + +Install prefix /usr +BIOS directory /usr/share/qemu +binary directory /usr/bin +library directory /usr/lib +module directory /usr/lib/qemu +libexec directory /usr/lib/qemu +include directory /usr/include +config directory /etc +local state directory /var +Manual directory /usr/share/man +ELF interp prefix /usr/gnemul/qemu-%M +Source path /home/me/build/qemu/src/qemu-git +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/glib-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fPIC +QEMU_CFLAGS -I/usr/include/pixman-1 -Werror -fPIE -DPIE -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-strong -I/usr/include/libpng16 -I/usr/include/spice-server -I/usr/include/cacard -I/usr/include/nss -I/usr/include/nspr -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/spice-1 -I/usr/include/libusb-1.0 +LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g -Wl,-O1,--sort-common,--as-needed,-z,relro +make make +install install +python /usr/bin/python2 -B +smbd /usr/sbin/smbd +module support yes +host CPU x86_64 +host big endian no +target list x86_64-softmmu i386-softmmu +tcg debug enabled no +gprof enabled no +sparse enabled no +strip binaries yes +profiler no +static build no +pixman system +SDL support yes (1.2.15) +GTK support no +GTK GL support no +VTE support no +GNUTLS support no +GNUTLS hash no +GNUTLS rnd no +libgcrypt no +libgcrypt kdf no +nettle no +nettle kdf no +libtasn1 yes +curses support yes +virgl support no +curl support no +mingw32 support no +Audio drivers sdl +Block whitelist (rw) +Block whitelist (ro) +VirtFS support no +VNC support yes +VNC SASL support no +VNC JPEG support yes +VNC PNG support yes +xen support no +brlapi support no +bluez support no +Documentation yes +PIE yes +vde support yes +netmap support no +Linux AIO support yes +ATTR/XATTR support yes +Install blobs yes +KVM support yes +RDMA support no +TCG interpreter no +fdt support no +preadv support yes +fdatasync yes +madvise yes +posix_madvise yes +uuid support yes +libcap-ng support yes +vhost-net support yes +vhost-scsi support yes +Trace backends nop +spice support yes (0.12.10/0.12.6) +rbd support no +xfsctl support yes +smartcard support no +libusb yes +usb net redir no +OpenGL support no +OpenGL dmabufs no +libiscsi support no +libnfs support no +build guest agent no +QGA VSS support no +QGA w32 disk info no +QGA MSI support no +seccomp support yes +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 no +lzo support no +snappy support no +bzip2 support no +NUMA host support yes +tcmalloc support no +jemalloc support no +avx2 optimization yes \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1596 b/results/classifier/gemma3:12b/vnc/1596 new file mode 100644 index 00000000..4293c4dc --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1596 @@ -0,0 +1,21 @@ + +VNC console with 4K resolutions is cut off on the right side and mouse coordinates are offset (or horizontal res greater than 2600-3000 pixels) +Description of problem: +For some reason when connecting to the VNC console of a QEMU VM, when you use a resolution that has its horizontal size of about 3000 pixels or more, it gets cut off by about 1/4 of the screen from the right, and the mouse position is offset by that value towards the left. See image for explanation: + + +Steps to reproduce: +1. Create a Fedora 37 VM +2. Use `virtio-vga-gl` and `egl-headless` +3. Set the resolution to 4K (3840x2160) or anything with the horizontal resolution greater than 3000 pixels +4. Use Windows to connect to the VNC console. Issue happens with TightVNC Viewer and RealVNC Viewer +Additional information: +I also tried `-device virtio-vga-gl,edid=off,xres=3840,yres=2160`. Same result, but `edid=off` helps to make 2560x1600 appear, making it bearable. + +This also happens with Wayland and Xorg. + +Please note that while it's possible to use Gnome's Screen Sharing (RDP/VNC) options, as well as NoMachine or other options, this is an undesirable behavior in QEMU's VNC server/console that should be fixed (and can, the VNC protocol perfectly supports 4K without issues) + +Not to mention that, at least in my use case, the VNC console is faster than the alternatives, even SPICE (connecting from Windows is barely unusable at 4K res - it's a bliss from Linux. Both cases from a remote machine in the same LAN, but that is unrelated to this bug). + +I would happily try different use cases to try to help nail down this bug :smile: diff --git a/results/classifier/gemma3:12b/vnc/1637447 b/results/classifier/gemma3:12b/vnc/1637447 new file mode 100644 index 00000000..6fdaceb0 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1637447 @@ -0,0 +1,13 @@ + +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... \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1653 b/results/classifier/gemma3:12b/vnc/1653 new file mode 100644 index 00000000..751a0d3e --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1653 @@ -0,0 +1,21 @@ + +qemu uses uefi to install the redhad6.0 VM, use the vnc connect it which is stuck +Description of problem: +I want to use uefi(udk2-->ovmf.fd) to install redhad6.0, but after I enter uefi and start up, I cannot use vnc to connect to it,The screen is black or often stuck, nor can I use the console of other pages, or it is a special slow to be able to use it. It's sure that the virtual machine is not crash. Anad the same operation is normal for redhad6.1 systems. +Steps to reproduce: +1.compile udk2 generate ovmf.fd +compile config: + +make -C BaseTools/Source/C + +./OvmfPkg/build.sh -D DEBUG_ON_SERIAL_PORT=true + + +2.run qemu with "-bios /bin/OVMF.fd" + + +3.use vnc to connet it + + + +The screen is stuck can't handle it. diff --git a/results/classifier/gemma3:12b/vnc/1661176 b/results/classifier/gemma3:12b/vnc/1661176 new file mode 100644 index 00000000..219921d8 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1661176 @@ -0,0 +1,5 @@ + +[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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1665791 b/results/classifier/gemma3:12b/vnc/1665791 new file mode 100644 index 00000000..7251150c --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1665791 @@ -0,0 +1,4 @@ + +Multiple displays each attached to a separate vnc connection + +Would it be possible to create two displays in qemu (for windows 10) with each accessible by a separate vnc connection? I think this already exists for spice (and I would like it because vnc works better for me than does spice) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1670377 b/results/classifier/gemma3:12b/vnc/1670377 new file mode 100644 index 00000000..96b13a67 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1670377 @@ -0,0 +1,38 @@ + + VNC: short read for zlre data/RDR EndOfStream + +In openQA we have a custom VNC client (https://github.com/os-autoinst/os-autoinst/tree/master/consoles), which connects to QEMU guest and from there performs actions (sends keys, handles pointer, ...). We have several backends (https://github.com/os-autoinst/os-autoinst/tree/master/backend). With qemu backend we start QEMU guest *locally* on openQA worker which connects to it via VNC and sends commands. That works fine. + +However, with svirt backend we start QEMU on a KVM or Xen host and then connect to it remotely from openQA worker - the guest and worker are different systems. In this scenario fairly often happens that while system operates in Grub2, QEMU stops sending data via VNC: + +... +15:24:15.5341 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:50 called testapi::send_key +15:24:15.5342 27074 <<< testapi::send_key(key='c') +15:24:15.7361 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:51 called testapi::type_string +15:24:15.7362 27074 <<< testapi::type_string(string='gfxmode=1024x768; terminal_output console; terminal_output gfxterm +', max_interval=250, wait_screen_changes=0) +15:24:22.2243 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:53 called testapi::send_key +15:24:22.2244 27074 <<< testapi::send_key(key='esc') +15:24:22.4255 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:79 called testapi::send_key +15:24:22.4256 27074 <<< testapi::send_key(key='e') +15:24:22.6264 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.6265 27074 <<< testapi::send_key(key='down') +15:24:22.8273 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:22.8274 27074 <<< testapi::send_key(key='down') +15:24:23.0282 Debug: /var/lib/openqa/share/tests/sle-12-SP1/tests/installation/bootloader_uefi.pm:81 called testapi::send_key +15:24:23.0283 27074 <<< testapi::send_key(key='down') +DIE short read for zlre data 107132 - 995002 at /usr/lib/os-autoinst/consoles/VNC.pm line 978. + + at /usr/lib/os-autoinst/backend/baseclass.pm line 73. +... + +My observation is that it happens only while in Grub, when resolution happened a short while ago. See attached video and log. + +Prior to QEMU 2.8.0 I was able to reproduce a similar issue with vncviewer. I started QEMU with SLES JeOS image pressed several times a 'down' key in Grub and vncviewer (Tiger VNC 1.6.0 from openSUSE Leap 42.2) crashed with rdr::EndOfStream exception. This does not happen with QEMU 2.8.0, but I am still able to reproduce similar issue via openQA. + +/usr/bin/qemu-system-x86_64 -name guest=openQA-SUT-20,debug-threads=on -S -machine pc-i440fx-2.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 87535fc1-e693-41b9-813e-834d6fc4cb5a -no-user-config -nodefaults -rtc base=utc -no-reboot -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/openQA-SUT-20.img,format=qcow2,if=none,id=drive-virtio-disk0,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:12:34:56,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-tablet-pci,id=input0,bus=pci.0,addr=0x6 -device virtio-keyboard-pci,id=input1,bus=pci.0,addr=0x7 -vnc 0.0.0.0:20,share=force-shared -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on -monitor stdio + +Host: openSUSE Leap 42.2 x86_64 KVM or Xen on x86_64 Intel with QEMU 2.6.0. +Guest: Leap 42.2. + +I can't reproduce the problem with QEMU 2.5.0, but I can with any QEMU version from 2.6 RC1 on. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1686390 b/results/classifier/gemma3:12b/vnc/1686390 new file mode 100644 index 00000000..251d360f --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1686390 @@ -0,0 +1,19 @@ + +vnc server closed socket after arrow "down" keyevent + +This is a rewrite for https://bugs.launchpad.net/qemu/+bug/1670377 + +QEMU 2.6 or later +tigervncviwer 1.6 + +Once get into grub boot interface(choose boot os, or recovery mode), keep pressing arrow down button for couple times, qemu will close the connection, vnc used zrle mode. + +Interesting place: +1. when stopped at grub interface, only arrow up and down key could trigger it, +2. only in zrle or tight mode, could work well in raw mode +2. it only triggered by remote connection, not happen if local vncviewer and vnc server + + +A trace is attached. + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/170 b/results/classifier/gemma3:12b/vnc/170 new file mode 100644 index 00000000..76efcdf1 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/170 @@ -0,0 +1,2 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server diff --git a/results/classifier/gemma3:12b/vnc/1715186 b/results/classifier/gemma3:12b/vnc/1715186 new file mode 100644 index 00000000..dc62c31b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1715186 @@ -0,0 +1,13 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1717414 b/results/classifier/gemma3:12b/vnc/1717414 new file mode 100644 index 00000000..b86ecbd9 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1717414 @@ -0,0 +1,27 @@ + +Sending certain keysyms results in wrong symbol input + +I develop bVNC, an Android VNC client. I noticed that when I connect to qemu VMs that have a VNC console, Keysyms that are usually sent over with SHIFT modifier when connecting from a PC have wrong symbols typed within the VM. A very short list of examples: + +exclam 33 0x0021 + +results in "1" typed in the VM. + +at 64 0x0040 + +results in "2" + +plus 43 0x002b + +results in "=" + +asterisk 42 0x002a + +results in "8" + +On Android, KEYCODEs that correspond to the above keysyms do not come with SHIFT metastate. Therefore, the keysyms that they correspond to are not sent over with any modifiers and must just work. + +The issue was reproduced with bVNC and RealVNC viewers connecting to many versions of qemu (Ubuntu 14.04, oVirt 3.4, oVirt 4.1, etc.). The qemu version that comes with oVirt 4.1 is 2.6.0, commit hash bfc766d38e1fae5767d43845c15c79ac8fa6d6af. + +Sincerely, +iordan \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1718964 b/results/classifier/gemma3:12b/vnc/1718964 new file mode 100644 index 00000000..4d6308ae --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1718964 @@ -0,0 +1,73 @@ + +Memory leak when using websocket over a low speed network + +Description of problem +------------------------- + +When VNC is connected to QEMU via websocket over a low speed network (e.g. 300KB/S Wide Area Network), and there is a lot of frame buffer update, the VNC Client will get stuck, the cursor is almost impossible to move, which may result in accumulation of a large number of data in the QEMU process (memory consumption will keep increasing). + + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.5.1 / 2.6.0 / 2.8.1.1 / 2.9.0 / 2.10.0 +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Guest OS: Windows 7 64bit / Ubuntu 16.04 Desktop LTS +Client OS: Windows 7 64bit / Windows 10 64bit +Client Browser: IE 11.0.9600 / Chrome 60.0.3112 / Firefox 55.0.2 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 +VNC Web Client: noVNC 0.5.1 / noVNC 0.61 / noVNC 0.62 +VNC Server: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 +VNC Client: TigerVNC Viewer 1.8 / UltraVNC Viewer 1.2.1.5 / TightVNC Viewer 2.8.8 + + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance with websocket option: +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :1,websocket=5701 + +2. Open VNC Web Client (noVNC/vnc.html) in browser and connect to QEMU VM via websocket + +3. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +4. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +5. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +6. Observe QEMU process on the host, more and more data are accumulated in the process, the consumption of memory continues to keep increasing + + +Current result: +------------------------- +[Top - Initial status] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7229144 5.910g 23024 S 16.3 18.9 0:12.84 qemu-system-x86_64 + +[Top - After an hour's playing w/o limit (6-8MB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 7370284 6.046g 23132 S 28.0 19.3 35:58.15 qemu-system-x86_64 + +[Top - Limit the bandwidth and continue to playing for another an hour (300KB/S)] + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND + 2725 root 20 0 11.029g 8.853g 23132 S 20.0 28.2 72:14.17 qemu-system-x86_64 + +Also test several other combinations in the same environment: + +1. Client(VNC Viewer) - Server(QEMU) +2. Client(VNC Viewer) - Server(tigervnc/x11vnc/tightvnc) +3. Client(noVNC) - Server(tigervnc/x11vnc/tightvnc) + +Likewise, the client's inbound bandwidth is limited to 300KB/S, +although a lot of frame are lost, all of they still works (at least the mouse is movable). + +It's found that when connect to QEMU via websocket, it never drop any frames. +QEMU still sends a lot of data to its websocket even when the network is congested, +the process is continually consuming more memory, then it gets stack. + + +Expected results: +------------------------- +When the network is poor (non-LAN), QEMU would reduce the VNC data send to its websocket correspondingly, and the memory usage remains stable. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1721468 b/results/classifier/gemma3:12b/vnc/1721468 new file mode 100644 index 00000000..0dca6bed --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1721468 @@ -0,0 +1,50 @@ + +Free invalid pointer crash in vnc + +Attempt to send qemu monitor command crashed the VM. I have sent the following qemu monitor command to a running instance: + +virsh qemu-monitor-command --hmp instance-xxxxxxx 'change vnc none' + +At the time I was connected via VNC. Closing my xvncviewer resulted +in a crash of the VM. + +Backtrace: + +*** Error in `/usr/bin/qemu-system-x86_64': free(): invalid pointer: 0x0000564f887a87e0 *** +======= Backtrace: ========= +/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fa18b38b7e5] +/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fa18b39437a] +/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fa18b39853c] +/usr/bin/qemu-system-x86_64(+0x4b25dd)[0x564f871a75dd] +/usr/bin/qemu-system-x86_64(visit_type_VncServerInfo+0xa2)[0x564f871b9612] +/usr/bin/qemu-system-x86_64(qapi_free_VncServerInfo+0x30)[0x564f871a6be0] +/usr/bin/qemu-system-x86_64(+0x441bca)[0x564f87136bca] +/usr/bin/qemu-system-x86_64(vnc_disconnect_finish+0x37)[0x564f87137bf7] +/usr/bin/qemu-system-x86_64(aio_dispatch+0x68)[0x564f8715dcb8] +/usr/bin/qemu-system-x86_64(+0x45bf9e)[0x564f87150f9e] +/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7fa18c06c197] +/usr/bin/qemu-system-x86_64(main_loop_wait+0x18b)[0x564f8715c5bb] +/usr/bin/qemu-system-x86_64(main+0x17b4)[0x564f86ed64e4] +/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fa18b334830] +/usr/bin/qemu-system-x86_64(_start+0x29)[0x564f86edbb79] + + +Version info: + +ii qemu-system 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU full system emulation binaries +ii qemu-system-x86 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU full system emulation binaries (x86) +ii qemu-utils 1:2.5+dfsg-5ubuntu10.16 amd64 QEMU utilities +ii libvirt-bin 1.3.1-1ubuntu10.14 amd64 programs for the libvirt library +ii libvirt0:amd64 1.3.1-1ubuntu10.14 amd64 library for interfacing with different virtualization systems +ii nova-compute-libvirt 2:13.1.4-0ubuntu3 all OpenStack Compute - compute node libvirt support +ii python-libvirt 1.3.1-1ubuntu1 amd64 libvirt Python bindings + +uname -a +Linux <redacted> 4.10.0-32-generic #36~16.04.1-Ubuntu SMP Wed Aug 9 09:19:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux + + +Qemu startup: + +starting up libvirt version: 1.3.1, package: 1ubuntu10.14 (Jorge Niedbalski <email address hidden> Thu, 10 Aug 2017 22:50:46 -0400), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), hostname: <redacted> +LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name instance-000015ea -S -machine pc-i440fx-xenial,accel=kvm,usb=off -cpu Haswell-noTSX,+abm,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 32768 -realtime mlock=off -smp 10,sockets=5,cores=1,threads=2 -object memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=34359738368,host-nodes=0,policy=bind -numa node,nodeid=0,cpus=0-9,memdev=ram-node0 -uuid 9c2c7bdb-baae-45e7-888f-d090b3d331be -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=13.1.4,serial=24efafa3-b4a7-4489-a06a-17f23a63ff2b,uuid=9c2c7bdb-baae-45e7-888f-d090b3d331be,family=Virtual Machine' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-instance-000015ea/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xd,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.eph0,format=qcow2,if=none,id=drive-virtio-disk1,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xe,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.swap,format=qcow2,if=none,id=drive-virtio-disk2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0xf,drive=drive-virtio-disk2,id=virtio-disk2 -drive file=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/disk.config,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:94:ae:0c,bus=pci.0,addr=0x3 -netdev tap,fd=30,id=hostnet1,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=fa:16:3e:0e:c5:cc,bus=pci.0,addr=0x4 -netdev tap,fd=32,id=hostnet2,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=fa:16:3e:7a:1f:cf,bus=pci.0,addr=0x5 -netdev tap,fd=34,id=hostnet3,vhost=on,vhostfd=35 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=fa:16:3e:70:8a:21,bus=pci.0,addr=0x6 -netdev tap,fd=36,id=hostnet4,vhost=on,vhostfd=37 -device virtio-net-pci,netdev=hostnet4,id=net4,mac=fa:16:3e:41:2a:c9,bus=pci.0,addr=0x7 -netdev tap,fd=38,id=hostnet5,vhost=on,vhostfd=39 -device virtio-net-pci,netdev=hostnet5,id=net5,mac=fa:16:3e:da:e5:4c,bus=pci.0,addr=0x8 -netdev tap,fd=40,id=hostnet6,vhost=on,vhostfd=41 -device virtio-net-pci,netdev=hostnet6,id=net6,mac=fa:16:3e:c5:0f:8d,bus=pci.0,addr=0x9 -netdev tap,fd=42,id=hostnet7,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet7,id=net7,mac=fa:16:3e:db:c5:4a,bus=pci.0,addr=0xa -netdev tap,fd=44,id=hostnet8,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet8,id=net8,mac=fa:16:3e:9f:b6:15,bus=pci.0,addr=0xb -netdev tap,fd=46,id=hostnet9,vhost=on,vhostfd=47 -device virtio-net-pci,netdev=hostnet9,id=net9,mac=fa:16:3e:df:f2:0b,bus=pci.0,addr=0xc -chardev file,id=charserial0,path=/srv/nova/instances/9c2c7bdb-baae-45e7-888f-d090b3d331be/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x10 -msg timestamp=on +char device redirected to /dev/pts/1 (label charserial1) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1725707 b/results/classifier/gemma3:12b/vnc/1725707 new file mode 100644 index 00000000..07a22f4e --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1725707 @@ -0,0 +1,62 @@ + +QEMU sends excess VNC data to websockify even when network is poor + +Description of problem +------------------------- +In my latest topic, I reported a bug relate to QEMU's websocket: +https://bugs.launchpad.net/qemu/+bug/1718964 + +It has been fixed but someone mentioned that he met the same problem when using QEMU with a standalone websocket proxy. +That makes me confused because in that scenario QEMU will get a "RAW" VNC connection. +So I did a test and found that there indeed existed some problems. The problem is: + +When the client's network is poor (on a low speed WAN), QEMU still sends a lot of data to the websocket proxy, then the client get stuck. It seems that only QEMU has this problem, other VNC servers works fine. + +Environment +------------------------- +All of the following versions have been tested: + +QEMU: 2.8.1.1 / 2.9.1 / 2.10.1 / master (Up to date) +Host OS: Ubuntu 16.04 Server LTS / CentOS 7 x86_64_1611 +Websocket Proxy: websockify 0.6.0 / 0.7.0 / 0.8.0 / master +VNC Web Client: noVNC 0.5.1 / 0.61 / 0.62 / master +Other VNC Servers: TigerVNC 1.8 / x11vnc 0.9.13 / TightVNC 2.8.8 + +Steps to reproduce: +------------------------- +100% reproducible. + +1. Launch a QEMU instance (No need websocket option): +qemu-system-x86_64 -enable-kvm -m 6G ./win_x64.qcow2 -vnc :0 + +2. Launch websockify on a separate host and connect to QEMU's VNC port + +3. Open VNC Web Client (noVNC/vnc.html) in browser and connect to websockify + +4. Play a video (e.g. Watch YouTube) on VM (To produce a lot of frame buffer update) + +5. Limit (e.g. Use NetLimiter) the client inbound bandwidth to 300KB/S (To simulate a low speed WAN) + +6. Then client's output gets stuck(less than 1 fps), the cursor is almost impossible to move + +7. Monitor network traffic on the proxy server + +Current result: +------------------------- +Monitor Downlink/Uplink network traffic on the proxy server +(Refer to the attachments for more details). + +1. Used with QEMU +- D: 5.9 MB/s U: 5.7 MB/s (Client on LAN) +- D: 4.3 MB/s U: 334 KB/s (Client on WAN) + +2. Used with other VNC servers +- D: 5.9 MB/s U: 5.6 MB/s (Client on LAN) +- D: 369 KB/s U: 328 KB/s (Client on WAN) + +It is found that when the client's network is poor, all the VNC servers (tigervnc/x11vnc/tightvnc) +will reduce the VNC data send to websocket proxy (uplink and downlink symmetry), but QEMU never drop any frames and still sends a lot of data to websockify, the client has no capacity to accept so much data, more and more data are accumulated in the websockify, then it crashes. + +Expected results: +------------------------- +When the client's network is poor (WAN), QEMU will reduce the VNC data send to websocket proxy. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1732671 b/results/classifier/gemma3:12b/vnc/1732671 new file mode 100644 index 00000000..098fa734 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1732671 @@ -0,0 +1,10 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1738283 b/results/classifier/gemma3:12b/vnc/1738283 new file mode 100644 index 00000000..885cb854 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1738283 @@ -0,0 +1,12 @@ + +'Less than' (<), 'more than' (>), and 'pipe' (|) can't be typed via VNC + +If I start QEMU 2.11 (from https://build.opensuse.org/package/show/Virtualization/qemu) VM with VNC, I am unable to type following three characters: 'less than' (<), 'more than' (>), and 'pipe' (|) on en_US QWERTY keyboard. Other characters work fine. QEMu version 2.10.1 worked fine. + +/usr/bin/qemu-kvm -m 2048 -cpu kvm64 -drive media=cdrom,if=none,id=cd0,format=raw,file=OI-hipster-minimal-20171031.iso -device ide-cd,drive=cd0 -boot once=d,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -vnc :91,share=force-shared + +The ISO can be downloaded here: https://www.openindiana.org/download/ + +Also tried Fedora-Server-dvd-x86_64-25-1.3.iso and it's the same situation. + +If I run the same command without '-vnc :91,share=force-shared', everything works just fine. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1752646 b/results/classifier/gemma3:12b/vnc/1752646 new file mode 100644 index 00000000..1f6e6a60 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1752646 @@ -0,0 +1,23 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1795100 b/results/classifier/gemma3:12b/vnc/1795100 new file mode 100644 index 00000000..8cd78405 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1795100 @@ -0,0 +1,33 @@ + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1802465 b/results/classifier/gemma3:12b/vnc/1802465 new file mode 100644 index 00000000..cdb9ace5 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1802465 @@ -0,0 +1,28 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1809252 b/results/classifier/gemma3:12b/vnc/1809252 new file mode 100644 index 00000000..64d1769f --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1809252 @@ -0,0 +1,8 @@ + +Password authentication in FIPS-compliant mode + +The documentation states, that: + +"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher." + +Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher? \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1821131 b/results/classifier/gemma3:12b/vnc/1821131 new file mode 100644 index 00000000..40369393 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1821131 @@ -0,0 +1,29 @@ + +VM running under latest Qemu receives 2, 3, 8, and = when sent the keysyms for @, #, *, and + respectively + +Git commit hash where bug was reproduced: 62a172e6a77d9072bb1a18f295ce0fcf4b90a4f2 + +A user of my application bVNC reported that when he connects to his VMs running under Qemu, he cannot send @, #, and *. Instead, 2, 3, and 8 appear in the VM respectively. I built the latest Qemu from source, and reproduced the issue. + +bVNC converts keycodes or unicode characters that the Android keyboard sends it to corresponding keysyms. For example, it sends keysym 64 for @ rather than sending SHIFT+2. + +A debug log of the application sending the keysyms shows metaState == 0, indicating lack of modifier keys. + +When 2 appears in place of @: + +03-21 00:11:21.761 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 64. keysym:64, metaState: 0 +03-21 00:11:21.763 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 64. keysym:64, metaState: 0 + +When 3 appears in place of #: + +03-21 00:11:08.947 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 35. keysym:35, metaState: 0 +03-21 00:11:08.950 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 35. keysym:35, metaState: 0 + +When 0 appears instead of *: + +03-21 00:11:28.586 8864 8864 I RemoteKeyboard: Sending key. Down: true, key: 42. keysym:42, metaState: 0 +03-21 00:11:28.588 8864 8864 I RemoteKeyboard: Sending key. Down: false, key: 42. keysym:42, metaState: 0 + +When = appears instead of +: +03-21 01:05:40.021 10061 10061 I RemoteKeyboard: Sending key. Down: true, key: 43. keysym:43, metaState: 0 +03-21 01:05:40.022 10061 10061 I RemoteKeyboard: Sending key. Down: false, key: 43. keysym:43, metaState: 0 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1828207 b/results/classifier/gemma3:12b/vnc/1828207 new file mode 100644 index 00000000..131d5bdf --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1828207 @@ -0,0 +1,7 @@ + +Request to add something like "Auth failed from IP" log report for built-in VNC server + +In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on. +Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability. + +Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1849644 b/results/classifier/gemma3:12b/vnc/1849644 new file mode 100644 index 00000000..096ddacf --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1849644 @@ -0,0 +1,14 @@ + +QEMU VNC websocket proxy requires non-standard 'binary' subprotocol + +When running a machine using "-vnc" and the "websocket" option QEMU seems to require the subprotocol called 'binary'. This subprotocol does not exist in the WebSocket specification. In fact it has never existed in the spec, in one of the very early drafts of WebSockets it was briefly mentioned but it never made it to a final version. + +When the WebSocket server requires a non-standard subprotocol any WebSocket client that works correctly won't be able to connect. + +One example of such a client is noVNC, it tells the server that it doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't let noVNC connect. If noVNC is modified to ask for 'binary' it will work, this is, however, incorrect behavior. + +Looking at the code in "io/channel-websock.c" it seems it's quite hard-coded to binary: + +Look at line 58 and 433 here: https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c + +This code has to be made more dynamic, and shouldn't require binary. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1858623 b/results/classifier/gemma3:12b/vnc/1858623 new file mode 100644 index 00000000..971eea27 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1858623 @@ -0,0 +1,15 @@ + +VNC outputs garbage in zlib mode + +TL;DR: When QEMU is launched with VNC as the output and viewed with a client that defaults to zlib VNC encoding, the resulting output tends to accumulate artifacts. + +Reproduction: +Launch QEMU (tried with versions 4.2.0 and 4.1.0 on Linux 64bit) with -vnc 0.0.0.0:0 +Connect to it with a VNC client that allows you to select encoding, i.e. UltraVNC. +Set encoding to zlib (type 6), 32bit color. +As screen content changes it starts accumulating artifacts. Almost certain to appear if you open-close windows over a pattern. +Does not seem to depend on guest used, but easier to reproduce with a GUI. + +Looks like this: https://orbides.org/img/vnc.png + +It appears to be a deflate glitch of some sort - all of the bad pixels are generated by length/distance codes. Can't narrow it down any more. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1882817 b/results/classifier/gemma3:12b/vnc/1882817 new file mode 100644 index 00000000..e7c6357d --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1882817 @@ -0,0 +1,26 @@ + +Segfault in audio_pcm_sw_write with audio over VNC + +QEMU 5.0.0, built with ./configure --target-list=x86_64-softmmu --enable-debug --disable-strip --disable-docs --disable-sdl + +Running on a headless host (Ryzen 3600), Arch Linux, 64bit latest. +Guest is also Arch Linux, 64bit. + +Started with qemu-system-x86_64 -vnc 0.0.0.0:0 -enable-kvm -m 4096 -cpu host -smp cores=2,threads=1,sockets=1 -machine q35 -vga std -device + ich9-ahci,id=ahci -drive file=vm0.qcow2,format=qcow2,if=none,id=dsk0 -device ide-hd,drive=dsk0,bus=ahci.0 -soundhw hda + +So, a headless VM is running on a server and is being connected to over VNC. The virtual sound card is detected and speaker test is running inside the VM. So far so good. + +Then, i tell the VNC client to enable audio (QEMU Audio Client Message, 255,1,0). QEMU responds with a "stream is about to start" message (QEMU Audio Server Message, 255,1,1) and then promptly crashes without sending anything else. + +Running it in GDB produces a crash at audio/audio.c:739 + +Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. +audio_pcm_sw_write (sw=0x5555575bbf30, buf=0x0, size=1628) at audio/audio.c:739 +739 if (!sw->hw->pcm_ops->volume_out) { + +The exact sequence of events does not matter - i can enable sound before playing anything, and then it would say nothing and keep working, but crash with the same message once anything sound-playing is launched in the VM. + +Using different soundhw or adding various audiodev options does not seem to affect anything. + +I can't quite figure out if the QEMU Audio VNC extension is supposed to work at all or not, but it would be handy to me if it is. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1894818 b/results/classifier/gemma3:12b/vnc/1894818 new file mode 100644 index 00000000..7f4c2d7f --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1894818 @@ -0,0 +1,20 @@ + +COLO's guest VNC client hang after failover + +Hello, + +After setting up COLO's primary and secondary VMs, +I installed the vncserver and xrdp (apt install tightvncserver xrdp) inside the VM. + +I access the VM from another PC via VNC/RDP client, and everything is OK. +Then, kill the primary VM and issue the failover commands. + +The expected result is that the VNC/RDP client can resume after failover. +But in my test, the VNC client's screen hangs and cannot be recovered no longer. + +BTW, it works well after killing SVM. + +Thanks. + +Regards, +Derek \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1895219 b/results/classifier/gemma3:12b/vnc/1895219 new file mode 100644 index 00000000..eb24ec0f --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1895219 @@ -0,0 +1,12 @@ + +qemu git -vnc fails due to missing en-us keymap + +If trying to run qemu with -vnc :0, it will fail with: +./qemu-system-x86_64 -vnc :2 +qemu-system-x86_64: -vnc :2: could not read keymap file: 'en-us' + +share/keymaps is missing en-us keymap and only has sl and sv, confirmed previous stable versions had en-us. + +Tried with multiple targets, on arm64 and amd64 + +Git commit hash: 9435a8b3dd35f1f926f1b9127e8a906217a5518a (head) \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1900352 b/results/classifier/gemma3:12b/vnc/1900352 new file mode 100644 index 00000000..b9033fe0 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1900352 @@ -0,0 +1,6 @@ + +no sound in spice when VNC enabled + +Running Fedora32 with virt-manager → libvirt → qemu I noticed that I got no sound in my spice client. The VM is configured with a SPICE-server and a QXL display, and in addition a VNC display. + +Apparently when I remove the VNC display, then the sound is routed just fine to the spice client: I can hear it, and `G_MESSAGES_DEBUG=all remote-viewer --spice-debug spice://localhost:5900` mentions SpicePlaybackChannel and SpiceRecordChannel. With the VNC server configured, such messages are missing, and I cannot hear the sound (which is sent by the guest OS to the virtual hardware). \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/1988 b/results/classifier/gemma3:12b/vnc/1988 new file mode 100644 index 00000000..186ccfcb --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1988 @@ -0,0 +1,27 @@ + +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/gemma3:12b/vnc/1989 b/results/classifier/gemma3:12b/vnc/1989 new file mode 100644 index 00000000..7c5939a3 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/1989 @@ -0,0 +1,33 @@ + +Regression: by default qemu opens both vnc and stdout console +Description of problem: +Running qemu with a vnc display (by default I'm not using the -display option) and -monitor stdio, +it fails because the display also wants the std output (it fails even if a pass the -vnc option). +If I remove the monitor I have both the vnc and the std output console at the same time. +I was able to use `-monitor stdio`, passing `-serial telent:...` +Steps to reproduce: +1. ./configure --enable-slirp --target-list=x86_64-softmmu --disable-user --disable-docs +2. make -j 4 +3. qemu-system-x86_64 ... (without `-display` as shown above) +Additional information: +After bisecting I found the following commit changed the behavior: + +``` +commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f +Author: Marc-André Lureau <marcandre.lureau@redhat.com> +Date: Tue Sep 5 23:18:08 2023 +0400 + + ui/console: allow to override the default VC + + If a display is backed by a specialized VC, allow to override the + default "vc:80Cx24C". + + As suggested by Paolo, if the display doesn't implement a VC (get_vc() + returns NULL), use a fallback that will use a muxed console on stdio. + + This changes the behaviour of "qemu -display none", to create a muxed + serial/monitor by default (on TTY & not daemonized). + + Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> + Reviewed-by: Thomas Huth <thuth@redhat.com> +``` diff --git a/results/classifier/gemma3:12b/vnc/2492 b/results/classifier/gemma3:12b/vnc/2492 new file mode 100644 index 00000000..21a5975b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2492 @@ -0,0 +1,21 @@ + +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/gemma3:12b/vnc/2608 b/results/classifier/gemma3:12b/vnc/2608 new file mode 100644 index 00000000..b354fd61 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2608 @@ -0,0 +1,10 @@ + +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/gemma3:12b/vnc/2668 b/results/classifier/gemma3:12b/vnc/2668 new file mode 100644 index 00000000..de13500b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2668 @@ -0,0 +1,4 @@ + +h.264 encoding/compression support +Additional information: +noVNC now support h.264 decoding. diff --git a/results/classifier/gemma3:12b/vnc/2819 b/results/classifier/gemma3:12b/vnc/2819 new file mode 100644 index 00000000..b6faa32b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2819 @@ -0,0 +1,118 @@ + +QEMU 9.2.0 hangs with 100% CPU when using `-vnc` on Loongarch (3A6000 and 3C6000) +Description of problem: +When launching VMs with the `-vnc` parameter (generated by `<graphics type='vnc'>`) on a Loongarch (Loongson 3A6000 or Loongson 3C6000) machine. QEMU process hangs indefinitely with 100% CPU usage, no VNC output. +Steps to reproduce: +1. Create a VM using libvirt (Cockpit-Machines or virt-manager). +2. Configure VNC graphics as follows in libvirt XML, which is provided by Cockpit-Machines by default. +```xml +<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'> + <listen type='address' address='127.0.0.1'/> +</graphics> +``` +3. Start the VM: QEMU process hangs indefinitely with 100% CPU usage, no VNC output. +Additional information: +- Removing the `-vnc` parameter from the QEMU command line (via removing <graphics ... In libvirt XML) resolves the issue. +- The issue appears to stem from changes introduced after QEMU 9.0.1, as downgrading resolves the problem. +- Libvirtd log: https://aosc.io/paste/detail?id=da60d57c-5040-4326-a622-6a692eab488a +- QEMU command line: https://aosc.io/paste/detail?id=30c97bd5-e666-4578-adfd-236cc1fe02ef +- Full Libvirt VM XML: https://aosc.io/paste/detail?id=6bff0fed-d805-4c36-afb7-d14f29d6313b +- No activity in `strace` during the hang. +- GDB backtrace shows the process stuck in `ppoll` (full trace below): +``` +(gdb) bt + #0 0x00007ffff189cad0 in __GI_ppoll (fds=0x7fffa4068d00, nfds=10, timeout=<optimized out>, sigmask=0x0) + at ../sysdeps/unix/sysv/linux/ppoll.c:42 + #1 0x0000555557e67320 in qemu_poll_ns () + #2 0x0000555557e636a4 in main_loop_wait () + #3 0x0000555557a0c4d4 in qemu_main_loop () + #4 0x0000555557d79cc8 in qemu_default_main () + #5 0x00007ffff17c8f30 in __libc_start_call_main + (main=main@entry=0x5555577969c0 <main>, argc=argc@entry=119, argv=argv@entry=0x7ffffbad5508) + at ../sysdeps/nptl/libc_start_call_main.h:58 + #6 0x00007ffff17c9020 in __libc_start_main_impl + (main=0x5555577969c0 <main>, argc=119, argv=0x7ffffbad5508, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:360 + #7 0x0000555557797b70 in _start () +``` +- Qemu full command line: +``` +LC_ALL=C \ +PATH=/usr/local/bin:/usr/bin \ +USER=root \ +HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-buildbot-new/.config \ +/usr/bin/qemu-system-loongarch64 \ +-name guest=buildbot-new,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-buildbot-new/master-key.aes"}' \ +-blockdev '{"driver":"file","filename":"/usr/share/qemu/edk2-loongarch64-code.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/buildbot-new_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \ +-machine virt,usb=off,dump-guest-core=off,memory-backend=loongarch.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,acpi=on \ +-accel kvm \ +-cpu la464 \ +-m size=1048576k \ +-object '{"qom-type":"memory-backend-ram","id":"loongarch.ram","size":1073741824}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,dies=1,clusters=1,cores=1,threads=1 \ +-uuid c56a24b5-c539-4240-9c72-39fd0d0de860 \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=33,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device '{"driver":"pcie-root-port","port":8,"chassis":1,"id":"pci.1","bus":"pcie.0","multifunction":true,"addr":"0x1"}' \ +-device '{"driver":"pcie-root-port","port":9,"chassis":2,"id":"pci.2","bus":"pcie.0","addr":"0x1.0x1"}' \ +-device '{"driver":"pcie-root-port","port":10,"chassis":3,"id":"pci.3","bus":"pcie.0","addr":"0x1.0x2"}' \ +-device '{"driver":"pcie-root-port","port":11,"chassis":4,"id":"pci.4","bus":"pcie.0","addr":"0x1.0x3"}' \ +-device '{"driver":"pcie-root-port","port":12,"chassis":5,"id":"pci.5","bus":"pcie.0","addr":"0x1.0x4"}' \ +-device '{"driver":"pcie-root-port","port":13,"chassis":6,"id":"pci.6","bus":"pcie.0","addr":"0x1.0x5"}' \ +-device '{"driver":"pcie-root-port","port":14,"chassis":7,"id":"pci.7","bus":"pcie.0","addr":"0x1.0x6"}' \ +-device '{"driver":"pcie-root-port","port":15,"chassis":8,"id":"pci.8","bus":"pcie.0","addr":"0x1.0x7"}' \ +-device '{"driver":"pcie-root-port","port":16,"chassis":9,"id":"pci.9","bus":"pcie.0","multifunction":true,"addr":"0x2"}' \ +-device '{"driver":"pcie-root-port","port":17,"chassis":10,"id":"pci.10","bus":"pcie.0","addr":"0x2.0x1"}' \ +-device '{"driver":"pcie-root-port","port":18,"chassis":11,"id":"pci.11","bus":"pcie.0","addr":"0x2.0x2"}' \ +-device '{"driver":"pcie-root-port","port":19,"chassis":12,"id":"pci.12","bus":"pcie.0","addr":"0x2.0x3"}' \ +-device '{"driver":"pcie-root-port","port":20,"chassis":13,"id":"pci.13","bus":"pcie.0","addr":"0x2.0x4"}' \ +-device '{"driver":"pcie-root-port","port":21,"chassis":14,"id":"pci.14","bus":"pcie.0","addr":"0x2.0x5"}' \ +-device '{"driver":"pcie-root-port","port":22,"chassis":15,"id":"pci.15","bus":"pcie.0","addr":"0x2.0x6"}' \ +-device '{"driver":"pcie-pci-bridge","id":"pci.16","bus":"pci.1","addr":"0x0"}' \ +-device '{"driver":"qemu-xhci","p2":15,"p3":15,"id":"usb","bus":"pci.3","addr":"0x0"}' \ +-device '{"driver":"virtio-scsi-pci","id":"scsi0","bus":"pci.8","addr":"0x0"}' \ +-device '{"driver":"virtio-serial-pci","id":"virtio-serial0","bus":"pci.4","addr":"0x0"}' \ +-blockdev '{"driver":"file","filename":"/mnt/data/aosc-os_installer_20241122_loongarch64.iso","node-name":"libvirt-1-storage","read-only":true}' \ +-device '{"driver":"scsi-cd","bus":"scsi0.0","channel":0,"scsi-id":0,"lun":0,"device_id":"drive-scsi0-0-0-0","drive":"libvirt-1-storage","id":"scsi0-0-0-0"}' \ +-chardev pty,id=charserial0 \ +-serial chardev:charserial0 \ +-chardev socket,id=charchannel0,fd=32,server=on,wait=off \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":1,"chardev":"charchannel0","id":"channel0","name":"org.qemu.guest_agent.0"}' \ +-chardev spicevmc,id=charchannel1,name=vdagent \ +-device '{"driver":"virtserialport","bus":"virtio-serial0.0","nr":2,"chardev":"charchannel1","id":"channel1","name":"com.redhat.spice.0"}' \ +-device '{"driver":"usb-tablet","id":"input0","bus":"usb.0","port":"1"}' \ +-device '{"driver":"usb-kbd","id":"input1","bus":"usb.0","port":"2"}' \ +-audiodev '{"id":"audio1","driver":"spice"}' \ +-vnc 127.0.0.1:0,audiodev=audio1 \ +-spice port=5901,addr=127.0.0.1,disable-ticketing=on,image-compression=off,seamless-migration=on \ +-device '{"driver":"virtio-gpu-pci","id":"video0","max_outputs":1,"bus":"pci.7","addr":"0x0"}' \ +-device '{"driver":"ich9-intel-hda","id":"sound0","bus":"pci.16","addr":"0x1"}' \ +-device '{"driver":"hda-duplex","id":"sound0-codec0","bus":"sound0.0","cad":0,"audiodev":"audio1"}' \ +-device '{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.5","addr":"0x0"}' \ +-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ +-device '{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.6","addr":"0x0"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on +``` +- I tried to reproduce the bug with a simple command but failed, not sure what is the real cause. Following commands works fine. +``` +qemu-system-loongarch64 -m 2G \ + -cpu la464 \ + -machine virt \ + -smp 2 \ + -bios /usr/share/qemu/edk2-loongarch64-code.fd \ + -vnc 127.0.0.1:0 \ + -device virtio-gpu-pci +``` diff --git a/results/classifier/gemma3:12b/vnc/2836 b/results/classifier/gemma3:12b/vnc/2836 new file mode 100644 index 00000000..0047f32b --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2836 @@ -0,0 +1,44 @@ + +readconfig with [vnc] only causes assertion failure +Description of problem: +Given test.config containing +``` +[vnc] +``` + +``` +$ qemu-system-amd64 -readconfig test.config +qemu-system-amd64: ui/vnc.c:4294: vnc_init_func: Assertion `id' failed. +Aborted +``` + + +``` +(gdb) bt +#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) + at ./nptl/pthread_kill.c:44 +#1 0x00007ffff68f3e2f in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:78 +#2 0x00007ffff689fd02 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 +#3 0x00007ffff68884f0 in __GI_abort () at ./stdlib/abort.c:79 +#4 0x00007ffff6888418 in __assert_fail_base (fmt=0x7ffff6a0cca0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", + assertion=assertion@entry=0x55555608eef6 "id", file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:96 +#5 0x00007ffff6898612 in __assert_fail (assertion=assertion@entry=0x55555608eef6 "id", + file=file@entry=0x555556068a5e "ui/vnc.c", line=line@entry=4294, + function=function@entry=0x5555561c3fe0 <__PRETTY_FUNCTION__.0> "vnc_init_func") at ./assert/assert.c:105 +#6 0x0000555555a03adb in vnc_init_func (opaque=<optimized out>, opts=<optimized out>, + errp=0x5555570db038 <error_fatal>) at ui/vnc.c:4294 +#7 0x0000555556037b31 in qemu_opts_foreach (list=<optimized out>, func=0x555555a039f0 <vnc_init_func>, + opaque=opaque@entry=0x0, errp=errp@entry=0x5555570db038 <error_fatal>) at util/qemu-option.c:1135 +#8 0x0000555555c41eff in qemu_init_displays () at system/vl.c:2619 +#9 qemu_init (argc=<optimized out>, argv=<optimized out>) at system/vl.c:3762 +#10 0x00005555559e1c0d in main (argc=<optimized out>, argv=<optimized out>) at system/main.c:47 +``` + +https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L4294 + +Passing an invalid value to id results in `qemu-system-amd64: -readconfig test.config: Parameter 'id' expects an identifier +Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.` so perhaps a missing value should cause a similar error? + + +PS: Where's the documentation for `-readconfig`? diff --git a/results/classifier/gemma3:12b/vnc/2949 b/results/classifier/gemma3:12b/vnc/2949 new file mode 100644 index 00000000..08655c50 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/2949 @@ -0,0 +1,18 @@ + +VNC: virtio-gpu outputs not displayed by VNC client +Description of problem: +When combining virtio-gpu multiple outputs with VNC display, only output 0 is enabled. +Additional output are enabled when VNC client sent SetDesktopSize command. + +The following statement assumes that all displays (gtk, sdl) are disabled except VNC: + +# +Steps to reproduce: +1. Start Qemu +2. Start a VNC client on 5900 +3. Start the second VNC client on 5901 +Additional information: +The state of an output is controlled by the [enabled_output_bitmask](https://gitlab.com/qemu-project/qemu/-/blob/master/include/hw/virtio/virtio-gpu.h#L158) which is initialized to `1` at [device realization](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L204), thus VNC0 is always enabled. + +Other devices will set this parameter during inititliazation by calling [dpy_set_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/console.c#L754) which schedules a call to [virtio_gpu_ui_info](https://gitlab.com/qemu-project/qemu/-/blob/master/hw/display/virtio-gpu-base.c#L89). However VNC calls this function only when handling [VNC_MSG_CLIENT_SET_DESKTOP_SIZE](https://gitlab.com/qemu-project/qemu/-/blob/master/ui/vnc.c#L2607) client command.\ +If the client does not support this command or never changes the size of the default window, the respective display will remain disabled. diff --git a/results/classifier/gemma3:12b/vnc/351 b/results/classifier/gemma3:12b/vnc/351 new file mode 100644 index 00000000..2c0d1865 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/351 @@ -0,0 +1,2 @@ + +German keyboard vnc issue diff --git a/results/classifier/gemma3:12b/vnc/498039 b/results/classifier/gemma3:12b/vnc/498039 new file mode 100644 index 00000000..8255a538 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/498039 @@ -0,0 +1,10 @@ + +No copy/paste with VNC display with Windows guest + +There is no copy/paste functionality between a Windows guest and the VNC client. This is a significant usability problem. + +One work-around is to run VNC inside of the guest. But that appears to have more overhead than qemu's VNC display. + +Obviously, qemu's VNC display is just a display device and knows absolutely nothing about the Windows clipboard. Thus, to interface with the guest's clipboard would require a helper app running in the guest that can hook into qemu. This would probably be the best solution. + +There are probably not a lot of qemu developers interested in trying to write the helper app. Not exactly an interesting job. But since it is a significant usability problem, and many users would see this as a major oversight, I suggest leaving this bug open long-term as a hint so that some volunteer later looking for something to do might take pity on everyone and write this helper app. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/595 b/results/classifier/gemma3:12b/vnc/595 new file mode 100644 index 00000000..56fb2e68 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/595 @@ -0,0 +1,12 @@ + +QEMU VNC mouse doesn't move in tablet mode os9 +Description of problem: +What I am trying to do is have a headless os9 running in QEMU on ubuntu and use the native vnc support in QEMU to access the screen. That is setup and works as expected but the mouse only works in ps/2 mode and that is clearly very undesirable (mouse is never lined up). I set it up in tablet mode and when I am in the QEMU window on the host the mouse works perfect (I added tablet mode to os9 with: https://github.com/kanjitalk755/macos9-usb-tablet). That same tablet mode results in the mouse not moving at all over vnc, if I ctrl+alt 2 and switch the mouse type from tablet mode it starts working again but not lined up at all as expected, cant get to any buttons on edges. Is there anyone in here that ran into this? Am I the only one using QEMU VNC? + +Iv thought about running a vnc application on the vm itself but performance was meh at best. Any tips would be worth a lot to me, its a sin to say but I am trying to adapt this into a production environment... + +Upon further investigation this seems to be a issue on Linux. I am testing the QEMU on windows and its working as expected over VNC. That is to say if QEMU is running on a windows host, it just works over vnc with tablet mode. So what could be causing Linux version to not work? I did compile it from source, are there any configure flags I am missing? I am trying to run it on Ubuntu server 21.04 +Steps to reproduce: +1.add vnc option to parameters +2.enable tablet mode and install driver in os9 +3.connect to vnc and mouse doesn't move diff --git a/results/classifier/gemma3:12b/vnc/667791 b/results/classifier/gemma3:12b/vnc/667791 new file mode 100644 index 00000000..485ccf92 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/667791 @@ -0,0 +1,40 @@ + +Cygwin build fails due to ui/vnc-etc-tight.c + +Configure: +./configure \ +--prefix="./install/bin/" \ +--interp-prefix="./install/bin-%M/" \ +--cc="gcc -mno-cygwin" \ +--host-cc="gcc" \ +--disable-sdl \ +--enable-system \ +--disable-user \ +--disable-linux-user \ +--disable-darwin-user \ +--disable-bsd-user \ +--disable-xen \ +--disable-brlapi \ +--disable-vnc-tls \ +--disable-vnc-sasl \ +--disable-vnc-jpeg \ +--disable-vnc-png \ +--disable-vnc-thread \ +--disable-curses \ +--disable-curl \ +--disable-bluez \ +--disable-kvm \ +--disable-nptl \ +--disable-vde \ +--disable-vhost-net + +Versions of software +Cygwin 1.7 +GNU Make 3.81 +GCC 3.4.4 (/usr/lib/gcc/i686-pc-cygwin/3.4.4/libgcc.a) +QEMU 0.13.0 + +Result: +Function tight_detect_smooth_image24(...) uses "uint" type, that appears to be not defined in this scope. Prepending this function with +typedef unsigned int uint; +fixes build. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/697197 b/results/classifier/gemma3:12b/vnc/697197 new file mode 100644 index 00000000..c5732e02 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/697197 @@ -0,0 +1,27 @@ + +Empty password allows access to VNC in libvirt + +The help in the /etc/libvirt/qemu.conf states + +"To allow access without passwords, leave this commented out. An empty +string will still enable passwords, but be rejected by QEMU +effectively preventing any use of VNC." + +yet setting: + +vnc_password="" + +allows access to the vnc console without any password prompt just as if it is hashed out completely. + +ProblemType: Bug +DistroRelease: Ubuntu 10.10 +Package: libvirt-bin 0.8.3-1ubuntu14 +ProcVersionSignature: Ubuntu 2.6.35-24.42-server 2.6.35.8 +Uname: Linux 2.6.35-24-server x86_64 +Architecture: amd64 +Date: Tue Jan 4 12:18:35 2011 +InstallationMedia: Ubuntu-Server 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.2) +ProcEnviron: + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: libvirt \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/70 b/results/classifier/gemma3:12b/vnc/70 new file mode 100644 index 00000000..c855171d --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/70 @@ -0,0 +1,2 @@ + +hda sound capture broken with VNC diff --git a/results/classifier/gemma3:12b/vnc/759 b/results/classifier/gemma3:12b/vnc/759 new file mode 100644 index 00000000..351929e2 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/759 @@ -0,0 +1,13 @@ + +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/gemma3:12b/vnc/779 b/results/classifier/gemma3:12b/vnc/779 new file mode 100644 index 00000000..d6652bd7 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/779 @@ -0,0 +1,14 @@ + +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/gemma3:12b/vnc/806656 b/results/classifier/gemma3:12b/vnc/806656 new file mode 100644 index 00000000..d69e144c --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/806656 @@ -0,0 +1,8 @@ + +Tight PNG VNC encoding is sent even when --disable-vnc-png is set + +This bug exists in 0.14.1 and also in 9312805d33e8b (Jun 17, 2011) in the master git repo. + +The "Tight PNG" encoding is a derivative of the "Tight" encoding that replaces zlib encoded rects with PNG encoded data instead. However, when the "Tight PNG" encoding is disabled (--disable-vnc-png), the server will send frame buffer updates that are marked as "Tight PNG" but in fact contain zlib encoded regions (i.e. it's really "tight" protocol). + +The "Tight PNG" encoding should only be used when --enable-vnc-png is set. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/807 b/results/classifier/gemma3:12b/vnc/807 new file mode 100644 index 00000000..79eef675 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/807 @@ -0,0 +1,19 @@ + +TigerVNC client to built-in VNC server causes VM to crash/freeze +Description of problem: +Connecting to the built-in VNC server via TigerVNC upon disconnect the whole VM process freezes/crashes. The process continues to exist but does not respond to any network connection and the monitor socket is dead too. Killing it with TERM doesn't work. + +Using tigervnc-viewer 1.10.1+dfsg-3 (Ubuntu 20.04) with default options like `vncviwer localhost:0` +Steps to reproduce: +* `qemu-system-x86_64 -vnc 127.0.0.1:0` + * Connect to built-in VNC server via TigerVNC + * Keep the VNC connection open and wait some period of time (usually 5-10 minutes is enough though sometimes hours) then disconnect/reconnect VNC. If the reconnect succeeds then wait again for a period of time then disconnect and try again until failure. Often just connecting and disconnecting to the VNC once is enough to make the VM eventually crash/freeze even if running only in the background but this is less reproducible. + * Observe VM is no longer responsive to anything + +If TigerVNC is never connected/disconnected from the VM then this doesn't happen. +Additional information: +Note due to the nature of this issue it might be hard to reproduce for unknown reasons. The VM always eventually freezes though. The qemu process has no output when it freezes. + +As far as I can tell connecting to the built-in VNC server via `gvncviwer` seems to be OK and doesn't cause an issue (?). I'm not sure about other VNC clients (eg. TurboVNC). + +I am connecting to the VNC server from a completely different machine than the host via SSH port redirection (the host is headless). Not sure if that matters. diff --git a/results/classifier/gemma3:12b/vnc/824074 b/results/classifier/gemma3:12b/vnc/824074 new file mode 100644 index 00000000..4e1de270 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/824074 @@ -0,0 +1,6 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/88 b/results/classifier/gemma3:12b/vnc/88 new file mode 100644 index 00000000..8556c7bb --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/88 @@ -0,0 +1,2 @@ + +VNC server does not work with Mac Screen Sharing diff --git a/results/classifier/gemma3:12b/vnc/894037 b/results/classifier/gemma3:12b/vnc/894037 new file mode 100644 index 00000000..a94d06bc --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/894037 @@ -0,0 +1,16 @@ + +With VNC, "-usbdevice tablet" no longer makes mouse pointers line up + +I use qemu in VNC mode. In order to get the client and server mouse pointers to line up, I've had to use the "-usbdevice tablet" option. This no longer works, and it behaves the same as if the option is not there. This makes my VMs unusable to me. + +Here's how I'm booting WinXP: + +qemu-system-x86_64 -vga std -drive cache=writeback,index=0,media=disk,file=winxp.img -k en-us -m 2048 -smp 2 -vnc :3101 -usbdevice tablet -boot c -enable-kvm & + +The Windows install hasn't changed, only qemu. + +I'm running this version of QEMU: + +QEMU emulator version 0.15.0 (qemu-kvm-0.15.0), Copyright (c) 2003-2008 Fabrice Bellard + +I'll see about upgrading to 0.15.1, but since I haven't seen other reports of this particular problem in your DB, I'm assuming that this problem has not been fixed between 0.15.0 and 0.15.1. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/895 b/results/classifier/gemma3:12b/vnc/895 new file mode 100644 index 00000000..2d66bbda --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/895 @@ -0,0 +1,39 @@ + +can't find table device while call qemu_input_is_absolute function +Description of problem: +vnc service can‘t run with mouse absolute mode +Steps to reproduce: +1.create a virtual machine with vnc service via virt-manager. + +2.delete mouse and table device if exists. + +3.add table devices first,next add mouse device. + +4.gdb attach corresponding qemu thread, run command +print "%d",qemu_input_is_absolute() +display function return false ,so I can't use mouse with absolute mode. +Additional information: +code in qemu_input_is_absolute() is +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_REL | INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +qemu_input_find_handler function find a handler INPUT_EVENT_MASK_REL or INPUT_EVENT_MASK_ABS,but just compare with INPUT_EVENT_MASK_ABS, +I think it should be +``` +bool qemu_input_is_absolute(void) +{ + QemuInputHandlerState *s; + + s = qemu_input_find_handler(INPUT_EVENT_MASK_ABS, + NULL); + return (s != NULL) && (s->handler->mask & INPUT_EVENT_MASK_ABS); +} +``` +thanks for your help. diff --git a/results/classifier/gemma3:12b/vnc/925405 b/results/classifier/gemma3:12b/vnc/925405 new file mode 100644 index 00000000..b438a899 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/925405 @@ -0,0 +1,19 @@ + +VNC server does not work with Mac Screen Sharing + +When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. + +I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. + +It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. + +Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. + +Background info: + +Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: + +* At a terminal, by typing "open vnc://hostname:tcp_port" +* From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port + +Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/974229 b/results/classifier/gemma3:12b/vnc/974229 new file mode 100644 index 00000000..da181b91 --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/974229 @@ -0,0 +1,50 @@ + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:12b/vnc/981 b/results/classifier/gemma3:12b/vnc/981 new file mode 100644 index 00000000..0f2e910d --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/981 @@ -0,0 +1,11 @@ + +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 + ``` diff --git a/results/classifier/gemma3:12b/vnc/994412 b/results/classifier/gemma3:12b/vnc/994412 new file mode 100644 index 00000000..c35a641c --- /dev/null +++ b/results/classifier/gemma3:12b/vnc/994412 @@ -0,0 +1,9 @@ + +reverse vnc to unix domain sockets does not work + +I tried to connect to a unix domain socket, but failed. + +$ qemu -vnc unix:/tmp/my.sock,reverse +connect(unix:/tmp/my.sock,reverse): No such file or directory + +I guess it is because unix_connect does not remove characters after first comma. \ No newline at end of file |