首頁(yè) 猿問(wèn) 仍然可達(dá)的泄漏檢測(cè)

仍然可達(dá)的泄漏檢測(cè)

C C++

蝴蝶刀刀 2019-07-11 16:21:33

仍然可達(dá)的泄漏檢測(cè)這個(gè)塊中提到的所有函數(shù)都是庫(kù)函數(shù)。我如何糾正這個(gè)內(nèi)存泄漏？它列在“仍可達(dá)“類(lèi)別。(還有4種，它們非常相似，但大小不同)?！?nbsp;630 bytes in 1 blocks are still reachable in loss record 5 of 5 at 0x4004F1B: calloc (vg_replace_malloc.c:418) by 0x931CD2: _dl_new_object (dl-object.c:52) by 0x92DD36: _dl_map_object_from_fd (dl-load.c:972) by 0x92EFB6: _dl_map_object (dl-load.c:2251) by 0x939F1B: dl_open_worker (dl-open.c:255) by 0x935965: _dl_catch_error (dl-error.c:178) by 0x9399C5: _dl_open (dl-open.c:584) by 0xA64E31: do_dlopen (dl-libc.c:86) by 0x935965: _dl_catch_error (dl-error.c:178) by 0xA64FF4: __libc_dlopen_mode (dl-libc.c:47) by 0xAE6086: pthread_cancel_init (unwind-forcedunwind.c:53) by 0xAE61FC: _Unwind_ForcedUnwind (unwind-forcedunwind.c:126)捕獲：一旦我運(yùn)行了我的程序，它就不會(huì)產(chǎn)生內(nèi)存泄漏，但是它在Valrun輸出中有一個(gè)額外的行，這在以前是不存在的：在/lib/libgcc_s-4.4.4-20100630.so.1中丟棄0x5296fa0-0x52af438中的Syms，原因是munmap()如果泄漏無(wú)法糾正，至少有人能解釋munmap()行為什么導(dǎo)致Val差爾報(bào)告0“仍然可以到達(dá)”泄漏嗎？

查看完整描述

3 回答

蕪湖不蕪

TA貢獻(xiàn)1796條經(jīng)驗(yàn) 獲得超7個(gè)贊

定義“內(nèi)存泄漏”的方法不止一種。特別是，“內(nèi)存泄漏”有兩個(gè)主要的定義，它們是程序員常用的。

“內(nèi)存泄漏”的第一個(gè)常用定義是，“在程序結(jié)束之前，內(nèi)存被分配，隨后未被釋放?！比欢S多程序員(正確地)認(rèn)為，符合這個(gè)定義的某些類(lèi)型的內(nèi)存泄漏實(shí)際上并不構(gòu)成任何類(lèi)型的問(wèn)題，因此不應(yīng)該考慮。千真萬(wàn)確“記憶泄漏”。

可以說(shuō)，“內(nèi)存泄漏”的一個(gè)更嚴(yán)格(也更有用)的定義是，“內(nèi)存被分配了，并且不可能隨后釋放，因?yàn)槌绦虿辉儆兄赶蛞逊峙鋬?nèi)存塊的指針?！皳Q句話說(shuō)，您不能釋放不再有指針的內(nèi)存。因此，這種內(nèi)存是”內(nèi)存泄漏“。Val差倫對(duì)”內(nèi)存泄漏“一詞使用了更嚴(yán)格的定義。這是一種可能導(dǎo)致堆耗盡的類(lèi)型，特別是對(duì)于長(zhǎng)期存在的進(jìn)程。

Val差爾泄漏報(bào)告中的“仍然可達(dá)”類(lèi)別指的是只符合“內(nèi)存泄漏”的第一個(gè)定義的分配。這些塊沒(méi)有被釋放，但是它們可以被釋放(如果程序員愿意的話)，因?yàn)槌绦蛉匀辉诟欀赶蜻@些內(nèi)存塊的指針。

