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

Question

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

在示例 (resultset.cpp) 和我自己的程序中，都有一个未释放的 56 字节 block 。在我自己的程序中，我已将泄漏追踪到对 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 block ？
2. 该 block 是否对我尝试将错误归零有用？
3. 如果 block 没有用，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

Reachable 只是意味着当程序退出时，这些 block 有一个在范围内引用它们的有效指针，这表明该程序在退出时不会明确释放所有内容，因为它依赖于底层操作系统来这样做。您应该寻找的是丢失 block ，其中内存块丢失了对它们的所有引用并且无法再被释放。

因此，这 56 个字节可能是在 main 中分配的，并没有明确释放它们。您发布的内容没有显示内存泄漏。它显示 main 释放除了 main 分配的所有内容，因为 main 假设当它死掉时，所有内存都将被内核回收。

具体来说，是 pthread(在 main 中)做出了这个假设(这是对过去 15 年以上在生产中发现的几乎所有内容的有效假设)。需要释放在退出时仍然具有有效引用的 block 是一个有争议的问题，但对于这个特定问题，所有需要提及的是做出了假设。

编辑

实际上 pthread_exit() 没有在退出时清理一些东西，但是正如所解释的那样，它可能不需要(或者很可能 不能)一旦它到达那个点。