Bug 141056

Summary: X forwarding via ssh fails for some apps
Product: [Fedora] Fedora Reporter: Bob T. <rdtennent>
Component: xorg-x11Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED DUPLICATE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:07:18 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:

Description Bob T. 2004-11-28 22:40:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Some apps are crashing with weird error messages when used remotely.
Here's what xdvi produces:

X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  18 (X_ChangeProperty)
  Atom id in failed request:  0x126
  Serial number of failed request:  179
  Current serial number in output stream:  181

Here's what xv produces:

X Error: BadWindow (invalid Window parameter)
  Major Opcode:  3

Other apps (e.g., xterm) work OK.  These problems never arose before
updating tp FC3.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.1-12.FC3.1  openssh-3.9p1-7

How reproducible:
Always

Steps to Reproduce:
1. ssh to another computer, forwarding X11
2. start one of the affected applications
3. observe the error message
    

Actual Results:  Application starts up, then crashes.

Expected Results:  Application works.

Additional info:

Problem seems to be on the local box, not the remote one.  The apps
work fine when not forwarded.

Comment 1 Sitsofe Wheeler 2004-11-29 00:47:08 UTC
This looks like a dup of bug 134425

Comment 2 Bob T. 2004-11-29 03:08:51 UTC
Hardly recognizable as a dup of 134425 but seems to have same
workaround: using ssh -Y. Why is there nothing in the release notes
about this? And what is the config-file analogue of -Y?  

*** This bug has been marked as a duplicate of 134425 ***

Comment 3 Red Hat Bugzilla 2006-02-21 19:07:18 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.