Bug 125698 - mc crash on remote host when to press any non-alphabetic key.
mc crash on remote host when to press any non-alphabetic key.
Status: CLOSED DUPLICATE of bug 137685
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
: 139970 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-10 05:52 EDT by Ivo Sarak
Modified: 2016-03-17 22:30 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-08 10:56:02 EST
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 Ivo Sarak 2004-06-10 05:52:35 EDT
Description of problem:
If I ssh out of FC2 running KDE (not under textmode console), start mc
over remote end and to press some other key than <,>, ..., a,b,...z
 the mc will die with:
"X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 38 (X_QueryPointer)"

Version-Release number of selected component (if applicable):
xorg-x11-6.7.0-2

How reproducible:
Always

Steps to Reproduce:
1. Install FC2;
2. Upgrade to latest packages;
3. Start KDE;
4. ssh to some other host and start mc;
5. Press arrow down;
  
Actual results:
"X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 38 (X_QueryPointer)"

http://www.vendomar.ee/~ivo/mc_crash.png

Expected results:
Nothing similar.

Additional info:
I get the crash with ssh'ing to both RH9 and FC1. Under textmode
console the same procedure is working just fine.
Comment 1 Ivo Sarak 2004-06-11 15:38:06 EDT
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...
Comment 2 Ivo Sarak 2004-06-11 15:39:30 EDT
...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]$
Comment 3 Ivo Sarak 2004-06-16 09:25:57 EDT
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.)

Comment 4 Ivo Sarak 2004-06-23 12:04:10 EDT
Still th same results:
xorg-x11-6.7.0-4
Comment 5 Mike A. Harris 2004-07-07 04:37:34 EDT
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.
Comment 6 Ivo Sarak 2004-07-09 07:02:29 EDT
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?
Comment 7 Doncho N. Gunchev 2004-07-16 17:10:41 EDT
    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'.
Comment 8 Leonard den Ottolander 2004-07-16 17:52:50 EDT
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.
Comment 9 Ivo Sarak 2004-07-16 18:09:59 EDT
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).
Comment 10 Ivo Sarak 2004-07-17 15:41:45 EDT
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...
Comment 11 Ivo Sarak 2004-07-17 17:04:33 EDT
I tried this under Gnome as well, the same results.
Comment 12 Ivo Sarak 2004-07-19 04:09:30 EDT
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.
Comment 13 Ivo Sarak 2004-07-19 15:34:04 EDT
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.
Comment 14 Ivo Sarak 2004-07-19 15:52:18 EDT
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.
Comment 15 Ivo Sarak 2004-07-19 15:58:43 EDT
MC is working OK over telnet, but SSH is failing.

Can it be SSH issue after all?
Comment 16 Doncho N. Gunchev 2004-07-19 16:10:17 EDT
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...
Comment 17 Ivo Sarak 2004-07-20 03:19:03 EDT
"unset DISPLAY" before SSHing did the trick - no MC abort!
Comment 18 Ivo Sarak 2004-07-20 03:29:36 EDT
It seems not to be related to old config files, even SSHing with new
user has the same issue.

Where to look next?
Comment 19 Leonard den Ottolander 2004-07-20 11:04:32 EDT
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 ***
Comment 20 Leonard den Ottolander 2004-07-26 19:47:34 EDT
Not entirely the same issue as bug 125838. Reopening.
Comment 21 Nalin Dahyabhai 2004-09-15 20:01:10 EDT
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?
Comment 22 Ivo Sarak 2004-10-02 17:56:52 EDT
I use "-Y" and it's been OK.
Comment 23 Jindrich Novy 2004-11-19 03:21:37 EST
*** Bug 139970 has been marked as a duplicate of this bug. ***
Comment 24 Leonard den Ottolander 2004-11-19 04:09:50 EST
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.
Comment 25 Tomas Mraz 2005-02-08 10:56:02 EST

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

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