title: Is there a Valgrind for detecting "Memory Leaks" with Smart Pointers
body: <p>Our team has recently started to experiment with smart pointers, and I am increasingly concerned about our ability to detect and correct memory leaks.</p>
  
  <p>I understand ( I think. . .) that in the purest sense, smart pointers rarely have true leaks, and if there are, it's generally related to circular references.  However, I am afraid this is masking the problem of a memory leak in the sense of being "unwanted and unnecessary memory consumption".  </p>
  
  <p>For example, when using traditional raw pointers, if an object fails to properly clean up memory, we could run Valgrind and at the end of the program, anything left was a leak (often this could be a leak that continues to grow during program execution leading to severe problems). . . Now with smart pointers, these all get cleaned up before program exit and Valgrind won't see any lost references to allocated memory.</p>
  
  <p>In general I see the value of smart pointers in helping developers prevent leaks, however we are human and make mistakes, thats why we have debugging tools! </p>
  
  <p>How can we detect unwanted memory growth due to a programming error, like we used to be able to do with Valgrind and raw pointers?</p>
  
  <p>... Edits </p>
  
  <p>1)
  Foolishly I normally associate Valgrind with Memcheck and that is how I intended to use it above.  My apologies for confusion.  </p>
  
  <p>2) As an illustration here is an example:</p>
  
  <p>Consider  multi-threaded application to process data.  The first thread reads input (from disk or network whatever), then passes a data block to another thread running Algorithm Step 1 via a queue,  Step1's thread grabs data out of its input queue does its thing and passes the data on to Step2.  Repeat until a final thread writes out a result (to disk or network).  When all the input data is processed, each thread kills itself after it finishes the last items and the program exits. </p>
  
  <p>Now during execution our footprint grows significantly, assuming we can process data as fast as we ingest it, there must be a leak.  Using raw pointers I used to detect this kind of error with Memcheck which would have reported lost or possibly lost blocks of memory at the program end which we could track down and fix.</p>
  
  <p>3) In our haste to learn and apply smart-pointers we probably used "shared_ptr" where as another type may have been more appropriate for our application.</p>