A static Analyzer for Finding Dynamic Programming Errors

A static Analyzer for Finding Dynamic Programming Errors Possamai Lino, 800509 Analisi e Verifica di Programmi 4 Maggio 2006

Introduzione
Gli errori dinamici di programmazione appartengono alla classe di errori che sono difficili da rilevare sia manualmente che automaticamente
Invalid pointer references
Faulty storage allocation
Uso di memoria non inizializzata
Operazioni improprie sulle risorse
Sono causati nella maggior parte dei casi da interazioni complesse tra componenti del programma. In prodotti commerciali, si stima che sia nell’ordine del 90% degli errori rilevati.

Obiettivi
L’obiettivo principale è stato quello di costruire un tool per l’analisi del codice
che fosse facile da usare come nel caso dei runtime memory debugger, ma che non richieda all’utente di dover eseguire il programma, fornendo quindi i test case,
che riportasse molti degli errori possibili,
che l’informazione fosse ricavata esclusivamente dall’analisi del codice sorgente, senza l’uso di annotazioni
che l’analisi effettuata analizzasse solamente i cammini possibili
che l’informazione prodotta riguardante gli errori rilevati fosse abbastanza esplicativa in modo tale che l’utente capisca velocemente dove si genera l’errore

Architettura di PRE fix
La prima fase consiste nel parsing del codice sorgente in modo tale
da costruire l’AST, determinando, allo stesso tempo, l’ordine di esecuzione delle funzioni.
È una fase molto “pesante” in termini di tempo. Può consumare circa il 20-25% del tempo totale di esecuzione
Bottom up????

Architettura di PRE fix
Per rilevare gli errori inter-procedurali, è necessario simulare l’esecuzione di una funzione su un modello astratto della memoria grazie ad una macchina virtuale.
Lo stato della memoria viene tracciato durante tutta la simulazione delle funzioni, come anche tra gli archi del grafo delle chiamate.
Il compito del simulatore è quello di osservare lo stato della memoria nel modello astratto e di costruisce, alla fine,
un modello di comportamento per la funzione
simulata.

Architettura di PRE fix 3.x – visione d’insieme

Esempio
1 #include <stdlib.h>
2 #include <stdio.h>
3
4 char *f(int size )
5 {
6 char *result;
7
8 if (size > 0)
9 result = (char*)malloc(size);
10 if (size == 1)
11 return NULL;
12 result[0] = 0;
13 return result ;
14 }
La funzione f alloca memoria nello heap e la inizializza (se la dimensione richiesta è maggiore di zero).
Se size=1 , la funzione ritorna NULL.
Negli altri casi, inizializza a zero la variabile result .
In questo caso, PRE fix individua tre warning.

Esempio
1 #include <stdlib.h>
2 #include <stdio.h>
3
4 char *f(int size)
5 {
6 char *result;
7
8 if (size > 0)
9 result = (char*)malloc(size);
10 if (size == 1)
11 return NULL;
12 result[0] = 0;
13 return result;
14 }
example1.c(11) : warning 14: leaking memory problem occurs in function 'f' The call stack when memory is allocated is: example1.c(9) : f Problem occurs when the following conditions are true: example1.c(8) : when 'size > 0' here example1.c(10) : when 'size == 1' here Path includes 4 statements on the following lines: 8 9 10 11 example1.c(9) : used system model 'malloc' for function call: 'malloc(size)' function returns a new memory block memory allocated Sorgente: Output dell’analisi:

Risultati

Limitazioni
Per programmi commerciali, quali per esempio Apache o Mozilla, l’analisi del codice è molto lenta, non è quindi un tool interattivo. Dato che il numero di cammino possibili può risultare molto grande, la simulazione di tutti i cammini risulta un’operazione intrattabile. Questo implica che limitare il numero di cammini percorribili, limita di conseguenza anche il numero di errori rilevati
È incompleto nel considerare gli errori che possono essere rilevati. Non tutti gli errori vengono rilevati (espandi).
Non c’è la possibilità di limitare il codice da analizzare.
La creazione di modelli per funzioni di cui non si dispone il codice (es. librerie dinamiche), risulta difficoltosa.

Conclusioni
È uno strumento indispensabile durante lo sviluppo di un’applicazione.
Molto utile quando si vogliono scoprire dei bug che sarebbero stati di difficile individuazione anche con debugger che usano test cases.
La possibilità di vedere il cammino che genera l’errore è essenziale per l’usabilità del tool.
La possibilità di filtrare i noise errors , e la possibilità di parametrizzare il numero di cammini visitati nonché il numero di volte che si devono eseguire le funzioni ricorsive, sono di vitale importanza.

References
A Static Analyzer for Finding Dynamic Programming Errors, William R. Bush, Jonathan D. Pincus, David J. Sielaff, Intrinsa Corporation, Mountain View, CA, USA
CMSC 631 Program Analysis and Understanding, Department of Computer Science, University of Maryland

A static Analyzer for Finding Dynamic Programming Errors

by ellepiu on Mar 31, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 2

Statistics

A static Analyzer for Finding Dynamic Programming Errors — Presentation Transcript