Il 'baco' della Malloc

...il programma funzionava perfettamente finche' non ho aggiunto l'istruzione
int i=0;
A questo punto continua a segnalarmi un errore di "access violation", ma non capisco da che puo' dipendere, se rimuovo la dichiarazione sembra tornare tutto a posto...

Chiunque abbia un minimo di esperienza in C/C++ avra' gia' identificato il problema: un bel "puntatore pazzo". Il guaio sta' nel trovare dove e' il maledetto puntatore che sta' sputtanando la memoria del sistema.

Nel 90% dei casi, un simile comportamento e' dovuto al "bug della malloc()", cioe' all'utilizzo di free() su un puntatore che non e' stato ottenuto con malloc().

Per capire come un simile casino si puo' verificare occorre capire come funziona "sotto il coperchio" il meccanismo di gestione della memoria.

Benche' la memoria virtuale riservata al programma sia molto grande (gigabyte), se cerchiamo di utilizzarne una parte direttamente il sistema si incavolera' moltissimo, in generale otterremo un bell'errore di "accesso violation" (dipende dal compilatore e dal sistema Win 95/98/NT/2000...). Questo perche', benche' il nostro programma possa teoricamente accedere a gigabyte di memoria, prima di farlo deve informarne in qualche modo il sistema stesso, che provvedera' ad allocare realmente la memoria.

Il processo quindi e' quello di chiamare una delle funzioni di gestione della memoria malloc() se stiamo lavorando in C, oppure usare new se stiamo lavorando in C++, le due cose non sono poi tanto differenti in quanto (di solito) new e' costruita sopra una malloc().

La malloc() solitamente ottiene un blocco di memoria contigua disponibile e passa il puntatore ottenuto al programma chiamante, il quale fara' quello che vuole con il blocco di memoria e poi utilizzera' la corrispondente funzione free() per "restituire" il blocco di memoria al sistema.

Come viene gestita la memoria dalla malloc? in genere la malloc, internamente, si gestisce un elenco di "blocchi" di memoria disponibili, quando richiediamo un pezzo di memoria la malloc controlla quale e' il blocco sufficientemente grande a contenere il pezzo da noi richiesto, quindi "marca" il blocco come utilizzato nella sua lista interna e ritorna il puntatore al blocco stesso.

Se la malloc non ha nessun blocco sufficientemente grande, richiedera' al sistema un nuovo blocco di memoria che poi gestira' per cavoli suoi.

Questo comportamento (incidentalmente) provoca tutta una serie di problemi: supponiamo di avere un programma del tipo:

char *p = (char*) malloc(1024);

// faccio qualche cosa con p...

free( p );

Questo comporta un ulteriore problema: malloc() deve fornire anche un indirizzo di memoria correttamente allineato, altrimenti l'accesso ad un long di 8 byte produrrebbe un ottimo "invalid hardware address", oppure (nel caso di processori Intel) il programma risulterebbe mostruosamente lento...

#define INCR_STACK 32

int *push( int *stack, int value )
{

  int *nuovoStack;
  int nuovaDim;

  /* verifico se lo stack e' abbastanza grande*/
  if( stack[0] <= stack[1] )
  {
    /* devo ingrandire lo stack */
    nuovaDim = stack[0] + INCR_STACK;
    nuovoStack = (int*) malloc( sizeof(int) * nuovaDim );
    
    /* copio il vecchio stack nel nuovo */
    memcpy( nuovoStack, stack, sizeof(int) * stack[0] );
    nuovoStack[0] = newSize;
    
    /* elimino il vecchio stack */
    /***** OCCHIO!!! ******/
    free( stack );
    
    stack = nuovoStack;
  }

  /* inserisco l'elemento nello stack */  
  stack[ stack[1] + 1 ] = value;
  stack[1]++;
  
  return stack;
}

void faiqualchecosa()
{
  int value;
  int stack[4] = {4,2};
  int i;
  
  value=1024;
  for( i=2; i<4; ++i )
  {
    push( stack, i );
    value++;
  }

}

La banalita' del programma e' sconvolgente, e proprio questo e' il problema.

Per chiunque non fosse riuscito ancora a capire quale e' il problema ecco la soluzione, il programmatore che ha scritto faiqualchecosa() fondamentalmente ha pensato "non mi sembra il caso di allocare dinamicamente qualche cosa quando so gia' di quanti elementi avro' bisogno"...tutto giusto in teoria, in pratica pero' la dichiarazione int stack[4] = (4,2);, crea un array dichiarato di 4 elementi, ma solo due sono usati, quindi l'array stesso e' solo di due elementi.

