繁体   English   中英

使用Valgrind调查的Glib内存泄漏

[英]Glib memory leak using valgrind investigation

我知道在此之前有一个类似的线程可以解决此问题,并且已经解释了此站点上的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所说的“未显示可到达的块(找到指针的块)”。 然后由于使用了glib-2.35.4版本,因此我尝试检查相应功能上的gmem.c源代码。 我发现以下代码

   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;
  }

我的问题是

  1. 在valgrind说过“未显示可到达的块(未找到指针的块)”的情况下,这仍然是正常情况吗?我认为该语句是指上面的g_malloc函数,该函数在其中返回了mem一个gpointer变量?

  2. 如果没有解决的办法,那么上面valgrind所说的“仍然可以达到:18块中的14,746字节”?

我正在运行x86 fedora 18谢谢

它最有可能引用由函数g_strsignal()返回的动态分配的内存。
valgrind说“ Reachable blocks ....” ,因为有效的指针( signalfound )仍然指向动态分配的内存。
如果Valgrind发现指向动态内存的指针丢失( 被覆盖 ),则它将报告“确定的泄漏...” ,因为它可以确定地说动态内存块永远无法释放。 在您的情况下,指针仍然指向valgrind块,并不认为它已丢失,但它可能是设计使然。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM