[C] free()

[Oceans11]

In un recente thread ho scritto:

Sono memory leak innocui per programmi tipo questo che non è un demone ne un server. Ricordo che all'uscita del programma si occupa il s.o. di liberare la memoria allocata.

Innanzitutto ho scoperto che non tutti i S/O si preoccupano di liberare la memoria allocata dai programmi (ma quali sono lo ignoro)
Poi, siccome l'argomento mi sembra interessante e io sono tutt'altro che bravo nello spiegarmi nonchè autorevole, volevo linkare questi due articoli che trattano l'argomento.

articolo #1
articolo #2

Senza far partire flame, mi piacerebbe conoscere l'opinione dei più "navigati" e non, l'importante sono le motivazioni della scelta.

Ciao

[Daniels118]

Io la vedo in questo modo: bisogna sempre essere precisi.
Che il sistema operativo in uso liberi la memoria o meno, bisogna sempre liberare ciò che si è allocato. E' una pratica che aiuta ad assumere quest'atteggiamento sempre, così si evita di "dimenticarsi" quando ce n'è veramente bisogno.

Poi, che il SO debba liberare la memoria è un dovere: il SO è uno, i programmi sono tanti, ne nasce uno nuovo ogni giorno, è matematico che i programmi abbiano qualche bug. I sistemi operativi hanno una vita molto lunga e tanto tempo per migliorarsi: se il SO può risolvere un problema comune deve farlo. Se non lo fa e devo implementare tutto io, tanto vale fare a meno del sistema operativo (ovviamente questa è un'esagerazione, ma è giusto per rendere l'idea).

[Oceans11]

Originariamente inviato da Daniels118

Io la vedo in questo modo: bisogna sempre essere precisi.
Che il sistema operativo in uso liberi la memoria o meno, bisogna sempre liberare ciò che si è allocato. E' una pratica che aiuta ad assumere quest'atteggiamento sempre, così si evita di "dimenticarsi" quando ce n'è veramente bisogno.

porsi il problema basterebbe come atteggiamento, no?
così si evitano chiamate a funzioni inutili (quando a breve il programma termina) e il rischio di chiamare la free() su, ad esempio, un puntatore a memoria già liberata, causando gravi problemi.

Originariamente inviato da Daniels118

Poi, che il SO debba liberare la memoria è un dovere: il SO è uno, i programmi sono tanti, ne nasce uno nuovo ogni giorno, è matematico che i programmi abbiano qualche bug. I sistemi operativi hanno una vita molto lunga e tanto tempo per migliorarsi: se il SO può risolvere un problema comune deve farlo. Se non lo fa e devo implementare tutto io, tanto vale fare a meno del sistema operativo (ovviamente questa è un'esagerazione, ma è giusto per rendere l'idea).

tanto vale fare a meno di "quel" sistema operativo, non è affatto un'esagerazione. Un bug del sistema operativo è molto più grave di un bug di un programma.

ps: grazie per aver detto la tua.

[sottovento]

Originariamente inviato da Oceans11

Innanzitutto ho scoperto che non tutti i S/O si preoccupano di liberare la memoria allocata dai programmi (ma quali sono lo ignoro)

Fra quelli che conosco, VxWorks, pSOS+, VMEExec. Tutti a seconda della configurazione e del tipo di allocazione che vai a fare.
Nei sistemi embedded non e' poi cosi' strano, e questo non significa che il sistema operativo non sia utile, anzi.

Originariamente inviato da Oceans11

Ciao

Ciao

[Oceans11]

Originariamente inviato da sottovento

Fra quelli che conosco, VxWorks, pSOS+, VMEExec. Tutti a seconda della configurazione e del tipo di allocazione che vai a fare.
Nei sistemi embedded non e' poi cosi' strano, e questo non significa che il sistema operativo non sia utile, anzi.

