Jak wykrywać / unikać wycieków pamięci w (niezarządzanym) kodzie? [Zamknięte]

Jakie są najlepsze praktyki wykrywania wycieków pamięci w niezarządzanym kodzie C / C ++? I wskazówek dotyczących kodowania, których należy unikać? (Jakby to było takie proste;)

W przeszłości używaliśmy trochę głupiego sposobu: dysponowania przyrostem licznika dla każdego wywołania alokacji pamięci i zmniejszaniem podczas zwalniania. Pod koniec programu stan licznika powinien wynosić zero.

Wiem, że to nie jest świetny sposób i jest kilka haczyków. (Na przykład, jeśli zwalniasz pamięć, która została przydzielona przez wywołanie interfejsu API platformy, liczba przydziałów nie będzie dokładnie odpowiadać liczbie zwolnień. Oczywiście zwiększaliśmy licznik podczas wywoływania wywołań API, które przydzielają pamięć).

Oczekuję Waszych doświadczeń, sugestii i być może odniesień do narzędzi, które to upraszczają.

Jeśli twój kod C / C ++ jest przenośny do * nix, kilka rzeczy jest lepszych niż Valgrind .

Jeśli korzystasz z programu Visual Studio, firma Microsoft udostępnia przydatne funkcje do wykrywania i debugowania wycieków pamięci.

Zacząłbym od tego artykułu: https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx

Oto krótkie podsumowanie tych artykułów. Najpierw uwzględnij te nagłówki:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

Następnie musisz wywołać to, gdy program kończy pracę:

_CrtDumpMemoryLeaks();

Alternatywnie, jeśli twój program nie kończy się za każdym razem w tym samym miejscu, możesz wywołać to na początku swojego programu:

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

Teraz, gdy program zakończy pracę, wszystkie alokacje, które nie były wolne, zostaną wydrukowane w oknie wyjściowym wraz z plikiem, w którym zostały przydzielone, oraz wystąpieniem alokacji.

Ta strategia działa w przypadku większości programów. Jednak w niektórych przypadkach staje się to trudne lub niemożliwe. Korzystanie z bibliotek innych firm, które wykonują pewne inicjalizacje podczas uruchamiania, może spowodować pojawienie się innych obiektów w zrzucie pamięci i może utrudnić śledzenie wycieków. Ponadto, jeśli którakolwiek z twoich klas ma członków o takiej samej nazwie jak którakolwiek z procedur alokacji pamięci (takich jak malloc), makra debugowania CRT spowodują problemy.

Istnieją inne techniki wyjaśnione w odnośniku MSDN, o którym mowa powyżej, które również mogą być użyte.

W C ++: użyj RAII. Inteligentne wskaźniki podoba std::unique_ptr, std::shared_ptr, std::weak_ptrsą twoimi przyjaciółmi.

Jako programista C ++ oto kilka prostych wskazówek:

1. Używaj wskaźników tylko wtedy, gdy jest to absolutnie konieczne
2. Jeśli potrzebujesz wskaźnika, dwukrotnie sprawdź, czy SmartPointer jest możliwy
3. Użyj wzorca GRASP Creator .

Jeśli chodzi o wykrywanie wycieków pamięci osobiście, zawsze korzystałem z Visual Leak Detector i uważam, że jest bardzo przydatny.

Używam DevStudio od zbyt wielu lat i zawsze mnie zadziwia, ilu programistów nie wie o narzędziach do analizy pamięci, które są dostępne w bibliotekach uruchomieniowych debugowania. Oto kilka linków, od których możesz zacząć:

Śledzenie żądań alokacji sterty - w szczególności sekcja dotycząca unikalnych numerów zleceń alokacji

_CrtSetDbgFlag

_CrtSetBreakAlloc

Oczywiście, jeśli nie używasz DevStudio, nie będzie to szczególnie pomocne.

Jestem zdumiony, że nikt nie wspomniał o DebugDiag dla systemu operacyjnego Windows.
Działa w kompilacjach wydań, a nawet w witrynie klienta.
(Wystarczy zachować PDB wersji wydania i skonfigurować DebugDiag do korzystania z publicznego serwera symboli firmy Microsoft)

Visual Leak Detector jest bardzo dobrym narzędziem, chociaż nie obsługuje wywołań w środowiskach wykonawczych VC9 (na przykład MSVCR90D.DLL).

Microsoft VC ++ w trybie debugowania pokazuje wycieki pamięci, chociaż nie pokazuje, gdzie są wycieki.

