2010-04-02 4 views
21

Я пытаюсь исследовать состояние кучи C/C++ из gdb в Linux amd64, есть ли хороший способ сделать это?Изучение статистики памяти кучи C/C++ в gdb

Один из подходов, который я пробовал, заключается в «вызове mallinfo()», но, к сожалению, я не могу извлечь значения, которые я хочу, так как gdb неправильно обрабатывает возвращаемое значение.

Я не могу написать функцию, которая будет скомпилирована в двоичный файл для процесса, к которому я присоединен, поэтому я могу просто реализовать свою собственную функцию для извлечения значений, вызвав mallinfo() в моем собственном коде. путь. Может быть, умный трюк, который позволит мне сделать это на лету?

Другим вариантом может быть поиск кучи и перемещение заголовков/свободного списка malloc; Я был бы признателен за любые указания, где я мог бы начать находить расположение и расположение этих.

Я пытался Google и читал проблему около двух часов, и я узнал некоторые интересные вещи, но до сих пор не нашел то, что мне нужно.

+1

Что вам нужно знать о состоянии? Какую статистику вы должны знать? –

+0

Размер кучи, используемое количество и количество бесплатно - хорошее начало –

+0

Что такое gdb, который не работает должным образом? – leedm777

ответ

20

@fd - у RedHat bug был ваш ответ.

Функция mallinfo устарела и не обновляется. Истиной API статистики запросов является TDB. Сегодня у вас есть malloc_stats и malloc_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, которая указывала на livejournal Ульриха Дреппера с этим сообщением - http: //udrepper.livejournal.com/20948.html - с апреля '09, описывая замену на mallinfo (помимо других вещей), но мне еще предстоит попробовать. Спасибо за публикацию результатов, выглядит очень интересно. +1 –

+0

Кстати, вы нашли какой-нибудь документ для malloc_info()? Означает ли первый аргумент номер арены? Я вижу вывод , и в моем тесте malloc_stats() показывает статистику для ряда аренов (в стороне: mallinfo() также кажется ограниченным, поскольку он отображает только информацию с нулевой арены, поэтому мой тесты этого не соответствовали используемому ядру памяти, о котором я рассказывал сверху, а также никакой статистики в одной арене не было достаточно, чтобы попасть в ошибку, о которой я упоминал ранее). –

+0

Я не могу найти документы для malloc_info(). Согласно источнику, 'if (options! = 0) возвращает EINVAL' - http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=558e8bab0ab3808ec9f5b569ca62863ef4651b27; ПП = ГОЛОВА # l6323. Похоже, он проходит через все арены. – leedm777

3

Если вы можете изменить код:

#include <malloc.h> 
#include <stdio.h> 

void dumpMallinfo(void) { 
    struct mallinfo m = mallinfo(); 
    printf("uordblks = %d\nfordblks = %d\n", m.uordblks, m.fordblks); 
} 

В GDB, вы можете call dumpMallinfo().

+0

Как я уже сказал в вопросе, я не могу, однако это полезная техника. +1 (это был один из подходов, показанный 2 часа раскрытия в Google) –

+1

Нашел полезный бит информации о mallinfo(); он не выглядит 64-битным. Возвращенная структура, состоящая из членов int, не обрабатывает размеры байтов выше 4 ГБ. Я не нашел никаких доказательств исправления для этого, хотя я обнаружил, что оба отчета об ошибках Debian и RedHat закрыты как NOTABUG/WONTFIX. –

+0

Повторить мой комментарий к другому ответу дэйва ниже: mallinfo() также кажется ограниченным в том, что он отображает только информацию с нулевой арены, поэтому мои тесты не совпадают с использованием памяти, о которой я говорил Вверх; Кроме того, ни одна статистика арены не увеличилась настолько, чтобы попасть в ошибку, о которой я упоминал ранее. malloc_stats() отображает информацию со всех арен. –