Bug 125698

I still suspect the X to be the quilty one, because if to start any
other application, these will throw somilar errors as well:

[ivo@sarmax ivo]$ ssh ivo@haskaa
ivo@haskaa's password:
Last login: Fri Jun 11 01:22:39 2004
[ivo@haskaa ivo]$ kuickshow
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x103
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x20a
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
_KDE_IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
Xlib:  extension "GLX" missing on display "localhost:10.0".
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  20
  Minor opcode:  0
  Resource id:  0x103
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
X Error: BadAtom (invalid Atom parameter) 5
  Major opcode:  18
  Minor opcode:  0
  Resource id:  0x20a
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
X Error: BadWindow (invalid Window parameter) 3
  Major opcode:  2
  Minor opcode:  0
  Resource id:  0x48
kbuildsycoca running...

...and if to exit the kuickshow then:

X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  7 (X_ReparentWindow)
  Resource id in failed request:  0x48
  Serial number of failed request:  10503
  Current serial number in output stream:  10687
[ivo@haskaa ivo]$

Another one:

[ivo@sarmax ivo]$ ssh root@ragana
root@ragana's password:
Last login: Wed Jun 16 13:41:34 2004 from skhal
[root@ragana root]# redhat-config-users
The program 'redhat-config-users' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 36 error_code 3 request_code 25 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.)
[root@ragana root]# The program 'redhat-config-users.py' received an X
Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 45 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.)

Still th same results:
xorg-x11-6.7.0-4

This isn't an xorg bug, it is an mc bug.  The error you see is
because mc is passing invalid parameters to an X library function,
so the function is giving an error indicating that the calling
application is incorrectly using the routine.

Updating X wont fix this.

This issue affects wide variety of applications, how does all sort of
applications suddenly became invalid?
Something must have changed over X side to get this error appear...

Are anyone looking into it or it is just a sad feature to have?

    I can't reproduce this bug no matter how hard I try. Please add
details about your localization, mc version, kde version and so on...
Also give a try to
http://www.ottolander.nl/opensource/srpms/fc1/mc-4.6.0-14.10n.src.rpm.
    I only have problem to 'ssh somewhere; sudo su -; start_x_app',
while 'ssh somewhere; su -; start_x_app works'.

I don't think the src rpm in comment #7 is relevant wrt this bug as it
only contains extra UTF-8 patches. It might be that
http://www.ottolander.nl/mc-patches/suse91/full/mc-4.6.0-X-error.patch
is relevant to this situation. See if it fixes the crash.

Jakub, the X error patch might need to be applied anyway if we stay
with mc-4.6.0. Not sure if upstream CVS needs a similar fix, but the
patch doesn't patch against the current tree.

I have updated FC2 to latest available packages for it (provided by
yum & synaptic). The issue came with some updates I made, but I do not
recall what.

On FC2:
[ivo@sarmax ivo]$ rpm -q kdebase
kdebase-3.2.3-1
[ivo@sarmax ivo]$ rpm -q xorg-x11
xorg-x11-6.7.0-6

The MC crashing here is the remote MC on FC1:
[ivo@haskaa ivo]$ rpm -q mc
mc-4.6.0-14.10

As the MC is not only one giving "BadWindow (invalid Window
parameter)", maybe the SSH have it's part in this issue?
SSH on FC2:
[ivo@sarmax ivo]$ rpm -q openssh
openssh-3.8.1p1-4

SSH server on FC1 side:
[ivo@haskaa ivo]$ rpm -q openssh-server
openssh-server-3.6.1p2-19

Local FC2:
[ivo@sarmax ivo]$ echo $LANG
en_US.UTF-8

Remote end FC1:
[ivo@haskaa ivo]$ echo $LANG
en_US

Btw: SSH'ig into FreeBSD and starting MC 4.6.0 over there is working
OK (somehow echo $LANG is empty there, also).

Per Leonard den Ottolander advice I tried to get a crash backtrace (I
added "ulimit -c 100000" to ~/.bashrc) but I get no dump file. Where
it should land?
Also, I updated MC to version mc-4.6.0-16 on this FC1, but no changes
in behaviour.
I try some more tricks...

I tried this under Gnome as well, the same results.

I have tried to get backtrace of the crash, but all arrows point to
abort, not a crash: 

> > If you are running Gnome Bug Buddy should pop up on a crash. Are you
> > really experiencing a crash or an abort? 
> 
> I get:
> 
> [ivo@haskaa ivo]$ X Error of failed request:  BadWindow (invalid Window
> parameter)elp   2Menu   3View   4Edit   5Copy   6RenMov 7Mkdir  8Delete
> 9PullDn 10Quit
>     Major opcode of failed request:  38 (X_QueryPointer)
>                                                           Resource id in
> failed request:  0x48
>                 Serial number of failed request:  6
>                                                      Current serial
> number in output stream:  6
>                [ivo@haskaa ivo]$
> 
> I do not know if it is an abort or crash, but MC will die and konsole
> will become useless (characters typed after this are invisible).

That looks like an abort. The program (mc) stops because it gets into
a situation it can't handle.

I upgraded second box from FC1 to FC2. SSHing out of it and running MC
will cause no issues.

Current state:
[root@ragana root]# rpm -q mc
mc-4.6.0-15
[root@ragana root]# rpm -q openssh
openssh-3.6.1p2-34
[root@ragana root]# rpm -q kdebase
kdebase-3.2.2-4
[root@ragana root]# rpm -q xorg-x11
xorg-x11-6.7.0-5
[root@ragana root]# echo $LANG
en_US.UTF-8
[root@ragana root]# echo $TERM
xterm
[root@ragana root]#

I'll update it to the same state the first FC2 is and let seet what it
will bring out.

Another piece of information:
The remote host must not even be a another computer. I get the same
"results" even if to SSH into the same computer.

MC is working OK over telnet, but SSH is failing.

Can it be SSH issue after all?

Try 'unset DISPLAY'. If this works I belive it's ssh X authentication
problem. Try creating new user, some old files in your home can cause
trouble...

"unset DISPLAY" before SSHing did the trick - no MC abort!

It seems not to be related to old config files, even SSHing with new
user has the same issue.

Where to look next?

Although this report is a little older than bug 125838 I'll close this
one as a duplicate of 125838 as the latter is less cluttered.


*** This bug has been marked as a duplicate of 125838 ***

Not entirely the same issue as bug 125838. Reopening.

If your client is OpenSSH 3.8 or later, you may need to use the -Y
option instead of the -X option when opening connections which need
X11 forwarding.  You can find more information about why this is
necessary at http://www.openssh.com/faq.html#3.13

Does running ssh with either the -x or -Y flag resolve/work around this?

I use "-Y" and it's been OK.

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

Wrt comment 22: That is probably the fix and this report a duplicate
of an issue that has been reported quite a while ago. SSH's behaviour
changed a while back.

*** This bug has been marked as a duplicate of 137685 ***