Co NAPRAWDĘ dzieje się, gdy nie zwalniasz po Malloc?

To mnie martwiło od wieków.

Wszyscy uczymy się w szkole (przynajmniej ja byłem), że MUSISZ uwolnić każdy przydzielony wskaźnik. Jestem jednak trochę ciekawy, jakie są rzeczywiste koszty nie zwalniania pamięci. W niektórych oczywistych przypadkach, takich jak mallocwywołanie w pętli lub części wykonania wątku, bardzo ważne jest zwolnienie, aby nie było wycieków pamięci. Ale rozważ następujące dwa przykłady:

Po pierwsze, jeśli mam kod, to coś takiego:

int main()
{
    char *a = malloc(1024);
    /* Do some arbitrary stuff with 'a' (no alloc functions) */
    return 0;
}

Jaki jest tutaj prawdziwy wynik? freeUważam, że proces umiera, a następnie przestrzeń stosu i tak nie ma miejsca, więc nie ma żadnych szkód w nieodebraniu wezwania do (jednak zdaję sobie sprawę z tego, jak ważne jest, aby mieć to do zamknięcia, konserwacji i dobrej praktyki). Czy mam rację w tym myśleniu?

Po drugie, powiedzmy, że mam program, który działa trochę jak powłoka. Użytkownicy mogą deklarować zmienne podobne, aaa = 123a te są przechowywane w jakiejś dynamicznej strukturze danych do późniejszego wykorzystania. Najwyraźniej wydaje się oczywiste, że użyłbyś jakiegoś rozwiązania, które wywoła jakąś * funkcję przydzielania (skrót, lista połączona, coś podobnego). W przypadku tego rodzaju programu nie ma sensu nigdy zwalniać po wywołaniu, mallocponieważ zmienne te muszą być obecne przez cały czas podczas wykonywania programu i nie ma dobrego sposobu (jak widzę) na wdrożenie tego przy użyciu statycznie przydzielonego miejsca. Czy źle jest mieć część pamięci, która jest przydzielana, ale zwalniana tylko jako część procesu kończącego się? Jeśli tak, jaka jest alternatywa?

Prawie każdy nowoczesny system operacyjny odzyska całą przydzieloną pamięć po zakończeniu programu. Jedynym wyjątkiem, jaki mogę wymyślić, może być coś takiego jak Palm OS, w którym pamięć statyczna i pamięć wykonawcza programu są prawie takie same, więc brak zwolnienia może spowodować, że program zajmie więcej pamięci. (Spekuluję tylko tutaj.)

Ogólnie rzecz biorąc, nie ma w tym żadnej szkody, z wyjątkiem kosztów środowiska wykonawczego posiadania większej ilości miejsca niż potrzebujesz. Z pewnością w podanym przykładzie chcesz zachować pamięć dla zmiennej, która może być używana, dopóki nie zostanie wyczyszczona.

Jednak uważa się za dobry styl, aby zwolnić pamięć, gdy tylko jej nie potrzebujesz, i uwolnić wszystko, co masz jeszcze przy wyjściu z programu. Jest to raczej ćwiczenie polegające na poznaniu używanej pamięci i zastanowieniu się, czy nadal jej potrzebujesz. Jeśli nie będziesz śledzić, być może wycieki pamięci.

Z drugiej strony, podobne upomnienie o zamykaniu plików przy wyjściu ma znacznie bardziej konkretny wynik - jeśli nie, dane, które do nich napisałeś, mogą nie zostać usunięte, lub jeśli są plikami tymczasowymi, mogą nie zostaną usunięte, gdy skończysz. Ponadto uchwyty baz danych powinny zostać zatwierdzone, a następnie zamknięte, gdy skończysz z nimi. Podobnie, jeśli używasz języka zorientowanego obiektowo, takiego jak C ++ lub Objective C, nie zwolnienie obiektu po jego zakończeniu będzie oznaczać, że destruktor nigdy nie zostanie wywołany, a wszelkie zasoby, za które odpowiedzialna jest klasa, mogą nie zostać wyczyszczone.