Jeśli używasz C ++ zawsze można uniknąć stosując nowy wyraźnie: trzeba vector, string, auto_ptr(pre C ++ 11, zastąpione unique_ptrw C ++ 11), unique_ptr(C ++ 11) i shared_ptr(C ++ 11) w swoim arsenale.

Kiedy nowy jest nieunikniony, spróbuj ukryć go w konstruktorze (i ukryj usuń w destruktorze); to samo dotyczy interfejsów API innych firm.

Istnieją różne zastępcze biblioteki "malloc", które pozwolą ci wywołać funkcję na końcu i powie ci o całej nieuleczonej pamięci, aw wielu przypadkach, kto ją pobrał (lub nowy) w pierwszej kolejności .

Jeśli używasz MS VC ++, gorąco polecam to bezpłatne narzędzie z projektu code: leakfinder autorstwa Jochena Kalmbacha.

Po prostu dodajesz klasę do swojego projektu i dzwonisz

InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()

przed i po kodzie, który chcesz sprawdzić pod kątem wycieków.

Po skompilowaniu i uruchomieniu kodu Jochen zapewnia zgrabne narzędzie GUI, w którym można załadować wynikowy plik .xmlleaks i nawigować po stosie wywołań, w którym został wygenerowany każdy wyciek, w celu wyszukania niewłaściwego wiersza kodu.

PurifyPlus firmy Rational (obecnie należący do IBM) ilustruje wycieki w podobny sposób, ale uważam, że narzędzie do wykrywania wycieków jest rzeczywiście łatwiejsze w użyciu, a jego premia nie kosztuje kilku tysięcy dolarów!

Sam nigdy tego nie używałem, ale moi przyjaciele z C mówią mi Purify .

Jeśli używasz programu Visual Studio, warto przyjrzeć się narzędziu Bounds Checker . To nie jest darmowe, ale było niezwykle pomocne w znajdowaniu wycieków w moim kodzie. Nie tylko powodują wycieki pamięci, ale także wycieki zasobów GDI, błędy użytkowania WinAPI i inne rzeczy. Pokaże nawet, gdzie zainicjowano wyciek pamięci, co znacznie ułatwia wyśledzenie wycieku.

Myślę, że nie ma łatwej odpowiedzi na to pytanie. To, jak naprawdę możesz podejść do tego rozwiązania, zależy od Twoich wymagań. Czy potrzebujesz rozwiązania wieloplatformowego? Czy używasz nowego / delete lub malloc / free (lub obu)? Czy naprawdę szukasz tylko „wycieków”, czy też potrzebujesz lepszej ochrony, takiej jak wykrywanie przepełnień bufora (lub niedopełnienia)?

Jeśli pracujesz po stronie systemu Windows, biblioteki środowiska uruchomieniowego MS debug mają pewne podstawowe funkcje wykrywania debugowania, a jak inny już wskazał, istnieje kilka opakowań, które można dołączyć do źródła, aby pomóc w wykrywaniu wycieków. Znalezienie pakietu, który może współpracować zarówno z new / delete, jak i malloc / free, oczywiście zapewnia większą elastyczność.

Nie wiem wystarczająco dużo o stronie uniksowej, aby zapewnić pomoc, chociaż znowu inni.

Ale poza samym wykrywaniem wycieków istnieje pojęcie wykrywania uszkodzeń pamięci poprzez przepełnienia bufora (lub niedomiar). Myślę, że ten typ funkcji debugowania jest trudniejszy niż zwykłe wykrywanie wycieków. Ten typ systemu jest również bardziej skomplikowany, jeśli pracujesz z obiektami C ++, ponieważ klasy polimorficzne można usuwać na różne sposoby, co powoduje trudności w określeniu prawdziwego wskaźnika podstawowego, który jest usuwany. Nie znam dobrego „darmowego” systemu, który zapewnia dobrą ochronę przed przekroczeniami. napisaliśmy system (wieloplatformowy) i stwierdziliśmy, że jest to dość trudne.

Chciałbym zaoferować coś, z czego czasami korzystałem w przeszłości: podstawowy program do sprawdzania wycieków, który jest na poziomie źródła i dość automatyczny. Oddaję to z trzech powodów:

1. Może ci się to przydać.

2. Chociaż to trochę krufty, nie pozwalam, żeby mnie to zawstydziło.

3. Mimo że jest powiązany z niektórymi hakami win32, powinno to być łatwe do złagodzenia.

Są rzeczy, na które musisz uważać podczas korzystania z niego: nie rób niczego, na czym trzeba polegać neww kodzie bazowym, uważaj na ostrzeżenia o przypadkach, które mogą przeoczyć na początku leakcheck.cpp, zdaj sobie sprawę, że jeśli włączysz na (i napraw wszelkie problemy z) kodem, który wykonuje zrzuty obrazu, możesz wygenerować ogromny plik.

