Dlaczego nadal mogę uzyskać dostęp do elementu struktury po zwolnieniu wskaźnika?

Question

Gdybym określić strukturę ...

struct LinkNode 
{ 
    int node_val; 
    struct LinkNode *next_node; 
}; 

a następnie utworzyć wskaźnik do niego ...

struct LinkNode *mynode = malloc(sizeof(struct LinkNode)); 

... i wreszcie free() to ...

free(mynode); 

... Wciąż mogę uzyskać dostęp do elementu struktury "next_node".

mynode->next_node 

Moje pytanie jest takie: który kawałek mechaniki bazowych śledzi to, że ten blok pamięci ma reprezentować LinkNode struct? Jestem nowicjuszem w C i spodziewałem się, że po tym, jak użyłem free() na wskaźniku do mojego LinkNode, nie będę już mógł uzyskać dostępu do członków tej struktury. Spodziewałem się jakiegoś ostrzeżenia "już niedostępnego".

Chciałbym dowiedzieć się więcej o tym, jak działa ten proces.

Answer 1

Skompilowany program nie ma już żadnej wiedzy na temat struct LinkedNode lub pola o nazwie next_node lub czegoś w tym stylu. Wszelkie nazwy są zupełnie nieobecne w skompilowanym programie. Skompilowany program działa pod względem wartości liczbowych, które mogą odgrywać role adresów pamięci, przesunięć, indeksów i tak dalej.

W przykładzie, kiedy czytasz mynode->next_node w kodzie źródłowym programu, jest kompilowany do kodu maszynowego, które po prostu odczytuje 4-bajtowy wartość liczbową od jakiegoś zarezerwowanego miejsca pamięci (znany jako zmiennej mynode w kodzie źródłowym) , dodaje 4 do niego (co jest przesunięciem pola next_node) i odczytuje 4-bajtową wartość w wynikowym adresie (który jest mynode->next_node). Ten kod, jak widać, działa w kategoriach wartości całkowitych - adresów, rozmiarów i przesunięć. Nie interesują go żadne nazwy, takie jak LinkedNode lub next_node. Nie obchodzi, czy pamięć jest przydzielona i/lub uwolniona. Nie obchodzi, czy którykolwiek z tych dostępów jest legalny, czy nie.

(Stała 4 I wielokrotnie używane w powyższym przykładzie jest specyficzne dla platformy 32-bitowych. Platform 64-bitowych to być zastąpione 8 w większości (lub wszystkich) przypadkach).

Jeżeli próba jest przeznaczony do odczytu pamięci, która została uwolniona, te dostępy mogą spowodować awarię twojego programu. A może nie. To kwestia czystego szczęścia. Jeśli chodzi o język, zachowanie jest niezdefiniowane.

Answer 2

Nie ma i nie można. Jest to klasyczny przypadek niezdefiniowanego zachowania.

Kiedy masz niezdefiniowane zachowanie, wszystko może się zdarzyć. Może się nawet wydawać, że działa, ale losowo rozbija się rok później.

Answer 3

Żadna część podstawowej pamięci nie śledzi tego. To tylko semantyka, którą język programowania nadaje kawałkowi pamięci. Możesz np. rzucić go do czegoś zupełnie innego i nadal może uzyskać dostęp do tego samego regionu pamięci. Jednak tutaj jest haczyk, który z większym prawdopodobieństwem może prowadzić do błędów. Zwłaszcza bezpieczeństwo typu zniknie. W twoim przypadku tylko dlatego, że zadzwoniłeś pod numer free, nie oznacza to, że pamięć bazowa w ogóle działa. W systemie operacyjnym znajduje się tylko flaga oznaczająca ten region jako wolny ponownie.

Pomyśl o tym w ten sposób: funkcja free jest czymś w rodzaju "minimalnego" systemu zarządzania pamięcią. Jeśli twoje zgłoszenie wymagałoby czegoś więcej niż ustawienie flagi, wprowadziłoby to niepotrzebnie narzut. Również wtedy, gdy uzyskujesz dostęp do elementu, który użytkownik (tj. Twój system operacyjny) może sprawdzić, czy flaga dla tego regionu pamięci jest ustawiona na "wolny" lub "w użyciu". Ale to znowu jest w górze.