Tak, masz rację, twój przykład nie wyrządza żadnej szkody (przynajmniej nie w większości nowoczesnych systemów operacyjnych). Cała pamięć przydzielona przez proces zostanie odzyskana przez system operacyjny po zakończeniu procesu.

Źródło: Allocation and GC Myths (PostScript alert!)

Alokacja Mit 4: Programy niezawierające śmieci powinny zawsze zwalniać całą przydzieloną pamięć.

The Truth: Pominięte zwolnienia w często wykonywanym kodzie powodują wzrost wycieków. Są rzadko akceptowane. ale programy, które zachowują większość przydzielonej pamięci do momentu wyjścia z programu, często działają lepiej bez żadnego pośredniego zwolnienia. Malloc jest znacznie łatwiejszy do wdrożenia, jeśli nie ma za darmo.

W większości przypadków zwalnianie pamięci tuż przed wyjściem z programu jest bezcelowe. System operacyjny i tak go odzyska. Free będzie dotykać i przewijać martwe obiekty; system operacyjny nie.

Konsekwencja: Uważaj na „detektory wycieków”, które liczą przydziały. Niektóre „wycieki” są dobre!

To powiedziawszy, powinieneś naprawdę spróbować uniknąć wszystkich wycieków pamięci!

Drugie pytanie: twój projekt jest w porządku. Jeśli musisz coś zapisać do momentu zamknięcia aplikacji, możesz to zrobić z dynamicznym przydzielaniem pamięci. Jeśli nie znasz wymaganego rozmiaru z góry, nie możesz użyć pamięci przydzielonej statycznie.

=== A co z przyszłym proofingiem i ponownym użyciem kodu ? ===

Jeśli nie napiszesz kodu, aby uwolnić obiekty, ograniczasz go do bezpiecznego korzystania z niego tylko wtedy, gdy możesz polegać na zwolnieniu pamięci przez zamknięcie procesu ... tj. Jednorazowe małe użycie projekty lub „wyrzucane” ^[1] projekty) ... gdzie wiesz, kiedy proces się zakończy.

Jeśli zrobić napisać kod, który free () s całe dynamicznie przydzieloną pamięć, to jesteś w przyszłości pokryć kodu i pozwalając inni używają go w większym projekcie.

^{[1] w odniesieniu do projektów „wyrzucanych”. Kod używany w projektach „Wyrzucanie” ma sposób, aby nie zostać wyrzuconym. Następną rzeczą, którą wiesz, że minęło dziesięć lat, a Twój kod „wyrzucania” jest nadal używany).}

^{Słyszałem historię o facecie, który napisał kod tylko dla zabawy, aby jego sprzęt działał lepiej. Powiedział „ po prostu hobby, nie będzie duże i profesjonalne ”. Wiele lat później wiele osób korzysta z jego kodu „hobby”.}

Masz rację, nic się nie dzieje i szybsze jest wyjście

Istnieją różne przyczyny tego:

• Wszystkie środowiska stacjonarne i serwerowe po prostu zwalniają całą przestrzeń pamięci przy exit (). Nie są świadomi wewnętrznych struktur danych programu, takich jak stosy.

• Prawie wszystkie free()implementacje i tak nigdy nie zwracają pamięci do systemu operacyjnego.

• Co ważniejsze, jest to strata czasu, gdy jest wykonywana tuż przed wyjściem (). Przy wyjściu strony pamięci i przestrzeń wymiany są po prostu zwalniane. Natomiast seria bezpłatnych wywołań () spowoduje spalenie czasu procesora i może spowodować operacje stronicowania dysku, brak pamięci podręcznej i wykluczenie pamięci podręcznej.

Odnośnie możliwości przyszłego ponownego wykorzystania kodu uzasadniającego pewność bezcelowych operacji: to kwestia rozważana, ale prawdopodobnie nie jest to zwinny sposób. YAGNI!

Całkowicie nie zgadzam się ze wszystkimi, którzy twierdzą, że OP jest poprawny lub nie ma żadnej szkody.

Wszyscy mówią o nowoczesnym i / lub starszym systemie operacyjnym.

