Prepare toolchain/logs/master branch.

1 files changed, 0 insertions, 128 deletions

diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn
deleted file mode 100644
index 19d18d0e..00000000
--- a/open_issues/term_blocking.mdwn
+++ /dev/null
@@ -1,128 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-[[!tag open_issue_hurd]]
-
-There must be some blocking / dead-locking (?) problem in `term`.
-
-[[!toc]]
-
-
-# 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|gdb]].
-
----
-
-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.
-
-
-[[2011-07-04]].
-
-
-# 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 [[!FF_project 277]][[!tag bounty]] on this task.