Bug 125698 - mc crash on remote host when to press any non-alphabetic key.
Summary: mc crash on remote host when to press any non-alphabetic key.
Status: CLOSED DUPLICATE of bug 137685
Alias: None
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
(Show other bugs)
Version: 2
Hardware: athlon Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
URL:
Whiteboard:
Keywords:
: 139970 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-10 09:52 UTC by Ivo Sarak
Modified: 2016-03-18 02:30 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-08 15:56:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Ivo Sarak 2004-06-10 09:52:35 UTC
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 19:38:06 UTC
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 19:39:30 UTC
...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 13:25:57 UTC
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 16:04:10 UTC
Still th same results:
xorg-x11-6.7.0-4

Comment 5 Mike A. Harris 2004-07-07 08:37:34 UTC
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 11:02:29 UTC
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 Gunchev 2004-07-16 21:10:41 UTC
    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 21:52:50 UTC
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 22:09:59 UTC
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 19:41:45 UTC
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 21:04:33 UTC
I tried this under Gnome as well, the same results.


Comment 12 Ivo Sarak 2004-07-19 08:09:30 UTC
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 19:34:04 UTC
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 19:52:18 UTC
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 19:58:43 UTC
MC is working OK over telnet, but SSH is failing.

Can it be SSH issue after all?

Comment 16 Doncho Gunchev 2004-07-19 20:10:17 UTC
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 07:19:03 UTC
"unset DISPLAY" before SSHing did the trick - no MC abort!

Comment 18 Ivo Sarak 2004-07-20 07:29:36 UTC
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 15:04:32 UTC
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 23:47:34 UTC
Not entirely the same issue as bug 125838. Reopening.


Comment 21 Nalin Dahyabhai 2004-09-16 00:01:10 UTC
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 21:56:52 UTC
I use "-Y" and it's been OK.

Comment 23 Jindrich Novy 2004-11-19 08:21:37 UTC
*** Bug 139970 has been marked as a duplicate of this bug. ***

Comment 24 Leonard den Ottolander 2004-11-19 09:09:50 UTC
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 15:56:02 UTC

*** 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.