Cosa succede DAVVERO quando non ti liberi dopo malloc?

Questo è stato qualcosa che mi ha infastidito per secoli.

A scuola ci viene insegnato (almeno lo ero) che DEVI liberare ogni puntatore assegnato. Sono un po 'curioso, però, del costo reale di non liberare memoria. In alcuni casi ovvi, come quando mallocviene chiamato all'interno di un ciclo o parte dell'esecuzione di un thread, è molto importante liberarsi, quindi non ci sono perdite di memoria. Ma considera i seguenti due esempi:

Innanzitutto, se ho un codice simile a questo:

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

Qual è il vero risultato qui? Il mio pensiero è che il processo muoia e quindi lo spazio dell'heap è andato comunque, quindi non c'è nulla di male nel perdere la chiamata free(tuttavia, riconosco l'importanza di averlo comunque per la chiusura, la manutenibilità e le buone pratiche). Ho ragione in questo pensiero?

Secondo, diciamo che ho un programma che si comporta un po 'come una shell. Gli utenti possono dichiarare variabili simili aaa = 123e quelle sono archiviate in una struttura di dati dinamica per un uso successivo. Chiaramente, sembra ovvio che useresti una soluzione che chiamerà una funzione * alloc (hashmap, elenco collegato, qualcosa del genere). Per questo tipo di programma, non ha senso liberarsi mai dopo aver chiamato mallocperché queste variabili devono essere sempre presenti durante l'esecuzione del programma e non c'è un buon modo (che posso vedere) per implementarlo con spazio allocato staticamente. È una cattiva progettazione avere un mucchio di memoria allocata ma liberata solo durante la fine del processo? In tal caso, qual è l'alternativa?

Quasi tutti i moderni sistemi operativi recupereranno tutto lo spazio di memoria allocato dopo l'uscita da un programma. L'unica eccezione che mi viene in mente potrebbe essere qualcosa come Palm OS in cui l'archiviazione statica del programma e la memoria di runtime sono praticamente la stessa cosa, quindi la mancata liberazione potrebbe far sì che il programma occupi più spazio di archiviazione. (Sto solo speculando qui.)

Quindi, in generale, non vi è alcun danno in esso, tranne il costo di runtime di avere più spazio di archiviazione di cui hai bisogno. Certamente nell'esempio che dai, vuoi conservare la memoria per una variabile che potrebbe essere usata fino a quando non viene cancellata.

Tuttavia, è considerato un buon stile liberare memoria non appena non ne hai più bisogno e liberare tutto ciò che hai ancora all'uscita dal programma. È più un esercizio per sapere quale memoria stai usando e pensare se ne hai ancora bisogno. Se non tieni traccia, potresti avere perdite di memoria.

D'altra parte, la stessa ammonizione di chiudere i tuoi file all'uscita ha un risultato molto più concreto: in caso contrario, i dati che hai scritto potrebbero non essere cancellati, o se sono un file temporaneo, potrebbero non viene eliminato al termine. Inoltre, gli handle del database devono eseguire il commit delle transazioni e quindi chiuderle al termine. Allo stesso modo, se stai usando un linguaggio orientato agli oggetti come C ++ o Objective C, non liberare un oggetto quando hai finito significherà che il distruttore non verrà mai chiamato e qualsiasi risorsa di cui è responsabile la classe potrebbe non essere ripulita.

Sì, hai ragione, il tuo esempio non fa alcun danno (almeno non sulla maggior parte dei sistemi operativi moderni). Tutta la memoria allocata dal processo verrà recuperata dal sistema operativo una volta terminato il processo.

Fonte: allocazione e GC Myths (avviso PostScript!)

Allocation Myth 4: I programmi non garbage collection dovrebbero sempre deallocare tutta la memoria che allocano.

La verità: le deallocazioni omesse nel codice eseguito di frequente causano crescenti perdite. Sono raramente accettabili. ma i programmi che conservano la maggior parte della memoria allocata fino all'uscita dal programma spesso funzionano meglio senza intervenire sulla deallocazione. Malloc è molto più facile da implementare se non c'è libero.

Nella maggior parte dei casi, la deallocazione della memoria appena prima dell'uscita dal programma è inutile. Il sistema operativo lo rivendicherà comunque. Tocco libero e sfogliare gli oggetti morti; il sistema operativo non lo farà.

Conseguenza: fare attenzione con i "rilevatori di perdite" che contano le allocazioni. Alcune "perdite" sono buone!

Detto questo, dovresti davvero cercare di evitare tutte le perdite di memoria!

Seconda domanda: il tuo design è ok. Se è necessario archiviare qualcosa fino alla chiusura dell'applicazione, è possibile farlo con allocazione dinamica della memoria. Se non si conosce anticipatamente la dimensione richiesta, non è possibile utilizzare la memoria allocata staticamente.

=== Che dire di future prove e riutilizzo del codice ? ===

Se non scrivi il codice per liberare gli oggetti, stai limitando il codice ad essere sicuro da usare solo quando puoi dipendere dalla memoria libera dal processo che si sta chiudendo ... cioè un piccolo uso una tantum progetti o "usa e getta" ^[1] ) ... dove sai quando finirà il processo.