一般來(lái)說(shuō)，沒(méi)有必要擔(dān)心“仍然可以到達(dá)”塊。他們不會(huì)提出這樣的問(wèn)題千真萬(wàn)確內(nèi)存泄漏會(huì)導(dǎo)致。例如，通常沒(méi)有可能從“仍然可達(dá)”的塊中耗盡堆。這是因?yàn)檫@些塊通常是一次分配，對(duì)其的引用在整個(gè)過(guò)程的生存期內(nèi)保持不變。而您可以通過(guò)并確保您的程序釋放全分配內(nèi)存時(shí)，這樣做通常沒(méi)有實(shí)際好處，因?yàn)樵谶M(jìn)程終止后，操作系統(tǒng)將回收進(jìn)程的所有內(nèi)存。對(duì)比一下千真萬(wàn)確內(nèi)存泄漏，如果沒(méi)有固定，如果保持足夠長(zhǎng)的運(yùn)行時(shí)間，可能會(huì)導(dǎo)致進(jìn)程耗盡內(nèi)存，或者只會(huì)導(dǎo)致進(jìn)程消耗比所需的內(nèi)存多得多的內(nèi)存。

確保所有分配都具有匹配的“frees”可能唯一有用的情況是，如果您的泄漏檢測(cè)工具無(wú)法判斷哪些塊“仍可訪問(wèn)”(但Val差爾可以做到這一點(diǎn))，或者如果您的操作系統(tǒng)沒(méi)有回收終止進(jìn)程的所有內(nèi)存(所有平臺(tái)都已被移植以完成此操作)。

反對(duì) 回復(fù) 2019-07-11

米脂

TA貢獻(xiàn)1836條經(jīng)驗(yàn) 獲得超3個(gè)贊

由于底部有一些來(lái)自p線程家族的例程(但我不知道具體的例程)，我猜您已經(jīng)啟動(dòng)了一些可連接的線程，該線程已經(jīng)終止了執(zhí)行。

在調(diào)用之前，該線程的退出狀態(tài)信息是可用的。pthread_join..因此，內(nèi)存保存在程序終止時(shí)的丟失記錄中，但由于您可以使用pthread_join去訪問(wèn)它。

如果此分析是正確的，則啟動(dòng)這些分離的線程，或者在終止程序之前加入它們。

編輯：我運(yùn)行了您的示例程序(經(jīng)過(guò)一些明顯的更正后)，我沒(méi)有錯(cuò)誤，但如下所示

==18933== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)--18933-- --18933-- used_suppression:     
 2 dl-hack3-cond-1--18933-- used_suppression:      2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a

因?yàn)?/trans>dl-事情很像你所看到的，我猜你看到了一個(gè)已知的問(wèn)題，它有一個(gè)抑制文件的解決方案。valgrind..也許您的系統(tǒng)不是最新的，或者您的發(fā)行版沒(méi)有維護(hù)這些東西。(我的是ubuntu 10.4，64位)

反對(duì) 回復(fù) 2019-07-11

拉莫斯之舞

TA貢獻(xiàn)1820條經(jīng)驗(yàn) 獲得超10個(gè)贊

以下是對(duì)“仍然可達(dá)”的適當(dāng)解釋?zhuān)?/trans>

“仍然可達(dá)”是分配給全局和靜態(tài)局部變量的泄漏。因?yàn)関alcher跟蹤全局和靜態(tài)變量，所以它可以排除分配給“一次性遺忘”的內(nèi)存分配。分配一次且從不重新分配的全局變量分配通常不是“泄漏”，因?yàn)樗粫?huì)無(wú)限期地增長(zhǎng)。從嚴(yán)格意義上講，這仍然是一個(gè)漏洞，但除非你是學(xué)究的，否則通常是可以忽略的。

分配而不是自由分配的局部變量幾乎總是泄漏。

下面是一個(gè)例子

int foo(void){
    static char *working_buf = NULL;
    char *temp_buf;
    if (!working_buf) {
         working_buf = (char *) malloc(16 * 1024);
    }
    temp_buf = (char *) malloc(5 * 1024);

    ....
    ....
    ....}

瓦蘭德將報(bào)告Work_BUF為“仍然可達(dá)-16k”，temp_BUF報(bào)告為“絕對(duì)丟失-5k”。

反對(duì) 回復(fù) 2019-07-11