summary refs log tree commit diff stats
path: root/results/classifier/zero-shot/118/network/807
blob: 95e5398dc1aade8d65ed5218202c86a4782a5759 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
network: 0.941
graphic: 0.934
performance: 0.866
device: 0.823
socket: 0.805
semantic: 0.796
architecture: 0.738
virtual: 0.730
x86: 0.728
vnc: 0.723
ppc: 0.613
permissions: 0.546
assembly: 0.525
peripherals: 0.519
i386: 0.491
register: 0.481
mistranslation: 0.448
arm: 0.414
VMM: 0.393
debug: 0.389
hypervisor: 0.378
PID: 0.332
KVM: 0.322
user-level: 0.297
risc-v: 0.292
TCG: 0.279
kernel: 0.253
boot: 0.251
files: 0.153

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.