random tigervnc freezes

[erikniessen]

Describe the bug
VNC server display gets randomly frozen. Seems to accept no input, no refreshing.
It happened a couple of times/day, always during active work.
Freeze happens between 1min and 10 min after that I was able to return to work without any problems.
Same freeze happens on different machines running the same sw.

Client:

• OS: Windows10
• VNC client: VNC Viewer
• VNC client version: 6.17

Server :

• OS: RHEL8.2
• VNC server: TigerVNC,
• VNC server version: 1.9.0 also happens with 1.11.0
• Server downloaded from: RHEL8
• Server was started using: /usr/bin/Xvnc :1 -alwaysshared -idletimeout 0 -listen tcp -securitytypes None -auth $HOME/.Xauthority -desktop $HOSTNAME:1 ($USER) -fp catalogue:/etc/X11/fontpath.d -geometry 1920x1080 -pn -rfbauth $HOME/.vnc/passwd -rfbport 5901 -rfbwait 30000 -desktop :1 -rfbport 5910

Additional context
pstack output of Xvnc

#0  0x00007fcd1e3524ef in select () from /usr/lib64/libc.so.6
#1  0x0000557dbc0dbfdd in rdr::FdOutStream::writeWithTimeout(void const*, unsigned long, int) ()
#2  0x0000557dbc0dc13e in rdr::FdOutStream::flush() ()
#3  0x0000557dbc0dbdd2 in rdr::FdOutStream::overrun(unsigned long, unsigned long) ()
#4  0x0000557dbc0be871 in rfb::SMsgWriter::writeServerCutText(char const*, int) ()
#5  0x0000557dbc0c43f2 in rfb::VNCSConnectionST::serverCutTextOrClose(char const*, int) ()
#6  0x0000557dbc0b4ae2 in rfb::VNCServerST::serverCutText(char const*, int) ()
#7  0x0000557dbc0a7042 in XserverDesktop::serverCutText(char const*, int) ()
#8  0x0000557dbc09c164 in vncServerCutText ()
#9  0x0000557dbc0a4603 in vncProcSendEvent ()
#10 0x0000557dbc0f308b in Dispatch ()
#11 0x0000557dbc0f70e6 in dix_main ()
#12 0x00007fcd1e2826a3 in __libc_start_main () from /usr/lib64/libc.so.6
#13 0x0000557dbbfcae6e in _start ()

strace: Process 3782047 attached with 33 threads
[pid 3782084] 14:46:37.101495 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782083] 14:46:37.101527 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782082] 14:46:37.101536 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782081] 14:46:37.101543 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782080] 14:46:37.101550 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782079] 14:46:37.101558 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782078] 14:46:37.101565 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782077] 14:46:37.101572 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782076] 14:46:37.101579 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
[pid 3782075] 14:46:37.101587 futex(0x557dbe1eefd0, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[CendioOssman]

We've updated that code a fair bit since 1.11.0. Do you think you could try 1.12.0, or a nightly build?

It looks like it is trying to send clipboard data when this happens. Have you noticed if this happens when you do something specific?

Is Xvnc consuming a lot of CPU when this happens?

And is the viewer locked up as well?

[erikniessen]

We've updated that code a fair bit since 1.11.0. Do you think you could

try 1.12.0, or a nightly build? I can give that a try.

>It looks like it is trying to send clipboard data when this happens. Have

you noticed if this happens when you do something specific? No, we don't have specific step(s) to reproduce this issue.

Is Xvnc consuming a lot of CPU when this happens?

No, normal cpu load for Xvnc.

And is the viewer locked up as well?

Yes, all clients are locked up. I don't understand why an issue in the clipboard is locking up all vnc clients?

…

On Mon, 21 Nov 2022 at 14:26, Pierre Ossman (Work account) < ***@***.***> wrote: We've updated that code a fair bit since 1.11.0. Do you think you could try 1.12.0, or a nightly build? It looks like it is trying to send clipboard data when this happens. Have you noticed if this happens when you do something specific? Is Xvnc consuming a lot of CPU when this happens? And is the viewer locked up as well? — Reply to this email directly, view it on GitHub <#1551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4IOBLPU7JEC6L7HXYJFU6DWJN2B3ANCNFSM6AAAAAASESSNGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[CendioOssman]

Yes, all clients are locked up.

I probably need to clarify this a bit, with a locked up client I mean that you cannot interact with the client at all. E.g. you can't even close the viewer or open the F8 menu.

I don't understand why an issue in the clipboard is locking up all vnc clients?

It shouldn't. This is some form of bug. But we need to figure out what is triggering it in order to come up with a fix.

[erikniessen]

Yes, all clients are locked up.

I probably need to clarify this a bit, with a locked up client I mean that

you cannot interact with the client at all. E.g. you can't even close the viewer or open the F8 menu. We can still close the viewer. To summarize: - All vnc-viewers connected to this vnc server don't get any screen updates no interaction possible for a period between 1 min and 16 min - after that VNC freeze we can continue as normal - During the vnc freeze the CPU load of the vncserver is low - stacktrace shows that Xvnc tries to flush its clipboard buffer, but since there is no space it keeps looping in a select() call with 5ms timeout Any ideas how I can debug this further?

…

On Thu, 24 Nov 2022 at 16:23, Pierre Ossman (Work account) < ***@***.***> wrote: Yes, all clients are locked up. I probably need to clarify this a bit, with a locked up client I mean that you cannot interact with the client at all. E.g. you can't even close the viewer or open the F8 menu. I don't understand why an issue in the clipboard is locking up all vnc clients? It shouldn't. This is some form of bug. But we need to figure out what is triggering it in order to come up with a fix. — Reply to this email directly, view it on GitHub <#1551 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4IOBLNEVVWM3445RUYVJ2TWJ6CAVANCNFSM6AAAAAASESSNGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[CendioOssman]

All right, so for some reason it thinks there is a lot of clipboard data. Could you check bandwidth usage when this happens? Does it seem to be hogging all available capacity?

And could you try 1.12.0? We redid a lot of the network handling there.

[erikniessen]

Short update on this issue:
I could reproduce the issue with 1.11.0
But 1.12.0 fixed our issue.

Thanks for your help.

[CendioOssman]

Glad to hear that. Thanks for testing.

[PooyaZv]

@erikniessen I can still see either this or a similar issue with 1.12.0. Basically the screen suddenly freezes and this is not in the middle of any particular operation. I'm using VNC viewer on Windows connecting to tigervnc 1.12.0 on Ubuntu 22.04. My settings are basically out-of-the-box without a custom xstartup file, etc. Once the session hangs, killing the session and trying to create a new session shows the error "Session startup via '/etc/X11/Xtigervnc-session' cleanly exited too early (< 3 seconds)!" What additional information can I provide for debugging?