Bug 141056 - X forwarding via ssh fails for some apps
Summary: X forwarding via ssh fails for some apps
Status: CLOSED DUPLICATE of bug 134425
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-28 22:40 UTC by Bob T.
Modified: 2007-11-30 22:10 UTC (History)
0 users

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


Attachments (Terms of Use)

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.


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