Il risultato di questo codice e' che la free() tenta di disallocare uno spazio di memoria che non e' stato allocato precedentemente da malloc(), questo fa si' che un blocco di memoria che non è gestito da malloc sia segnalato come "libero", questo potrebbe influenzare il blocco di memoria direttamente prima del nostro "stack", cioe' lo spazio occupato da value, che a questo punto dovrebbe valere piu' di 1024...

Cosa succede esattamente a questo punto dipende molto dal compilatore e dal sistema sui cui il programma e' usato. Nel caso peggiore non succede nulla, perche' il blocco di memoria che viene "sputtanato" non contiene nulla di cruciale per l'esecuzione del programma, questo significa che il nostro programma contiene un potenziale bug che e' li' pronto a demolire la memoria e noi non ce ne siamo accorti, nel caso migliore il programma si inchioda immediatamente alla prima esecuzione segnalando un qualsivoglia errore in un punto completamente diverso del codice, chiaro sintomo che abbiamo un puntatore pazzo a spasso per la memoria del computer...

Una DLL puo' essere fatta con un qualsiasi linguaggio che sia in grado di creare il file binario del formato giusto (VB, Delphi, Pascal, C, C++), e (di solito), puo' essere usata con un compilatore qualsiasi che sia in grado di creare le giuste chiamate al sistema per mappare la DLL nello spazio di indirizzamento del programma e richiamarne le funzioni.

Questo significa che se usate malloc() o free() nella DLL e nel programma, puo' darsi che stiate usando due diverse malloc() e free(). Ora, siccome ogni coppia di malloc()/free() utilizza un suo proprio elenco di blocchi di memoria disponibili per gestire la cosa, se non siete piu' che attenti potete usare la free() sbagliata... cioe' passare un blocco di memoria ad una free() dopo che era stato allocato con un'altra malloc().

Il risultato forse e' peggiore del precedente esempio, perche' prima se non altro avevamo un codice in cui c'era una free() ma nessuna malloc(), ma adesso... magari abbiamo il giusto numero di malloc()/free().

Piu' DLL usate e piu' non le avete scritte voi, piu' aumentano le possibilita' di avere diverse copie di malloc()/free() nel vostro spazio di indirizzi del programma, questo significa che aumentano i problemi.

Una (imperfetta) soluzione e' quella di forzare le DLL ed il vostro programma ad usare il runtime del linguaggio come DLL condivisa invece che includere tutto il runtime nel programma stesso, in questo modo la DLL ed il programma condivideranno lo stesso runtime e vi sara' una sola copia di malloc()/free() in memoria, questo ovviamente se la DLL ed il programma li avete fatti voi.

Cosi' facendo obbligherete l'utente/programmatore a sapere che sta' allocando/disallocando la memoria e gli darete anche una traccia da seguire quando/se il suo programma esplodera' misteriosamente per un bug di questo tipo.

Oppure obbligate l'utente a passarvi un blocco di memoria gia' allocato, cioe' scaricate sull'utente il compito di gestirsi la memoria all'esterno della vostra DLL.

Un altro sistema e' quello di usare HeapAlloc() per allocare la memoria direttamente dall'heap del programma e HeapFree() per rilasciarla, queste sono API di Windows, quindi sara' Windows a gestirsi il lavoro ed eviteremo i problemi dovuti a molteplici copie di malloc()/free().

Purtroppo, bisogna impararlo sulla propria pelle (nel modo peggiore cioe'), che e' sempre possibile avere un bug nascosto nella gestione della memoria, che e' li' che aspetta che noi aggiungiamo quella "stupidissima assegnazione" cioe' quel tanto che basta a spostare l'immagine della memoria in maniera da "sputtanare" parti importanti del codice invece di memoria inutilizzata.

Un tool di controllo consente, nella maggioranza dei casi, di individuare a priori questo tipo di problemi, se non altro consente di "mettere il dito" nel punto giusto del problema, individuando quando la memoria viene sputtanata e da chi.

Questo tipo di tool in genere non sono gratuiti, ve ne sono alcuni free, ma la loro utilita' e' molto inferiore a quella dei tool a pagamento.

Vi assicuro pero' che questo tipo di tool risparmiano parecchie notti insonni ed in generale valgono la spesa.

Questo e' un elenco (senza pretese di completezza) di alcuni tool che sono in grado di rilevare problemi nell'allocazione/gestione della memoria in maniera completamente automatica.

Max length of comments: 1000 chars.

il problema di tradurre il codice dall'inglese...

Add a comment (max 1000 chars)