
Domanda uno : cosa è un memory leak?
Un memory leak non è altro che un uso “illegale” della memoria di sistema : quando un’applicazione viene mandata in esecuzione, il sistema alloca ( = occupa) una porzione di memoria per la sua esecuzione. Quando viene terminata, invece, il sistema stesso dealloca ( = rilascia ) la stessa porzione di memoria. Ci sono casi in cui, però, il sistema e l’applicazione – per qualche ragione – non riescono a comunicare correttamente… e lo stesso sistema non sa che l’applicazione è terminata, di conseguenza tiene allocata memoria inutilmente. E questo stato viene definito in gergo memory leak.
Ovviamente, se la stessa applicazione viene ripetutamente invocata si presenteranno memory leaks in abbondanza : prima o poi la memoria finirà, e il tutto terminerà con un bellissimo crash di sistema.
Immaginiamo ora di avere un demone…anzi no, nel nostro caso, un server. Supponiamo che qualche subroutine (un “sottoprogramma” chiamato dal nostro programma server) di questo sia buggata, e che questo bug provochi un memory leak. Supponiamo ancora che questa subroutine, durante una sessione, non venga invocata una sola volta…ma ripetutamente : il tutto finirà, prima o poi, in un bellissimo freeze.
La situazione di X.org, in Ubuntu 10.04 LL, è esattamente questa : una delle sue subroutines, a causa degli effetti collaterali di alcune patches applicate per aumentare il supporto di X a GLX 1.4 ed evitare il crash di alcune applicazioni, è soggetta a memory leaks continui. Il bug che provoca il memory leak è stato definito “GEM object not deallocated” (GEM sta per graphics execution manager) sulla segnalazione bugs di launchpad. Tutto ciò, giustamente, preoccupa tantissimo gli sviluppatori : fare rollback significherebbe o rendere compatibile X.Org con GLX 1.2 , o andare fuori dalla deadline. Si sta pensando di rilasciare una SRU (stable release update) poco dopo il rilascio della versione definitiva di Ubuntu 10.04 LL.
Vedremo come andrà a finire…
Commenti Lasciati