Co tak naprawdę się dzieje, gdy nie jesteś wolny po malloc?

Tak masz rację, twój przykład nie szkodzi (przynajmniej nie na 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: alokacja i mity GC (PostScript alert!)

Mit alokacji 4: programy bez śmieci powinien zawsze dealokować całą pamięć przydzielają.

Prawda: Pominięta dealokacje w często wykonywanych kod powodować rosnące przecieki. Są to rzadko akceptowalne. ale programy, które zachowaj najwięcej przydzielonej pamięci do wyjście programu często działa lepiej bez interwencji dealokacji. Malloc jest znacznie łatwiejsze do wdrożenia, jeśli nie ma za darmo.

W większości przypadków dealokacja pamięci tuż przed zakończeniem programu jest bezcelowe. OS i tak go odzyska. Free dotyka i stroni w umarłych obiekty; system operacyjny nie będzie.

Konsekwencja: uważaj na " przeciek detektory", które liczą przydziały. Niektóre "przecieki" są dobre!

To powiedziawszy, naprawdę powinieneś starać się unikać wszystkich wycieków pamięci!

Drugie pytanie: twój projekt jest ok. Jeśli musisz coś przechowywać, dopóki aplikacja nie zakończy działania, możesz to zrobić z dynamiczną alokacją pamięci. Jeśli nie znasz z góry wymaganego rozmiaru, nie możesz użyć statycznie przydzielonej pamięci.

=== co z future proofing i code reuse? ===

Jeśli nie napiszesz kodu, aby uwolnić obiekty, ograniczysz kod do bezpiecznego użycia tylko wtedy, gdy możesz polegać na tym, że pamięć zostanie uwolniona przez zamknięty Proces ... czyli małe projekty jednorazowego użytku lub "wyrzucenie"^[1] projekty)... gdzie wiesz, kiedy proces się skończy.

If you do write the code that free () s all your dynamic allocated Pamięci, następnie sprawdzasz kod w przyszłości i pozwalasz innym używać go w większym projekcie.

^{[1] dotyczące projektów "wyrzuć". Kod używany w projektach "Throw-away" ma sposób, aby nie zostać wyrzuconym. Następne co wiesz minęło 10 lat i twój kod" wyrzuć " jest nadal używany).}

^{słyszałem historię o jakimś facecie, który napisał Kod tylko dla zabawy, aby jego sprzęt działał lepiej. Powiedział " tylko hobby, nie będzie duże i professional". Wiele lat później wiele osób używa jego kodu "hobby".}

Masz rację, nic się nie stało i szybciej jest po prostu wyjść

Istnieją różne powody tego:

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

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

• Co ważniejsze, jest to strata czasu, gdy robi się to tuż przed exit (). Po wyjściu strony pamięci i przestrzeń wymiany są po prostu zwalniane. W przeciwieństwie do tego, seria darmowych wywołań() spala czas procesora i może spowodować operacje stronicowania dysku, brak pamięci podręcznej i eksmisje pamięci podręcznej.

Jeśli chodzi o możliwość przyszłego ponownego użycia kodu uzasadniającego pewność bezsensownych operacji: to rozważenie, ale prawdopodobnie nie jest to sposób zwinny . YAGNI!

Całkowicie nie zgadzam się z każdym, kto twierdzi, że OP ma rację lub nie ma nic złego.

Wszyscy mówią o nowoczesnym i / lub dziedzicznym 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 standardzie C ISO/IEC:9899 jest to czas życia pamięci podany jako:

7.20.3 funkcje zarządzania pamięcią

1 Kolejność i ciągłość przechowywanie przydzielane przez kolejne wywołania do calloc, funkcje malloc i realloc są nieokreślone. Wskaźnik zwrócony, jeśli przydział succeeds jest odpowiednio wyrównane, dzięki czemu może być przypisane do wskaźnika do dowolnego typu obiektu a następnie służy do uzyskania dostępu do takiego obiektu lub tablicy takich obiektów w przydzielonej przestrzeni (dopóki przestrzeń nie zostanie wyraźnie dealokowana). Czas życia przydzielonego obiektu wydłuża się od przydziału do dealokacji.[...]

Więc nie musi być biorąc pod uwagę, że środowisko wykonuje za Ciebie pracę uwalniającą. W przeciwnym razie zostałby dodany do ostatniego zdania: "lub do czasu zakończenia programu."

Czyli innymi słowy: Nie uwalnianie pamięci to nie tylko zła praktyka. Produkuje non przenośny i nie C zgodny kod. Które można przynajmniej uznać za " poprawne, jeżeli: [...], jest wspierany przez środowisko".

Ale w przypadkach, gdy nie masz w ogóle systemu operacyjnego, nikt nie wykonuje pracy za Ciebie (Wiem, że generalnie nie przydzielasz i realokacja pamięci w systemach wbudowanych, ale są przypadki, w których możesz chcieć.)

Tak mówiąc ogólnie zwykły C (jako który OP jest oznaczony), jest to po prostu generowanie błędnego i nie przenośnego kodu.

Zazwyczaj zwalniam każdy przydzielony blok, gdy jestem pewien, że z nim skończę. Dzisiaj punktem wejścia mojego programu może być main(int argc, char *argv[]), ale jutro może być {[2] } i być wpisany jako wskaźnik funkcji.

Jeśli chodzi o twoje drugie pytanie, jeśli mój program miał Dane wejściowe jak a=5, przydzieliłbym miejsce na a, lub ponownie przydzielił tę samą przestrzeń na kolejnym a="foo". To pozostanie przydzielone do:

1. użytkownik wpisał ' unset a "
2. moja funkcja czyszczenia została wprowadzona, albo obsługując sygnał, albo użytkownik wpisał "Zakończ"

Nie mogę wymyślić żadnego nowoczesnego systemu operacyjnego, który nie odzyskuje pamięci po zakończeniu procesu. Z drugiej strony free() jest tanie, dlaczego nie posprzątać? Jak powiedzieli inni, narzędzia takie jak valgrind są świetne do wykrywania wycieków, o które naprawdę musisz się martwić. Nawet jeśli bloki, które przykład będzie oznaczony jako "nadal osiągalne", to po prostu dodatkowy szum na wyjściu, gdy jesteś staram się upewnić, że nie masz przecieków.

Innym mitem jest " jeśli jest w main(), nie muszę go uwolnić " , jest to niepoprawne. Rozważmy następujące:

char *t;

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

Jeśli to nastąpiło przed rozwidleniem / demonizacją (i teoretycznie działa w nieskończoność), Twój program właśnie wyciekł nieokreślony rozmiar t 255 razy.

Dobry, dobrze napisany program powinien zawsze posprzątać po sobie. Zwolnij całą pamięć, wyczyść wszystkie pliki, Zamknij wszystkie deskryptory, odłącz wszystkie pliki tymczasowe itp. To funkcja czyszczenia powinna zostać osiągnięta po normalnym zakończeniu lub po otrzymaniu różnego rodzaju sygnałów fatalnych, chyba że chcesz zostawić kilka plików leżących wokół, aby można było wykryć awarię i wznowić.

Malloc() przydziela pamięć z obszaru pamięci zwanego "stertą", a cała sterta procesu jest zwalniana, gdy proces się kończy.

To powiedziawszy, jednym z powodów, dla których ludzie nadal upierają się, że dobrze jest uwolnić wszystko przed zakończeniem, jest to, że debuggery pamięci (np. valgrind na Linuksie) wykrywają nieużywane bloki jako wycieki pamięci, a jeśli masz również "prawdziwe" wycieki pamięci, trudniej jest je wykryć, jeśli otrzymujesz również "fałszywe" wyniki na końcu.

