Czy powinienem zawracać sobie głowę wykrywaniem błędów OOM (out of memory) w moim kodzie C?

Spójrz na drugą stronę Pytania: jeśli malloc pamięci, to zawiedzie, i NIE wykryć go w malloc, kiedy wykryć go?

Oczywiście, gdy próbujesz zdereferować wskaźnik.

Z drugiej strony możesz napisać

  #define OOM 42 /* just some number */

  /* ... */

  if((ptr=malloc(size))==NULL){
      /* a well-behaved fprintf should NOT malloc, so it can be used
       * in this sort of context
       */
      fprintf(stderr,"OOM at %s: %s\n", __FILE__, __LINE__);
      exit(OOM);
   }

I get " OOM at parser.c: 447".

Update

W większości programów, W tym schemacie (mam nadzieję) otrzymasz przydatną wiadomość na stderr - oczywiście może to być również do loggera lub coś w tym stylu-i znaną wartość jako kod powrotu.

Programy o wysokiej niezawodności z krótkim czasem odzyskiwania pchają cię w coś w rodzaju bloki odzyskiwania, gdzie piszesz kod, który próbuje przywrócić system do przetrwania stan. Są świetne, ale skomplikowane; artykuł, który połączyłem, mówi o nich szczegółowo.

W środku możesz wymyślić bardziej skomplikowany schemat zarządzania pamięcią, powiedzmy zarządzanie własną pulą pamięci dynamicznej -- w końcu, jeśli ktoś inny może napisać malloc, to Ty też możesz.

Ale po prostu nie ma ogólnego wzorca (którego i tak jestem świadomy) na sprzątanie wystarczająco dużo, Aby móc powrócić niezawodnie i pozwolić otaczającemu programowi kontynuować.

Niezależnie od platformy (może poza systemami wbudowanymi) dobrze jest sprawdzić, czy nie ma NULL, a następnie po prostu wyjść bez ręcznego czyszczenia.

KsiążkaThe Practice of Programming (Brian W. Kernighan i Rob Pike, 1999) definiuje funkcje takie jak emalloc(), które po prostu wychodzą z Komunikatem o błędzie, jeśli nie ma już pamięci.

To zależy od tego, co piszesz. Czy to biblioteka ogólnego przeznaczenia? Jeśli tak, chcesz poradzić sobie z brakiem pamięci tak wdzięcznie, jak to możliwe, szczególnie jeśli można oczekiwać, że będzie ona używana na systemach el-cheapo lub urządzeniach wbudowanych.

Rozważ to: programista korzysta z twojej Biblioteki. W jego programie pojawia się błąd (być może zmienna niezainicjowana), który przekazuje głupi argument do kodu, który w konsekwencji próbuje przydzielić pojedynczy blok pamięci o pojemności 3,6 GB. Oczywiście malloc() zwraca NULL. Czy wolałby niewyjaśniony segfault wygenerowany gdzieś w kodzie biblioteki, czy wartość zwracaną, aby wskazać błąd?

Aby uniknąć sprawdzania błędów w całym kodzie, jedną z metod jest przydzielanie rozsądnej ilości pamięci na początku i przydzielanie jej zgodnie z wymaganiami.

Jeśli chodzi o zabójcę Oom Linuksa, słyszałem, że to zachowanie jest teraz domyślnie wyłączone na głównych dystrybucjach. Nawet jeśli jest włączona, nie zrozum mnie źle: malloc() Może zwrócić NULL, i na pewno będzie, jeśli całkowite zużycie pamięci programu przekroczy 4GiB (w systemie 32-bitowym). Innymi słowy, nawet jeśli malloc() nie zabezpieczy Ci przestrzeni pamięci RAM/swap, to zarezerwuje część twojej przestrzeni adresowej.

Proponuję eksperyment-napisać mały program, który utrzymuje alokację pamięci bez jej zwalniania, a następnie wyświetli mały (stały) komunikat, gdy alokacja nie powiedzie się. Jakie efekty zauważysz na swoim systemie podczas uruchamiania tego programu? Czy wiadomość zostanie wydrukowana?

Jeśli system zachowuje się normalnie i pozostaje responsywny do momentu wyświetlenia błędu, to powiedziałbym, że tak, warto to sprawdzić. OTOH, jeśli system staje się powolny, nie reaguje i zdarzenia nie nadaje się do użytku przed wyświetlaniem wiadomości (Jeśli w ogóle jest), wtedy powiedziałbym Nie, Nie warto tego sprawdzać.

Ważne: przed uruchomieniem tego testu zapisz wszystkie ważne prace. Nie uruchamiaj go na serwerze produkcyjnym.

Regardfing zachowania Oom Linuksa - jest to właściwie pożądane i jest to sposób, w jaki działa większość OSs. Ważne jest, aby zdać sobie sprawę, że gdy malloc () jakąś pamięć nie dostaje się bezpośrednio z systemu operacyjnego, to dostaje się ją z biblioteki C runtime. To zazwyczaj poprosi SYSTEM OPERACYJNY o dużą część pamięci z przodu (lub na pierwsze żądanie), którą następnie zarządza za pośrednictwem interfejsu malloc/free. Ponieważ wiele programów w ogóle nie używa pamięci dynamicznej, nie byłoby pożądane, aby system operacyjny przekazywał" rzeczywistą " pamięć do środowiska wykonawczego C - zamiast tego przekazuje som euncomited vM, które będą faktycznie dostarczane podczas wykonywania połączeń malloc.

