[英]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;
}
我的問題是
在valgrind說過“未顯示可到達的塊(未找到指針的塊)”的情況下,這仍然是正常情況嗎?我認為該語句是指上面的g_malloc函數,該函數在其中返回了mem一個gpointer變量?
如果沒有解決的辦法,那么上面valgrind所說的“仍然可以達到:18塊中的14,746字節”?
我正在運行x86 fedora 18謝謝
它最有可能引用由函數g_strsignal()
返回的動態分配的內存。
valgrind說“ Reachable blocks ....” ,因為有效的指針( signalfound
)仍然指向動態分配的內存。
如果Valgrind發現指向動態內存的指針丟失( 被覆蓋 ),則它將報告“確定的泄漏...” ,因為它可以確定地說動態內存塊永遠無法釋放。 在您的情況下,指針仍然指向valgrind塊,並不認為它已丟失,但它可能是設計使然。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.