Bug 138617 - ssh of X apps breaks cut'n'paste and causes crash
ssh of X apps breaks cut'n'paste and causes crash
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brian Brock
: MoveUpstream
: 140924 142957 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-10 04:41 EST by kb
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-19 03:46:55 EDT
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 kb 2004-11-10 04:41:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5)
Gecko/20041104

Description of problem:
steps to reproduce:
1. log in to the system as root via ssh
   ssh localhost -X -C -l root

2. open emacs the following way:
   cd /opt/openoffice1.9.60/share/dict/ooo
   emacs dictionary.lst &

3. klick a few times in the emacs windows, crash.

the following output is given on the terminal:

[root@computer ooo]# X protocol error: BadWindow (invalid Window
parameter) on protocol request 38

[1]+  Exit 70                 emacs dictionary.lst


Version-Release number of selected component (if applicable):
GNU Emacs 21.3.1

How reproducible:
Sometimes

Steps to Reproduce:
see above

Additional info:
Comment 1 kb 2004-11-10 07:17:45 EST
this actually seems to be only X on my FC3 that has problems.
if i connect to other machines i get the same problem.

if emacs starts at all it usually crashes after a short while with the
message as above.

sometimes it dioes not start at all, the remote machine says:
[user@remote user]# Xlib: connection to "localhost:12.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
emacs: Cannot connect to X server localhost:12.0.
Check the DISPLAY environment variable or use `-d'.
Also use the `xhost' program to verify that it is set to permit
connections from your machine.

[1]+  Exit 1                  emacs file.txt
Comment 2 Jens Petersen 2004-11-10 08:39:04 EST
It only crashes when you ssh in as root?
And for the above dictionary file?

Sounds like it could be a xorg-x11 issue.
Comment 3 kb 2004-11-10 08:59:48 EST
it happens both as normal user and root.

here is another example, it does not matter which machine i connect
to, the problem seems to be locally with FC3.



ssh computer2.localdomain.abc -X -C -l myusername

after i get logged in i do the follwing:

[myusername@computer2 ~]$ emacs dead.letter &
[1] 22779
[myusername@computer2 ~]$ X protocol error: BadWindow (invalid Window
parameter) onprotocol request 38

[1]+  Exit 70                 emacs dead.letter




when the emacs windows is opened it first works for a short while.
but after changing fucus to other windows and then back to the emacs
windows a few times (1-6) emacs dies with the message:
X protocol error: BadWindow (invalid Window parameter) onprotocol
request 38

i have tried against servers/computers of the following type:
localhost runs FC3. this is the machine i am on.
computer2 runs redhat8.0.
a third server that runs sunos 5.9
all produce the same problem
Comment 4 kb 2004-11-10 09:34:30 EST
you seem to be right agoub that this is a x issu rather then emacs.
i jst reinstalled the xorg-packages (with --force), restarted the x
server and tested again, same problem.
i tested using both KDE and xfce.

maybe the summary should be changed?
Comment 5 kb 2004-11-10 10:00:32 EST
here is some more input, dont know if it helps but anyway.
i have reinstalled my openssh packages. no changes.


if i run ethereal locally (from terminal) on the RH8 machine all works
fine. no errors etc.

if i connect from the FC3 machine using ssh as above (as root) and try
to run ethereal, it starts up and then after a few times focus/defocus
to ethereal it crashes leaving the following on the terminal:

Gdk-ERROR **: BadWindow (invalid Window parameter)
  serial 3334 error_code 3 request_code 38 minor_code 0
Gdk-ERROR **: BadAccess (attempt to access private resource denied)
  serial 3335 error_code 10 request_code 102 minor_code 0

[1]+  Exit 1                  ethereal




just to test i also ran up2date on the RH8 machine, locally it says
nothing. remotly run it says:
Xlib:  extension "RENDER" missing on display "localhost:11.0".

up2date did not crash however.
Comment 6 kb 2004-11-10 12:21:47 EST
after reading some messages on fedora-list i treid using the -Y option
instead of -X, at the moment it seems to work.
Comment 7 Thomas Moschny 2004-11-18 16:02:29 EST
I can confirm that problem, too. If emacs is started over a ssh
connection, it not only crashes on mouse drag operations, but also
does'nt accept clipboard pasting via middle-mouse click. Using the -Y
option of ssh seems to work here, too.
Comment 8 Deron Meranda 2004-11-23 11:38:47 EST
I also confirm.  It does not appear to be emacs itself, but it's
interaction with X and/or the ssh X-tunnel.  It doesn't matter what OS
you ssh into.  I even did an ssh into an HP-UX machine, and started
emacs 20.7.1 (old) with its window mapped back to my FC3 desktop, and
it had problems too.

Pasting (either via middle-mouse-click or the emacs Edit->Paste menu)
always gives a "Kill ring is empty" error in the emacs status line.
I then started an "xterm" also over the ssh X-tunnel...and
middle-mouse-paste is also broken for it.  (So the paste issue is
definitely unrelated to emacs).

I also tried to do selection and paste the other way; and that too is
broken.  (e.g., highlighting text in the ssh'd xterm and trying to
paste it into a local application resulted in nothing being pasted).

As far as the crash, I've not reproduced that against an HP-UX server,
but I have against other non-Fedora Linuxes.

An emacs started locally (within FC3) works fine.