Ale co, jeśli jestem w środowisku, w którym po prostu nie mam systemu operacyjnego? Gdzie nic nie ma?

Wyobraź sobie, że używasz przerwań w stylu wątku i przydzielasz pamięć. W normie C ISO / IEC: 9899 oznacza trwałość pamięci wyrażoną jako:

7.20.3 Funkcje zarządzania pamięcią

1 Kolejność i ciągłość pamięci przydzielanej przez kolejne wywołania funkcji calloc, malloc i realloc nie jest określona. Wskaźnik zwrócony, jeśli alokacja się powiedzie, zostanie odpowiednio wyrównany, aby można go było przypisać do wskaźnika do dowolnego typu obiektu, a następnie użyć do uzyskania dostępu do takiego obiektu lub tablicy takich obiektów w przydzielonym miejscu (do momentu jawnego zwolnienia miejsca) . Żywotność przydzielonego obiektu rozciąga się od przydziału do delokalizacji. [...]

Dlatego nie należy zapominać, że środowisko wykonuje dla ciebie zadanie polegające na uwolnieniu. W przeciwnym razie zostanie dodane do ostatniego zdania: „Lub do czasu zakończenia programu”.

Innymi słowy: nie zwalnianie pamięci to nie tylko zła praktyka. Tworzy nieprzenośny i niezgodny kod C. Które można co najmniej uznać za „poprawne, jeżeli: [...] jest obsługiwane przez środowisko”.

Ale w przypadkach, w których w ogóle nie masz systemu operacyjnego, nikt nie wykonuje zadania za ciebie (wiem, że ogólnie nie przydzielasz i nie przenosisz pamięci w systemach wbudowanych, ale są przypadki, w których możesz chcieć).

Mówiąc ogólnie, zwykły C (jako oznaczony OP), powoduje to po prostu błędny i nieprzenośny kod.

Zazwyczaj zwalniam każdy przydzielony blok, gdy mam pewność, że już z nim skończyłem. Dzisiaj może być punktem wejścia mojego programu main(int argc, char *argv[]), ale jutro może być foo_entry_point(char **args, struct foo *f)i napisany jako wskaźnik funkcji.

Więc jeśli tak się stanie, mam teraz wyciek.

Jeśli chodzi o twoje drugie pytanie, jeśli mój program pobierze dane wejściowe jak a = 5, przydzieliłbym miejsce dla a lub ponownie przydzieliłbym to samo miejsce dla kolejnego a = "foo". Zostanie to przydzielone do:

1. Użytkownik wpisał „unset a”
2. Wprowadzono moją funkcję czyszczenia, obsługującą sygnał lub użytkownik wpisał „quit”

Nie mogę wymyślić żadnego nowoczesnego systemu operacyjnego, który nie odzyska pamięci po zakończeniu procesu. Z drugiej strony free () jest tanie, dlaczego nie posprzątać? Jak powiedzieli inni, narzędzia takie jak valgrind świetnie nadają się do wykrywania wycieków, o które naprawdę musisz się martwić. Mimo że przykładowe bloki zostałyby oznaczone jako „wciąż osiągalne”, to tylko dodatkowy szum na wyjściu, gdy próbujesz upewnić się, że nie ma wycieków.

Kolejny mit brzmi: „ Jeśli jest w main (), nie muszę go zwalniać ”, jest to niepoprawne. Rozważ następujące:

char *t;

for (i=0; i < 255; i++) {
    t = strdup(foo->name);
    let_strtok_eat_away_at(t);
}

Jeśli miało to miejsce przed rozwidleniem / demonizacją (i teoretycznie działało wiecznie), twój program przeciekł nieokreślony rozmiar t 255 razy.

Dobry, dobrze napisany program powinien zawsze po sobie posprzątać. Zwolnij całą pamięć, opróżnij wszystkie pliki, zamknij wszystkie deskryptory, odłącz wszystkie pliki tymczasowe itp. Ta funkcja czyszczenia powinna zostać uruchomiona po normalnym zakończeniu lub po otrzymaniu różnego rodzaju sygnałów krytycznych, chyba że chcesz zostawić jakieś pliki, abyś mógł wykryć awarię i wznowić.

