Bug#470882: /dev/gpmctl freezes acknowledge
samuel.thibault at ens-lyon.org
Wed Nov 12 18:33:19 UTC 2008
Gerfried Fuchs, le Wed 12 Nov 2008 14:43:19 +0100, a écrit :
> > The unfortunate effect here is that it waits without handling clients.
> > The attached patch fixes that: when not in text mode, the mouse
> > is closed, but the select() loop continues. I had to change the
> > timeout of select, I have made it 2 seconds, like the latency of the
> > previously-used wait_text(). That should fix the hang of clients.
> 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. :)
It is: now you at least get a connexion, and get rejected.
The pdmenu segfault is due to another bug, see my mail dated 11th
October. The problem is that pdmenu tries to connect to gpm, but because
it is not running as root or as the owner of the console ttys, the
server eventually rejects it (_after_ having received some data, because
on some systems it's the only way to get the credentials), i.e. the
server closes the connection, the client gets an EOF, closes it too, and
sets gpm_fd to -1. Then pdmenu uses it in a FD_SET() call. SEGFAULT.
One way to fix it would be in the client to create a pipe, and dup2()
the read side into the gpm_fd, in order to keep the fd never readable
again. It's quite ugly, but that's the only way I can see to fix clients
that use gpm_fd without taking care. Else we have to fix all the
(Note that if gpm is restarted, you get the same issue: the client gets
an EOF etc).
More information about the pkg-gpm-devel