Przy dzisiejszych komputerach i zazwyczaj zainstalowanej ilości pamięci RAM, sprawdzanie wszędzie pod kątem błędów alokacji pamięci jest prawdopodobnie zbyt szczegółowe. Jak już zauważyłeś, często trudno lub niemożliwe jest podjęcie racjonalnej decyzji co do dealokacji. Ponieważ proces alokuje coraz więcej pamięci, system operacyjny odpowiednio zmniejszy ilość pamięci dostępnej dla buforów dyskowych. Gdy spadnie poniżej pewnego progu, system operacyjny rozpocznie przywoływanie pamięci na dysk. (Jest to uproszczenie, ponieważ istnieje wiele czynników w zarządzaniu pamięcią.)

Gdy system operacyjny zacznie stronicować pamięć, cały system staje się coraz wolniejszy i wolniejszy, i prawdopodobnie minie sporo czasu, zanim Twoja aplikacja kiedykolwiek zobaczy NULL z malloc (jeśli w ogóle).

Przy dużej ilości pamięci dostępnej w dzisiejszych systemach, błąd "out of memory" najprawdopodobniej oznacza, że błąd w kodzie próbował przydzielić dowolną ilość pamięci. W takim przypadku nie ma kwoty uwolnienie i ponowna próba ze strony procesu rozwiąże problem.

Musisz zważyć, co jest dla ciebie lepsze lub gorsze: Wkładanie całej pracy w sprawdzenie OOM lub niepowodzenie programu w nieoczekiwanym czasie

Procesy są zwykle uruchamiane z limitem zasobów (zobacz ulimit (3)) Na rozmiarze stosu, ale nie na rozmiarze stosu. malloc (3) zarządza wzrostem pamięci obszaru sterty strona po stronie z systemu operacyjnego, a system operacyjny zorganizuje, aby ta strona została fizycznie przydzielona i odpowiadała Twojej stercie dla procesu. Jeśli w komputerze nie ma więcej pamięci RAM, większość systemów operacyjnych ma coś w rodzaju partycji wymiany na dysku. Kiedy Twój system zacznie trzeba użyć swap, a następnie rzeczy stopniowo powoli. Jeśli jeden proces prowadzi do tego, można go łatwo zidentyfikować za pomocą jakiegoś narzędzia, takiego jak ps (1).

Chyba, że Twój kod ma działać z limitem zasobów lub na systemie o słabym rozmiarze pamięci i Bez Swapu, myślę, że można programować przy założeniu, że malloc (3) powiedzie się. Jeśli nie jesteś pewien, po prostu zrób manekin, który może kiedyś zrobić kontrolę i po prostu wyjdź. Wartość zwracana stanu błędu nie ma sensu, ponieważ twój program wymaga pamięć, którą już przeznaczył. Jeśli malloc (3) zawiedzie i nie sprawdzisz, czy nie ma NULL, proces i tak umrze, gdy zacznie uzyskiwać dostęp do wskaźnika (NULL), który otrzymał.

Problemy z malloc (3) w większości przypadków nie wynikają z braku pamięci, ale z błędu logicznego w twoim programie, który prowadzi do błędnych wywołań do malloc i free. Ten zwykły problem nie zostanie wykryty przez sprawdzenie sukcesu malloc.

Cóż. Wszystko zależy od sytuacji.

if (ptr == NULL) {
    fprintf(log /* stderr or anything */, "Cannot allocate memory");
    exit(2);
}

Po Drugie-po co Ci informacje o OOM? Występuje w dwóch przypadkach:

1. inne oprogramowanie jest wadliwe. Nie możesz nic z tym zrobić
2. twój program jest wadliwy. W takim przypadku jest to program graficzny, w którym jest mało prawdopodobne, aby powiadomić użytkownika w jakikolwiek sposób (nie wspominając o tym, że 99% użytkowników nie czyta wiadomości i powie, że oprogramowanie uległo awarii bez dalszych szczegółów). Jeśli nie jest użytkownik prawdopodobnie i tak go zauważy (monitoruje system Ops lub używa bardziej specjalistycznego oprogramowania).
3. aby uwolnić niektóre pamięci podręczne itp. Należy sprawdzić w systemie jednak ostrzega, że prawdopodobnie nie będzie działać. Możesz obsługiwać tylko własne sbrk / mmap / etc. połączenia i w Linuksie i tak dostaniesz OOM

Tak, wierzę, że jest, jeśli konsekwentnie przestrzegać praktyki. Może to być niepraktyczne w przypadku dużego programu napisanego w języku C ze względu na stopień pracy fizycznej, który może tego wymagać, ale w bardziej nowoczesnym języku większość tej pracy jest wykonywana za Ciebie, ponieważ stan braku pamięci powoduje wyrzucenie wyjątku.

Korzyści płynące z tego konsekwentnego działania są takie, że program nie wejdzie w nieokreślony stan z powodu stanu braku pamięci, co spowoduje przekroczenie bufora (to oczywiście pozostawia możliwość nieokreślonego stanu z powodu wcześniejszego wyjścia z funkcji, chociaż jest to inna klasa błędu). Po dokonaniu tego, twój program może konsekwentnie obsługiwać warunek błędu, lub jeśli awaria była krytyczna, zdecydować się zamknąć w sposób pełen wdzięku.

Sprawdzenie warunków OOM i podjęcie odpowiednich działań może być trudne, jeśli źle zaprojektujesz oprogramowanie. To, czy rzeczywiście trzeba sprawdzić w takich sytuacjach, zależy od niezawodności oprogramowania, które chcesz uzyskać.