title: Using valgrind to find a memory leak in the mysql c++ client
body: <p>I'm using valgrind to try and track down a memory leak is the mysql c++ client distributed from mysql.</p>
  
  <p>In both the examples (resultset.cpp) and my own program, there is a single 56 byte block that is not freed. In my own program, I've traced the leak to a call to the mysql client.</p>
  
  <p>Here are the results when I run the test:</p>
  
  <pre><code>valgrind --leak-check=full --show-reachable=yes ./my-executable
  
  ==29858== Memcheck, a memory error detector
  ==29858== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
  ==29858== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
  ==29858== Command: ./my-executable
  ==29858==
  ==29858==
  ==29858== HEAP SUMMARY:
  ==29858==     in use at exit: 56 bytes in 1 blocks
  ==29858==   total heap usage: 693 allocs, 692 frees, 308,667 bytes allocated
  ==29858==
  ==29858== 56 bytes in 1 blocks are still reachable in loss record 1 of 1
  ==29858==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
  ==29858==    by 0x400D334: _dl_map_object_deps (dl-deps.c:506)
  ==29858==    by 0x4013652: dl_open_worker (dl-open.c:291)
  ==29858==    by 0x400E9C5: _dl_catch_error (dl-error.c:178)
  ==29858==    by 0x4012FF9: _dl_open (dl-open.c:583)
  ==29858==    by 0x7077BCF: do_dlopen (dl-libc.c:86)
  ==29858==    by 0x400E9C5: _dl_catch_error (dl-error.c:178)
  ==29858==    by 0x7077D26: __libc_dlopen_mode (dl-libc.c:47)
  ==29858==    by 0x72E5FEB: pthread_cancel_init (unwind-forcedunwind.c:53)
  ==29858==    by 0x72E614B: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)
  ==29858==    by 0x72E408F: __pthread_unwind (unwind.c:130)
  ==29858==    by 0x72DDEB4: pthread_exit (pthreadP.h:265)
  ==29858==
  ==29858== LEAK SUMMARY:
  ==29858==    definitely lost: 0 bytes in 0 blocks
  ==29858==    indirectly lost: 0 bytes in 0 blocks
  ==29858==      possibly lost: 0 bytes in 0 blocks
  ==29858==    still reachable: 56 bytes in 1 blocks
  ==29858==         suppressed: 0 bytes in 0 blocks
  ==29858==
  ==29858== For counts of detected and suppressed errors, rerun with: -v
  ==29858== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 6)
  </code></pre>
  
  <p>I have a few questions regarding this:</p>
  
  <ol>
  <li>How should I interpret the --show-reachable block? </li>
  <li>Is that block useful for me to try and zero in on the error?</li>
  <li>If the block is not useful, does valgrind have another mechanism that would help me trace the leak? </li>
  <li>If not, is there some other tool (hopefully OSS on linux) to help me narrow this down?</li>
  </ol>
  
  <p>Thanks in advance..</p>
  
  <p><strong>UPDATE:</strong> Here is the code that I found on my system for the definition of pthread_exit. I'm not certain that this is the actual source that is being invoked. However, if it is, can anyone explain what might be going wrong?</p>
  
  <pre><code>void
  pthread_exit (void *retval)
  {
      /*  specific to PTHREAD_TO_WINTHREAD  */
  
      ExitThread ((DWORD) ((size_t) retval));  /*  thread becomes signalled so its death can be waited upon  */
      /*NOTREACHED*/
      assert (0); return;  /*  void fnc; can't return an error code  */
  }
  </code></pre>