This bug is a follow-up of valgrind users mailing list discussion:
http://sourceforge.net/mailarchive/message.php?msg_id=31040653
(which is basically https://bugs.kde.org/show_bug.cgi?id=124418)

This bug describes several aspects related to thread stack management.
Some aspects are "strange" but unclear how to fix/improve.
Some aspects could be fixed.

* thread stacks are registered using m_stacks.c VG_(register_stack),
  but are never deregistered.
  syswrap-<machine>-linux.c are all calling VG_(register_stack).
  However, these stacks are never deregistered: the only call to
  VG_(deregister_stack) is in scheduler.c (for the client request).
  So, an application with many threads creation/destruction might end up with
  a bunch of "dead" client stacks registered in m_stacks.c
  (these dead stacks might then point anywhere, as the client thread memory
   might have been recycled e.g. for malloc).
  Also, it is unclear if and where the darwin implementation registers
  the thread stacks.

* comments in pub_core_threadstate.h are wrong/inconsistent
  with syswrap-<machine>-linux.c
  Comment (around line 322 /* Client stacks.) indicates that the client
  stack is not deallocated and increased if needed.
  However, the code in syswrap-x86-linux.c (and others) tells:
   /* We don't really know where the client stack is, because its
      allocated by the client. 
  Comment in pub_core_threadstate.h looks incorrect: the thread stack
  is fully managed by the client.

* It is not very clear why m_stacks.c has to be "hooked" with clone:
  at least on debian6/amd64 and debian6/x86,
  commenting out the calls to VG_(register_stack) for the main thread
  and for the cloned threads makes no difference in regtests results.

* Valgrind client thread stack size guess can be wrong:
  When the clone syscall is handled by Valgrind, Valgrind is
  guessing the stack size using the current stack pointer value
  and the lowest address of the segment in which the current
  stack pointer is.
  This guess should be ok when each thread stack has its own
  segment. The guess will however be wrong when e.g.
  malloc-ed memory is used for the thread stack: the lowest
  thread stack address will be the address of the segment
  as managed by the malloc lib (or Valgrind malloc lib).
  This can e.g. give overlapping stacks and/or
  overestimate the size of the stack.
  It is unclear how to improve the guess, without user hints.
  The problem of guessing the stack size was already discussed in
  e.g. bug https://bugs.kde.org/show_bug.cgi?id=188969

* memcheck VA bits for user managed stacks not ok after thread exit:
  When the user manages thread stack (e.g. using malloc-ed memory),
  then once the thread is terminated, memcheck does not reset the
  VA-bits of the thread stack memory:
  when esp is decreased, memcheck marks the "new" stack memory as
  accessible. When esp is increased, memcheck marks the "old" stack
  memory as not accessible.
  When the thread terminates, the VA-bits are left unchanged.
  If the user re-uses this memory for other purposes, this can give
  false positive of "memory not accessible".
  It is unclear how to fix that without user help: as the stack size
  guess can give wrong results, memcheck cannot blindly
  make the guessed stack accessible+uninit (as this could changes
  the VA bits of unrelated memory (e.g. neighbour malloc-ed memory
  in the same segment).
  This is bug https://bugs.kde.org/show_bug.cgi?id=124418