Red Hat Bugzilla – Full Text Bug Listing
|Summary:||execution using ssh fails with "BadWindow (invalid Window parameter)"|
|Component:||openssh||Assignee:||Tomas Mraz <tmraz>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 14:06:36 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description james 2004-10-24 12:51:55 EDT
Description of problem: execution with ssh fails with "BadWindow (invalid Window parameter)" Version-Release number of selected component (if applicable): system-config-soundcard-1.2.10-1 How reproducible: always Steps to Reproduce: 1. set sshd_config: X11Forwarding yes 2. execute using ssh on local or remote system: #ssh <host> /usr/share/system-config-soundcard/system-config-soundcard 3. Actual results: On local system, there is: X Error: BadAtom (invalid Atom parameter) 5 Major opcode: 20 Minor opcode: 0 Resource id: 0x106 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 Minor opcode: 0 Resource id: 0x8c ... Ending, on both local and remote machines, with: The program 'system-config-soundcard.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 64 error_code 3 request_code 38 minor_code 0) (Note to programmers:... Expected results: soundcard detection window... Additional info: This may or may not be related to ssh. For instance, #ssh <remote> xcalc will work ok, but #ssh <remote> ... #xcalc fails with Xlib: connection to "localhost:10.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key Error: Can't open display: localhost:10.0 Other "/usr/share/system-config-*" programs fail similarly.
Comment 1 Barry K. Nathan 2004-10-24 21:23:37 EDT
For now, you can avoid this problem by using ssh's -Y option.
Comment 2 Bastien Nocera 2004-10-25 04:36:28 EDT
" Error: Can't open display: localhost:10.0" This means that the problem is with your ssh/X setup, not with system-config-soundcard.
Comment 3 Benjamin S. Scarlet 2004-11-22 15:26:25 EST
I get a similar failure whenever running ediff in emacs over ssh. local$ ssh <remote> remote$ xterm ... (xterm works, no DISPLAY problems) remote$ emacs ... (emacs works) in emacs, M-x ediff-buffers emacs dies every time with a BadWindow Adding -Y to the ssh flags does not help.
Comment 4 Benjamin S. Scarlet 2004-11-22 15:30:34 EST
(sorry, left off config info) I'm running Fedora Core 3 on i386, with everything up to date. The details of the emacs don't seem to matter. If I <remote> is localhost, I get the problem. If I don't ssh, but run emacs locally, it works. If I ssh from Fedora Core 2, the ediff works. If I ssh to a completely different platform, the emacs still dies.
Comment 5 Bill Petersen 2004-11-30 14:15:57 EST
This is critical for me. It worked fine with FC2, but started failing as soon as I installed FC-3 (not upgrade, but fresh install). ssh -X to machine run nessus after a few mouse movements, the Nessus/ssh session dies with the following message. Nessus is critical to me, and so I must have a fix soon or I will be forced to revert back to FC-2 to do my job. # The program 'nessus' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 3258 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() function.)
Comment 6 Mike Nuss 2005-01-04 13:57:51 EST
I have the same problem with just about every application. If I use ssh X forwarding and try to run an app, it crashes with a BadWindow error.
Comment 7 Tomas Mraz 2005-01-31 15:50:28 EST
*** This bug has been marked as a duplicate of 137685 ***
Comment 8 Red Hat Bugzilla 2006-02-21 14:06:36 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.