2010-04-02 7 views
21

Próbuję sprawdzić stan stosu C/C++ z poziomu gdb na Linux amd64, czy jest dobry sposób na zrobienie tego?Badanie statystyk pamięci sterty C/C++ w gdb

Jedna z metod, którą próbowałem, to "call mallinfo()", ale niestety nie mogę wtedy wyodrębnić wartości, które chcę, ponieważ gdb nie radzi sobie poprawnie z wartością zwracaną.

Nie jestem w stanie napisać funkcji do binarnej dla procesu, do którego jestem przywiązany, więc mogę po prostu zaimplementować moją własną funkcję, aby wyodrębnić wartości przez wywołanie mallinfo() w moim własnym kodzie droga. Czy jest jakiś sprytny trik, który pozwoli mi to robić w locie?

Inną opcją może być zlokalizowanie sterty i przejście przez nagłówki malloc/wolną listę; Byłbym wdzięczny za wszelkie wskazówki, od których mógłbym zacząć szukać lokalizacji i układu tych elementów.

Próbowałem Google'a i przeczytałem problem przez około 2 godziny. Nauczyłem się fascynujących rzeczy, ale wciąż nie znalazłem tego, czego potrzebuję.

+1

Co należy wiedzieć o stanie? Jakie statystyki potrzebujesz znać? –

+0

Rozmiar sterty, ilość używana i kwota za darmo to dobry początek –

+0

Co to jest GDB nie działa prawidłowo? – leedm777

Odpowiedz

20

@fd - RedHat bug miał swoją odpowiedź.

Funkcja mallinfo została uznana za przestarzałą i nie będzie aktualizowana. Prawdziwym API statystyk zapytań jest TDB. Dzisiaj masz malloc_stats i malloc_info. Nie mogę znaleźć żadnej dokumentacji na żadnej z nich, ale oto, co ci dają.

Czy jest wystarczająco blisko tego, czego potrzebujesz?

(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

Dobra robota, znalazłem wczoraj wieczorem malloc_stats() i użyłem jej do całkiem dobrego efektu w moich testach wcześniej. Natknąłem się również na wiki glibc ze źródłami, które wskazywało na livejournal Ulricha Dreppera w tym post - http: //udrepper.livejournal.com/20948.html - od kwietnia '09 opisujący wymianę na mallinfo (oprócz innych rzeczy), ale jeszcze go nie wypróbowałem. Dzięki za opublikowanie wyników, wygląda bardzo interesująco. +1 –

+0

Przy okazji, czy znalazłeś jakiś dokument dla malloc_info()? Czy pierwszy argument opisuje numer areny? Na wyjściu widzę iw moim teście malloc_stats() pokazuje statystyki dla wielu aren (na bok: mallinfo() również wydaje się być ograniczone, ponieważ pokazuje tylko informacje z zerowej areny, dlatego mój jego testy nie dorównały używanemu przeze mnie zużyciu pamięci, a także, że żadna pojedyncza statystyka areny nie wzrosła wystarczająco, by trafić w błąd, o którym wspomniałem wcześniej). –

+0

Nie mogę znaleźć dokumentów dla malloc_info(). Zgodnie ze źródłem, 'if (options! = 0) return EINVAL' - http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=558e8bab0ab3808ec9f5b569ca62863ef4651b27; hb = HEAD # l6323. Wygląda na to, że iteracja przebiega przez wszystkie areny. – leedm777

3

Jeśli można zmienić kod:

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

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

W GDB, można call dumpMallinfo().

+0

Jak stwierdziłem w pytaniu, nie mogę, jednak jest to przydatna technika. +1 (było to jedno z podejść ujawnionych przez 2 godziny Google). –

+1

Znaleziono użyteczne informacje o mallinfo(); nie wygląda na 64-bitowy. Struktura zwrócona, składająca się z członków int, nie obsługuje wielkości bajtów powyżej 4 GB. Nie znalazłem żadnego dowodu na poprawkę, chociaż znalazłem zarówno raport błędów Debiana, jak i RedHata, oba zamknięte jako NOTABUG/WONTFIX. –

+0

Aby powtórzyć mój komentarz na temat innej odpowiedzi dave'a poniżej: mallinfo() również wydaje się być ograniczone pod tym względem, że wyświetla tylko informacje z zerowej areny, dlatego moje testy nie dorównały używanemu przeze mnie zużyciu pamięci Top; również żadna statystyka areny nie wzrosła wystarczająco, aby trafić w błąd, o którym wspomniałem wcześniej. malloc_stats() pokazał informacje ze wszystkich aren. –

Powiązane problemy