Bug 141056 - X forwarding via ssh fails for some apps
X forwarding via ssh fails for some apps
Status: CLOSED DUPLICATE of bug 134425
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-28 17:40 EST by Bob T.
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:07:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bob T. 2004-11-28 17:40:11 EST
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-28 19:47:08 EST
This looks like a dup of bug 134425
Comment 2 Bob T. 2004-11-28 22:08:51 EST
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 14:07:18 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.