Newsgroup: it.comp.lang.c++
Titolo: Domanda sui memory leak

Ciao,
vorrei chiedervi:se per sbaglio in un programma si viene a creare un memory 
leak,la memoria non più raggiungibile che si è venuta a creare viene 
liberata alla fine del programma che l'ha generata oppure permane anche dopo 
la fine di esso? 

Iuzo wrote:

Nei nuovi e moderni sistemi operativi, quali linux, windows, ecc...se si
verifica una cosa del genere, viene automaticamente liberata, o meglio,
recuperata dal sistema operativo...

 ha scritto nel messaggio 
news:442fd4cb$0$29730$4faf...@reader2.news.tin.it...

Credo dipenda esclusivamente dal sistema operativo.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 Credo dipenda esclusivamente dal sistema operativo.
Non dimentichiamoci però che il "C++ run-time system" solitamente 
utilizza un heap per allocare i dati.
Kiuhnm


E quindi?
Non ho capito questo cosa c'entra!

 Non ho capito questo cosa c'entra!
Ehi, non ti alterare :)
Anche se il sistema operativo non recuperasse la memoria non restituita, 
lo farebbe comunque il CRT distruggendo l'heap.
In caso di crash invece sarebbe necessario l'intervento dell'OS.
Kiuhnm

 In caso di crash invece sarebbe necessario l'intervento dell'OS.
In un sistema operativo moderno è sempre e comunque necessario 
l'intervento dell'OS.
La questione riguarda la definizione stessa di memoria che se 
all'applicativo (incluso il CRT) appare come uno spazio lineare, in 
realtà è un insieme di pagine virtuali e di strutture per la loro gestione.
All'uscita del processo il SO si occupa di disallocare tutte le risorse 
dinamiche allocate dallo stesso (anche quelle non allocate DAL processo 
ma semplicemente PER il processo).
Questo include memoria, file handles, sockets e vari altri "oggetti" 
gestiti dal sistema operativo.
L'unica cosa che non viene "deallocata" sono risorse statiche create dal 
programma (per esempio i file che il processo ha creato non vengono 
cancellati, anche se eventuali handle a quei file vengono disallocati e 
pertanto i file stessi vengono, a tutti gli effetti, chiusi).

 pertanto i file stessi vengono, a tutti gli effetti, chiusi).
Stai facendo confusione. Il sistema operativo, in assenza di bug, 
distrugge ciò che crea, quando opportuno.
Le strutture di cui parli vengono create implicitamente dal sistema 
operativo quindi sono sotto la sua responsabilità.
La questione si pone se invece (vedi post iniziale) le chiamate a 
funzioni di allocazione/deallocazione di risorse sono spaiate.
Un sistema operativo potrebbe pretendere questo tipo di 
disciplina/correttezza da parte delle applicazioni.
Detto questo, ho semplicemente fatto notare che, anche qualora il codice 
utente sia errato, il CRT, facendo da intermediario, pone rimedio e 
quindi, in assenza di crash, non è necessario l'intervento straordinario 
dell'OS.
Kiuhnm

 disciplina/correttezza da parte delle applicazioni.
Non so nell'embedded, ma per il resto mi sembra che oggi nessun S.O. parta
dal presupposto che i programmi siano scritti "bene". Si va "addirittura"
sempre di più a S.O. che controllano anche i parametri delle chiamate alle
funzioni di sistema (un tempo per questione di prestazioni c'erano S.O. che
non controllavano la validità dei parametri).

 dal presupposto che i programmi siano scritti "bene".
Allo stesso modo, nessuno stato parte dal presupposto che i cittadini 
non rubino eppure chi ruba viene punito.
Il sistema deve essere il più possibile fault-tolerant, però non deve 
incentivare un comportamento indisciplinato.
In pratica ogni sistema operativo gestisce correttamente i leak di 
memoria. Non ho contraddetto questo. Ho aggiunto che tali leak (in 
mancaza di crash) vengono addirittura gestiti dal CRT quindi ci sono due 
barriere di difesa: CRT e OS.
Kiuhnm

 memoria.
Ovviamente non stiamo parlando dei vari windows a 16 bit, e anche sui vari
windows a 32 bit non c'č un vero controllo dei parametri nelle chiamate a
funzioni del S.O.
Poi il run-time dei VC e MFC, almeno fino al 6 e secondo i tool della
NuMega perdevano loro stessi memoria che era un piacere. Oggi non uso piů i
tool della NuMega, quindi non lo so.
Detto ciň mi sembra che i processori stessi stiano andando in una direzione
tale da distinguere in modo sempre piů netto le parti di memoria che
contegono istruzioni eseguibili e quelle no. Ovvero mi sembra (sono
ignorante in materia, quindi uso il "mi sembra") che si vada sempre di piů
ad un insieme CPU - S.O che parta dal presupposto che l'ambiente č ostile.
Tipo le console, in cui prima si verifica che i programmi siano
certificati, e solo poi si eseguono.
Ovviamente so benissimo che non sto contestando niente di quello che hai
detto. Avevo solo voglio di scrivere due righe tra una compilazione e
l'altra.
Ciao

 l'altra.
Allora aggiungo anche che, purtroppo, i processori con architettura 
Intel/Amd non permettono un pieno controllo sul codice eseguito dalle 
applicazioni. L'unica garanzia è che operazioni invalide non hanno 
successo, ma il sistema operativo potrebbe non esserne informato. Questo 
è uno dei più gravi problemi che affronta chi deve scrivere una macchina 
virtuale su un comune PC o virtualizzare l'ambiente nel quale opera un 
programma ostile.
Kiuhnm

 applicazioni.
Quindi ne deduco che quando Intel strombazza le future estensioni per
migliorare la virtualizzazione, in realtà, parla semplicemente di allineare
l'architettura x86 a quello che altre CPU fanno da decenni.
Il punto critico è che l'architettura x86 è incredibilmente diffusa. Fatta
bene o fatta male che sia, è un realtà con cui fare sempre i conti. Da
qualche anno mi sembra che anche i produttori di super computer se ne sono
accorti (leggi qualcuno è fallito), visto che un cluster di ferraglia x86
può costare un paio di ordini di grandezza in meno a parità di potenza
elaborativa.

 elaborativa.
Si deve ringraziare anche la nascita di metodi sempre più efficienti per 
risolvere i problemi in parallelo. In teoria, la potenza di processori 
che lavorano in parallelo non si può sempre sommare perché alcuni 
processori potrebbero dover aspettare i risultati calcolati da altri 
processori.
Kiuhnm