This sounds like two problems...one is the emacs crash, the other is
the ssh-X-tunnel paste disfunction.
Comment 9 Jens Petersen 2004-11-23 22:03:31 EST
Deron, with -Y cut'n'paste works?
Comment 10 Jens Petersen 2004-11-23 22:04:48 EST
I propose closing this notabug... any objections?
Comment 11 Deron Meranda 2004-11-23 23:06:38 EST
Yes, adding a -Y option to ssh seems to work as far as the cut-n-paste
error (with FC3 being the ssh client (and the X server)).  I tested
also against my HP-UX server (running openssh 3.8.1) to make sure it
works with it too.  I don't know about the emacs crashing.  This may
solve it, but I'm not in the position to reliably test or prove that
one way or the other yet.

For the benifit of other people reading this, rather than supplying a
-Y option to ssh, you can also put the setting "ForwardX11Trusted=yes"
into their ~/.ssh/config file.


The real culprit here is openssh.  FC2 shipped version 3.6.1, while
FC3 uses 3.9.  The trusted X forwarding feature was first introduced
in ssh version 3.8.  See the release notes at:
<http://www.openssh.com/txt/release-3.8>

I would say this can be closed.  But should this be relabeled as an
"ssh" component rather than "emacs", or the title changed to better
indicate this manifests itself as a cut and paste failure?
Comment 12 kb 2004-11-24 01:01:12 EST
no objections
Comment 13 Thomas Moschny 2004-11-26 09:28:16 EST
Not sure, whether this really *isn't* an emacs bug after all.

When I log ssh from one fc3 machine to another fc3 machine with
ForwardX11Trusted=no, emacs dies with an "X protocol error: BadWindow
(invalid Window parameter) on protocol request 38" after a while or
when dragging with the left mouse button.

From googling other mailing list archives I have the impression that
all X applications (or their toolkits, respectively) need to be fixed
to cope with the limited functionality they get as untrusted clients.

BTW, setting "ForwardX11Trusted=yes" in ~/.ssh/config is not feasible
in a heterogenous environment with nfs mounted homes, because older
openssh clients unfortunately don't ignore this option.
Comment 14 Steffen Persvold 2004-11-27 10:37:58 EST
Just to clarify, the ForwardX11Trusted is a new feature in opensh 3.8,
right ? Does that mean that on previous versions, all X11 forwarding
was "Trusted" per default (i.e with an older openssh client you will
not have this issue because the X11 forwarding _is_ "trusted" even
without the explicit ssh option) ?

So what is the real difference between a "trusted" X11 forwarding
tunnel and a regular one (when you only have ForwardX11=yes) ?
Comment 15 Steffen Persvold 2004-11-27 10:40:33 EST
*** Bug 140924 has been marked as a duplicate of this bug. ***
Comment 16 Deron Meranda 2004-11-27 14:05:35 EST
FYI, the "trusted" X11 forward has to do with the X authentication
(e.g., MIT Cookies) that get set up.  It's really nothing to do with
ssh, it's just that as of ssh 3.8 that inherent capability of X is now
exposed.  From ssh's perspective the only difference between -X and
-Y, is when it runs the xauth program behind the scenes it gives
different command line options...

With -X (ForwardX11):

   xauth -f <xauthfile> generate <displayname>

With -Y (ForwardX11Trusted):

   xauth -f <xauthfile> generate <displayname> untrusted timeout 120

You'll need to dig around the X11 documentation to figure that out. 
The xauth manual page is a start.  But it points to the X Security
Entension documentation for the details.

I do agree that applications (such as emacs) should handle nontrusted
X displays instead of crashing.
Comment 17 Thomas Moschny 2004-11-28 06:13:41 EST
So I would say, we should change the component tag back to emacs.
Comment 18 Mike A. Harris 2004-11-28 07:19:05 EST
Reassigning back to emacs component as per multiple requests above,
so emacs can be fixed to not crash.
Comment 19 André Johansen 2004-12-15 10:09:44 EST
*** Bug 142957 has been marked as a duplicate of this bug. ***
Comment 20 Jens Petersen 2005-02-24 09:25:57 EST
It seems even cvs emacs still has this problem.
I suggest moving this problem to upstream
Comment 21 Jens Petersen 2005-02-24 09:28:22 EST
Having said that, how do you expect Emacs to handle this situation?
Printing a friendlier warning/error message and exiting?
Comment 22 Thomas Moschny 2005-02-24 10:27:40 EST
Exiting is definitively not ok. It should be possible to *use* emacs as an
untrusted X11 client, albeit with some limitations. 

A warning however could inform the user about those, e.g. why exchanging data
with the clipboard doesn't work.
Comment 23 Keith McNeill 2005-03-23 11:55:04 EST
same thing happens with xterm.  Adding ForwardX11Trusted to .ssh/config fixed
the problem.
Comment 24 Jens Petersen 2005-04-07 21:43:21 EDT
Hmm, now I'm having trouble reproducing this on my fc3 box and with current
rawhide: cut'n'paste to/fro emacs and switching windows back and forth to emacs
seem to work just fine for me now with -X.
Comment 25 Jens Petersen 2005-04-07 21:44:10 EDT
This is still reproducible with uptodate FC3?
Comment 26 kb 2005-04-18 15:46:53 EDT
i too have trouble to reproduce it on FC3, maybe it went away?

WORKSFORME?

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