Hide Forgot
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:
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?