ecco i sistemi embedded non li stavo proprio a considerare.
Ma a pensarci su ora, bisognerebbe vedere se si hanno a disposizione tali funzioni di allocazione dinamica, no? (non so nulla a riguardo)
Non ho capito "il tipo di allocazione che vai a fare", (sto supponendo che l'heap sia comunque disponibile)

[sottovento]

Originariamente inviato da Oceans11

ecco i sistemi embedded non li stavo proprio a considerare.
Ma a pensarci su ora, bisognerebbe vedere se si hanno a disposizione tali funzioni di allocazione dinamica, no? (non so nulla a riguardo)
Non ho capito "il tipo di allocazione che vai a fare", (sto supponendo che l'heap sia comunque disponibile)

VxWorks puo' girare su CPU senza MMU, ed i "processi" condividono le aree globali. Addirittura le variabili globali! Pertanto si puo' dichiarare una variabile in un "processo" ed utilizzarla in un altro.
pSOS+, VMEExec possono allocare delle regioni di memoria, con un'API del tipo allocate_region(nome, quantita',....).
Essendo sistemi operativi HARD real-time, le regioni di memoria hanno dimensioni fissate al momento del build del kernel e vengono allocate in first fit. Ne risulta che anche l'allocazione ha tempi deterministici. In altri casi, anche durante l'allocazione della memoria c'e' un time out, allo scadere del quale l'allocazione fallisce.

(Questo e' un ulteriore motivo per arrabbiarsi tanto per il "blind faith" (http://en.wikipedia.org/wiki/Blind_f...rogramming%29). Il 90% degli esempi fatti nelle scuole di tutti i livelli danno sempre per scontato che l'allocazione vada bene, provocando la mia ira )

Una volta create, le regioni sono visibili a tutti e le si possono identificare tramite il nome assegnato.

Un altro "trucco" che che viene (veniva?) spesso usato con questi sistemi, specialmente in ambito VME era quello di inserire una scheda di memoria sul bus (VME appunto) e di "smapparla" dal sistema operativo. In questo modo l'area di memoria in questione risulta non gestito da nessun sistema operativo/CPU che si affaccia sul bus.
Essendo l'indirizzo noto, l'area di memoria viene spesso usata come "database di processo"

[Oceans11]

Originariamente inviato da sottovento

VxWorks puo' girare su CPU senza MMU, ed i "processi" condividono le aree globali. Addirittura le variabili globali! Pertanto si puo' dichiarare una variabile in un "processo" ed utilizzarla in un altro.

sarà meglio che ci lavori su una singola persona allora
potente, ma immagino i bordelli

Originariamente inviato da sottovento

(Questo e' un ulteriore motivo per arrabbiarsi tanto per il "blind faith" (http://en.wikipedia.org/wiki/Blind_f...rogramming%29). Il 90% degli esempi fatti nelle scuole di tutti i livelli danno sempre per scontato che l'allocazione vada bene, provocando la mia ira )

dalla malloc(3) man page:

NOTES
By default, Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no guarantee
that the memory really is available.

lo so bene e poi "optimistic" dice tutto

tutto il resto è molto interessante, ma non riesco ad apprezzare a pieno per colpa di mancanza di conoscenze.

[sottovento]

Il tuo post mi ha fatto sollevare un sopracciglio. Mi riferivo semplicemente al controllo del ritorno a NULL nel caso della malloc() o alla gestione dell'eccezione std::bad_alloc per la new.

Sono andato a controllare, ed in effetti hai ragione. Pero' in una versione delle man pages presenti in rete c'era scritto:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer. In case Linux is employed under circumstances where it would be less desirable to suddenly lose some randomly picked processes, and moreover the kernel version is sufficiently recent, one can switch off this overcommitting behavior using a command like:
...

sembrerebbe un bug, dunque. E la cosa spaventa parecchio.
Non mi riferivo certamente a questo, ma al piu' classico dei blind faith: per esempio, se apri uno qualsiasi dei thread di questa pagina che parla di liste linkate, vedrai malloc() dappertutto senza che ci sia mai un controllo che la funzione abbia avuto successo.

Quello che hai trovato h una portata ben diversa e non ne so assolutamente nulla!
Ne sai qualcosa di piu? Qualcun altro ne sa di piu'?
Come faccio ad esser veramente sicuro che l'allocazione sia andata a buon fine?

[Daniels118]

Diciamo che i programmi che vedi in giro sul forum servono più che altro per dimostrare il funzionamento delle strutture dati astratte, che la gestione delle eccezioni. Comunque questo bug è disarmante, non ci sono parole...

[sottovento]

Originariamente inviato da Daniels118

Diciamo che i programmi che vedi in giro sul forum servono più che altro per dimostrare il funzionamento delle strutture dati astratte, che la gestione delle eccezioni. Comunque questo bug è disarmante, non ci sono parole...

Hai ragione. E' cosi' disarmante che non mi sembra vero.
Anzi, cosi' disarmante che non posso credere che sia caratteristico di Linux e nessuno abbia mai detto o fatto nulla!
Immagino che, nonostante quanto le man dicano, se un simile bug esiste non puo' che essere presente solo in alcune distribuzioni, o versioni delle stesse. Altrimenti non avrebbe senso usarlo, no?
Penso che sia necessario approfondire il problema...

Per quanto riguarda i programmi sul forum: hai ragione un'altra volta.
Tuttavia, penso che sia necessario che i docenti non si limitino a spiegare la parte algoritmica, quella "importante", ma che si debba chiarire che un'applicazione e' considerata non funzionante anche se mancano questi dettagli, che di teorico non hanno nulla, ma che sono vitali per il corretto e robusto funzionamento.

[Oceans11]

Originariamente inviato da sottovento

Il tuo post mi ha fatto sollevare un sopracciglio. Mi riferivo semplicemente al controllo del ritorno a NULL nel caso della malloc() o alla gestione dell'eccezione std::bad_alloc per la new.

Sono andato a controllare, ed in effetti hai ragione. Pero' in una versione delle man pages presenti in rete c'era scritto:


sembrerebbe un bug, dunque. E la cosa spaventa parecchio.
Non mi riferivo certamente a questo, ma al piu' classico dei blind faith: per esempio, se apri uno qualsiasi dei thread di questa pagina che parla di liste linkate, vedrai malloc() dappertutto senza che ci sia mai un controllo che la funzione abbia avuto successo.

Quello che hai trovato h una portata ben diversa e non ne so assolutamente nulla!
Ne sai qualcosa di piu? Qualcun altro ne sa di piu'?
Come faccio ad esser veramente sicuro che l'allocazione sia andata a buon fine?

Non volevo far agitare il tuo sopracciglio.
Non so perchè ho pensato subito alla allocazione fallita piuttosto che al fallimento della chiamata a funzione.

Ad ogni modo, leggo che optimistic sta a causa della strategia di overcommit dei processi ossia i processi chiedono al s/o più memoria di quanta gliene potrebbe effettivamente servire.

Dalla documentazione del kernel Documentation/vm/overcommit-accounting:

obvious overcommits of address space are refused

Ma se serve più memoria ecco che viene lanciato l' OOM killer (Out-Of-Memory).
Capisco che crollino le certezze di un utente che rischia di vedere il suo processo ammazzato di punto in bianco secondo chissà quali strane euristiche (da qualche parte ho letto infatti che non viene necessariamente killato un processo pieno zeppo di memory leak) ma stiamo parlando di un qualcosa che non deve accadere tutti i giorni.

Voglio far notare che la swap è considerata (in quest'ambito) memoria.
Quindi ce ne passa (almeno in ambito desktop) prima di occupare tutta la ram e tutta la swap per finire OOM.

Nell'89, quando il mio nuovissimo pc aveva 1MB di ram, forse il problema era maggiormente pressante per i programmatori

[Oceans11]

Nel frattempo ho trovato questo articolo. Quoto la parte relativa ai sistemi embedded.

Low Memory in Embedded Systems
The Android developers required a greater degree of control over the low memory situation because the OOM killer does not kick in till late in the low memory situation, i.e. till all the cache is emptied. Android wanted a solution which would start early while the free memory is being depleted. So they introduced the "lowmemory" driver, which has multiple thresholds of low memory. In a low-memory situation, when the first thresholds are met, background processes are notified of the problem. They do not exit, but, instead, save their state. This affects the latency when switching applications, because the application has to reload on activation. On further pressure, the lowmemory killer kills the non-critical background processes whose state had been saved in the previous threshold and, finally, the foreground applications.

Keeping multiple low memory triggers gives the processes enough time to free memory from their caches because in an OOM situation, user-space processes may not be able to run at all. All it takes is a single allocation from the kernel's internal structures, or a page fault to make the system run out of memory. An earlier notification of a low-memory situation could avoid the OOM situation with a little help from the user space applications which respond to low memory notifications.

Killing processes based on kernel heuristics is not an optimal solution, and these new initiatives of offering better control to the user in selecting the process to be the sacrificial lamb are steps to a robust design to give more control to the user. However, it may take some time to come to a consensus on a final control solution.

[sottovento]

Originariamente inviato da Oceans11

Nel frattempo ho trovato questo articolo. Quoto la parte relativa ai sistemi embedded.

Wow! E' davvero interessante. Grazie per le info, cerchero' di approfondire il problema

[Oceans11]

Stavo facendo qualche prova per vedere il comportamento e le soglie sul mio sistema:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define SIZE (10*1024*1024)

int main() {
	int i = 0;
	printf("page size=%d\n", getpagesize());
	while(1) {
		char *mem = malloc(SIZE);
		printf("\rAllocation #%d", ++i);
		if(mem == NULL) {
			printf("Out of memory.\n");
			fflush(stdout);
			exit(1);
		}
	}
	
	return 0;
}

kernel: 3.12.8 SMP PREEMPT x86_64
swap: disabled
Memory: 7872048K/8082980K available (5116K kernel code, 807K rwdata, 1628K rodata, 1144K init, 1288K bss, 210932K reserved)
/proc/sys/vm/overcommit_ratio = 50
/proc/sys/vm/overcommit_memory = 0

Mi aspettavo di vedere crashare il sistema (overcommit_memory a 0)
mentre invece il programma termina correttamente (intendo dire che mem == NULL)
allora aggiungo il contatore per vedere quanta memoria alloca prima di terminare: si ferma a 65515! sempre a 65515.
Infine aggiungo la chiamata a getpagesize(), non sicuro di quanto siano grandi le pagine per un 64bit: 4k è il risultato.

Assolutamente strano!
Facendo un paio di conti a braccio, ho circa 7.5GB di memoria disponibile in userspace, allocando 10 MB alla volta mi aspettavo di terminare la memoria in 750 chiamate a malloc, senza considerare l'overcommit.
Con quest'ultimo, essendo la ratio a 50, dovrebbe terminare a total_memory+total_memory*0.5+swap_space = 7.5+3.7+0 = 11GB circa, quindi circa 1100 chiamate.
Stranamente, cambiando SIZE il risultato è sempre 65515.
E tanto per togliermi i dubbi sulla page size, 65515 * 4k fa tipo 256MB, non diversi GB.

Qualcuno mi dice dove sbaglio a fare i conti?
O del perchè il programma non sembra mostare il comportamento dichiarato nelle pagine di manuale di malloc?

[bancodeipugni]

in effetti malloc() come open() e fopen() andrebbe sempre controllata a scanso di cantonate oltre che castata (castata, non castrata )

[Oceans11]

Originariamente inviato da bancodeipugni

in effetti malloc() come open() e fopen() andrebbe sempre controllata a scanso di cantonate oltre che castata (castata, non castrata )

No, castare mai!
link

[bancodeipugni]

castare malloc intendo non open

[Oceans11]

Originariamente inviato da bancodeipugni

castare malloc intendo non open

anch'io intendo malloc. Hai visto il link che ho postato?

[Oceans11]

Originariamente inviato da Antonio23

la spiegazione data in quel link è praticamente senza senso..

per amore della chiarezza: link

[Oceans11]

non ricordarsi di importare stdlib.h non mi sembra meno grave del credere che si stia programmando in C quando la realtà è diversa.
_Personalmente_ non vedo perchè aggiungere codice inutile (il cast) e che oltretutto rende lo stesso meno leggibile.
Poi questi sono gusti.

Sulla free e sul fallimento della malloc che mi dite?