Se fate scrivere il codice che il libero () s tutta la memoria allocata dinamicamente, allora siete prova di futuro il codice e lasciare che gli altri lo usano in un progetto più ampio.

^{[1] per quanto riguarda i progetti "usa e getta". Il codice utilizzato nei progetti "butta via" ha un modo di non essere gettato via. La prossima cosa che sai sono passati dieci anni e il tuo codice "usa e getta" è ancora in uso).}

^{Ho sentito la storia di un ragazzo che ha scritto del codice solo per divertimento per far funzionare meglio il suo hardware. Ha detto " solo un hobby, non sarà grande e professionale ". Anni dopo molte persone usano il suo codice "hobby".}

Hai ragione, non viene fatto alcun danno ed è più veloce uscire

Ci sono diverse ragioni per questo:

• Tutti gli ambienti desktop e server rilasciano semplicemente l'intero spazio di memoria su exit (). Non sono a conoscenza delle strutture di dati interne al programma come gli heap.

• Quasi tutte le free()implementazioni non restituiscono comunque la memoria al sistema operativo.

• Ancora più importante, è una perdita di tempo se fatto subito prima di exit (). All'uscita, le pagine di memoria e lo spazio di swap vengono semplicemente rilasciati. Al contrario, una serie di chiamate free () bruciano il tempo della CPU e possono causare operazioni di paging del disco, errori nella cache e sfratti della cache.

Per quanto riguarda la possibilità di un futuro riutilizzo del codice che giustifica la certezza di operazioni inutili: questa è una considerazione, ma probabilmente non è il modo Agile . YAGNI!

Sono completamente in disaccordo con tutti coloro che affermano che OP è corretto o che non vi è alcun danno.

Tutti parlano di un sistema operativo moderno e / o legacy.

Ma cosa succede se mi trovo in un ambiente in cui semplicemente non ho un sistema operativo? Dove non c'è niente?

Immagina ora di utilizzare interrupt in stile thread e di allocare memoria. Nella norma C ISO / IEC: 9899 è la durata della memoria dichiarata come:

7.20.3 Funzioni di gestione della memoria

1 L'ordine e la contiguità della memoria allocata dalle chiamate successive alle funzioni calloc, malloc e realloc non sono specificate. Il puntatore restituito se l'allocazione ha esito positivo è opportunamente allineato in modo che possa essere assegnato a un puntatore a qualsiasi tipo di oggetto e quindi utilizzato per accedere a tale oggetto o ad una matrice di tali oggetti nello spazio allocato (fino a quando lo spazio non viene esplicitamente deallocato) . La durata di un oggetto allocato si estende dall'allocazione fino alla deallocazione. [...]

Quindi non si deve dare per scontato che l'ambiente stia facendo il lavoro di liberazione per te. Altrimenti verrebbe aggiunto all'ultima frase: "O fino al termine del programma."

Quindi, in altre parole: non liberare memoria non è solo una cattiva pratica. Produce codice non portatile e non conforme a C. Che può almeno essere visto come "corretto, se quanto segue: [...], è supportato dall'ambiente".

Ma nei casi in cui non hai affatto un sistema operativo, nessuno sta facendo il lavoro per te (so che generalmente non allochi e riallochi la memoria su sistemi incorporati, ma ci sono casi in cui potresti volerlo.)

