x0tigervncserver crashes on user action under VNC desktop #869
Comments
|
Hmm... very odd. The X server seems to be disconnecting us. Could you test one of our nightly builds and see if it behaves the same? |
|
That is the latest stable release. But it is helpful to know that it shows the same behaviour as Debian's build. The nightly builds are available via a link on our homepage, pointing to http://tigervnc.bphinz.com/nightly/. Please test |
|
Here it is: |
|
Great, thanks. So it seems the issue is still there. Not sure how to debug this. Could you try running it via |
|
There don't seem to be binary packages for |
|
You need to omit the |
|
Ok, here is the result. I'm just posting the end, because the full log is very long: I replaced the host name with I have the impression that the error occurs more often (but not exclusively) when a Java GUI application starts. |
|
Unfortunately there is nothing obviously wrong there. :/ Could you check the X server log (the one on |
|
I again ran x0vncserver with xtruss and connected via VPN until a crash occurred – at 16:36. After that, The card has many outputs of which I only use one (DFP-2), and at this time the attached monitor is switched off, so all outputs are reported as disconnected in the last message. I switched the monitor off yesterday evening at about 18:00, but X is continuing to run and I was able to connect via x0vncserver. So as far as I can tell, there is no information about the crash in the X server log. |
|
The timestamps are seconds since launch I think, so they're a bit of a pain to work with. Could the crash be when the local display decides to go in to standby? The driver might be doing something silly at that point. On the same note; do you think you could test with a different graphics driver temporarily? |
|
I don't think it is related to standby. I access the computer from home after having left work, so by the time I do it the computer should already be in standby. I can connect despite of that, and then the crash usually happens after a few minutes, well before standby should kick in again. Moreover, it happens while I use the computer remotely, so standby should be prevented by my continuous mouse and keyboard interaction. Switching between nvidia and nouveau drivers is a bit of a hassle, but I'll see whether I can get around to doing it. |
|
I am also encountering this problem - here is a gdb backtrace from when the error is thrown: I was actually going to try to build a workaround for this to see if it's just a transient error that could be retried by changing this in Image.cxx: (or perhaps skip the grabRegion portion of writeUpdate if this exception occurs and just try the next time) However I have not yet been successful in getting a build environment setup to compile. Is there a docker image or a vm or something that is pre-configured for tigervnc builds? |
|
Followed build instructions on a clean 16.04 ubuntu vm, but ended up failing at the make for unix/xserver: It would be tremendously helpful if someone could provide some steps to setup a tigervnc build environment from scratch that matches the environment used to build the official linux binaries. E.g. start with stock Centos #.##, yum install [pkgs], etc, etc (or debian, or ubuntu - whatever matches the official build server) |
|
Managed to compile a new x0vncserver with the above code, but unfortunately there is no exception thrown - the XIOError simply calls "exit". I think this url is very pertinent to the issue at hand (at least based on the stack trace that I'm getting): https://stackoverflow.com/questions/23871516/xreply-terminates-app-with-xioerror |
|
What's odd is that the libxcb being used on my system is 1.1.0 which is before the issue noted above. None of the libs being used by x0vncserver have changed. I've been using the same version of x0vncserver for a long time, but it started exhibiting this problem after a system update a few days ago. I've been reviewing the update logs to see which libs/programs were changed to find the root cause, but I don't see any overlap. Xvnc doesn't seem to exhibit this problem, so I might have to use that as a workaround if I can't figure out what's gone awry here. For additional information, I can reliably make it crash if I open chrome and go to something like youtube and start playing a video. Sometimes just opening chrome and having it visit the homepage of www.google.com is enough to cause the crash, but playing a youtube video makes it crash in a few seconds. |
|
Are you also on Debian 10, @SvenCarlberg? |
|
The system in question is ubuntu 14.04 which has been semi-updated to 16.04 (never went through full upgrade, but using 16.04 repos for many programss/libs) I have at least got a workaround for my problem - I forced X11 to use the fbdev driver by creating /usr/share/X11/xorg.conf.d/20-fbdev.conf with this content: No more weirdness, but I'm no longer using the official i915 Intel driver (for the CPU's onboard GPU). I still have some 3D acceleration (glx, etc) but I don't know what (if anything) I'm losing by using fbdev instead of the driver which would seem to be more specific for my GPU. I don't do anything graphics-intensive, so probably nothing lost. Maybe this will help the OP (i.e. try changing your X driver and see if that helps). Or perhaps they're hitting the libxcb issue noted earlier. I think that the main culprit was actually chrome in my case. That was updated in the aforementioned system update and it seems that everything was working fine as long as I didn't try to use chrome. As soon as I opened chrome and started using it for anything substantial, I got that libxcb abort. |
|
Very odd. But thanks for the extra info. Someone will have to try to reproduce this and try to debug the code where it goes wrong. I'm afraid I don't think I have time anytime soon myself though. Hopefully someone else can have a look. |
|
Hi @SvenCarlberg how did you solved the RandrGlue.h missing problem? |
|
@Benik3 I hand-edited the Makefiles to add some absolute paths to the relevant include directories. Also remember you need to pass in the src dir during make - e.g.: make TIGERVNC_SRCDIR=../../../tigervnc-1.10.0 |
|
Thanks. I will try something (It's first time what I try build something :D ) |
|
I get a similar error here. I forward part of the screen with x0tigervncserver. And after some time, the server just crashes. However, I observed a few occations where this happens regulary:
What did not provoke a crash
I got the follwing error (including the Stacktrace): Perhaps, Chrome is using some X extension that the screen grabbing does not like/handle? |
|
i solved using vnc4server! |
That should not affect things as we're not monitoring things on such a low level. We're simply getting notifications when the screen changes and then try to get those changed pixels. So far the reports have been on either Debian or Ubuntu. I wonder if they simply have a bug in their libX11 or X server that we are triggering. @stettberger, what version of Debian/Ubuntu are you using? |
|
I'm using debian unstable on the VNC Server. Here are a few version numbers that could be of interest. |
|
#869 (comment) |
|
It is very easy to trigger if you hover the mouse over the task switcher causing live previews to be shown @stettberger are you running kwin? What rendering backend do you use? |
|
I am also seeing this crash in x0vncserver: |
|
I have also run into this issue with the 1.9.0 package of x0vncserver on Debian 10, while using the OSX screen sharing as a client. It seems a I use the X display as much as I want, but the moment I open a shell and attempt type, that's when the connection drops for me. Here is the server output: I also tried with Protocol3.3 enabled / disabled, and there was no change. I will try another client, and updated server later. |
|
I can reproduce this problem (or one very like it) easily and reliably, so if there is anything I should test or debug, I'm happy to help. The end of |
|
I have had a similar issue recently. I used to run x11vnc but autonomous key repeats began to appear after a system upgrade, which made VNC sessions unusable. After switching to x0vncserver, the crash problem also occurred to me. I can easily reproduce the crashes with KDE App Launcher. Here are a few excerpts from /var/log/syslog: Jun 15 08:01:21 MacPro start_vncserver.sh[91001]: [xcb] Unknown sequence number while processing queue After these repeated crashes, key strokes became unusable. I needed to use mouse to logout and login to reset. Sometimes I could see a similar autonomous key-repeating event on App Launcher after reestablishing a new VNC session. It seemed to me the problem is related to how key strokes are handled among x0vncserver, X server, and X applications. Because x11vnc also has the strange key-repeating issue, probably a recent upgrade of X itself has something to do with these. |
|
@DanFulger seems to be on to something here with Glamor. Could a few more of you guys also see if the problem goes away if Glamor is disabled? |
|
For me, glamor, although technically enabled, doesn't seem to actually work: I'll try disabling it completely, explicitly, and see if it makes a difference. |
|
Unfortunately it doesn't. I disabled As well as But the The end of |
|
Googling around to see if it would maybe be possible to just ignore the EAGAIN, I came across https://stackoverflow.com/questions/25790890/xio-fatal-io-error-11-caused-by-32-bit-libxcb and tried the reproducer (which can also be found at https://bugs.freedesktop.org/show_bug.cgi?id=71338). I wasn't able to make the reproducer crash, so this is apparently not the "32 bit counter widening bug" in libxcb. For me, the x0tigervncserver crashes occur very frequently when a "hovering" window is displayed or disappears: windows such as tooltips in Opera, context menus, or window previous in the task switcher. My workaround, for now, is using a shell loop to keep restarting x0tigervncserver, like this: as well as the client, like this: This is still very inconvenient due to the frequent crashes. I'm also hitting another problem with this where x0tigervncserver would apparently lock up (the window doesn't update and no new messages are logged) without exiting; I'll file a separate issue about that if/when I get some useful debug info related to it. |
|
Followup on my two month old comment:
I have not tried with glamor disabled, but I when I start chrome --disable-gpu the crash no longer occurs, even during video playback. With GPU enabled the crash instantly reproduces, on both old and the most recent version of Chome. The GPU is the one inside the Intel processor. It could also be related to latency; the client and server are both connected to fixed Internet service from the same provider and located on the same street. |
|
Hi, I just ran into this problem too when I connected to one of my machines running x0vncserver and KDE under Debian. I solved the problem temporarily by switching the compositor output module from OpenGL to XRender. Maybe this workaround will help some of you until this bug is fixed. |
|
Ahoy! I believe I am hitting this bug as well, can reproduce using nightly: TigerVNC Server version 1.11.80, built Jun 1 2021 02:45:07. OS is Ubuntu 20.04.2 LTS (Linux nostromo 5.8.0-50-generic #56~20.04.1-Ubuntu SMP Mon Apr 12 21:46:35 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux). X Server is 1.20.9. Attaching output of And bare x0tigervncserver log: I'm not using Chrome, but rather Firefox. This happens with clients remmina on desktop and vnc connect by RealVNC on mobile (Android). Thank you for your attention! Please let me know how I can help troubleshoot this further. |
|
Has anyone reported this to your respective distributions? Or to the Xorg folks? The crash is in a system library so this isn't necessarily a bug in TigerVNC. They may be in a better position to figure out what is going on. |
|
I hit this issue too, using tigervnc-scraping-server package on Debian 11 with Nvidia proprietary driver. Window manager is Window Maker. A VNC client is x2vnc on Ubuntu 20.04. Moving a window can easily reproduce the issue. I could not find the root cause of the issue but I found a workaround. A x0vncserver binary compiled without |
CendioOssman
added
notourbug
|
enabling compositor fixed this issue for me EDIT: I have a theory of what' happening: if you have a look at https://cgit.freedesktop.org/xorg/proto/damageproto/tree/damageproto.txt - it says that XDAMAGE is taking special care handling multiple pixel storage areas used by compositing extension. But in case when compositing window manager is disabled - something confuses this part of generating rects from designated areas (maybe the regions are improperly mutexed on accelerated hardware, likely on proprietary AMD GPUs) so some rects get generated improperly and accessing them causes abort in XLib's XIO My hypothesis is that by analyzing the rects stream generated by XDAMAGE we can detect and skip the dangerous part of the stream - e.g. by looking at the rate or amount of rects generated The reason for thoughts is that disabling compositor crucially accelerates everything on my setup (tethered AMDGPU + VNC streaming of desktop to monitors rendered in a VR headset) so I would prefer using whatever workaround is available to cut down any milliseconds of lag |
|
I reported a few month ago at least the |
|
Nice find! Let's hope this is it, and that we get some attention from the libX11 developers. |
Describe the bug
I run x0tigervncserver on a Debian 10 (stable) computer remotely via ssh, in order to access the already running X session (with KDE, non-free nvidia-driver). I can connect to the VNC server using Remmina and the desktop gets displayed, I can open windows etc., but after a short while some action (e.g. clicking on the KDE menu, clicking on a window to change focus, etc.) lets the VNC server crash. Here is one example log, they look different in detail but always end with "fatal IO error 11":
To Reproduce
See above.
Expected behavior
The VNC server not to crash.
Client (please complete the following information):
Server (please complete the following information):
Additional context
The VNC connection goes through a VPN based on SonicWALL's ConnectTunnel application. I do not have any connectivity problems with this connection, e.g. when the VNC server started under SSH crashes, the SSH connection itself is unaffected.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: