Package: slrn Version: 0.9.9~pre77-1 Severity: normal For a while now, certainly prior to the current version in experimental, I've had deadlocks in random circumstances when quitting the composition of a message, that I think I have only just been able to pin down.
If I compose a message or followup, and my $EDITOR points to a graphical program (xemacs), then if I accidentally press ctrl-a ctrl-s in the slrn session (dunno whether the ctrl-a is necessary to trigger this bug, but pressing them both in that order triggers it 100% of the time on my system), don't notice this (I can see the "^A" echoed to the status area, but think that's all I've accidentally hit) and eventually close xemacs, then the screen won't update since the XOFF character has been received. So I press ctrl-q to allow the screen to update again, and it doesn't. Dunno whether this is a slrn bug or an xterm bug, but slrn is the only thing that has triggered it so far. I wonder if it is an interaction with the curses handling of the tty settings - it responds to ctrl-s pausing the terminal, but has it remapped ctrl-q to something other than its usual binding to unpause the terminal? The process tree is: 31977,7> ps axf | grep -A2 [3]1046 31046 ? S 0:00 \_ xterm -geometry 101x32 31049 pts/13 Ss 0:00 | \_ bash 31351 pts/13 S+ 0:00 | \_ slrn --kill-log /home/tconnors/News/.kill-log An strace of the slrn process shows it is blocking on a write: 31979,9> strace -p 31351 Process 31351 attached - interrupt to quit write(1, "\33[?1049h\33[1;44r\33[4l\33[m\33(B\33[37m\33["..., 2443 File descriptor 1 is pts/13: 31979,9> l /proc/31351/fd total 0 lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 0 -> /dev/pts/13 lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 1 -> /dev/pts/13 lrwx------ 1 tconnors tconnors 64 Feb 15 18:15 2 -> /dev/pts/13 l-wx------ 1 tconnors tconnors 64 Feb 15 18:28 3 -> /home/tconnors/common-files/News/.kill-log lr-x------ 1 tconnors tconnors 64 Feb 15 18:28 4 -> /dev/null l-wx------ 1 tconnors tconnors 64 Feb 15 18:28 5 -> /home/tconnors/.slrnfaces/dirac.31351 (deleted) lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 6 -> socket:[2198498] lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 7 -> /dev/tty xterm is blocking on a select on reading file descriptors 3 and 5: 31977,7> strace -p 31046 Process 31046 attached - interrupt to quit select(6, [3 5], [], NULL, NULL <unfinished ...> Process 31046 detached These file descriptors are 31978,8> l /proc/31046/fd total 0 lr-x------ 1 tconnors tconnors 64 Feb 15 18:28 0 -> /dev/null l-wx------ 1 tconnors tconnors 64 Feb 15 18:28 1 -> /home/tconnors/.xsession-errors.dirac:0.0.20080207.12211 l-wx------ 1 tconnors tconnors 64 Feb 15 18:28 2 -> /home/tconnors/.xsession-errors.dirac:0.0.20080207.12211 lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 3 -> socket:[2198203] lr-x------ 1 tconnors tconnors 64 Feb 15 18:28 4 -> /dev/null lrwx------ 1 tconnors tconnors 64 Feb 15 18:28 5 -> /dev/ptmx Dunno who owns the socket 31982,12> sudo lsof | grep 2198203 xterm 31046 tconnors 3u unix 0xffff8101191291c0 2198203 socket but fd5==/dev/ptmx is presumably the other half of the pseudo tty (dunno the mechanics of this). Simply killing slrn with any signal I can think of is not enough to bring the xterm back to life - it has to be killed too. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages slrn depends on: ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy ii libc6 2.7-6 GNU C Library: Shared libraries ii libcanlock2 2b-4 library for creating and verifying ii libslang2 2.1.3-2 The S-Lang programming library - r slrn recommends no packages. -- debconf information: * shared/mailname: dirac.rather.puzzling.org slrn/manual_getdescs: slrn/getdescs: cron job slrn/getdescs_now: false * shared/news/server: news.rather.puzzling.org slrn/lost_slrnpull: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