Quindi parlando in generale C (come quello che l'OP è etichettato), questo sta semplicemente producendo un codice errato e non portatile.

In genere, libero ogni blocco allocato una volta che sono sicuro di averlo fatto. Oggi, il punto di ingresso del mio programma potrebbe essere main(int argc, char *argv[]), ma domani potrebbe essere foo_entry_point(char **args, struct foo *f)e digitato come puntatore a funzione.

Quindi, se ciò accade, ora ho una perdita.

Per quanto riguarda la tua seconda domanda, se il mio programma prendesse input come a = 5, assegnerei lo spazio per a, o riassegnerei lo stesso spazio su un successivo "= pippo". Ciò rimarrebbe assegnato fino a quando:

1. L'utente ha digitato 'unset a'
2. La mia funzione di pulizia è stata inserita, eseguendo la manutenzione di un segnale o digitando "esci" dall'utente

Non riesco a pensare a nessun sistema operativo moderno che non recupera memoria dopo la chiusura di un processo. Poi di nuovo, free () è economico, perché non ripulire? Come altri hanno già detto, strumenti come valgrind sono ottimi per individuare le perdite di cui devi davvero preoccuparti. Anche se i blocchi che tu esempio verrebbero etichettati come 'ancora raggiungibili', è solo un rumore extra nell'output quando stai cercando di assicurarti di non avere perdite.

Un altro mito è " Se è in main (), non devo liberarlo ", questo non è corretto. Considera quanto segue:

char *t;

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

Se ciò è avvenuto prima del biforcazione / demonizzazione (e in teoria in esecuzione per sempre), il tuo programma ha appena trapelato una dimensione indeterminata di t 255 volte.

Un buon programma ben scritto dovrebbe sempre ripulire dopo se stesso. Liberare tutta la memoria, svuotare tutti i file, chiudere tutti i descrittori, scollegare tutti i file temporanei, ecc. Questa funzione di pulizia dovrebbe essere raggiunta al termine normale o alla ricezione di vari tipi di segnali fatali, a meno che non si desideri lasciare alcuni file in posa in modo da poter rilevare un arresto anomalo e riprendere.

Davvero, sii gentile con la povera anima che deve mantenere la tua roba quando passi ad altre cose .. consegnala a loro 'valgrind clean' :)

Va completamente bene lasciare la memoria libera quando si esce; malloc () alloca la memoria dall'area di memoria chiamata "heap" e l'heap completo di un processo viene liberato quando il processo termina.

Detto questo, uno dei motivi per cui le persone insistono ancora sul fatto che è bene liberare tutto prima di uscire è che i debugger di memoria (ad esempio valgrind su Linux) rilevano i blocchi non ordinati come perdite di memoria, e se hai anche perdite di memoria "reali", diventa più difficile individuarli se si ottengono anche risultati "falsi" alla fine.

Se stai usando la memoria che hai allocato, non stai facendo nulla di male. Diventa un problema quando si scrivono funzioni (diverse da quelle principali) che allocano la memoria senza liberarla e senza renderla disponibile al resto del programma. Quindi il programma continua a funzionare con quella memoria allocata, ma non è possibile utilizzarlo. Il tuo programma e altri programmi in esecuzione sono privati ​​di quella memoria.

Modifica: non è preciso al 100% affermare che altri programmi in esecuzione siano privati ​​di quella memoria. Il sistema operativo può sempre lasciarlo utilizzare a spese dello scambio del programma nella memoria virtuale ( </handwaving>). Il punto è, tuttavia, che se il programma libera la memoria che non utilizza, è meno probabile che uno scambio di memoria virtuale sia necessario.

Questo codice di solito funziona bene, ma considera il problema del riutilizzo del codice.

È possibile che tu abbia scritto un frammento di codice che non libera la memoria allocata, ma viene eseguito in modo tale da recuperare automaticamente la memoria. Sembra tutto a posto.

Quindi qualcun altro copia il tuo frammento nel suo progetto in modo che venga eseguito mille volte al secondo. Quella persona ora ha un'enorme perdita di memoria nel suo programma. Non molto buono in generale, di solito fatale per un'applicazione server.

Il riutilizzo del codice è tipico nelle aziende. Di solito la società possiede tutto il codice che i suoi dipendenti producono e ogni dipartimento può riutilizzare qualunque cosa la società possieda. Quindi, scrivendo un codice "dall'aspetto innocente", potresti causare mal di testa ad altre persone. Questo potrebbe farti licenziare.

