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

It only crashes when you ssh in as root?
And for the above dictionary file?

Sounds like it could be a xorg-x11 issue.

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

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?

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.

after reading some messages on fedora-list i treid using the -Y option
instead of -X, at the moment it seems to work.

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.

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.

Deron, with -Y cut'n'paste works?

I propose closing this notabug... any objections?

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?

no objections

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.

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) ?

*** Bug 140924 has been marked as a duplicate of this bug. ***

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.

So I would say, we should change the component tag back to emacs.

Reassigning back to emacs component as per multiple requests above,
so emacs can be fixed to not crash.

*** Bug 142957 has been marked as a duplicate of this bug. ***

It seems even cvs emacs still has this problem.
I suggest moving this problem to upstream

Having said that, how do you expect Emacs to handle this situation?
Printing a friendlier warning/error message and exiting?

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.

same thing happens with xterm.  Adding ForwardX11Trusted to .ssh/config fixed
the problem.

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.

This is still reproducible with uptodate FC3?

i too have trouble to reproduce it on FC3, maybe it went away?

WORKSFORME?