diff options
Diffstat (limited to 'results/classifier/118/vnc/1795100')
| -rw-r--r-- | results/classifier/118/vnc/1795100 | 79 |
1 files changed, 79 insertions, 0 deletions
diff --git a/results/classifier/118/vnc/1795100 b/results/classifier/118/vnc/1795100 new file mode 100644 index 000000000..3853e52bb --- /dev/null +++ b/results/classifier/118/vnc/1795100 @@ -0,0 +1,79 @@ +vnc: 0.920 +x86: 0.905 +socket: 0.895 +graphic: 0.768 +network: 0.731 +user-level: 0.719 +device: 0.633 +performance: 0.625 +ppc: 0.622 +semantic: 0.609 +architecture: 0.607 +mistranslation: 0.586 +PID: 0.512 +files: 0.487 +risc-v: 0.483 +register: 0.452 +permissions: 0.447 +virtual: 0.426 +boot: 0.396 +arm: 0.382 +kernel: 0.365 +i386: 0.356 +debug: 0.288 +TCG: 0.263 +KVM: 0.191 +assembly: 0.133 +peripherals: 0.124 +hypervisor: 0.111 +VMM: 0.077 + +VNC unix-domain socket unlink()ed prematurely + +With qemu 3.0.0 (I don't believe this happened with previous +versions), if I tell it `-vnc unix:/path/to/vnc.sock`, qemu will +unlink() that file when the first client disconnects, meaning that +once I disconnect, I can't ever reconnect without restarting the VM. + +A stupid testcase demonstrating the issue: + +In terminal A: + + $ qemu-system-x86_64 -vnc unix:$PWD/vnc.sock + +In terminal B: + + $ ls vnc.sock + vnc.sock + $ socat STDIO UNIX-CONNECT:vnc.sock <<<'' + RFB 003.008 + $ ls vnc.sock + ls: cannot access 'vnc.sock': No such file or directory + +I have determined that the offending unlink() call is the one in +io/channel-socket.c:qio_channel_socket_close(). That call was first +introduced in commit d66f78e1eaa832f73c771d9df1b606fe75d52a50, which +first appeared in version 3.0.0. + +This type of premature unlink() does not happen on monitor.sock with +`-monitor unix:/path/to/monitor.sock,server,nowait`. + +I am not familiar enough with the QIO subsystem to suggest a fix that +fixes VNC, but preserves the QMP fix targeted in the offending commit. + +This is still a problem with 3.1.0. + +Added Daniel to the bug. + +It only affects VNC, not chardevs because the chardevs fail to call qio_channel_close() and just rely on finalize() cleaning up the open socket. To fix this we just need to made the code conditional on it being a listener socket + + if (qio_channel_has_feature(ioc, QIO_CHANNEL_FEATURE_LISTEN)) { + ... + } + +Patch proposed at + +https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg02774.html + +Fix merged to git master https://git.qemu.org/?p=qemu.git;a=commit;h=feff02089113839d233e40a9bd7134241de12d1d + |