Qual è il vero risultato qui?

Il tuo programma ha fatto trapelare la memoria. A seconda del sistema operativo in uso, potrebbe essere stato ripristinato.

La maggior parte dei moderni sistemi operativi desktop lo fanno recuperare memoria persa a terminazione dei processi, il che rende tristemente comune a ignorare il problema, come si può vedere da molte altre risposte qui.)

Ma stai facendo affidamento su una funzionalità di sicurezza su cui non dovresti fare affidamento e il tuo programma (o funzione) potrebbe essere eseguito su un sistema in cui questo comportamento provoca una perdita di memoria "difficile", la prossima volta.

Potrebbe essere in esecuzione in modalità kernel o su sistemi operativi vintage / incorporati che non utilizzano la protezione della memoria come compromesso. (Le MMU occupano spazio, la protezione della memoria costa ulteriori cicli della CPU e non è troppo chiedere a un programmatore di ripulire dopo se stesso).

Puoi usare e riutilizzare la memoria come preferisci, ma assicurati di aver deallocato tutte le risorse prima di uscire.

In realtà c'è una sezione nel libro di testo online OSTEP per un corso di laurea in sistemi operativi che discute esattamente la tua domanda.

La sezione pertinente è "Dimenticare la memoria libera" nel capitolo API di memoria a pagina 6 che fornisce la seguente spiegazione:

In alcuni casi, può sembrare ragionevole non chiamare free (). Ad esempio, il tuo programma è di breve durata e presto uscirà; in questo caso, quando il processo termina, il sistema operativo pulirà tutte le pagine allocate e quindi non si verificherà alcuna perdita di memoria. Mentre questo sicuramente "funziona" (vedi il lato a pagina 7), è probabilmente una cattiva abitudine da sviluppare, quindi diffidare di scegliere una tale strategia

Questo estratto è nel contesto dell'introduzione del concetto di memoria virtuale. Fondamentalmente a questo punto del libro, gli autori spiegano che uno degli obiettivi di un sistema operativo è "virtualizzare la memoria", ovvero lasciare che ogni programma creda di avere accesso a uno spazio di indirizzi di memoria molto ampio.

Dietro le quinte, il sistema operativo tradurrà "indirizzi virtuali" che l'utente vede in indirizzi reali che puntano alla memoria fisica.

Tuttavia, la condivisione di risorse come la memoria fisica richiede al sistema operativo di tenere traccia di quali processi la stanno utilizzando. Quindi, se un processo termina, rientra nelle capacità e negli obiettivi di progettazione del sistema operativo recuperare la memoria del processo in modo che possa ridistribuire e condividere la memoria con altri processi.

EDIT: il lato menzionato nell'estratto è copiato di seguito.

A PARTIRE: PERCHÉ NESSUNA MEMORIA È LASCIATA UNA VOLTA DAL VOSTRO PROCESSO

Quando si scrive un programma di breve durata, è possibile allocare spazio utilizzando malloc(). Il programma funziona e sta per essere completato: è necessario chiamare free()un sacco di volte prima di uscire? Anche se sembra sbagliato non farlo, nessun ricordo sarà "perso" in alcun senso reale. Il motivo è semplice: ci sono davvero due livelli di gestione della memoria nel sistema. Il primo livello di gestione della memoria viene eseguito dal sistema operativo, che distribuisce la memoria ai processi quando vengono eseguiti e la riprende quando i processi terminano (o altrimenti muoiono). Il secondo livello di gestione è all'interno di ciascun processo, ad esempio all'interno dell'heap quando si chiama malloc()efree() . Anche se non riesci a chiamarefree()(e quindi perdita di memoria nell'heap), il sistema operativo recupererà tutta la memoria del processo (comprese quelle pagine per codice, stack e, come pertinente qui, heap) al termine dell'esecuzione del programma. Indipendentemente dallo stato del tuo heap nel tuo spazio degli indirizzi, il sistema operativo riprende tutte quelle pagine quando il processo termina, assicurando così che nessuna memoria vada persa nonostante il fatto che non l'hai liberata.

