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?
Definitely. > 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 clients. (Note that if gpm is restarted, you get the same issue: the client gets an EOF etc). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