Naprawdę, bądź dobry dla biednej duszy, która musi utrzymywać twoje rzeczy, kiedy przechodzisz do innych rzeczy ... podaj im „valgrind clean” :)

Całkowicie w porządku jest pozostawienie pamięci bez pamięci po wyjściu; malloc () przydziela pamięć z obszaru pamięci zwanego „stertą”, a cała sterta procesu jest zwalniana po zakończeniu procesu.

To powiedziawszy, jednym z powodów, dla których ludzie wciąż upierają się, że dobrze jest zwolnić wszystko przed wyjściem, jest to, że debuggery pamięci (np. Valgrind w Linuksie) wykrywają niewyleczone bloki jako wycieki pamięci, a jeśli masz również „prawdziwe” wycieki pamięci, staje się trudniej je dostrzec, jeśli na końcu uzyskasz „fałszywe” wyniki.

Jeśli korzystasz z przydzielonej pamięci, nie robisz nic złego. Staje się to problemem, gdy piszesz funkcje (inne niż główne), które przydzielają pamięć bez zwalniania jej i bez udostępniania jej pozostałej części programu. Następnie program kontynuuje działanie z przydzieloną pamięcią, ale nie ma możliwości korzystania z niego. Twój program i inne uruchomione programy są pozbawione tej pamięci.

Edycja: Nie jest w 100% dokładne stwierdzenie, że inne działające programy są pozbawione tej pamięci. System operacyjny może zawsze pozwolić mu na użycie go kosztem zamiany programu na pamięć wirtualną ( </handwaving>). Chodzi o to, że jeśli twój program zwolni pamięć, której nie używa, wówczas zamiana pamięci wirtualnej jest mniej prawdopodobna.

Ten kod zwykle działa poprawnie, ale weź pod uwagę problem ponownego użycia kodu.

Być może napisałeś fragment kodu, który nie zwalnia przydzielonej pamięci, jest on uruchamiany w taki sposób, że pamięć jest następnie automatycznie odzyskiwana. Wydaje się w porządku.

Następnie ktoś inny kopiuje Twój fragment do swojego projektu w taki sposób, że jest on wykonywany tysiąc razy na sekundę. Ta osoba ma teraz ogromny wyciek pamięci w swoim programie. Ogólnie niezbyt dobry, zwykle śmiertelny dla aplikacji serwerowej.

Ponowne użycie kodu jest typowe dla przedsiębiorstw. Zwykle firma jest właścicielem całego kodu, który produkują jej pracownicy, i każdy dział może ponownie wykorzystać to, co firma jest właścicielem. Pisząc taki „niewinnie wyglądający” kod, wywołujesz potencjalny ból głowy u innych ludzi. Może cię to zwolnić.

Jaki jest tutaj prawdziwy wynik?

Twój program wyciekł z pamięci. W zależności od systemu operacyjnego może zostać odzyskany.

Większość nowoczesnych komputerów stacjonarnych systemów operacyjnych zrobić odzyskać pamięć wyciekły na zakończenie procesu, co niestety powszechne ignorowanie problemu, ponieważ mogą być postrzegane przez wielu innych odpowiedzi tutaj.)

Ale polegasz na funkcji bezpieczeństwa, na której nie powinieneś polegać, a twój program (lub funkcja) może działać w systemie, w którym to zachowanie powoduje „twardy” wyciek pamięci, następnym razem.

Być może działasz w trybie jądra lub w systemach operacyjnych vintage / embedded, które nie wykorzystują ochrony pamięci jako kompromisu. (MMU zajmują miejsce na matrycę, ochrona pamięci kosztuje dodatkowe cykle procesora i programiści nie muszą zbytnio prosić o posprzątanie po sobie).

Możesz używać i ponownie wykorzystywać pamięć w dowolny sposób, ale pamiętaj, aby zwolnić wszystkie zasoby przed wyjściem.

W podręczniku online OSTEP znajduje się sekcja dla studentów studiów licencjackich na temat systemów operacyjnych, która dokładnie omawia twoje pytanie.

Odpowiednia sekcja to „Zapominanie o zwolnieniu pamięci” w rozdziale API pamięci na stronie 6, który zawiera następujące wyjaśnienie:

W niektórych przypadkach może się wydawać, że nie wywoływanie free () jest uzasadnione. Na przykład twój program jest krótkotrwały i wkrótce się zakończy; w takim przypadku, gdy proces umrze, system operacyjny wyczyści wszystkie przydzielone strony, a zatem nie wystąpi przeciek pamięci. Chociaż to z pewnością „działa” (patrz strona 7), prawdopodobnie jest to zły nawyk do rozwijania się, więc bądź ostrożny przy wyborze takiej strategii

Ten fragment jest w kontekście wprowadzenia koncepcji pamięci wirtualnej. Zasadniczo w tym momencie książki autorzy wyjaśniają, że jednym z celów systemu operacyjnego jest „wirtualizacja pamięci”, to znaczy, aby każdy program mógł uwierzyć, że ma dostęp do bardzo dużej przestrzeni adresowej pamięci.

Za kulisami system operacyjny tłumaczy „adresy wirtualne”, które widzi użytkownik, na rzeczywiste adresy wskazujące na pamięć fizyczną.

Jednak współdzielenie zasobów, takich jak pamięć fizyczna, wymaga od systemu operacyjnego śledzenia, z jakich procesów korzystają. Jeśli proces zostanie zakończony, odzyskanie pamięci procesu w ramach możliwości i celów projektowych systemu operacyjnego będzie możliwe w celu redystrybucji i współdzielenia pamięci z innymi procesami.

EDYCJA: strona wymieniona we fragmencie jest skopiowana poniżej.

Poza tym: DLACZEGO PAMIĘĆ NIE WYCIE SIĘ PO WYJŚCIU Z PROCESU

Kiedy piszesz program krótkotrwały, możesz przydzielić trochę miejsca za pomocą malloc(). Program działa i wkrótce się kończy: czy trzeba wywołać free()kilka razy tuż przed wyjściem? Chociaż nie wydaje się to niewłaściwe, żadna pamięć nie zostanie „utracona” w żadnym prawdziwym sensie. Powód jest prosty: w systemie istnieją dwa poziomy zarządzania pamięcią. Pierwszy poziom zarządzania pamięcią jest wykonywany przez system operacyjny, który przekazuje pamięć procesom podczas ich działania i zabiera ją z powrotem, gdy procesy wychodzą (lub w inny sposób umierają). Drugi poziom zarządzania znajduje się w ramach każdego procesu, na przykład w stercie podczas wywoływania malloc()i free(). Nawet jeśli nie zadzwoniszfree()(i tym samym wyciek pamięci w stercie), system operacyjny odzyska całą pamięć procesu (w tym strony kodu, stosu i, stosownie do tego, stosu), gdy program zakończy działanie. Bez względu na stan stosu w przestrzeni adresowej, system operacyjny zabiera wszystkie te strony, gdy proces umiera, zapewniając w ten sposób, że pamięć nie zostanie utracona, mimo że jej nie zwolniłeś.

Dlatego w przypadku programów krótkotrwałych wyciek pamięci często nie powoduje żadnych problemów operacyjnych (choć można uznać to za kiepską formę). Gdy piszesz długo działający serwer (taki jak serwer WWW lub system zarządzania bazą danych, który nigdy się nie kończy), wyciek pamięci jest znacznie większym problemem i ostatecznie doprowadzi do awarii, gdy w aplikacji zabraknie pamięci. I oczywiście wyciek pamięci jest jeszcze większym problemem w jednym konkretnym programie: samym systemie operacyjnym. Pokazuje nam jeszcze raz: ci, którzy piszą kod jądra, mają najtrudniejsze zadanie ze wszystkich ...

z strony 7 rozdziału Memory API z

Systemy operacyjne: trzy łatwe utwory
Remzi H. Arpaci-Dusseau i Andrea C. Arpaci-Dusseau Arpaci-Dusseau Books Marzec 2015 (wersja 0.90)