Pertanto, per i programmi di breve durata, la perdita di memoria spesso non causa problemi operativi (sebbene possa essere considerata una forma scadente). Quando si scrive un server a esecuzione prolungata (come un server Web o un sistema di gestione del database, che non si chiude mai), la perdita di memoria è un problema molto più grande e alla fine porta a un arresto anomalo quando l'applicazione esaurisce la memoria. E, naturalmente, la perdita di memoria è un problema ancora più grande all'interno di un particolare programma: il sistema operativo stesso. Ci mostra ancora una volta: coloro che scrivono il codice del kernel hanno il lavoro più duro di tutti ...

dalla pagina 7 del capitolo API di memoria di

Sistemi operativi: tre pezzi facili
Remzi H. Arpaci-Dusseau e Andrea C. Arpaci-Dusseau Libri Arpaci-Dusseau Marzo 2015 (Versione 0.90)

Non c'è nessun vero pericolo nel non liberare le variabili, ma se si assegna un puntatore a un blocco di memoria a un diverso blocco di memoria senza liberare il primo blocco, il primo blocco non è più accessibile ma occupa ancora spazio. Questo è ciò che viene chiamato perdita di memoria e, se lo fai con regolarità, il tuo processo inizierà a consumare sempre più memoria, togliendo risorse di sistema da altri processi.

Se il processo è di breve durata, è spesso possibile evitarlo, poiché al termine del processo tutta la memoria allocata viene recuperata dal sistema operativo, ma consiglio di prendere l'abitudine di liberare tutta la memoria per la quale non è più necessario.

Hai assolutamente ragione sotto questo aspetto. Nei piccoli programmi banali in cui una variabile deve esistere fino alla morte del programma, non vi è alcun reale vantaggio nel deallocare la memoria.

In effetti, una volta ero stato coinvolto in un progetto in cui ogni esecuzione del programma era molto complessa ma relativamente di breve durata, e la decisione era quella di mantenere la memoria allocata e non destabilizzare il progetto commettendo errori nel collocarlo.

Detto questo, nella maggior parte dei programmi questa non è davvero un'opzione, o può portare a rimanere senza memoria.

Hai ragione, la memoria viene automaticamente liberata quando termina il processo. Alcune persone si sforzano di non eseguire una pulizia approfondita al termine del processo, poiché verrà abbandonato al sistema operativo. Tuttavia, mentre il programma è in esecuzione, è necessario liberare memoria inutilizzata. In caso contrario, alla fine potresti esaurire o causare un paging eccessivo se il tuo set di lavoro diventa troppo grande.

Se stai sviluppando un'applicazione da zero, puoi fare alcune scelte istruite su quando chiamare gratuitamente. Il tuo programma di esempio va bene: alloca memoria, forse hai un po 'di lavoro per qualche secondo, quindi si chiude, liberando tutte le risorse che ha rivendicato.

Se stai scrivendo qualcos'altro, però: un server / un'applicazione a esecuzione prolungata o una libreria che verrà utilizzata da qualcun altro, dovresti aspettarti di chiamare gratuitamente su tutto ciò che malloc.

Ignorando il lato pragmatico per un secondo, è molto più sicuro seguire un approccio più rigoroso e forzarti a liberare tutto ciò che mali. Se non hai l'abitudine di cercare perdite di memoria ogni volta che scrivi un codice, potresti facilmente generare qualche perdita. Quindi, in altre parole, sì: puoi scappare senza di essa; per favore stai attento, però.

Se un programma dimentica di liberare qualche Megabyte prima di uscire, il sistema operativo li libererà. Ma se il tuo programma viene eseguito per settimane alla volta e un ciclo all'interno del programma dimentica di liberare pochi byte in ogni iterazione, avrai una potente perdita di memoria che consumerà tutta la memoria disponibile nel tuo computer a meno che non lo riavvii regolarmente base => anche piccole perdite di memoria potrebbero essere dannose se il programma viene utilizzato per un'attività seriamente grande anche se in origine non era progettato per uno.

Penso che i tuoi due esempi siano in realtà solo uno: free()dovrebbero accadere solo alla fine del processo, che come fai notare è inutile poiché il processo sta terminando.

Nel secondo esempio, tuttavia, l'unica differenza è che si consente un numero indefinito di malloc(), che potrebbe portare all'esaurimento della memoria. L'unico modo per gestire la situazione è controllare il codice di ritorno malloc()e agire di conseguenza.