Jeśli używasz przydzielonej pamięci, to nie robisz nic złego. Staje się to problemem, gdy piszesz funkcje (inne niż main), które przydzielają pamięć bez jej zwalniania i bez udostępniania jej reszcie programu. Następnie program kontynuuje pracę z przydzieloną do niego pamięcią, ale nie ma możliwości jej użycia. Twój program i inne uruchomione programy są pozbawione tej pamięci.

Edit: nie jest w 100% trafne stwierdzenie, że inne bieganie programy są pozbawione tej pamięci. System operacyjny zawsze może pozwolić im go używać kosztem wymiany programu na pamięć wirtualną (</handwaving>). Chodzi jednak o to, że jeśli twój program uwalnia pamięć, której nie używa, wymiana pamięci wirtualnej jest mniej prawdopodobna.

Ten kod zwykle działa poprawnie, ale rozważ problem ponownego użycia kodu.

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

Wtedy ktoś inny skopiuje Twój fragment do jego 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 dobre, zazwyczaj fatalne dla serwera podanie.

Ponowne użycie kodu jest typowe dla przedsiębiorstw. Zazwyczaj firma posiada cały kod, który jej pracownicy produkują, a każdy dział może ponownie użyć tego, co firma posiada. PiszÄ ... c wiÄ ™ c taki "niewinnie wyglÄ ... dajÄ ... cy" kod powodujesz potencjalny băłl gĹ ' owy dla innych ludzi. To może cię zwolnić.

Jaki jest prawdziwy rezultat?

Twój program wyciekł z pamięci. W zależności od Twojego systemu operacyjnego, to Może zostały odzyskane.

Większość nowoczesnych systemów operacyjnychdesktop odzyskuje wyciekającą pamięć po zakończeniu procesu, co niestety często ignoruje problem, co widać po wielu innych odpowiedziach tutaj.)

Ale polegasz na funkcji bezpieczeństwa, na której nie powinieneś polegać, a twój program (lub funkcja) może działać na system, w którym to zachowanie powoduje "twardy" wyciek pamięci, Następny czas.

Możesz działać w trybie jądra lub na starych / wbudowanych systemach operacyjnych, które nie wykorzystują ochrony pamięci jako kompromisu. (MMU zajmują miejsce matrycy, Ochrona pamięci kosztuje dodatkowe cykle procesora, a programista nie wymaga zbyt wiele, aby posprzątać po sobie).

Możesz używać i ponownie używać pamięci w dowolny sposób, ale upewnij się, że rozdzieliłeś wszystkie zasoby przed wychodzę.

W OSTEP podręczniku internetowym na studia licencjackie z systemów operacyjnych jest rozdział, który omawia dokładnie twoje pytanie.

Odpowiednią sekcją jest "zapominanie o wolnej 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łanie free() jest rozsądne. Na przykład, twój program jest krótkotrwały i wkrótce zakończy działanie; w tym przypadku, kiedy proces umiera, system operacyjny wyczyści wszystkie przydzielone strony i w ten sposób nie dojdzie do wycieku pamięci per se. chociaż to z pewnością " działa" (patrz na stronie 7), prawdopodobnie jest to zły nawyk do rozwoju, więc uważaj wyboru takiej strategii

Ten fragment jest w kontekście wprowadzenia pojęcia pamięci wirtualnej. Zasadniczo w tym momencie w książce autorzy wyjaśniają, że jednym z celów systemu operacyjnego jest "wirtualizacja pamięci", czyli niech każdy program wierzy, że ma dostęp do bardzo dużej przestrzeni adresowej pamięci.

Za kulisami system operacyjny będzie tłumaczył" wirtualne adresy " widziane przez użytkownika na rzeczywiste adresy wskazujące na fizyczną pamięć.

EDIT: bok wymieniony w fragmencie jest skopiowany poniżej.

