(see master bug 323020) * 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.
Fix committed in revision 16159 This fix is a good candidate for a 3.12.1, as the missing deregister can cause a big performance degradation. Another change will be done later to produce a warning if overlapping stacks are registered and/or non existing stacks are deregistered
Follow up in SVN r16160.
macOS-specific follow up in r16168.