Red Hat Bugzilla – Bug 146239
X11 crashes applications ov SSH-forwarded DISPLAY
Last modified: 2007-11-30 17:10:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
I am logged onto an fc3/i686 (2xPIII). I log onto a distant machine,
with X11Forward & ForwardAgent on in my /etc/ssh/ssh_config. Once
logged on the distant machine (sample is for a rhel3/ia64, bit it
happens with any machine), DISPLAY is correctly redirected.
When I run xterm or gedit from this remote display, things work fine.
Some other GNOME applications (e.g. op_visualize) crash the X11 display.
op_visalize: when I click the menubar "File" button
emacs : when I click the "New file" button in the toolbar.
[fxk@tarifa1 fxk]% ssh email@example.com
Last login: Wed Jan 26 11:21:34 2005 from tarifa1.grenoble.hp.com
[root@conjnor root]# echo $DISPLAY
[root@conjnor root]# xterm
[root@conjnor root]# gedit
[root@conjnor root]# op_visualise
The program 'op_visualise' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 789 error_code 3 request_code 38 minor_code 0)
(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()
[root@conjnor root]# emacs
X protocol error: BadWindow (invalid Window parameter) on protocol
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: Remote X11 application with redirected DISPLAY crash.
Expected Results: X11 applicatiom should remain up.
This problem does neither occur with FC2 not FC1 (which where kept
up2date until I upgrade my FC1 to FC3 recently)
Does using ssh -Y help? If so it looks like you have been caught out by the "ssh
-X is now ssh -Y" change. (If -Y does help you can read more about the change in
bug #141515 )
Yes, this is due to "ssh -X" being changed by openssh.org to
now be "ssh -Y", so unless you reconfigure ssh manually, remote
X applications will not run properly unless they handle the
X-SECURITY extension properly. Most applications do not, and so
the default ssh configuration out of the box is not suitable
for running remote X applications, until you reconfigure it
to change the default to forwarding untrusted clients also,
or invoke it with -Y.
Reassigning to openssh component.
*** This bug has been marked as a duplicate of 137685 ***