Bug 373046

Summary: Stacks registered by core are never deregistered
Product: [Developer tools] valgrind Reporter: Philippe Waroquiers <philippe.waroquiers>
Component: generalAssignee: Julian Seward <jseward>
Status: RESOLVED FIXED    
Severity: normal CC: ivosh, philippe.waroquiers, rhyskidd
Priority: NOR    
Version First Reported In: 3.12 SVN   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Philippe Waroquiers 2016-11-28 19:30:47 UTC 
(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.
Comment 1 Philippe Waroquiers 2016-11-28 19:37:20 UTC 
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
Comment 2 Ivo Raisr 2016-11-28 21:42:15 UTC 
Follow up in SVN r16160.
Comment 3 Rhys Kidd 2016-12-04 03:53:01 UTC 
macOS-specific follow up in r16168.