Nie ma realnego niebezpieczeństwa, nie zwalniając zmiennych, ale jeśli przypiszesz wskaźnik do bloku pamięci do innego bloku pamięci bez zwolnienia pierwszego bloku, pierwszy blok nie jest już dostępny, ale nadal zajmuje miejsce. Nazywa się to wyciekiem pamięci, a jeśli robisz to regularnie, proces zacznie zużywać coraz więcej pamięci, zabierając zasoby systemowe innym procesom.

Jeśli proces ten jest krótkotrwały, często możesz tego uniknąć, ponieważ cała przydzielona pamięć jest odzyskiwana przez system operacyjny po zakończeniu procesu, ale radzę nabrać nawyku zwalniania całej pamięci, z której nie będziesz już korzystać.

Masz absolutną rację pod tym względem. W małych, trywialnych programach, w których zmienna musi istnieć aż do śmierci programu, nie ma realnej korzyści z zwolnienia pamięci.

W rzeczywistości byłem kiedyś zaangażowany w projekt, w którym każde wykonanie programu było bardzo złożone, ale stosunkowo krótkotrwałe, i postanowiłem po prostu zachować przydzieloną pamięć i nie destabilizować projektu, popełniając błędy przy jego dezalokacji.

To powiedziawszy, w większości programów nie jest to tak naprawdę opcja, lub może doprowadzić do wyczerpania się pamięci.

Masz rację, pamięć jest automatycznie zwalniana po zakończeniu procesu. Niektóre osoby starają się nie przeprowadzać obszernego czyszczenia po zakończeniu procesu, ponieważ wszystko to zostanie przekazane systemowi operacyjnemu. Jednak podczas działania programu należy zwolnić nieużywaną pamięć. Jeśli tego nie zrobisz, możesz w końcu skończyć się lub spowodować nadmierne stronicowanie, jeśli zestaw roboczy stanie się zbyt duży.

Jeśli tworzysz aplikację od zera, możesz dokonać świadomego wyboru, kiedy zadzwonić za darmo. Twój przykładowy program jest w porządku: alokuje pamięć, być może masz kilka sekund pracy, a następnie zamyka się, uwalniając wszystkie zasoby, o które twierdził.

Jeśli piszesz cokolwiek innego - serwer / długo działającą aplikację lub bibliotekę, z której może korzystać ktoś inny, powinieneś spodziewać się bezpłatnego połączenia ze wszystkim, co robisz malloc.

Ignorując pragmatyczną stronę przez sekundę, znacznie bezpieczniej jest podążać za bardziej rygorystycznym podejściem i zmusić się do uwolnienia wszystkiego, co Malloc. Jeśli nie masz zwyczaju obserwowania wycieków pamięci za każdym razem, gdy kodujesz, możesz z łatwością wygenerować kilka wycieków. Innymi słowy, tak - możesz uciec bez niego; proszę jednak uważać.

Jeśli program zapomni zwolnić kilka megabajtów przed wyjściem, system operacyjny je zwolni. Ale jeśli twój program działa przez kilka tygodni, a pętla wewnątrz programu zapomina o zwolnieniu kilku bajtów w każdej iteracji, będziesz mieć ogromny wyciek pamięci, który pochłonie całą dostępną pamięć w komputerze, chyba że uruchomisz ją ponownie base => nawet małe wycieki pamięci mogą być złe, jeśli program jest używany do poważnie dużego zadania, nawet jeśli pierwotnie nie został zaprojektowany dla jednego.

Myślę, że twoje dwa przykłady są w rzeczywistości tylko jednym: free()powinny wystąpić tylko na końcu procesu, co, jak zauważyłeś, jest bezużyteczne, ponieważ proces się kończy.

W drugim przykładzie jedyną różnicą jest to, że dopuszczasz nieokreśloną liczbę malloc(), co może doprowadzić do wyczerpania się pamięci. Jedynym sposobem na poradzenie sobie z sytuacją jest sprawdzenie kodu powrotu malloc()i odpowiednie działanie.