Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 493097

Summary:

vino-server crashes with BadImplementation error

Product:

Red Hat Enterprise Linux 5

Reporter:

Greg Matthews <greg.matthews>

Component:

vino

Assignee:

Søren Sandmann Pedersen <sandmann>

Status:

CLOSED ERRATA

QA Contact:

desktop-bugs <desktop-bugs>

Severity:

high

Docs Contact:

Priority:

high

Version:

5.3

CC:

cepheid, Colin.Simpson, greg.matthews, jbastian, kem, rbiba, rkhadgar, syeghiay, tao

Target Milestone:

Target Release:

---

Hardware:

i386

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Clones:

506497 (view as bug list)

Environment:

Last Closed:

2009-11-18 09:58:47 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

499522, 506497

Attachments:

Description	Flags
patch based on upstream code	none

Description Greg Matthews 2009-03-31 16:05:15 UTC

Description of problem:
desktop sharing causes vino-server to crash


Version-Release number of selected component (if applicable):
$ rpm -q vino
vino-2.13.5-6.el5.i386


How reproducible:
always


Steps to Reproduce:
run vino-server from the command line using /usr/libexec/vino-server
attempt to connect to it using vncviewer
  
Actual results:
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)

vino-server crashes:

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.)


Expected results:
desktop sharing

Additional info:

Comment 1 Amir Caspi 2009-03-31 19:15:07 UTC

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.

Comment 2 Amir Caspi 2009-03-31 19:17:34 UTC

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. =)

Comment 3 ritz 2009-04-07 19:52:48 UTC

Created attachment 338587 [details]
patch based on upstream code

thanks to rryder for pulling in the patch from upstream.

Comment 4 Amir Caspi 2009-04-07 20:16:18 UTC

(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?

Comment 5 ritz 2009-04-07 21:10:46 UTC

> 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.
http://www.redhat.com/security/updates/backporting


> 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?  
the patch applies cleanly.

-- ritz

Comment 6 Amir Caspi 2009-04-07 22:39:15 UTC

(In reply to comment #5)
> http://www.redhat.com/security/updates/backporting

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!

Comment 7 Greg Matthews 2009-04-08 11:46:34 UTC

confirm that the patch above appears to work. Testing is ongoing.

Comment 8 ritz 2009-04-08 17:50:03 UTC

> 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.

Comment 9 Amir Caspi 2009-04-08 18:11:05 UTC

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...

Comment 10 Colin.Simpson 2009-04-22 15:05:37 UTC

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?

Comment 22 Jeff Bastian 2009-08-12 18:16:58 UTC

On a side note, imlib was also affected by the change in SHM pixmaps in the nvidia drivers, see bug 487536.

Comment 23 Greg Matthews 2009-10-01 10:26:32 UTC

so, redhat release a new version of vino without this fix... can this /please/ be included in future vino releases?

Comment 28 errata-xmlrpc 2009-11-18 09:58:47 UTC

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.

http://rhn.redhat.com/errata/RHBA-2009-1590.html