rename open_issues/libpthread/t/fix_have_kernel_resources.mdwn -> open_issues/libpthread/fix_have_kernel_resources.mdwn

Message-Id: <20210102101217.8372-4-gfleury@disroot.org>

1 files changed, 0 insertions, 1301 deletions

diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
deleted file mode 100644
index 02b6ab05..00000000
--- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
+++ /dev/null
@@ -1,1301 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013, 2014 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_libpthread]]
-
-`t/fix_have_kernel_resources`
-
-Address problem mentioned in [[/libpthread]], *Threads' Death*.
-
-
-# IRC, freenode, #hurd, 2012-08-30
-
-    <braunr> tschwinge: this issue needs more cooperation with the kernel
-    <braunr> tschwinge: i.e. the ability to tell the kernel where the stack is,
-      so it's unmapped when the thread dies
-    <braunr> which requiring another thread to perform this deallocation
-
-
-## IRC, freenode, #hurd, 2013-05-09
-
-    <bddebian> braunr: Speaking of which, didn't you say you had another "easy"
-      task?
-    <braunr> bddebian: make a system call that both terminates a thread and
-      releases memory
-    <braunr> (the memory released being the thread stack)
-    <braunr> this way, a thread can completely terminates itself without the
-      assistance of a managing thread or deferring work
-    <bddebian> braunr: That's "easy" ? :)
-    <braunr> bddebian: since it's just a thread_terminate+vm_deallocate, it is
-    <braunr> something like thread_terminate_self
-    <bddebian> But a syscall not an RPC right?
-    <braunr> in hurd terminology, we don't make the distinction
-    <braunr> the only real syscalls are mach_msg (obviously) and some to get
-      well known port rights
-    <braunr> e.g. mach_task_self
-    <braunr> everything else should be an RPC but could be a system call for
-      performance
-    <braunr> since mach was designed to support clusters, it was necessary that
-      anything not strictly machine-local was an RPC
-    <braunr> and it also helps emulation a lot
-    <braunr> so keep doing RPCs :p
-
-
-## IRC, freenode, #hurd, 2013-05-10
-
-    <braunr> i'm not sure it should only apply to self though
-    <braunr> youpi: can we get a quick opinion on this please ?
-    <braunr> i've suggested bddebian to work on a new RPC that both terminates
-      a thread and releases its stack to help fix libpthread
-    <braunr> and initially, i thought of it as operating only on the calling
-      thread
-    <braunr> do you see any reason to make it work on any thread ?
-    <braunr> (e.g. a real thread_terminate + vm_deallocate)
-    <braunr> (or any reason not to)
-    <youpi> thread stack deallocation is always a burden indeed
-    <youpi> I'd tend to think it'd be useful, but perhaps ask the list
-
-
-## IRC, freenode, #hurd, 2013-06-26
-
-    <braunr> looks like there is a port right leak in libpthread
-    <braunr> grmbl, the port leak seems to come from mach_port_destroy being
-      buggy :/
-    <braunr> hum, apparently we're not the only ones to suffer from port leaks
-      wrt mach_port_destroy
-    <braunr> ew, libpthread is leaking
-    <pinotree> memory or ports?
-    <braunr> both
-    <pinotree> sounds great ;)
-    <braunr> as it is, libpthread doesn't destroy threads
-    <braunr> it queues them so they're recycled late
-    <braunr> r
-    <braunr> but there is confusion between the thread structure itself and its
-      internal resources
-    <braunr> i.e. there is pthread_alloc which allocates a thread structure,
-      and pthread_create which allocates everything else
-    <braunr> but on pthread_exit, nothing is destroyed
-    <braunr> when a thread structure is reused, its internal resources are
-      replaced by new instances
-    <pinotree> oh
-    <braunr> it's ok for joinable threads but most of our threads are detached
-    <braunr> pinotree: as expected, it's bigger than expected :p
-    <braunr> so i won't be able to write a quick fix
-    <braunr> the true way to fix this is make it possible for threads to free
-      their own resources
-    <braunr> let's do that :p
-    <braunr> ok, got the new thread termination function, i'll build eglibc
-      package providing it, then experiment with libpthread
-    <pinotree> braunr: iirc there's also a tschwinge patch in the debian eglibc
-      about that
-    <braunr> ah
-    <pinotree> libpthread_fix.diff
-    <braunr> i see
-    <braunr> thanks for the notice
-    <braunr> bddebian:
-      http://www.sceen.net/~rbraun/0001-thread_terminate_deallocate.patch
-    <braunr> bddebian: this is what it looks like
-    <braunr> see, short and easy
-    <bddebian> Aye but didn't youpi say not to bother with it??
-    <braunr> he did ?
-    <braunr> i don't remember
-    <bddebian> I thought that was the implication.  Or maybe that was the one I
-      already did!?
-    <braunr> i'd be interested in reading that
-    <braunr> anyway, there still are problems in libpthread, and this call is
-      one building block to fix some of them
-    <braunr> some important ones
-    <braunr> (big leaks)
-
-
-## IRC, freenode, #hurd, 2013-06-29
-
-    <braunr> damn, i fix leaks in libpthread, only to find out leaks somewhere
-      else :(
-    <braunr> bddebian: ok, actually it was a bit more complicated than what i
-      showed you
-    <braunr> because in addition to the stack, the call must also release the
-      send right in the caller's ipc space
-    <braunr> (it can't be released before since there would be no mean to
-      reference the thread to destroy)
-    <braunr> or perhaps it should strictly be reserved to self termination
-    <braunr> hmm
-    <braunr> yes it would probably be simpler
-    <braunr> but it should be a decent compromise
-    <braunr> i'm close to having a libpthread that doesn't leak anything
-    <braunr> and that properly destroys threads and their resources
-
-
-## IRC, freenode, #hurd, 2013-06-30
-
-    <braunr> bddebian: ok, it was even more tricky, because the kernel would
-      save the return value on the user stack (which is released by the call
-      and then invalid) before checking for asynchronous software traps (ASTs,
-      a kind of software interrupts in mach), and terminating the calling
-      thread is done by a deferred AST ... :)
-    <braunr> hmm, making threads able to terminate themselves makes rpctrace a
-      bit useless :/
-    <braunr> well, more restricted
-
-    <braunr> ok so, tough question :
-    <braunr> i have a small test program that creates a thread, and inspect its
-      state before any thread dies
-    <braunr> i can see msg_report_wait requests when using ps
-    <braunr> (one per thread)
-    <braunr> one of these requests create a new receive right, apparently for
-      the second thread in the test program
-    <braunr> each time i use ps, i can see the sequence numbers of two receive
-      rights increase
-    <braunr> i guess these rights are related to proc and signal handling per
-      thread
-    <braunr> but i can't find what create them
-    <braunr> does anyone know ?
-    <braunr> tschwing_: ^ :)
-
-    <braunr> again, too many things wrong elsewhere to cleanly destroy threads
-      ..
-    <braunr> something is deeply wrong with controlling terminals ..
-
-
-## IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> youpi: if you happen to notice what receive right is created for
-      each thread (beyond the obvious port used for blocking and waking up),
-      please let me know
-    <braunr> it's the only port leak i have with thread destruction
-    <braunr> and i think it's related to the proc server since i see the
-      sequence number increase every time i use ps
-
-    <braunr> pinotree: my change doesn't fix all the pthread leaks but it's a
-      lot better
-    <braunr> bddebian: i've spent almost the whole week end trying to find the
-      last port leak without success
-    <braunr> there is some weird bug related to the controlling tty that hits
-      me every time i try to change something
-    <braunr> it's the same bug that prevents ttys from being correctly closed
-      when using ssh or screen
-    <braunr> well maybe not the same, but it's close
-    <braunr> some stale receive right kept around for no apparent reason
-    <braunr> and i can't find its source
-
-
-## IRC, freenode, #hurd, 2013-07-02
-
-    <braunr> and btw, i don't think i can make my libpthread patch work
-    <braunr> i'll just aim at avoiding leaks, but destroying threads and their
-      related resources depends on other changes i don't clearly see
-
-
-## IRC, freenode, #hurd, 2013-07-03
-
-    <braunr> grmbl, i don't want to give up thread destruction ..
-
-
-## IRC, freenode, #hurd, 2013-07-15
-
-    <braunr> btw, my work on thread destruction is currently stalled
-    <braunr> i don't have much free time right now
-
-
-## IRC, freenode, #hurd, 2013-09-13
-
-    <braunr> i think i know why my thread_terminate_deallocate patches leak one
-      receive port :>
-    <braunr> but now i'm not sure of the proper solution
-    <braunr> every time a thread is created and destroyed, a receive right is
-      leaked
-    <braunr> i guess it's simply the reply port ..
-    <braunr> grmbl
-    <braunr> i guess i have to make it a simpleroutine ...
-    <braunr> hm too bad, it's not the reply port :(
-    <braunr> it's also leaking some memory
-    <braunr> it doesn't seem related to my changes though
-    <braunr> stacks, rights, and threads are correctly destroyed
-    <braunr> some obscure state is left behind
-    <braunr> i wonder how exception ports are dealt with
-    <braunr> vminfo seems to confirm memory is leaking in the heap
-    <braunr> humpf
-    <braunr> oh silly me
-    <braunr> i don't detach threads
-    <teythoon> well, detach them ;)
-    <braunr> hm worse :p
-    <braunr> now i get additional dead names
-    <braunr> but it's a step forward
-
-
-## IRC, freenode, #hurd, 2013-09-16
-
-    <braunr> that thread port leak is so strange
-    <braunr> the leaked port seems to be created when the new thread starts
-      running
-    <braunr> so it looks like a port the kernel would implicitely create
-    <braunr> hm could it be a thread-specific reply port ?
-    <youpi> ah, yes, there is one of those
-    <braunr> how come mach/mig-reply.c in glibc isn't thread-safe ?
-    <youpi> it is overriden by sysdeps/mach/hurd/img-reply.c I guess
-    <youpi> which uses a threadvar for the mig reply port
-    <braunr> oh
-    <youpi> talking of which, there is also last_value in
-      sysdeps/mach/strerror_l.c
-    <youpi> strerror_thread_freeres is supposed to get called, but who knows
-    <braunr> it does look to be that port
-    <youpi> iirc that's the issue which prevents from letting us make threads
-      exit on idleness?
-    <braunr> one of them
-    <youpi> ok
-    <braunr> maybe the only one, yes
-    <braunr> i see memory leaks but they could be related/normal
-    <braunr> (i.e. not actual leaks)
-    <braunr> on the other hand, i also can't boot a hurd with my patch
-    <braunr> but i consider removing such leaks a priority
-    <braunr> does anyone know the semantic difference between
-      __mig_put_reply_port and __mig_dealloc_reply_port ?
-    <braunr> i guess __mig_dealloc_reply_port is actually a destruction
-      operation, right ?
-    <youpi> AIUI, dealloc is used when one wants the port not to be reused at
-      all
-    <youpi> because it has been used as a reference for something, and can
-      still be currently in use
-    <youpi> while put_reply would be when we're really done with it, and won't
-      use it again, and can thus be used as such
-    <youpi> or at least something like that
-    <braunr> heh
-    <braunr> __mig_dealloc_reply_port calls __mach_port_mod_refs, which is a
-      RPC, and creates a new reply port when destroying the current one
-    <youpi> bah
-    <youpi> that's fine, it's a deref of the old port, which is not in the
-      reply_port variable any more
-    <braunr> it's fine, but still a leak
-    <youpi> well, dealloc does not completely deallocs, yes
-    <braunr> that's not really the problem here
-    <braunr> i've introduced a case that wasn't considered at the time, namely
-      that a thread can destroy itself
-    <youpi> we probably need another function to be called from the thread exit
-    <braunr> i'll simply try with mach_port_destroy
-    <braunr> mach_port_destroy seems to be a RPC too ...
-    <braunr> grmbl
-    <youpi> isn't there a trap version somehow ?
-    <braunr> not in libc
-    <youpi> erf
-    <braunr> at least i know what's wrong now :)
-    <braunr> there still is a small memory leak i have to investigate
-    <braunr> but outside the stack
-    <braunr> the stack, the thread name and the thread are correctly destroyed
-    <braunr> slabinfo confirms only one port leak and nothing else is leaked
-    <braunr> ok so the port leak was indeed the thread-specific reply port,
-      taken care of
-    <braunr> there are also memory leaks too
-
-
-## IRC, freenode, #hurd, 2013-09-17
-
-    <braunr> teythoon: on my side, i'm getting to know our threading
-      implementation better
-    <braunr> closing to clean thread destruction
-    <braunr> x15 ipc will hide reply ports ;p
-    <braunr> memory leaks solved \o/
-    <braunr> now, have to fix memory release when joining
-    <braunr> proper reference counting on detach/join/exit, let's see how it
-      goes ..
-    <braunr> seems to work fine
-
-
-## IRC, freenode, #hurd, 2013-09-18
-
-    <braunr> ok i'll soon have gnumach and libc packages including proper
-      thread destruction :>
-    <teythoon> braunr: why did you have to touch gnumach?
-    <braunr> to add a call allowing threads to release ports and memory
-    <braunr> i.e. their last self reference, their reply port and their stack
-    <braunr> let me public my current patches
-    <teythoon> braunr: thread_commit_suicide ?
-    <braunr> hehe
-    <braunr> initially thread_terminate_self but
-    <braunr> it can be used by other threads too
-    <braunr> to i named it thread_terminate_release
-    <braunr> http://darnassus.sceen.net/~rbraun/0001-pthread_thread_halt.patch
-    <braunr>
-      http://darnassus.sceen.net/~rbraun/0001-thread_terminate_release.patch
-    <braunr> the pthread patch needs to be polished because it changes the
-      semantics of pthread_thread_halt
-    <braunr> but other than that, it should be complete
-    <pinotree> pthread_thread_halt_reallyhalt
-    <braunr> ok let's try these libc packages
-    <braunr> old static ext2fs for the root, but other than that, it boots
-    <braunr> let's try iceweasel
-    <braunr> (i'll need to build a hurd package against this new libc, removing
-      the libports_stability patch which prevents thread destruction in servers
-      on the way)
-    <teythoon> prevents thread destruction o_O
-    <braunr> yes
-    <braunr> in libports only ;p
-    <teythoon> oh, *only* in libports, I assumed for a moment that it affected
-      almost every component of the Hurd...
-    <teythoon> *phew(
-    <braunr> ... :)
-    <braunr> that's why, after a burst of messages, say because of aptitude
-      (select), you may see a few hundred threads still hanging around
-    <braunr> also why unused servers remain running even after several minutes,
-      where the normal timeout is 2mins
-    <teythoon> I wondered about that, some servers (symlink comes to mind) seem
-      to go away if unused (or that's how I read the code)
-    <braunr> symlinks are usually not servers, since most of them actually
-      exist in file systems, and are implemented through an optimization
-    <teythoon> yes I know that
-    <teythoon> trans/symlink.c reads:
-    <teythoon>       /* The timeout here is 10 minutes */
-    <teythoon>       err = mach_msg_server_timeout (fsys_server, 0, control,
-    <teythoon> 				     MACH_RCV_TIMEOUT, 1000 * 60 * 10);
-    <teythoon>       if (err == MACH_RCV_TIMED_OUT)
-    <teythoon> 	exit (0);
-    <braunr> ok
-    <teythoon> hm, /hurd/symlink doesn't feel at all like a symlink... but
-      works like one
-    <braunr> well, starting iceweasel makes X on my host freeze oO
-    <braunr> bbl
-    <teythoon> /hurd/symlink translators do go away after being unused for 10
-      minutes... this is funny if they are set up by hand instead of being
-      started from a passive translator record
-    <teythoon> magically vanishing symlinks ;)
-
-
-## IRC, freenode, #hurd, 2013-09-19
-
-    <braunr> hum, i can't rebuild a hurd package :(
-    <teythoon> braunr: with your thread destruction patches in libc?
-    <braunr> yes but it's unrelated
-    <braunr> In file included from ../../libdiskfs/boot-start.c:38:0:
-    <braunr> ./fsys_reply_U.h:173:15: error: conflicting types for
-      ‘fsys_get_children’
-    <braunr> i didn't see a new libc debian release
-    <teythoon> hm, David reported that as well
-    <teythoon>
-      id:CAEvUa7=QzOiS41G5Vq8k4AiaN10jAPm+CL_205OHJnL0xpJXbw@mail.gmail.com
-    <teythoon> uh oh
-    <teythoon> it seems I didn't add a _reply suffix to the reply routines :/
-    <teythoon> there's quite a bit of fallout from my patches, I kinda feel bad
-      :(
-    <braunr> teythoon: what i'm wondering is what youpi did too, since he got
-      hurd binary packages
-    <teythoon> braunr: well neither he nor I noticed that b/c for us the
-      declarations were just missing
-    <braunr> from libc you mean ?
-    <braunr> or hum gnumach-common ?
-    <teythoon> not sure actually
-    <braunr> no it's not a gnumach thing
-    <braunr> hurd-dev then
-    <teythoon> the build system should have cought these, or mig...
-    <braunr> also, i see you changed fsys_reply.defs, but nothing about
-      fsys_request.defs
-    <teythoon> I have no fsys_requests.defs
-    <braunr> looks like there was no fsys_request.defs in the first place
-      ... *sigh*
-    <braunr> do you know an application that often creates and destroys threads
-      ?
-    <teythoon> no, sorry
-    <pinotree> maybe some test suite
-    <braunr> ah right
-    <braunr> sysbench maybe
-    <braunr> also, i've been hit by a lot more network deadlocks than usual
-      lately
-    <braunr> fixing netdde has gained some priority in my todo list
-
-
-## IRC, freenode, #hurd, 2013-09-20
-
-    <braunr> oh, git is multithreaded
-    <braunr> great
-    <braunr> so i've actually tested my libpthread patch quite a lot
-
-
-## IRC, freenode, #hurd, 2013-09-25
-
-    <braunr> on a side note, i was able to build gnumach/libc/hurd packages
-      with thread destruction
-    <teythoon> nice :)
-    <braunr> they boot and work mostly fine, although they add their own issues
-    <braunr> e.g. the comm field of the root ext2fs is empty
-    <braunr> ps crashes when trying to display threads
-    <braunr> but thread destruction actually works, i.e. servers (those that
-      are configured that away at least) go away after some time, and even
-      heavily used servers such as ext2fs dynamically scale over time :)
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
-    <braunr> concerning threads, i think i figured out the last bugs i had with
-      thread destruction
-    <braunr> it should be well on its way to be merged by the end of the year
-
-
-## IRC, freenode, #hurd, 2013-10-11
-
-    <gg0> braunr: is your thread destruction patch ready for testing?
-    <braunr> gg0: there are packages at my repository, yes
-    <braunr> but i still have hurd fixes to do before i polish it
-    <braunr> in particular, posix says returning from main() stops the entire
-      process and all other threads
-    <braunr> i didn't check that during the switch to pthreads, and ext2fs (and
-      maybe others) actually return from main but expect other threads to live
-      on
-    <braunr> this creates problems when the main thread is actually destroyed,
-      but not the process
-    <teythoon> braunr: tmpfs does something like that, but calls pthread_exit
-      at the end of main
-    <braunr> same effect
-    <braunr> this was fine with cthreads, but must be changed with pthreads
-    <braunr> and libpthread must be fixed to enforce it
-    <braunr> (or libc)
-
-    <braunr> diskfs_startup_diskfs should probably be changed to reuse the main
-      thread instead of returning
-
-
-## IRC, freenode, #hurd, 2013-10-19
-
-    <zacts> I know what threads are, but what is 'thread destruction'?
-    <braunr> the hurd currently never destroys individual threads
-    <braunr> they're destroyed when tasks are destroyed
-    <braunr> if the number of threads in a task peaks at a high number, say
-      thousands of them, they'll remain until the task is terminated
-    <braunr> such tasks are usually file systems, normally never restarted (and
-      in the case of the root file system, not restartable)
-    <braunr> this results in a form of leak
-    <braunr> another effect of this leak is that servers which should go away
-      because of inactivity still remain
-    <braunr> since thread destruction doesn't actually work, the debian package
-      uses a patch to prevent worker threads from timeouting
-    <braunr> and to finish with, since thread destruction actually doesn't
-      work, normal (unpatched) applications that destroy threads are certainly
-      failing bad
-    <braunr> i just need to polish a few things, wait for youpi to finish his
-      work on TLS to resolve conflicts, and that will be all
-
-
-## IRC, freenode, #hurd, 2013-10-30
-
-    <braunr> FYI, the packages on my repository enable actual thread
-      destruction, and i've altered the libports_stability.patch
-    <braunr> it nows only sets the global timeout to 0
-    <braunr> now*
-    <braunr> we actually can't let translator "die" on global timeout because
-      of a race issue
-    <braunr> tested for about two weeks now and no major problem sighted
-    <braunr> top reports processes running for 100% of their time when
-      terminating threads, but i expect it's simply mach/proc aggregating their
-      run time to the task
-    <braunr> 100% of cpu time
-
-
-## IRC, freenode, #hurd, 2013-11-08
-
-    <braunr> teythoon: darnassus is currently running a modified glibc with
-      thread destruction, yes
-    <teythoon> braunr: did that require any fixups in Hurd that I'd have missed
-      ?
-    <braunr> no
-    <braunr> well
-    <teythoon> b/c the resulting hurd package would not boot
-    <braunr> actually yes
-    <braunr> one
-    <braunr> i'll push the patch somewhere
-    <teythoon> iirc the mach-defpager spewed some error and /hurd/init failed
-      to bootstrap the system
-    <braunr> teythoon:
-      http://darnassus.sceen.net/~rbraun/0001-Prevent-diskfs-translators-from-destroying-main-thre.patch
-    <braunr> make sure you have the proper gnumach packages too :p
-    <teythoon> well, that could very well account for my trouble ;)
-    <teythoon> uh
-    <teythoon> well
-    <braunr> gnumach implements thread destruction, glibc uses it, hurd makes
-      sure it doesn't exit from main
-
-
-## IRC, freenode, #hurd, 2013-11-12
-
-    <braunr> ok so, calling pthread_exit() from main isn't the same as
-      returning from main()
-    <braunr> unlike what some man pages seem to say
-    <braunr> so loosing task info when destroying the main thread is actually a
-      proc bug
-    <braunr> ugh
-    <teythoon> ^^
-    <braunr> or a glibc one
-    <teythoon> the proc server, your favorite Hurd component...
-    <braunr> :)
-    <braunr> hm :/
-    <braunr> looks like command line arguments are stored on the stack of the
-      main thread
-    <braunr> and proc merely receives the addresses of those in the target task
-    <neal> why not just keep the main thread around?
-    <neal> it represents a minor resource leak, true
-    <braunr> yes
-    <braunr> that's the hack i suggested
-    <neal> but it is relatively small
-    <braunr> well no
-    <braunr> my hack was about diskfs translators
-    <braunr> it should be generalized in libpthread
-    <braunr> seems reasonable
-    <braunr> let's do it >)
-
-
-## IRC, freenode, #hurd, 2013-11-13
-
-    <youpi> braunr: there is a thread destruction issue in the experimental
-      ocaml build, worth looking at, probably
-    <braunr> what do you mean ?
-    <youpi> ... testing 'testfork.ml': ocamlcocamlrun:
-      ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt:
-      Unexpected error: (ipc/send) invalid destination port.
-    <youpi> during the experimental ocaml build
-    <braunr> well yes
-    <braunr> thread recycling is buggy
-    <braunr> i had the choice to fix it, or implement true destruction
-    <braunr> i'm tweaking my patch so it leaves the main thread stack untouched
-      on destruction
-    <braunr> and it should be ready
-    <braunr> for review at least
-
-
-## IRC, OFTC, #debian-hurd, 2013-11-13
-
-    <gg0> ironforge out of memory during ruby1.9.1 rebuild. during test which
-      creates 10000 threads
-    <gg0> ironforge out of memory during ruby1.9.1 rebuild, test which creates
-      10000 threads
-    <gg0> i guess ironforge kernel has been rebuilt against -95, correct?
-    <youpi> err, what kernel?
-    <gg0> 23:37 < youpi> hurd needs a rebuild to be able to work with the newer
-      eglibc
-    <gg0> i mean hurd
-    <youpi> yes, libc0.3 breaks the old packages anyway
-    <gg0> wrt ENOMEM, was it expected?
-    <gg0> wrt disk problems, aren't there on alioth only?
-    <youpi> well 10,000 threads is a lot, especially on 32bit machine with 2M
-      default stack  size
-    <youpi> that makes 2GiB stacks
-    <youpi> can't fit in a 2/2 split model, which gnumach uses
-    <gg0> well, though active thread should die right away, just after set x to
-      false, if i read it correctly
-    <youpi> perhaps the stacks are not correctly reused
-    <youpi> that's probably worth digging in libpthread
-    <youpi> by putting printfs, etc.
-    <youpi> it seems stacks are never reused indeed, damn
-    <youpi> I just wrote a small test that creates threads which just print
-      their stack address
-    <youpi> that takes just a few minutes to do
-    <gg0> i see. about reusage i guess you mean base address is kindof always
-      incremented
-    * gg0 likes being wrong
-    <youpi> that's it, yes
-    <youpi> gg0: take care, by keeping being wrong all the time, sometimes you
-      get right ;)
-    <youpi> and you are definitely right here :)
-    <youpi> Mmm, but the stack is really deallocated
-    <youpi> and the numbers wrap around
-    <youpi> I wonder how that is :)
-    <youpi> ok, creating 20 000 threads does work
-    <youpi> perhaps ruby does odd things which makes it not work
-
-
-### IRC, OFTC, #debian-hurd, 2013-11-14
-
-    <gg0>  UID   PID  PPID TH  MSGI  MSGO    SZ   RSS SC STAT     TIME COMMAND
-    <gg0> 1012 16446 15473 720  987   509 1.89G 23.6M  1 Hu    0:00.15
-      /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1
-      -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb
-    <gg0> 720 threads, stuck
-    <youpi> 2G SZ is very big :)
-    <gg0> 00:42 < youpi> perhaps ruby does odd things which makes it not work
-    <gg0> is that enough to file a ruby bug? as ruby suggests itself btw
-    <youpi> no, they will probably not be able to investigate
-    <youpi> but you can already check out how they create threads
-    <youpi> and try to reproduce the same with a small C program
-    <gg0> ehm on ruby2.0 with *context _enabled_ i can not reproduce it
-
-See [[/open_issues/glibc]] for `*context` functions.
-
-
-## IRC, freenode, #hurd, 2013-11-14
-
-    <braunr> nice, i got glibc packages with thread destruction
-    <braunr> building hurd packages against it now
-    <braunr> everything seems fine
-    <braunr> hurd packages ready, let's see
-
-    <gg0> ruby1.9.1 FTBFS due to a couple of tests
-      https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1&arch=hurd-i386&ver=1.9.3.448-1&stamp=1384265526
-    <gg0> second one creates 10000 threads and machine got ENOMEM
-    <braunr> bootstraptest.tmp.rb: [BUG] [BUG] pthread_cond_init: Cannot
-      allocate memory (ENOMEM) ew
-    <gg0> few hours ago trying to reproduce it:
-    <gg0> 01:20 < gg0>  UID   PID  PPID TH  MSGI  MSGO    SZ   RSS SC STAT
-      TIME COMMAND
-    <gg0> 01:20 < gg0> 1012 16446 15473 720  987   509 1.89G 23.6M  1 Hu
-      0:00.15 /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1
-      -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb
-    <braunr> yes that's expected
-    <braunr> our stacks are 2M
-    <braunr> 10k threads means right over 2G of stacks
-    <braunr> userspace is restricted to 2G
-    <gg0> but if i read correctly test in question, thread should just set x to
-      false then die
-    <braunr> so ?
-    <gg0> and ENOMEM popped upk when there were thread count was at 720
-    <braunr> hum
-    <braunr> 10k threads would actually be 20G
-    <braunr> 1k threads is 2G
-    <braunr> 720 is about 1.5G
-    <braunr> the rest is probably the ruby runtime
-    <gg0> youpi tried to create 10000 thread, no problem. he guessed something
-      wrong on ruby side
-    <gg0> indeed on ruby2.0 such test succeeds
-    <braunr> you can't create 10k threads unless you change the stack size
-    <braunr> hurd servers use a stack size of 64k by default which allows them
-      to go up to 30k iirc
-    <braunr> but normal applications use the default 2M
-    <gg0> i guess you mean 10000 threads active at the same time. test in
-      question should make them die after simply setting x to false, i guess
-      youpi's test did so as well
-    <braunr> no
-    <braunr> it's about stacks
-    <braunr> hm
-    <braunr> yes at the same time but
-    <braunr> thread recycling is known to be buggy
-    <braunr> which is what i'm currently fixing btw
-    <neal> what's the bug?
-    <braunr> neal: there are several subtle issues
-    <braunr> for example, joining a thread that is also calling pthread_exit
-      can fail badly
-    <neal> hmm
-    <neal> good that you are on it then :)
-    <braunr> or detaching
-    <braunr> i don't remember the details
-    <braunr> but i remember such problems
-    <braunr> apparently, keeping the stack of the main thread isn't enough
-    <braunr> :(
-    <braunr> for now, i'll keep the entire thread
-
-
-## IRC, freenode, #hurd, 2013-11-15
-
-    <gg0> i wasn't doing anything, just some single test runs. but yes, also
-      that one which creates hundreds of threads
-    <gg0> it would like creating 10000 but goes out of memory after ~720
-    <gg0> btw same tests succeed on ruby2.0, so they should be fixed by
-      backporting some changes
-    <braunr> actually it looks more like a deadlock ..
-    <gg0> deadlock that says ENOMEM?
-    <braunr> ?
-    <braunr> ENOMEM is returned because the test task has no more virtual
-      memory
-    <braunr> this doesn't mean the rest of the system should fail
-    <gg0> ok i thought you were talking about such test
-    <braunr> no it's something else
-    <braunr> a deadlock in a critical server
-    <braunr> the root file system maybe
-    <gg0> braunr: htop and ps hang. just run the test once again
-    <gg0> now you should still be able to login
-    <braunr> htop/ps hanging means one process is unable to reply to queries
-      sent to the message port/thread
-    <braunr> procfs does that to report on what a process is waiting
-    <braunr> it usually mean there is a bug around signals, since the message
-      thread is also in charge of delivering signals
-    <braunr> use ps -eM
-    <braunr> and kill -KILL
-    <braunr> hum
-    <braunr> root       954 S<o   0:00.05 /hurd/crash --dump-core
-    <braunr> dumping cores is known not to work most of the time
-    <braunr> exodar shouldn't be configured like that
-    <braunr> so yes, the crash server is hanging
-    <braunr> gg0: i've set it to crash --kill and killed the hanging crash
-      instances blocking top/ps
-    <gg0> nice
-
-    <braunr> my thread destruction patch and tls are indeed conflicting a bit
-    <braunr> i suspect the tcb is used after being freed
-    <braunr> i think i'll simply recycle the tcb, along with the pthread
-      structs
-    <braunr> ok i think it's fine now
-    <braunr> there was also a small bug in the tls code, keeping a reference on
-      the thread port
-    <braunr> mach reference counting is so counter intuitive :/
-    <braunr> well, error-prone
-
-    <braunr> argh, more bugs in libc :(
-    <teythoon> :/
-    <teythoon> but don't worry, there is always one more bug ;)
-    <braunr> this one might explain crashes that are long to trigger
-    <braunr> _hurd_self_sigstate() is implemented like this :
-      _hurd_thread_sigstate (__mach_thread_self ());
-    <braunr> it leaks a reference on the current thread each time it's called
-    <teythoon> >,<
-    <braunr> but glibc maintains such references, so if the maximum value is
-      reached, and references are dropped, the value can reach 0
-    <teythoon> ouch
-    <braunr> at which point any call on a thread will result in an invalid send
-      right
-    <braunr> and probably an assertion
-    <teythoon> well it's a good thing then that you found it :)
-    <braunr> i think it's always been there
-    <braunr> but it's more apparent since jknoenig's patch on signal
-      dispositions
-    <braunr> the maximum number of user references in mach is 64k
-    <braunr> this right leak isn't easy
-    <braunr> tls is very tricky heh :)
-    <braunr> for the main thread, tls initialization happens after the thread
-      creation, obviously
-    <braunr> but for other threads, it's initialized before starting them
-    <braunr> the leak was probably an overlook caused by that complexity
-    <braunr> teythoon: actually that leak i mentioned in _hurd_self_sigstate
-      has only been recently added in Convert sigstate to TLS
-    <braunr> so it's merely tls integration polishing
-    <braunr> youpi: i'm currently reviewing changes related to tls and i think
-      there is a bug in _hurd_self_sigstate
-    <braunr> calls to mach_thread_self() should be paired with
-      mach_port_deallocate to avoid urefs overflows
-    <braunr> and right leaks
-    <braunr> _hurd_critical_section_lock is probably affected too
-    <braunr> hm
-    <braunr> mhmm
-    <braunr> in glibc, hurd/hurd/signal.h, _hurd_critical_section_lock
-    <braunr> why is the sigstate unlocked after the call to
-      _hurd_thread_sigstate
-    <braunr> _hurd_thread_sigstate doesn't seem to lock it ..
-    <braunr> unless __spin_lock_init does it
-    <braunr> yes, leak solved :)
-
-
-## IRC, freenode, #hurd, 2013-11-16
-
-    <braunr> argh, _hurd_critical_section_lock is called before the send right
-      on the main thread is fetched in libpthread :/
-    <teythoon> is that bad ?
-    <braunr> the sigstate is supposed to be initialized after pthreads
-    <braunr> _hurd_critical_section_lock will create it if it sees there is
-      none
-    <braunr> creating the sigstate is currently what makes the send right leak
-    <teythoon> ok
-    <teythoon> it's bad then
-    <braunr> it may be due to my patch
-    <braunr> _hurd_critical_section_lock is called during pthreads
-      initializatio
-    <braunr> n
-    <braunr> before the sigstate for the main thread is created, but after the
-      pthread init routine is called
-    <braunr> it does indeed look like the code wasn't written with thread being
-      destroyed some day in mind :/
-    <teythoon> braunr: btw, if you ever feel like benchmarking, sysbench has a
-      benchmark for threads contending for a lock
-    <braunr> yes i've used it before
-    <teythoon> was it useful for this purpose ?
-    <braunr> no :)
-    <teythoon> :/
-    <braunr> we already know libpthread isn't optimized
-    <braunr> and felt it when we switched from cthreads
-    <braunr> humpf
-    <braunr> simply calling malloc implies a call to
-      _hurd_critical_section_lock
-    <braunr> on the other hand, unlike what some glibc comments say, this does
-      work
-
-
-## IRC, freenode, #hurd, 2013-11-17
-
-    <braunr> looks like i've fixed all leak issues with thread destruction and
-      tls :)
-    <braunr> let's see if ext2fs.static works fine too
-    <youpi> braunr: \o/
-    <youpi> sorry about introducing the tls ones :)
-    <braunr> no worries, it was expected
-    <braunr> and tls was really needed :)
-    <braunr> i mean, i expected to have some problems when rebasing on tls :p
-    <teythoon> braunr: this is good news, how is your rootfs translator holding
-      up?
-    <braunr> building hurd packages right now
-    <braunr> for now, only test applications and a few really multithreaded
-      ones (e.g. iceweasel) have been tested
-    <braunr> well, the system boots :)
-    <teythoon> awesome :)
-    <braunr> stressing the file system with git while watching youtube videos
-      with gnash doesn't make the system crash
-    <teythoon> you can actually watch yt videos on your Hurd box ?
-    <braunr> yes
-    <braunr> for a while now
-    <teythoon> o_O
-    <braunr> can't you ?
-    <teythoon> I never even dared to try
-    <braunr> hehe
-    <braunr> teythoon: looks stable enough to install on darnassus
-
-
-## IRC, freenode, #hurd, 2013-11-18
-
-    <teythoon> braunr: wrt to your thread destruction patchset, I thought you
-      also had to fix the proc server ?
-    <braunr> teythoon: no
-    <braunr> the problem was in glibc
-    <braunr> i may have to fix proc/procfs though, because cpu time gets wrong
-      with the patch
-    <braunr> currently, it's the addition of the cpu time of all threads
-    <braunr> mach provides aggregate times including destroyed threads though
-    <teythoon> ah, I see
-    <braunr> one side effect is that you'll see processes sometimes taking 100%
-      of cpu time although the cpu is unused
-    <braunr> or the cpu time of a process gets reduced :)
-    <braunr> i guess the 100% cpu is how top sees a negative increment
-    <teythoon> ^^
-    <braunr> gg0: do my threadterm packages help with ruby1.9 ?
-    <braunr> i mean, can you test with them some time ? :)
-
-
-## IRC, freenode, #hurd, 2013-11-21
-
-    <braunr> youpi: ping about my question regarding error handling in the
-      proposed thread_terminate_release call
-    <youpi> I agree with what Neal said
-    <braunr> he didn't say anything about error handling
-    <braunr> see
-      http://lists.gnu.org/archive/html/bug-hurd/2013-11/msg00181.html
-    <braunr> i think i should make the call fail on first error
-    <braunr> it shouldn't happen, so it would merely serve to catch bugs
-    <braunr> it's not easily recoverable (if it's recoverable at all)
-    <youpi> uh, I thought he had
-    <youpi> I must have dreamt
-
-    <braunr> i think i'll go ahead with thread destruction integration
-
-
-## IRC, freenode, #hurd, 2013-11-25
-
-    <braunr> i've pushed the thread destruction patches for gnumach upstream
-    <braunr> and made a branch in glibc for that too
-    <teythoon> awesome :)
-    <braunr> youpi: i don't remember how glibc changes should be managed
-    <braunr> once those are applied, i'll commit in libpthread
-    <youpi> braunr: usually we create a topgit branch, and then we add the
-      patch from that to the debian repository
-
-
-## IRC, freenode, #hurd, 2013-11-29
-
-    <braunr> youpi: i still have a leak somewhere with the thread destruction
-      patches
-    <braunr> maybe on the host priv port in bootstrap servers (root fs and proc
-      server)
-    <braunr> it prevents priority adjusting in libports and can easily bring
-      down a system because servers can start trashing a lot sooner, as it was
-      the case during the pthread migration
-
-See discussion about that on [[/open_issues/libpthread]].
-
-    <braunr> so i'll hunt it down before merging
-
-
-## IRC, freenode, #hurd, 2013-12-19
-
-    <braunr> darnassus still has the libports priority adjustement leaks
-    <braunr> i'll apply a few more patches to my hurd packages
-
-    <braunr> humpf, proc seems to have a problem getting the host priv port :/
-    <teythoon> thats bad
-    <teythoon> what did you do ?
-    <braunr> i fixed all the leaks in libports when adjusting priorities
-    <braunr> the last one being releasing the host priv right
-    <braunr> and i get errors at boot time from the proc server
-    <teythoon> remember when i had this problem ?
-    <braunr> proc doesn't get the host priv port the normal way since the
-      normal way is to get it from proc iirc
-    <teythoon> ah, thought you fixed that
-    <braunr> so i guess the alternate way doesn't add a reference
-    <braunr> well the leak is fixed
-    <braunr> the problem you had was due to the leak which made the host priv
-      port reach its max uref value
-    <braunr> now it's just the proc server
-    <braunr> the system works fine though
-    <teythoon> for real ?
-    <teythoon> the proc server needs the host priv port for getting the new
-      tasks
-    <braunr> well yes
-    <teythoon> how can it work w/o it ?
-    <braunr> i don't know ..
-    <braunr> i guess the problem is internal to glibc
-    <braunr> i mean, get_priv_ports fails, but that doesn't mean the host priv
-      port is lost
-    <teythoon> could be
-    <teythoon> are you running a patched rootfs translator too ?
-    <braunr> yes
-    <teythoon> ok
-    <teythoon> b/c i remember having trouble with that
-    <braunr> right, the glibc call would make proc call __proc_getprivports
-    <braunr> hum
-    <braunr> teythoon: do you remember how proc gets its host priv port ?
-    <teythoon> from init
-    <teythoon> i think
-    <braunr> startup_procinit ?
-    <teythoon> possibly
-    <braunr> right
-    <braunr> so it's probably not the host priv port
-    <braunr> i mean, the error is about another invalid send right
-    <braunr> hm nope, it is on host_priv :/
-    <braunr> hm ok i see, looks like a bug from a debian patch
-    <braunr> or rather, a bug fix not yet imported into the debian package
-    <braunr> teythoon: you actually fixed it in
-      2c9422595f41635e2f4f7ef1afb7eece9001feae
-    <braunr> great :)
-    <teythoon> ah, that one
-    <braunr> i was looking at the upstream code and couldn't understand what
-      was going wrong
-    <braunr> :)
-    <braunr> much better
-    <braunr> except ps -eT doesn't work any more ..
-    <braunr> interestingly, with the thread destruction patch, ps -eT sometimes
-      work, and sometimes doesn't
-    <braunr> the behaviour doesn't seem to change without a reboot
-    <braunr> and of course, as soon as i say it, i'm proven wrong by the next
-      test :)
-
-
-## IRC, freenode, #hurd, 2013-12-26
-
-    <braunr> __pthread_sigstate_init doesn't seem to be converted to TLS in the
-      upstream repository master branch
-
-    <braunr> ah dammit, the global signal dispositions patch touches both glibc
-      and libpthread @#!
-    <braunr> what a mess
-
-    <braunr> youpi: do you have some time to quickly review the
-      rbraun/thread_destruction branch in libpthread ?
-    <braunr> there might be conflict with some glibc patches
-    <braunr> or do you prefer it on the mailing list ?
-    <braunr> (i used a branch because it's not based on master)
-    <youpi> rather mail the list, yes
-    <braunr> ok
-    <youpi> it'd also be useful to write the rationale
-    <youpi> probably to be left as comment in the source code
-    <braunr> yes, that branch was for personal storage :)
-    <youpi> so the reader knows how things are recycled or not
-    <braunr> hm
-    <braunr> that should already be the case
-    <youpi> ok
-    <braunr> the two structures that are still recycled are the pthread struct
-      and tls
-    <braunr> it's quite obvious from pthread_alloc
-    <braunr> and well commented there
-    <braunr> for tls, it's explained in pthread_exit
-
-    <braunr> there, thread destruction finally merged in
-    <braunr> and now, we can remove the ugly hacks that were done for
-      threadvars
-    <braunr> :)
-    <braunr> change stacks at will and support all sorts of weird languages and
-      runtimes
-    <teythoon> braunr: cool :)
-
-
-## IRC, freenode, #hurd, 2013-12-31
-
-    <youpi1> braunr: I've added sigstate_locking, sigstate_thread_reference and
-      tls_thread_leak to the debian glibc 2.18 package
-    <youpi1> I believe that's complete?
-    <youpi1> is mach_msg_uspace_options ready for being added? Does it bring
-      much speedup?
-    <youpi1> AIUI, thread_terminate_release is  the union of the branches
-      mentioned above?
-    <youpi1> (I'm cleaning up branches in the glibc repo)
-    <braunr> youpi1: mach_msg_uspace_options can be left over, it only affects
-      selects and not noticeably
-    <braunr> yes, those three branches are the only ones needed for thread
-      destruction
-    <youpi1> ok
-    <youpi> does the hurd changes depend on these changes ?
-    <braunr> no
-    <youpi> good :)
-    <braunr> only on tls for one of them
-    <braunr> (it's about the default stack size of 64k for hurd servers)
-    <youpi> and we have had this in debian for a long time already :)
-    <braunr> yes
-    <youpi> (how big were they before?)
-    <youpi> (where they a couple MiB, and thus exploding to GiBs on thousands
-      of threads?)
-    <braunr> 64k
-    <braunr> pthread stacks are 2M by default
-    <braunr> yes
-
-
-## IRC, freenode, #hurd, 2014-01-14
-
-    <youpi> braunr: it seems your time change in libps made ps produce odd re
-    <youpi> results
-    <youpi>     samy 10987     5 -514358:-18:-42.17 /hurd/firmlink tmp
-    <braunr> youpi: wow :)
-    <braunr> that change is supposed to run on a system where threads actually
-      get destroyed
-    <braunr> but i don't see what could trigger this side effect
-    <youpi>     root  8629   664 56 years make -j 3
-    <youpi> :)
-    <braunr> heh
-    <braunr> youpi: does the hurd package on darnassus include that patch ?
-    <youpi> yes
-    <braunr> i don't reproduce the problem :/
-    <youpi> err
-    <braunr> what command are you using ?
-    <youpi> ps -feM on darnassus
-    <youpi>     root 29642   473 7 months /usr/sbin/sshd -R
-    <braunr> hmmmm
-    <braunr> i don't see it with a make -j
-    <youpi> well, it's not systematic
-    <youpi> it's like once over two launches
-    <braunr> hhhhmmmmm
-    <youpi> it'd look like some random numbers get added
-    <braunr> strangely, the gcc processes started by a recursive make aren't
-      children of make ..
-    <braunr> ps -eF hurd seems to report the correct values
-    <braunr> even ps -eM
-    <braunr> oO
-    <braunr> ps -ef too
-    <braunr> the problem seems to be with ps -efM
-    <youpi> too bad I'm always using that :)
-    <braunr> another way to see it is that it makes us spot the issue ;p
-
-
-### IRC, freenode, #hurd, 2014-01-15
-
-    <braunr> ok i have an idea of what goes wrong in libps
-
-    <braunr> youpi: for some reason, ps -efM lacks the PSTAT_TASK_BASIC flag
-    <braunr> my patch is wrong since it doesn't try to determine whether the
-      stats apply to a task or a thread, but that is easy to fix
-    <braunr> ps -efM should nonetheless provide basic task info, obviously
-    <braunr> in addition, the problems i've observed with ps -T (occasional
-      segfaults) seem to have existed before thread destruction
-    <braunr> they're just strongly exposed now that the thread list can be
-      shrunk
-
-    <braunr> libps is quite complicated
-    <braunr> even hairy, i'd say ..
-
-
-### IRC, freenode, #hurd, 2014-01-16
-
-    <braunr> youpi: i think i have a proper fix for libps
-    <braunr> i'll commit it soon
-    <youpi> ok
-    <braunr> basically, getting system times simply set the PSTAT_THREAD_BASIC
-      flag
-    <braunr> whereas getting the run time of the terminated threads requires
-      PSTAT_TASK_BASIC
-    <braunr> i assumed it was always set in the function i changed when dealing
-      with a task and not a thread
-    <braunr> and well, that was a wrong assumtion, -M can remove it if not
-      strictly needed by the format
-    <braunr> the default format asks for suspend_count, which forces the
-      retrieval of task basic info, os it works with -eM
-    <braunr> but -f doesn't :)
-    <youpi> so extremely bad lucky combination of flags :)
-    <braunr> indeed
-    <braunr> i added a pstat_times using the last (!) available flag bit
-    <braunr> looks clean to me
-    <braunr> i hope there is no abi issue
-    <braunr> (at least everything works with the unmodified ps-hurd executable
-      and a new libps.so)
-
-    <braunr> hm, small bug in the thread destruction patch :/
-
-
-### IRC, freenode, #hurd, 2014-01-17
-
-    <braunr> good, i have proper fixes for tls in the main thread and thread
-      termination :)
-    <teythoon> awesome :)
-    <teythoon> i've been wondering, what does it take to get the thread
-      destruction stuff into the debian package ?
-    <braunr> i still have to build test packages, look for (unlikely, heh)
-      regressions and work some integration details with samuel
-    <braunr> hum the main thread tls fixup i guess
-    <braunr> youpi was waiting for me to fix that
-    <braunr> gnumach already provides the RPC
-    <braunr> so it will be in glibc soon
-    <braunr> i just have to get those last bits right
-    <braunr> teythoon: i'm quite slow at integrating stuff
-    <teythoon> and samuel then builds packages ?
-    <teythoon> i mean, is our libc package build linked to the other libc
-      packages ?
-    <braunr> libpthread is applied as a patch to glibc
-    <braunr> and loaded as a plugin
-
-
-## IRC, freenode, #hurd, 2014-01-17
-
-    <braunr> uhm, did we break fakeroot-tcp ?
-    <teythoon> we did ?
-    <youpi> fakeroot-tcp just works fine on buildds
-    <braunr> with fakeroot-tcp, i get
-    <braunr> make[4]: Entering directory
-      `/home/rbraun/devel/debian/packages/hurd/hurd-0.5.git20140113/libdde-linux26/contrib/include'
-    <braunr> rm -f .general.d
-    <braunr> make[4]: *** [cleanall] Killed
-    <braunr> when cleaning the package before building ..
-
-
-### IRC, freenode, #hurd, 2014-01-18
-
-    <braunr> damn, fakeroot-tcp won't work on darnassus ..
-    <braunr> uh, looks like my tls/thread destruction "fixes" do cause
-      regressions :(
-    <braunr> fakeroot works fine with debian glibc
-    <teythoon> which one ?
-    <teythoon> which fakeroot i mean
-    <braunr> -tcp
-    <braunr> yes, it fails as soon as i use the patched glibc :/
-    <braunr> at least it's easy to reproduce
-
-
-### IRC, freenode, #hurd, 2014-01-20
-
-    <braunr> great, 3rd libc version installed on darnassus, let's see if i can
-      build hurd packages against that
-
-
-### IRC, freenode, #hurd, 2014-01-21
-
-    <braunr> damn, fakeroot-tcp still crashes with my latest changes ....
-
-    <braunr> darnassus looks in good shape
-    <braunr> youpi: ^
-    <braunr> youpi: if you have other tests, feel free to do them now
-    <braunr> i feel confident about committing the changes, if you're ok with
-      it
-    <youpi> which changes ?
-    <youpi> I'm a bit lost in what you were talking about :)
-    <braunr> you can find them in 2 patches in /var/tmp on darnassus
-    <braunr> one is about fixing thread destruction
-    <braunr> i'm pretty certain about this one so i'll commit it directly
-    <braunr> the other is fixing the tcb of the main thread
-
-[[open_issues/libpthread]].
-
-    <braunr> where i simply do tcb->self = thread->kernel_thread :)
-    <braunr> with a comment explaining why i don't do something else like
-      deallocating the unused tcb
-    <youpi> braunr: ok, that looks good
-    <teythoon> braunr: awesome :)
-    <braunr> youpi: ok
-
-
-### IRC, freenode, #hurd, 2014-01-22
-
-    <braunr> there, libpthread should be fine now
-
-
-## IRC, freenode, #hurd, 2014-02-06
-
-    <braunr> youpi: in case you're planning to upgrade glibc (or not), the
-      thread destruction changes are complete
-    <braunr> youpi: darnassus has been running them for some weeks with no
-      visible regression
-    <youpi> braunr: ok, good
-    <youpi> including it in glibc was on my todo list indeed
-    <youpi> and Adam  indeed plan for a 2.18 upload
-    <braunr> good :)
-    <youpi> braunr: this is up to 7c6dc6e28b2fc4b67934223f41cf080ffe58b230,
-      right? (Wed Jan 22, Fix up the main thread TCB)
-    <braunr> yes
-    <braunr> oh, i just saw 2.17-98~0 glibc packages on debian-ports :)
-    <youpi> yes, it's just to fix the dhcp crash
-    <braunr> ah yes, it's not 2.18
-    <youpi> 2.18 is available in experimental
-
-    <youpi> braunr: just to make sure: did you have
-      983b18a6ff16f5687a9ece63a50d1831dec88609 in libc on darnassus?
-    <youpi> (which drops the stack size  hack)
-    <braunr> youpi: let me check
-    <braunr> youpi: ah no, i don't, you're right
-    <youpi> well, I was just wondering, nothing make me think that was the case
-      :)
-    <youpi> what was the issue that it was raising btw?
-    <braunr> threadvards
-    <youpi> ok, b ut in which case?
-    <youpi> (to make sure I test that before committing)
-    <braunr> now that we switched to tls, i would assume the transition path to
-      be 1/ hurd stops defining that symbol, 2/ libpthread can stop using it
-    <braunr> the goal was to reduce the stack size of hurd server threads
-    <youpi> well, that's not my question :) I'm wondering in which precise case
-      that was breaking things
-    <braunr> youpi: i don't know, it shouldn't break
-    <youpi> ok
-    <braunr> youpi: just in case, don't forget that last one line patch i
-      committed last night, fakeroot can't work right without it
-    <braunr> (i made a minor change while reviewing before comitting, and
-      obviously got it wrong :p)
-    <youpi> ok
-
-    <youpi> braunr: I've upgraded libpthread in debian's eglibc btw
-
-    <braunr>
-      /home/rbraun/devel/debian/packages/eglibc/eglibc-2.17/build-tree/hurd-i386-libc/libc.so.phdr:
-      *** executable stack signaled
-    <braunr> from build-tree/hurd-i386-libc/elf/check-execstack.out
-    <braunr> i thought glibc didn't use those
-    <braunr> anyway it doesn't look to be the regression i'm having
-    <braunr> does this ring a bell :
-    <braunr> Encountered regressions that don't match expected failures
-      (debian/testsuite-checking/expected-results-i486-gnu-libc):
-    <braunr> test-stpcpy_chk.out, Error 1
-    <braunr> TEST test-stpcpy_chk.out: __stpcpy_chk    normal_stpcpy
-      simple_stpcpy_chk
-    <youpi> nope
-    <youpi> after what are you getting this regression?
-    <braunr> building glibc 2.17-97 with thread destruction patches, including
-      the one removing the stack size hack
-    <braunr> during tests
-    <braunr> there also are "progressions", but i'm not sure what these are
-    <youpi> some progressions are just luck, other seem to happen on some
-      platforms only
-    <youpi> I'm not sure you want to test 2.17
-    <youpi> a lot has changed between 2.17's libpthread and 2.18's libpthread
-      (which is now equal to cvs's libpthread
-    <youpi> )
-    <youpi> s/cvs/git/
-    <braunr> yes
-    <braunr> i usually build with nocheck
-
-
-## IRC, freenode, #hurd, 2014-02-07
-
-    <braunr> youpi: on a vm with hurd 1:0.5.git20140203-1, upgrading to a
-      patched glibc 2.17-97 that includes the patch which reverts the stack
-      size hack, the system reboots and works fine
-    <youpi> ok. I don't remember what problem I was seeing
-    <braunr> that version of the hurd no longer defines the symbol
-    <braunr> but even then, there shouldn't have been any problem
-    <braunr> hm, or does it
-    <braunr> yes, it does
-    <braunr> youpi: the hurd package patch mentions
-    <braunr> Revert this for now, will have to wait for dropping the use of
-    <braunr> __pthread_stack_default_size from eglibc's
-      libpthread_hurd_cond_wait.diff
-    <braunr> i wonder how it got there
-    <youpi> IIRC I was wondering too
-    <braunr> i've installed my c library on darnassus and it works fine there
-      too
-    <braunr> with older (january) hurd packages
-    <braunr> looks good to me
-
-
-## IRC, freenode, #hurd, 2014-02-10
-
-    <teythoon> braunr: btw, do the new libc packages contain your thread
-      destruction work ?
-    <braunr> teythoon: the -98 ones on experimental ?
-    <braunr> i don't think they do
-    <braunr> the -18 ones should do