NA BOK: DLACZEGO ŻADNA PAMIĘĆ NIE JEST WYCIEKANA PO ZAKOŃCZENIU PROCESU

Kiedy piszesz program krótkotrwały, możesz przeznaczyć trochę miejsca za pomocą malloc(). Program działa i zaraz się zakończy: czy jest musisz zadzwonić kilka razy przed wyjazdem? Choć wydaje się źle nie aby, żadna pamięć nie zostanie "utracona" w żadnym realnym znaczeniu. Powodem jest proste: istnieją naprawdę dwa poziomy zarządzania pamięcią w systemie. Pierwszy poziom zarządzania pamięcią jest wykonywany przez system operacyjny, który przekazuje pamięć procesom, gdy działają, i zabiera ją z powrotem, gdy procesy kończą pracę (lub w inny sposób umierają). Drugi poziom zarządzania jest w każdym procesie, na przykład w stercie, gdy wywołujesz malloc() i free(). Nawet jeśli nie zadzwonisz free() (i tym samym wyciek pamięć w stercie), system operacyjny odzyska całą pamięć proces (w tym strony kodu, stosu i, w stosownych przypadkach, tutaj, sterty) po zakończeniu działania programu. Bez względu na stan z Twojej sterty w przestrzeni adresowej, system operacyjny usuwa wszystkie te strony gdy proces umiera, zapewniając w ten sposób, że żadna pamięć nie zostanie utracona pomimo fakt, że go nie uwolniłeś.

Tak więc, w przypadku programów krótkotrwałych, wyciek pamięci często nie powoduje żadnych problemy operacyjne (choć może być uważany za słabą formę). Kiedy piszesz serwer długo działający (taki jak serwer WWW lub zarządzanie bazą danych systemu, który nigdy się nie kończy), wyciekła pamięć to znacznie większy problem, i ostatecznie doprowadzi do awarii, gdy aplikacja skończy się pamięć. I oczywiście wyciek pamięci jest jeszcze większym problemem wewnątrz jeden konkretny program: sam system operacyjny. Pokazując nam raz ponownie: ci, którzy piszą kod jądra, mają najtrudniejszą pracę ze wszystkich...

ze strony 7 rozdziału API pamięci z rozdziału

Systemy Operacyjne: Trzy Proste Elementy
Remzi H. Arpaci-Dusseau i Andrea C. Arpaci-Dusseau Arpaci-Dusseau Books Marzec, 2015 (Wersja 0.90)

Nie ma prawdziwego niebezpieczeństwa w nie uwolnieniu zmiennych, ale jeśli przypisasz wskaźnik do bloku pamięci do innego bloku pamięci bez uwolnienia pierwszego bloku, pierwszy blok nie jest już dostępny, ale nadal zajmuje miejsce. To się nazywa wyciek pamięci, a jeśli robisz to regularnie, twój proces zacznie zużywać coraz więcej pamięci, odbierając zasoby systemowe innym procesom.

Jeśli Proces jest krótkotrwały, często można uciec robiąc to, ponieważ cała przydzielona pamięć jest odzyskiwana przez system operacyjny po zakończeniu procesu, ale radzę przyzwyczaić się do uwalniania całej pamięci, do której nie masz dalszego użytku.

Masz rację, pamięć jest automatycznie zwalniana po zakończeniu procesu. Niektórzy ludzie starają się nie robić rozległego CZYSZCZENIA, gdy proces zostanie zakończony, ponieważ wszystko zostanie zrzec się systemu operacyjnego. Jednak podczas działania programu należy zwolnić nieużywaną pamięć. Jeśli tego nie zrobisz, może w końcu zabraknąć lub spowodować nadmierne stronicowanie, jeśli twój zestaw roboczy stanie się zbyt duży.

