Bug 168076

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

I haven't seen such behaviour of mc so far, so please include strace, your mc
and gpm versions. Also a test case, when this happens every time would be good
to let me reproduce it.

All my colleagues do have these problems. I only saw it on desktop usage so far.
As stated in my first post, I will include a strace when it hangs again :)

Versions:
mc-4.6.1a-0.11.FC4
gpm-1.20.1-71

Seems like it turned stable after you reported the bug here ;)
[still waiting for a strace]

He I finally got it again :) Here are the last strace lines, it keeps hanging on
the /dev/gpmctl. After shutting down gpm mc starts up again :)

readlink("/proc/self/fd/0", "/dev/pts/10", 4095) = 11
open("/dev/pts/10", O_WRONLY)           = 5
ioctl(5, TIOCGWINSZ, {ws_row=55, ws_col=155, ws_xpixel=0, ws_ypixel=0}) = 0    
                                                                               
                              socket(PF_FILE, SOCK_STREAM, 0)         = 6
connect(6, {sa_family=AF_FILE, path="/dev/gpmctl"}, 13

Ok, seen a similar problem recently. Just killing gpm before mc solves the
problem for me. However, this seems more like gpm problem IMO.

The problem is reproducible when gpm is running, user is logged to X Window and
the same user is trying to run mc via ssh connection.

I just restarted gpm when gpm hanged and now I'm not able to reproduce so some
other action should be made (mabe logout/login to the X or so).

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

Bug #172921 has been opened for this gpm bug (under RHEL4 so this may be better
to open the same bug for FC4 or for upcoming FC5).

Ok, gpm dependency removed and mc is no more compiled with gpm support since
mc-4.6.1a-0.15.FC4.

From User-Agent: XML-RPC

mc-4.6.1a-0.15.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

(for comment #10):

Jindrich,

I had the same issue as in comment #7 . Invoking mc with `-d' option solves this
issue ("mc -d" -- disable gpm at runtime).

As actually for most Fedora users "mc" is an alias for
/usr/share/mc/bin/mc-wrapper.sh, it looks more easy and correct just to add `-d'
option somewhere in that script, rather than disable gpm completely at compile
time...

Dmitry, thanks for the comment, maybe fixing the wrapper scripts would cause
less pain to users that still want to use the mc with the gpm support enabled.

The problem is that the -d option disables the mouse support completely what we
don't want. We need to disable only the mouse support for gpm and mc doesn't
have an option for that. It's bad as the xterm mouse support works fine on
gnome-terminal/xterm/konsole but -d disables it completely. The only effect of
the disabled gpm is that mouse services won't work on text console.

Well,

What about something like:

[ -n "$DISPLAY" ] && opts="-d"

in the wrapper script?

Typo... :)

[ -z "$DISPLAY" ] && opts="-d"

That won't help if you ssh to a machine from xterm then xterm support will still
work, but DISPLAY won't be set you could however test for TERM==xterm.

As discussed in bug 168076 I've done a localbuild of mc with gpm support
reanbled and now I've tried recreating the problem as described in bug 163061:
-start pc with gdm and gpm (runlevel 5)
-log into gdm as hans
-log into console as hans
-start mc, starts fine, mouse works fine
-ssh to localhost as hans
-start mc, the following message is printed over mc's screen:
 --
 *** info [lib/liblow.c(458)]:
 EditWarning: closing connection
 --
 and the mouse works as if mc has been compiled without gpmsupport, iow
 you can select parts of the screen but not control mc.
-as root from another console do: service restart gpm
-start mc again in the ssh session now the message is:
 *** warning [client.c(183)]: Failed gpm connect attempt by uid 500 for vc 0
 *** info [lib/liblow.c(458)]:
 EditWarning: closing connection

So I believe that this bug is now fixed somehow. Notice that since the version
used by the reporter of this bug (4.6.1a-0.11) a lott of syncs with upstream
have been done, so most likely this has been fixed / worked around upstream.

Some more digging has gotten some new insight, the messages shown I've reported
in comment #18 are actually gpm and/or libgpm messages, so probably this is
fixed in a newer gpm.

I have been digging around in this bug, but could not figure an easy solution.   
The problem apparently is that libgpm hangs on opening communication with gpm.  
If gpm hangs, the client will hang as well. It could be possibly worked around  
with a timeout, but the code is already somewhat hairy... I will think about  
it. Either that, or make gpm (daemon) not hang :-). 

Erm,

As I already reported this seems fixed, how can I reproduce this?

I would suspect that the "fix" is the fact that gpm support in mc is now 
disabled in fedora core. So the issue is not fixed, just worked around. I am 
not sure it is worth the effort to fix it for real, though :). For now, the 
"solution" is good enough. However, it will affect other apps than mc still, 
that use gpm mouse support. 

I know gpm is disabled *by default* I build a local mc rpm however with it
enabled and couldn't reproduce the problem.

See above.

You mean comment #19? There were no updates to gpm since 2004. 

Strange, maybe some change in mc then has fixed this? Like I said I can't
reproduce it. And yes I meant comment 19 (and mostly 18)

fc4 is out of support and this has been worked around by disabling gpm in mc,
therefor closing. I could try to fix it in RHEL4 though.

Oh, got it. Will start working on a fix...

mc-4.6.1a-36.20070124cvs.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

mc-4.6.1a-36.20070124cvs.fc5 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.