使用valgrind在mysql c ++客户端中查找内存泄漏

Question

我正在使用valgrind来尝试追踪内存泄漏是从mysql分发的mysql c ++客户端.

在示例(resultset.cpp)和我自己的程序中,都有一个未释放的56字节块.在我自己的程序中,我已经将泄漏跟踪到对mysql客户端的调用.

以下是我运行测试时的结果:

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)

我有几个问题:

1. 我应该如何解释--show-reachable块？
2. 这个块对我来说是否有用,可以尝试将错误归零？
3. 如果该块无用,valgrind是否有另一种机制可以帮助我追踪泄漏？
4. 如果没有,是否有其他工具(希望在Linux上的OSS)帮我缩小范围？

提前致谢..

更新:这是我在我的系统上找到的用于定义pthread_exit的代码.我不确定这是被调用的实际来源.但是,如果是的话,任何人都可以解释可能出现的问题吗？

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  */
}

Answer 1

可访问只是意味着当程序退出时,块具有在范围内引用它们的有效指针,这表示程序在退出时没有显式释放所有内容,因为它依赖于底层操作系统来执行此操作.您应该寻找的是丢失的块,其中内存块丢失了对它们的所有引用并且不能再被释放.

因此,56个字节可能在main中分配,没有明确释放它们.您发布的内容并未显示内存泄漏.它显示主要释放除了主要分配的所有内容,因为main假定当它死亡时,内核将回收所有内存.

具体来说,它是pthread(在主要方面)做出这个假设(这是在过去15年以来的生产中发现的所有内容附近的有效假设).在退出时释放仍然具有有效引用的块的需要是一个有争议的问题,但对于这个具体问题,需要提及的是所做的假设.

编辑

它实际上并pthread_exit()没有在退出时清理某些东西,但正如所解释的那样,一旦达到这一点,它可能不需要(或很可能不会).