There must be some blocking / dead-locking 
problem in term.
Original Findings
# w | grep [t]sch
tschwing p1 192.168.10.60: Tue 8PM 0:03 2172 /bin/bash
tschwing p2 192.168.10.60: Tue 4PM 40hrs 689 emacs
tschwing p3 192.168.10.60: 8:52PM 11:37 15307 /bin/bash
tschwing p0 192.168.10.60: 6:42PM 11:47 8104 /bin/bash
tschwing p8 192.168.10.60: 8:27AM 0:02 16510 /bin/bash
Now open a new screen window, or login shell, or...
# ps -Af | tail
[...]
tschwinge 16538 676 p6 0:00.08 /bin/bash
root 16554 128 co 0:00.09 ps -Af
root 16555 128 co 0:00.01 tail
bash is started (on p6), but newer makes it to the shell promt; doesn't
even start to execute .bash_profile / .bashrc. The next shell started, on
the next available pseudoterminal, will work without problems.
The term on p6 has already been running before:
# ps -Af | grep [t]typ6
root 6871 3 - 5:45.86 /hurd/term /dev/ptyp6 pty-master /dev/ttyp6
In this situation, w will sometimes report erroneous values for IDLE
for the process using that terminal.
Killed that term instance, and things were fine again.
All this reproducible happens while running the GDB testsuite.
Have a freshly started shell blocking on such a term instance.
$ ps -F hurd-long -p 1766 -T -Q
PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
1766 0 3 1 1 6 131M 1.14M 0.0 0:28.85 5:40.91 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
0 0.0 0:05.76 1:08.48
1 0.0 0:00.00 0:00.01
2 0.0 0:06.40 1:11.52
3 0.0 0:05.76 1:09.89
4 0.0 0:05.42 1:06.74
5 0.0 0:05.50 1:04.25
... and after 5:45 h:
$ ps -F hurd-long -p 21987 -T -Q
PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
21987 1001 676 21987 21987 2 148M 2.03M 0.0 0:00.02 0:00.07 /bin/bash
0 0.0 0:00.02 0:00.07
1 0.0 0:00.00 0:00.00
$ ps -F hurd-long -p 1766 -T -Q
PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args
1766 0 3 1 1 6 131M 1.14M 0.0 0:29.04 5:42.38 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
0 0.0 0:05.76 1:08.48
1 0.0 0:00.00 0:00.01
2 0.0 0:06.41 1:11.90
3 0.0 0:05.82 1:10.28
4 0.0 0:05.52 1:07.06
5 0.0 0:05.52 1:04.63
$ sudo gdb /hurd/term 1766
[sudo] password for tschwinge:
GNU gdb (GDB) 7.0-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /hurd/term...Reading symbols from /usr/lib/debug/hurd/term...done.
(no debugging symbols found)...done.
Attaching to program `/hurd/term', pid 1766
[New Thread 1766.1]
[New Thread 1766.2]
[New Thread 1766.3]
[New Thread 1766.4]
[New Thread 1766.5]
[New Thread 1766.6]
Reading symbols from /lib/libhurdbugaddr.so.0.3...Reading symbols from /usr/lib/debug/lib/libhurdbugaddr.so.0.3...
[System doesn't respond anymore, but no kernel crash.]
The very same behavior is still observable as of 2011-03-24.
Next: rebooted; on console started root shell, screen, a few spare windows; as
user started GDB test suite, noticed the PTY it's using; in a root shell
started GDB (the system one, for .debug stuff) on /hurd/term, set
noninvasive on, attach to the term that GDB is using.
Formal Verification
This issue may be a simple programming error, or it may be more complicated.
Methods of formal verification should be applied to confirm that there is
no error in /hurd/term's logic itself. There are tools for formal
verification/code analysis that can likely help here.
There is a FOSS Factory bounty (p277) on this task.