2010-04-02 55 views
21

我想調查在Linux上amd64 gdb內的C/C++堆的狀態,有沒有一種很好的方式來做到這一點?檢查C/C++在gdb堆內存統計信息

我試過的一種方法是「調用mallinfo()」,但不幸的是我不能提取我想要的值,因爲gdb沒有正確處理返回值。

我不是很容易編寫一個函數來編譯到我附加到的進程的二進制文件中,所以我可以簡單地實現我自己的函數,通過在我自己的代碼中調用mallinfo()來提取值辦法。是否有一個聰明的把戲可以讓我在飛行中做到這一點?

另一種選擇可能是找到堆並遍歷malloc頭文件/空閒列表;我很感激任何可以開始尋找這些位置和佈局的指針。

我一直在試圖谷歌和約2小時左右的問題,並瞭解了一些有趣的東西,但仍然沒有找到我所需要的東西。

+1

你需要了解什麼狀態?你需要知道什麼樣的統計數據? – 2010-04-02 02:46:36

+0

堆的大小,使用量和免費量是一個很好的開始 – 2010-04-02 04:04:26

+0

什麼是gdb沒有正確地執行? – leedm777 2010-04-02 23:52:23

回答

20

@fd - RedHat bug有你的答案。

mallinfo函數已被棄用,且不會被更新。一個真正的查詢統計API是TDB。今天,你有malloc_statsmalloc_info。我找不到任何一個文件,但這是他們給你的。

這是否足夠滿足您的需求?

(gdb) call malloc_stats() 
Arena 0: 
system bytes  =  135168 
in use bytes  =   96 
Total (incl. mmap): 
system bytes  =  135168 
in use bytes  =   96 
max mmap regions =   0 
max mmap bytes =   0 

(gdb) call malloc_info(0, stdout) 
<malloc version="1"> 
<heap nr="0"> 
<sizes> 
<unsorted from="1228788" to="1229476" total="3917678" count="3221220448"/> 
</sizes> 
<total type="fast" count="0" size="0"/> 
<total type="rest" count="3221220448" size="3917678"/> 
<system type="current" size="135168"/> 
<system type="max" size="135168"/> 
<aspace type="total" size="135168"/> 
<aspace type="mprotect" size="135168"/> 
</heap> 
<total type="fast" count="0" size="0"/> 
<total type="rest" count="3221220448" size="3917678"/> 
<system type="current" size="135168 
/> 
<system type="max" size="135168 
/> 
<aspace type="total" size="135168"/> 
<aspace type="mprotect" size="135168"/> 
</malloc> 
+0

好的工作,昨天晚上我發現了malloc_stats(),並在今天早些時候的測試中用它達到了相當不錯的效果。我也跑過了源碼軟件的glibc wiki,這篇文章指向了Ulrich Drepper的livejournal - http://udrepper.livejournal。com/20948.html - 從2009年4月開始描述了對mallinfo的替代(其他內容),但我還沒有嘗試過。感謝發佈輸出,看起來非常有趣。 +1 – 2010-04-07 19:25:58

+0

順便說一句,你有沒有找到malloc_info()的任何文檔?第一個參數是否描述競技場號碼?我在輸出中看到了,並且在我的測試中,malloc_stats()顯示了許多場館的統計信息(旁邊:mallinfo()也似乎有限,因爲它只顯示來自第零競技場的信息,這就是爲什麼我的它的測試不符合我上面報告的內存使用情況;同樣,沒有任何單一的競技場統計增長足以擊中之前引用的錯誤)。 – 2010-04-07 19:30:27

+0

我找不到malloc_info()的文檔。根據消息來源,「if(options!= 0)return EINVAL' - http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=558e8bab0ab3808ec9f5b569ca62863ef4651b27; HB = HEAD#l6323。看起來它遍歷所有領域。 – leedm777 2010-04-08 04:56:39

3

如果你可以改變代碼:

​​

在GDB,您可以call dumpMallinfo()

+0

正如我在問題中所述,我不能,但是這是一種有用的技術。 +1(這是Google搜索結果顯示的兩個小時內的一種方法) – 2010-04-03 01:27:14

+1

找到關於mallinfo()的一些有用信息;它似乎不是64位準備好的。返回的結構由int成員組成,不處理大於4GB的字節大小。我還沒有找到任何修復的證據,儘管我發現Debian和RedHat的一個bug報告都是NOTABUG/WONTFIX。 – 2010-04-06 22:44:57

+0

重申我對dave的其他答案的評論如下:mallinfo()似乎也是有限的,它只顯示來自第零競技場的信息,這就是爲什麼我的測試與我看到的報告的內存使用不匹配最佳;此外,沒有任何單一的統計數據增長足以擊中我之前提到的錯誤。 malloc_stats()顯示來自所有領域的信息。 – 2010-04-07 19:31:19