Projekt ma umożliwiać włączanie i wyłączanie kontrolera bez ponownej kompilacji wszystkiego, co zawiera jego nagłówek. Uwzględnij leakcheck.h, gdzie chcesz prześledzić sprawdzanie i raz odbudować. Następnie skompiluj leakcheck.cpp z lub bez definicji LEAKCHECK #, a następnie połącz ponownie, aby go włączyć i wyłączyć. Dołączenie unleakcheck.h spowoduje wyłączenie go lokalnie w pliku. Dostępne są dwa makra: CLEARALLOCINFO () pozwoli uniknąć nieprawidłowego raportowania tego samego pliku i wiersza podczas przeglądania kodu przydzielającego, który nie zawiera przecieku. ALLOCFENCE () po prostu upuszcza wiersz w wygenerowanym raporcie bez dokonywania alokacji.

Ponownie, proszę, uświadom sobie, że nie używałem tego od jakiegoś czasu i być może będziesz musiał z tym trochę popracować. Wrzucam to, żeby zilustrować ten pomysł. Jeśli zainteresowanie okaże się wystarczające, zechciałbym opracować przykład, zaktualizować kod w trakcie i zastąpić zawartość następującego adresu URL czymś ładniejszym, co zawiera listę w przyzwoitym kolorze składni.

Znajdziesz go tutaj: http://www.cse.ucsd.edu/~tkammeye/leakcheck.html

Linux: wypróbuj narzędzia Google Perftools

Istnieje wiele narzędzi, które wykonują podobne liczenie przydziałów / bezpłatnych zasobów, zalety Goolge Perftools:

• Dość szybko (w porównaniu do valgrind: bardzo szybko)
• Posiada przyjemną graficzną prezentację wyników
• Posiada inne przydatne możliwości: profilowanie procesora, profilowanie zużycia pamięci ...

Najlepszą ochroną przed wyciekami jest struktura programu, która minimalizuje użycie malloc. Jest to nie tylko dobre z punktu widzenia programowania, ale także poprawia wydajność i łatwość konserwacji. Nie mówię o używaniu innych rzeczy zamiast malloc, ale pod względem ponownego używania obiektów i utrzymywania bardzo wyraźnych zakładek na wszystkich przekazywanych obiektach, zamiast przydzielania chcąc nie chcąc, jak często się przyzwyczaja w językach ze śmieciami jak Java.

Na przykład program, nad którym pracuję, ma kilka obiektów ramek reprezentujących dane obrazu. Każdy obiekt ramki ma dane podrzędne, które są zwalniane przez destruktor ramki. Program przechowuje listę wszystkich przydzielonych ramek, a gdy potrzebuje nowej, sprawdza listę nieużywanych obiektów ramek, aby zobaczyć, czy może ponownie wykorzystać istniejącą, zamiast przydzielić nową. Po zamknięciu po prostu iteruje listę, zwalniając wszystko.

Polecam użycie Memory Validator z weryfikacji oprogramowania. To narzędzie okazało się nieocenioną pomocą, pomagając mi wykrywać wycieki pamięci i usprawniać zarządzanie pamięcią aplikacji, nad którymi pracuję.

Bardzo kompletne i szybkie narzędzie.

Czy liczysz alokacje i zwolnienia, interpolując własne funkcje wywołań systemowych, które rejestrują wywołania, a następnie przekazują je do funkcji rzeczywistej?

Tylko w ten sposób możesz śledzić wywołania pochodzące z kodu, którego nie napisałeś.

Zajrzyj na stronę podręcznika systemowego ld.so. Lub ld.so.1 w niektórych systemach.

Wykonaj również Google LD_PRELOAD, a znajdziesz kilka interesujących artykułów wyjaśniających tę technikę na www.itworld.com.

Przynajmniej w przypadku MS VC ++ biblioteka C Runtime ma kilka funkcji, które w przeszłości okazały się pomocne. Sprawdź pomoc MSDN dotyczącą _Crt*funkcji.

MMG Paula Nettle jest moim ulubionym narzędziem od dawna. Dołączasz mmgr.h do swoich plików źródłowych, definiujesz TEST_MEMORY i dostarcza on plik tekstowy pełen problemów z pamięcią, które wystąpiły podczas uruchamiania aplikacji.

Ogólne wytyczne dotyczące kodowania:

• Zasoby powinny zostać zwolnione w tej samej „warstwie” (funkcja / klasa / biblioteka), w której są przydzielane.
• Jeśli nie jest to możliwe, spróbuj użyć jakiejś automatycznej zwalniania (zwiększ współdzielony wskaźnik ...)

Narzędzia do debugowania pamięci są na wagę złota, ale przez lata odkryłem, że można zastosować dwa proste pomysły, aby zapobiec zakodowaniu większości wycieków pamięci / zasobów.

1. Napisz kod wydania natychmiast po napisaniu kodu nabycia zasobów, które chcesz przydzielić. Dzięki tej metodzie trudniej jest „zapomnieć” i w pewnym sensie zmusza do poważnego myślenia o cyklu życia zasobów wykorzystywanych z góry, a nie tylko na boku.

2. Używaj powrotu tak oszczędnie, jak to możliwe. To, co zostało przydzielone, powinno zostać uwolnione tylko w jednym miejscu, jeśli to możliwe. Warunkowa ścieżka między nabyciem zasobu a uwolnieniem powinna być tak prosta i oczywista, jak to tylko możliwe.

Na szczycie tej listy (kiedy ją czytałem) był valgrind. Valgrind jest doskonały, jeśli jesteś w stanie odtworzyć wyciek w systemie testowym. Użyłem go z wielkim sukcesem.

A co, jeśli właśnie zauważyłeś, że system produkcyjny przecieka teraz i nie masz pojęcia, jak go odtworzyć w testach? Pewne dowody na to, co jest nie tak, są uchwycone w stanie tego systemu produkcyjnego i może wystarczyć, aby uzyskać wgląd w to, gdzie jest problem, aby można było go odtworzyć.

W tym miejscu pojawia się samplowanie Monte Carlo. Przeczytaj artykuł na blogu Raymonda Chena „The poor man's way to identifying memory leaks”, a następnie sprawdź moją implementację (zakładam, że Linux, testowany tylko na x86 i x86-64)

http://github.com/tialaramex/leakuesday/tree/master

Pracując na systemie operacyjnym telefonów komórkowych Motorola, przejęliśmy bibliotekę alokacji pamięci, aby obserwować wszystkie alokacje pamięci. Pomogło to znaleźć wiele problemów z alokacją pamięci. Ponieważ lepiej zapobiegać niż leczyć, zalecałbym użycie narzędzia do analizy statycznej, takiego jak Klockwork lub PC-Lint

Valgrind to fajna opcja dla Linuksa. W MacOS X możesz włączyć bibliotekę MallocDebug, która ma kilka opcji debugowania problemów z alokacją pamięci (zobacz stronę podręcznika malloc, sekcja "ŚRODOWISKO" zawiera odpowiednie szczegóły). Zestaw OS X SDK zawiera również narzędzie o nazwie MallocDebug (zwykle instalowane w / Developer / Applications / Performance Tools /), które może pomóc w monitorowaniu użycia i wycieków.

Wykryć:

Debuguj CRT

Uniknąć:

Inteligentne wskaźniki, boehm GC

Przyjemnym zamiennikiem malloc, calloc i reallloc jest rmdebug, jest całkiem prosty w użyciu. Jest znacznie szybszy niż valgrind, więc możesz szeroko przetestować swój kod. Oczywiście ma to pewne wady, po znalezieniu wycieku prawdopodobnie nadal będziesz musiał użyć valgrind, aby znaleźć miejsce wycieku, i możesz testować tylko mallocs, które robisz bezpośrednio. Jeśli biblioteka wycieknie, ponieważ użyjesz jej nieprawidłowo, rmdebug jej nie znajdzie.

http://www.hexco.de/rmdebug/

Większość programów profilujących pamięć spowalnia moją dużą, złożoną aplikację Windows do punktu, w którym wyniki są bezużyteczne. Jest jedno narzędzie, które działa dobrze do znajdowania wycieków w mojej aplikacji: UMDH - http://msdn.microsoft.com/en-us/library/ff560206%28VS.85%29.aspx

Wydaje się, że Mtrace jest standardem wbudowanym w Linuksa. Kroki są następujące:

1. ustaw zmienną środowiskową MALLOC_TRACE w bash
   MALLOC_TRACE = / tmp / mtrace.dat
   export MALLOC_TRACE;
2. Dodaj #include <mcheck.h> na początku głównego pliku źródłowego
3. Dodaj mtrace (); na początku main i muntrace ();na dole (przed instrukcją powrotu)
4. skompiluj swój program z przełącznikiem -g, aby uzyskać informacje o debugowaniu
5. uruchom swój program
6. wyświetl informacje o wycieku za pomocą
   mtrace your_prog_exe_name /tmp/mtrace.dat
   (musiałem najpierw zainstalować skrypt mtrace perl na moim systemie fedora za pomocą yum install glibc_utils   )