Bugzilla Bug 219577

I found out I could only run a very limited number of curses programs at the
same time in my X session before they started to hang. Stracing such hanging
tasks showed them to be connecting to /dev/gpmctl. Switching to the text
console and moving the mouse there seemed to help, as did restarting gpm.

Steps to reproduce:
1. Make sure ncurses was emerged with gpm support.
2. Make sure gpm is running.
3. Open urxvt from x11-terms/rxvt-unicode.
4. Run screen in that terminal window.
5. Inside screen run "dialog --yesno Test 10 40".
6. Create new screen window (Ctrl+A Ctrl+C) and repeat 5.
7. Keep creating windows and starting dialogs until a dialog fails to display.
   I could start about five or six dialogs before it started to fail.
8. Run "netstat -x -a -p | grep gpm"
   It will display several sockets in "CONNECTING" state.

It looks like gpm wouldn't accept any connections and some queue of pending
connections filled up. Ltrace of the daemon shows a lot of sleep(2), which seem
to come from daemon/wait_text.c:wait_text() where a loop waits for the console
to enter text mode, not giving the select on the socket any chance.

Although one might argue that ncurses should not deal with gpm at all when run
in an X terminal window, I would also assume that a service that provides a
socket should also accept a reasonable number of connections on said socket. As
this whole socket communication is encapsulated inside the gpm library,
Gpm_Open should ensure it never hangs.

I'm a bit surprised that the connect syscall for a unix domain socket seems to
return before the connection is completely established. I'm also surprised that
such pending connections seem to outlive the process which initiated them, at
least if the initiating prcess is aborted in some way.

Not an issue with sys-libs/gpm-1.20.1-r60 due to the following check in
lib/liblow.c:Gpm_Open()

  if(strncmp(tty,option.consolename,strlen(option.consolename)-1)
     || !isdigit(tty[strlen(option.consolename)-1])) {
    /* gpm_report(GPM_PR_ERR,"strncmp/isdigit/option.consolename failed"); */
    goto err;
  }

The comment does come from a patch, 09_all_logfillup.patch, it was a statement
before. Together this might indicate that a check whether the application
console is indeed a text console might be the appropriate solution to this
problem, although I still consider a non-listening socket owner a bad thing.

is this still a problem with gpm-1.20.5 ?  i built ncurses with USE=gpm and
gpm-1.20.5, but i cant reproduce your issue

what i tried was:
$ sudo /etc/init.d/gpm start
$ for n in {1..50} ; do screen -dmS $n dialog --yesno Test 10 40 ; done
$ pgrep dialog | wc -l
50
$ killall dialog

(In reply to comment #2)
> is this still a problem with gpm-1.20.5 ?  i built ncurses with USE=gpm and
> gpm-1.20.5, but i cant reproduce your issue

I can't reproduce it with sys-libs/ncurses-5.7 but with ncurses-5.6-r2 and
gpm-1.20.5 the issue still exists.

> what i tried was:
> $ sudo /etc/init.d/gpm start
> $ for n in {1..50} ; do screen -dmS $n dialog --yesno Test 10 40 ; done
> $ pgrep dialog | wc -l
> 50
> $ killall dialog

How would you hope to identify hanging processes this way, without attaching to
the screens? You could either have them timeout, and see if they terminate:
"dialog --timeout 5 --yesno Test 10 40"
The bug causes dialog not to timeout, so even 10 seconds later the process
count would still be 50, not 0.

Or you could kill them and look for gpm connections in the CONNECTING state
using "netstat --unix -a | grep gpmctl". With the bug, there are six
connections CONNECTING.

i did check the network state and i did not see any connections pending.  the
point of the code i posted was to have a case that could be run w/out having to
type a ton of manual commands and to easily push the limit.

i guess we could move ncurses-5.7 to stable and just forget about the issue.

I don't know if we care, but it's still issue for net-im/ekg2

I can confirm that the same happens to me with ncurses-5.6-r2 & gpm-1.20.5 ...
I'm starting to test now the combination ncurses-5.7 & gpm-1.20.5 and will
report back to you ...

(In reply to comment #6)
> I can confirm that the same happens to me with ncurses-5.6-r2 & gpm-1.20.5 ...
> I'm starting to test now the combination ncurses-5.7 & gpm-1.20.5 and will
> report back to you ...

It still happens :-/

Invoking elinks in xfce terminal inside a screen session hangs and CTRL-C
evokes this error msg:

Jan 23 15:25:59 swimmer elinks: *** info 
Jan 23 15:25:59 swimmer elinks: /dev/gpmctl: Interrupted system call
Jan 23 15:25:59 swimmer elinks: *** err 
Jan 23 15:25:59 swimmer elinks: /dev/gpmctl: No such device or address
Jan 23 15:25:59 swimmer elinks: *** err 
Jan 23 15:25:59 swimmer elinks: Oh, oh, it's an error! possibly I die! 

 netstat -x -a -p | grep gpm
unix  2      [ ACC ]     STREAM     LISTENING     1351845  1032/gpm           
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTING    0        -                  
/dev/gpmctl
unix  3      [ ]         STREAM     CONNECTED     1351661  1032/gpm          

I have the same issue with sys-libs/gpm-1.20.5, sys-libs/ncurses-5.6-r2, and
www-client/links-2.2

Triggering of this issue seems to be sporatic and non-deterministic.  The usual
cause is connecting to a machine running X11 via ssh and then running links
within screen.  It seems to happen most often when opening multiple instances
of links within screen, and rapid startup and shutdown of links.

I just reproduced that damn bug with gpm-1.20.5 and gpm-1.20.6

These steps should help you to reproduce it:
1) Go to console (press Ctrl-Alt-F1 if you are running X server).
2) Connect (using SSH) to a Gentoo machine which runs gpm and X server.
3) Launch mc (mc should be compiled with gpm USE flag); press F10 to exit mc.
4) Repeat step (3) six times in a row.
5) Now if you try running any application that uses gpm (mc or links for
example), it will lock up. If you kill it and try running again it will be
locked up.
6) To unlock the applications you should restart gpm daemon.

That bug forced me to reboot the server several times :-( because I didn't know
what the problem was and how to fix it.

P.S. mc is midnight commander by the way.