5

我正在使用 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  */
}
4

1 回答 1

6

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

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

具体来说，它是 pthread（主要）做出了这个假设（这是对过去 15 年以上在生产中发现的所有内容的该死的有效假设）。释放在退出时仍然具有有效引用的块的需要是一个有争议的点，但对于这个特定的问题，所有需要提到的是做出了假设。

编辑

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

于 2012-08-07T17:00:58.987 回答