[http://wiki.debian.org/BugSprint is to blame for me looking into this]
As the locking occurs on exactly the 7th event (using rxvt-unicode + pdmenu here), there must be kept some state somewhere. That's most likely gpm. Client applications try to connect() to /dev/gpmctl, but starting from the 7th try, this locks up. Stracing gpm shows that it doesn't ever accept() the connection, not on the first tries, nor later. gdb shows it loops in wait_text() from which it never exits: #0 0x00007f41a2a13fc0 in nanosleep () from /lib/libc.so.6 #1 0x00007f41a2a13e17 in sleep () from /lib/libc.so.6 #2 0x000000000041378a in wait_text (fdptr=0x61c2a8) at daemon/wait_text.c:38 #3 0x0000000000410172 in old_main () at daemon/old_main.c:172 #4 0x000000000040f705 in main (argc=5, argv=0x7fffab167d88) at daemon/main.c:33 The bit that would accept() connections is processConn() is never reached because old_main() continues the loop earlier. So far I managed to find a way to work around the problem by starting gpm with the -F (force repeat) option: #0 0x00007f8b5e95ec93 in select () from /lib/libc.so.6 #1 0x000000000040ff05 in old_main () at daemon/old_main.c:133 #2 0x000000000040f719 in main (argc=6, argv=0x7fff67087c98) at daemon/main.c:33 Now pdmenu doesn't lock up anymore. I suspect the following code from old_main() is bogus: /* * Be sure to be in text mode. This used to be before select, * but actually it only matters if you have events. */ { int fd = open_console(O_RDONLY); if (ioctl(fd, KDGETMODE, &kd_mode) < 0) gpm_report(GPM_PR_OOPS,GPM_MESS_IOCTL_KDGETMODE); close(fd); if(kd_mode != KD_TEXT && !option.repeater && !option.force_repeat) { wait_text(&mouse_table[1].fd); What does it mean to be "in text mode"? What if X is started later? Does gpm assume that all X users will need to enable a repeater? Since /dev/input/mice exists, that's no longer true, afaict. Or is the bug rather that applications not running on a linux consule must not try to connect to gpm? In this case, gpm should probably still reject the connection in some way. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/
signature.asc
Description: Digital signature