Bug#470882: /dev/gpmctl freezes acknowledge

dEbian Bugs RC

Package: gpm
Version: 1.20.3~pre3-3
Followup-For: Bug #470882

I have this problem on my box and another two boxes at home too. Gpm
enabled applications freezes on communication with gpm. When I switch to
the console to see if mouse is functional under gpm right now (aptitude
hangs in rxvt) - mouse moves ok in text console.
Applications (aptitude, module-assistant,...) revive after gpm restart.
This problem appears several times a day for me.

It is sufficient to enter/quit aptitude or m-a six times (perhaps
exactly six times!) and problem arises (I check this several times with
aptitude now). Seventh enter is lockup. When I leave locked aptitude in
rxvt, switch to the text console, move around mouse a moment, go back
into the X-Window, aptitude revives.

Best Regards

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=cs_CZ.ISO-8859-2 (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/bash

Versions of packages gpm depends on:
ii debconf [debconf-2.0] 1.5.21 Debian configuration management sy
ii debianutils 2.28.5 Miscellaneous utilities specific t
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libgpmg1 1.20.3~pre3-3 General Purpose Mouse - shared lib
ii lsb-base 3.2-11 Linux Standard Base 3.2 init scrip
ii ucf 3.006 Update Configuration File: preserv

gpm recommends no packages.
Just to summarize a few things:

- apparently it happens just for clients run in an terminal in X.
- the server logs previously attached to the bug show
"Failed gpm connect attempt by uid 1000 for vc /dev/tty0"
which means that libgpm tried to connect to the gpm server, and failed
since it didn't know which VT to acquire, thus tried tty0, and failed
since it probably belongs to root, not to uid 1000.

I tried to reproduce that, and I noticed something in the strace I could

# the client logs the connection error

# closes the socket
# and still tries to select it!
select(5, [0 4], NULL, NULL, {0, 166000}) = -1 EBADF (Bad file descriptor)

it looks like the caller of libgpm didn't notice that gpm_fd is not
a valid file descriptor any more. In the case of aptitude, that's
ncurses... Thomas?

Now, that being said, that reminds me bug #472063: actually libgpm
shouldn't even have tried to connect to the server, it should have just
noticed it is running in an X terminal and set gpm_fd to -2...

Are you sure with that fix? I applied it and did a local rebuild, and
now pdmenu segfaults on any keypress after starting. I don't really call
that an improvment. :)

Just to be sure I did it properly, I dumped your patch into
debian/patches/060_eliminate-hang-in-X11 and added it to the series
file, the rebuild did happen in a current sid chroot.

So long,
Hmm, alright.

Ah, right. And aptitude does behave false here too (last two lines from

write(2, "Uncaught exception: Unable to read from stdin: Bad file descriptor\n"..., 67) = 67
exit_group(-1) = ?

I guess we need to clone the bug to there, too, or rather libncurses
through which it seems to use gpm, it doesn't directly depend on libgpm.

Not sure what other applications might be affected by it and should get
addressed, too ...

Processing commands for [email protected]:

Bug#470882: gpm freezes and makes other applications freeze/segfault
There were no tags set.
Bug#476431: gpm makes apps hang if running; they run normally if stopped
Tags added: patch

Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)
It return 0 (KD_TEXT) when the _current_ console is a text console
and 1 (KD_GRAPHICS) when you're in X. It has nothing to do with
what console gpm runs on, since it's detached.