Masz absolutną rację w tym względzie. W małych trywialnych programach, gdzie zmienna musi istnieć aż do śmierci programu, nie ma realnej korzyści z dealokacji 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, a decyzja była po prostu zachować przydzieloną pamięć i nie destabilizować projektu poprzez popełnianie błędów dealokacji.

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

Jeśli tworzysz aplikację od podstaw, możesz dokonać pewnych świadomych wyborów, kiedy zadzwonić za darmo. Twój przykładowy program jest w porządku: przydziela pamięć, może masz go pracować przez kilka sekund, a następnie zamyka, uwalniając wszystkie zasoby, które twierdził.

Jeśli piszesz coś jeszcze-serwer/długo działającą aplikację lub bibliotekę do wykorzystania przez kogoś innego, powinieneś spodziewać się darmowego wywołania na wszystkim, co chcesz.

Ignorowanie pragmatycznej strony dla po drugie, o wiele bezpieczniej jest podążać za surowszym podejściem i zmusić się do uwolnienia wszystkiego, co malloc. Jeśli nie masz zwyczaju obserwować wycieków pamięci za każdym razem, gdy kodujesz, możesz łatwo wywołać kilka wycieków. Innymi słowy, tak - możecie uciec bez tego, ale bądźcie ostrożni.

Jeśli program zapomni o zwolnieniu kilku megabajtów przed opuszczeniem systemu operacyjnego, zwolni je. Ale jeśli twój program działa tygodniami na raz i pętla wewnątrz programu zapomni zwolnić kilka bajtów w każdej iteracji będziesz miał potężny wyciek pamięci, który pochłonie całą dostępną pamięć w komputerze, chyba że regularnie go zrestartujesz = > 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 był przeznaczony do jeden.

To zależy od zakresu projektu, nad którym pracujesz. W kontekście twojego pytania, i mam na myśli tylko twoje pytanie, to nie ma znaczenia.

Dla dalszego wyjaśnienia (opcjonalne), niektóre scenariusze zauważyłem z całej tej dyskusji jest następujący:

(1) - jeśli pracujesz w środowisku wbudowanym, w którym nie możesz polegać na głównym systemie operacyjnym, aby odzyskać pamięć, powinieneś je uwolnić, ponieważ wycieki pamięci mogą naprawdę zawiesić program, jeśli to zrobisz / align = "left" /

(2) - jeśli pracujesz nad osobistym projektem, w którym nie ujawnisz go nikomu innemu, możesz go pominąć (zakładając, że używasz go na głównym systemie operacyjnym) lub dołączyć go dla" najlepszych praktyk".

(3) - jeśli pracujesz nad projektem i planujesz mieć go open source, musisz przeprowadzić więcej badań nad odbiorcami i dowiedzieć się, czy uwolnienie pamięci byłoby lepszym wyborem.

(4) - Jeśli masz dużą bibliotekę, a twoja publiczność składała się tylko z główny OS', to nie trzeba go zwolnić, jak ich OS ' pomoże im to zrobić. W międzyczasie, nie zwalniając, Twoje biblioteki/program może pomóc w zwiększeniu ogólnej wydajności, ponieważ program nie musi zamykać każdej struktury danych, wydłużając czas wyłączenia (wyobraź sobie bardzo powolne, rozdzierające oczekiwanie na wyłączenie komputera przed opuszczeniem domu...)

Mogę kontynuować i określać, który kurs wybrać, ale ostatecznie zależy to od tego, co chcesz osiągnąć ze swoim program. Uwalnianie pamięci jest uważane za dobrą praktykę w niektórych przypadkach, a nie tak bardzo w niektórych, więc ostatecznie zależy to od konkretnej sytuacji, w której się znajdujesz i zadawania właściwych pytań we właściwym czasie. Powodzenia!

Myślę, że Twoje dwa przykłady są w rzeczywistości tylko jednym: {[0] } powinny wystąpić tylko na końcu procesu, który, jak zaznaczasz, jest bezużyteczny, ponieważ proces się kończy.

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