使用 valgrind 调查 Glib 内存泄漏答案

【问题标题】：Glib memory leak using valgrind investigation使用 valgrind 调查 Glib 内存泄漏
【发布时间】：2013-01-28 13:34:19
【问题描述】：

我知道这里之前有类似的线程关于这个问题并且在这个网站上https://live.gnome.org/Valgrind已经解释过，我在下面写了我的简单程序

  #include <glib.h>
  #include <glib/gprintf.h>
  #include <iostream>

  int main()
 {
const gchar *signalfound = g_strsignal(1);
std::cout <<  signalfound<< std::endl;
return 0; 
  }

但是当我尝试使用 valgrind 使用此命令进行检查时 G_DEBUG=gc-friendly G_SLICE=always-malloc valgrind --leak-check=full --leak-resolution=high ./g_strsignal

这是结果

   ==30274== Memcheck, a memory error detector
   ==30274== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
   ==30274== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
   ==30274== Command: ./g_strsignal
   ==30274== Parent PID: 5201
   ==30274== 
   ==30274== 
   ==30274== HEAP SUMMARY:
   ==30274==     in use at exit: 14,746 bytes in 18 blocks
   ==30274==   total heap usage: 24 allocs, 6 frees, 23,503 bytes allocated
   ==30274== 
   ==30274== LEAK SUMMARY:
   ==30274==    definitely lost: 0 bytes in 0 blocks
   ==30274==    indirectly lost: 0 bytes in 0 blocks
   ==30274==      possibly lost: 0 bytes in 0 blocks
   ==30274==    still reachable: 14,746 bytes in 18 blocks
   ==30274==         suppressed: 0 bytes in 0 blocks
   ==30274== Reachable blocks (those to which a pointer was found) are not shown.
   ==30274== To see them, rerun with: --leak-check=full --show-reachable=yes
   ==30274== 
   ==30274== For counts of detected and suppressed errors, rerun with: -v
   ==30274== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

我注意到 valgrind 所说的“未显示可到达的块（找到指针的块）。”。然后我尝试检查 gmem.c 由于我使用了 glib-2.35.4 版本，因此有关相应功能的源代码。我找到了以下代码

   gpointer
   g_malloc (gsize n_bytes)
   {
      if (G_LIKELY (n_bytes))
         {
              gpointer mem;

               mem = glib_mem_vtable.malloc (n_bytes);
               TRACE (GLIB_MEM_ALLOC((void*) mem, (unsigned int) n_bytes, 0, 0));
               if (mem)
              return mem;

               g_error ("%s: failed to allocate %"G_GSIZE_FORMAT" bytes",
                G_STRLOC, n_bytes);
           }

       TRACE(GLIB_MEM_ALLOC((void*) NULL, (int) n_bytes, 0, 0));

   return NULL;
  }

我的问题是

在 valgrind 说过“未显示可到达的块（找到指针的块）”的情况下，这仍然是正常情况吗？我认为这句话是指上面的 g_malloc 函数，其中有返回 mem 一个 gpointer 变量？
如果没有，是否有任何替代方案可以解决，“仍然可达：18 个块中的 14,746 个字节”根据 valgrind 上面所说的？

我正在运行 x86 fedora 18 谢谢

【问题讨论】：

喂？这不是 C 代码。重新标记。
嘿嘿，我重新输入空格来清除
尝试在程序底部添加g_free(signalfound);...
它会引发错误，因为 g_free，需要 gpointer 参数而不是 const char *

标签： c++ glib

【解决方案1】：

它很可能是指由函数g_strsignal()返回的动态分配的内存。
valgrind 说 “可到达的块......”，因为有效的指针 (signalfound) 仍然指向动态分配的内存。
如果 Valgrind 发现指向动态内存的指针丢失（overwritten）然后它报告一个“确定泄漏...”，因为它可以最终说动态内存永远无法释放内存块。在您的情况下，指针仍然指向块 valgrind 不会假设它丢失了，但它假设它可能是设计使然。

【讨论】：