Oczywiście nie oznacza to, że nie ma sensu robić takich rzeczy. Uniknęłoby to wielu luk w zabezpieczeniach i zostało wykonane na przykład w .Net i Java. Te środowiska wykonawcze są jednak znacznie młodsze od C, a obecnie mamy znacznie więcej zasobów.

Answer 4

Działa na zasadzie szczęścia, ponieważ uwolniona pamięć nie została jeszcze nadpisana przez coś innego. Po zwolnieniu pamięci należy pamiętać, aby nie używać go ponownie.

Answer 5

Kiedy twój kompilator przetłumaczy twój kod C na kod wykonywalny maszyny, wyrzuci wiele informacji, w tym informacje o typie. Gdzie piszesz:

int x = 42; 

wygenerowany kod kopiuje tylko pewien wzorzec bitowy w pewnym fragmencie pamięci (fragmentu, który może być typowo 4 bajty). Nie można stwierdzić poprzez sprawdzenie kodu maszynowego, że fragment pamięci jest obiektem typu int.

Podobnie, gdy piszesz:

if (mynode->next_node == NULL) { /* ... */ } 

wygenerowany kod pobiera wskaźnik wielkości kawałek pamięci przez dereferencji innego wskaźnika wielkości kawałek pamięci, i porównać wynik z reprezentacją systemu z zerowym wskaźnikiem (zwykle wszystkie-bity-zero). Wygenerowany kod nie odzwierciedla bezpośrednio faktu, że next_node jest członkiem struktury, ani nic o tym, jak struktura została przydzielona lub czy nadal istnieje.

Kompilator może sprawdzić wiele rzeczy w czasie kompilacji, ale niekoniecznie generuje kod do przeprowadzania kontroli w czasie wykonywania. Od Ciebie zależy, czy jako programista unikniesz błędów.

W tym konkretnym przypadku, po wywołaniu free, mynode ma nieokreśloną wartość. Nie wskazuje żadnego poprawnego obiektu, ale nie ma wymogu implementacji, aby cokolwiek zrobić z tą wiedzą. Wywołanie free nie niszczy przydzielonej pamięci, a jedynie udostępnia ją do alokacji przez przyszłe połączenia z numerem malloc.

Istnieje wiele sposobów, że implementacja mógłby przeprowadzają kontrole w ten sposób, i wywołać błąd run-time jeśli nieprawidłowego wskaźnika po free ing go. Ale takie kontrole nie są wymagane przez język C, i generalnie nie są implementowane, ponieważ (a) byłyby one dość drogie, dzięki czemu twój program działałby wolniej i (b) kontrole i tak nie są w stanie wychwycić wszystkich błędów.

C jest tak zdefiniowany, że przydział pamięci i manipulacja kursorem będą działały poprawnie, jeśli twój program robi wszystko dobrze. Jeśli popełnisz pewne błędy, które można wykryć podczas kompilacji, kompilator może je zdiagnozować. Na przykład przypisanie wartości wskaźnika do obiektu typu liczba całkowita wymaga co najmniej ostrzeżenia o czasie kompilacji.Ale inne błędy, takie jak dereferencja ze wskaźnikiem free powodują, że twój program ma niezdefiniowane zachowanie . To ty, jako programista, musisz przede wszystkim unikać wprowadzania tych błędów. Jeśli ci się nie uda, jesteś sam.

Oczywiście istnieją narzędzia, które mogą pomóc. Valgrind to jeden; sprytne kompilatory optymalizujące to kolejne. (Włączenie optymalizacji powoduje, że kompilator wykonuje więcej analiz kodu, co często pozwala mu diagnozować więcej błędów.) Ale ostatecznie C nie jest językiem, który trzyma rękę. Jest to ostre narzędzie - i może być używane do budowania bezpieczniejszych narzędzi, takich jak języki interpretowane, które wykonują więcej sprawdzania w czasie pracy.

Answer 6

Musisz przypisać NULL do mynode-> next_node:

mynode-> next_node = NULL;

po zwolnieniu pamięci, aby wskazać, że nie jest już używana przydzielona pamięć.

Bez przypisania wartości NULL, nadal wskazuje poprzednio zwolnioną lokalizację pamięci.