Red Hat Bugzilla – Bug 493097
vino-server crashes with BadImplementation error
Last modified: 2014-06-18 05:11:10 EDT
Description of problem:
desktop sharing causes vino-server to crash
Version-Release number of selected component (if applicable):
$ rpm -q vino
Steps to Reproduce:
run vino-server from the command line using /usr/libexec/vino-server
attempt to connect to it using vncviewer
vncviewer reports connection reset by peer:
CConn: connected to host localhost port 5900
CConnection: reading protocol version
CConnection: Server supports RFB protocol version 3.7
CConnection: Using RFB protocol version 3.7
main: read: Connection reset by peer (104)
31/03/2009 16:41:49 Autoprobing TCP port
31/03/2009 16:41:49 Autoprobing selected port 5900
31/03/2009 16:41:49 Advertising authentication type: 'No Authentication' (1)
31/03/2009 16:41:49 Advertising security type: 'No Authentication' (1)
31/03/2009 16:41:56 Got connection from client 127.0.0.1
31/03/2009 16:41:56 other clients:
The program 'vino-server' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadImplementation (server does not implement operation)'.
(Details: serial 101 error_code 17 request_code 147 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
I can confirm that the newest version of vino-server (2.26) does not have this problem (I built it from source). I don't know when the problem was fixed between 2.13 and 2.26. I would recommend using the newest build of vino-server anyway, however, as it integrates with gnome-session and provides an icon in the gnome-panel Notification Area to alert the user that sharing is active.
I would also request that if building a new version of vino for distribution, please make it compatible with RHEL 5.2 rather than just 5.3. =)
Created attachment 338587 [details]
patch based on upstream code
thanks to rryder for pulling in the patch from upstream.
(In reply to comment #3)
> Created an attachment (id=338587) [details]
> patch based on upstream code
Please pardon my ignorance, but:
1) Why use a patch instead of just building a newer version of vino? v2.13 is incredibly old; v2.26 is the most recent version.
2) The patch appears to be based on vino 2.8.1, which was the version included with 4.2... the version shipping with 5.2/5.3 is vino 2.13.5. Is this a problem?
> 1) Why use a patch instead of just building a newer version of vino? v2.13 is
> incredibly old; v2.26 is the most recent version.
> 2) The patch appears to be based on vino 2.8.1, which was the version included
> with 4.2... the version shipping with 5.2/5.3 is vino 2.13.5. Is this a
the patch applies cleanly.
(In reply to comment #5)
Thanks ritz, that makes sense. In the case of vino, however, it is an "independent" package in the sense that nothing relies on it or uses vino as a dependency; it should be safe (as in, it won't break anything) to include a newer version rather than backporting. Just MHO - you're the expert!
confirm that the patch above appears to work. Testing is ongoing.
> Thanks ritz, that makes sense. In the case of vino, however, it is an
> "independent" package in the sense that nothing relies on it or uses vino as a
> dependency; it should be safe (as in, it won't break anything) to include a
This would be decided by Product Management, based on issue tracker ( submitted via web support/tam and bugzilla ). There are times when I've seen bugs submitted by BZ on RHEL problems that wind up hanging in limbo because there isn't an issue tracker ticket associated with it.
Thanks for the explanation. Unfortunately I'm downstream (in CentOS) so I don't think I can open an issue tracker ticket. Hopefully someone else can undertake that...
I've got a feeling this bug is related to using the proprietary NVIDIA driver (or maybe exposed by using it). We saw this first appear during the last few releases in the 180.x series (can't remember if it worked on any of the 180.x series of NVIDIA drivers).
Anyway I applied the above patch to the SRPM of vino-2.13.5-6 and that fixes it in RH5. Great.
Also if anyone from RH is listening, this bug is also present in RH4.7's latest vino i.e. vino-2.8.1-1.5 . The above patch also applies with a few offset warnings to this SRPM.
+ patch -d /usr/src/redhat/BUILD/vino-2.8.1 -p1
patching file server/vino-fb.c
Hunk #1 succeeded at 569 (offset -13 lines).
Hunk #2 succeeded at 816 (offset 6 lines).
Hunk #3 succeeded at 845 (offset -13 lines).
+ exit 0
So if you are planing to release a fix for this in RH5 can it also be fixed in RH4?
On a side note, imlib was also affected by the change in SHM pixmaps in the nvidia drivers, see bug 487536.
so, redhat release a new version of vino without this fix... can this /please/ be included in future vino releases?
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.