Compte rendu TP No3 : «Analyse dynamique de programme»

Transcription

1 LO20 : Vérification, validation et sûreté de fonctionnement logiciel.utc.fr/lo20/ Compte rendu TP No3 : «Analyse dynamique de programme» Le second TP concerne l'analyse dynamique de programme. Nous utiliserons des outils de profilage d'application. Binôme : Automne 2007

2 Introduction But du travail Le «profiling» d'application permet de déterminer dans quelles portions du code le programme passe la plupart de son temps et à partir de quelles fonctions celles ci sont invoquées. Ces informations permettent de révéler les problèmes d'optimisation. Dans certains cas cela peut également indiquer un bug si on se rend compte qu'une fonction est appelée plus souvent que prévu initialement. Présentation de l'outil Nous allons faire le profiling d'un programme java avec l'option prof de java, d'un programme C avec l'outil gprof, et analyser un programme C avec l'outil Valgrind. Travail à réaliser Il nous est demandé, pour les trois outils à étudier de réaliser une analyse du programme, de fournir les résultats de l'analyse informatique et d'interpréter les résultats. Dans un second temps, nous devons également fournir notre point de vue sur les outils d'analyse dynamique de programme.

3 Travail réalisé Profiling d'une application JAVA Analyse du programme Pour réaliser le profile d'une exécution d'une application JAVA, nous avons créer une petite application simple qui affiche un compteur de 0 à 10. import java.util.*; import java.io.*; public class tp3 public static void main(string[] args) for(int i=0;i<10;i++) System.out.println(i); On a ensuite réalisé l'analyse dynamique en exécutant la commande : java prof tp3.java Résultat et interprétation de l'analyse informatique Suite à l'analyse dynamique, nous sommes en présence d'un fichier java.prof volumineux, qui va nous permettre de voir les fonctions qui ont été appelées lors de l'exécution du programme, l'initiateur du lancement de la fonction, le nombre de fois que la fonction a été appelée et le temps d'exécution de la fonction. Quelques lignes du fichier java.prof : count callee caller time 281 java.lang.string.charat(i)c java.io.unixfilesystem.(...)(ljava/lang/string;)ljava/lang/string; java.lang.abstractstringbuilder.append(c)(...) java.lang.stringbuilder.append(c)ljava/lang/(...) java.lang.string.length()i sun.net java.lang.string.charat(i)c sun.net java.lang.stringbuilder.append(c)lja(...); sun.net. 4 Comme indiqué dans l'entête du fichier java.prof, le premier élément de chaque ligne

4 correspond au «count» c'est à dire au nombre de fois que la fonction a été appelée. Le second élément «callee» correspond au nom de la fonction appelée. Le troisième élément intitulé «caller» correspond au nom de la fonction qui l'a appelé. Et le dernier élément «time» nous donne une indication sur le temps d'exécution en milliseconde de la fonction. Le fichier java.prof peut donc nous permettre de détecter des problèmes d'optimisation dans notre programme. Par exemple en détectant l'appel successif d'une fonction que l'on ne pourrait pas détecter uniquement avec des tests logiciels du programme. Vu l'exemple simpliste que nous avons choisis, nous ne pouvions pas détecter de telle optimisation à faire dans notre programme. Après quelques recherches sur Internet, nous avons trouvé deux sites intéressant, fournissant des applications dédiées à l'analyse de ces profiles. L'analyse via ces outils pourraient permettre de détecter visuellement encore plus facilement des redondances. Analyse de profiles JAVA avec SpotFire : Profile viewer : Application JAVA permettant d'analyser de manière graphique les profiles JAVA. Le profiling avec l'option Xhrunprof permet d'avoir des informations supplémentaires sur la consommation mémoire de l'application à chaque top d'horloge. On obtiens ansi, le nombre de bytes allouée associé au nombre d'objet correspondant, et le nombre d'objet existant dans le programme associé au nombre de bytes devant être réservé en mémoire. Cela peux par exemple permettre de détecter une fuite mémoire. Profiling d'un programme C Analyse du programme Le programme C proposé se décompose en trois parties. le fichier header.h déclare la fonction WriteMyString()

5 /* * header.h */ void WriteMyString(); Le fichier WriteMyString.c modifié déclarant la fonction WriteMyString. Cette fonction affiche fois la chaîne de caractère passé en paramètres. /* * WriteMyString.c */ extern char *AnotherString; void WriteMyString(ThisString) char *ThisString; int i=0; while(i<500000) printf("%s\n", ThisString); printf("global Variable = %s\n", AnotherString); i++; Le fichier main.c faisant l'appel à cette fonction dans une boucle for exécutée 5 fois. /* * main.c */ #include "header.h" #include <stdio.h> char *AnotherString = "Hello Everyone"; main() int i; printf("running...\n"); for (i=0;i<5;i++) WriteMyString(MY_STRING); printf("finished.\n"); Résultat et interprétation de l'analyse informatique Le profiling d'un programme C se déroule en 3 phases : 1 La compilation du programme avec la commande gcc pg programme.c 2 Exécution de l'exécutable 3 Traitement avec gprof via la commande :

6 gprof display a.out Résultat avant l'ajout de la boucle : Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds seconds calls Ts/call Ts/call name WriteMyString granularity: each sample hit covers 4 byte(s) no time propagated index % time self children called name /5 main [8] [1] WriteMyString [1] Résultat après l'ajout de la boucle : Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds seconds calls Ts/call Ts/call name WriteMyString granularity: each sample hit covers 4 byte(s) no time propagated index % time self children called name /500 main [8] [1] WriteMyString [1] Interprétation : Gprof permet d'obtenir pour chaque fonction du programme, la proportion du temps passé pour cette fonction par rapport au temps total, et le nombre d appel de cette fonction. Il affiche un tableau qui présente le temps passé de chaque fonction et de ses enfants par l ordre. Gprof est donc un outil qui permet de déterminer dans quelles portions du code le programme passe la plus de temps et à partir de quelle fonctions il est bloqué. Ces informations permettent de révéler des problèmes d optimisation, et détecter un bug si on se rend compte qu une fonction est appelée plus souvent que prévu.

7 Valgrind Analyse du programme Le programme proposé fait appel à la fonction f qui alloue en mémoire un tableau de 10 valeurs de type entier et qui inscrit la valeur 0 dans la case 10. C'est à dire la 11ième case du tableau. Résultat et interprétation de l'analyse informatique ==13486== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1) ==13486== malloc/free: in use at exit: 40 bytes in 1 blocks. ==13486== malloc/free: 1 allocs, 0 frees, 40 bytes allocated. ==13486== For counts of detected errors, rerun with: v ==13486== searching for pointers to 1 not freed blocks. ==13486== checked bytes. ==13486== ==13486== ==13486== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==13486== at 0x1B90354C: malloc (vg_replace_malloc.c:130) ==13486== by 0x : f (in /volsme/user1x/uvs/lo20/lo20a012/tp3 sujettp2/t p3/valgrind2) ==13486== by 0x804837C: main (in /volsme/user1x/uvs/lo20/lo20a012/tp3 sujettp 2/tp3/valgrind2) ==13486== ==13486== LEAK SUMMARY: ==13486== definitely lost: 40 bytes in 1 blocks. ==13486== possibly lost: 0 bytes in 0 blocks. ==13486== still reachable: 0 bytes in 0 blocks. ==13486== suppressed: 0 bytes in 0 blocks. ==13486== Reachable blocks (those to which a pointer was found) are not shown. ==13486== To see them, rerun with: show reachable=yes L'analyse Valgrind nous permet de confirmer l'erreur détectée lors de l'analyse du code source. La fonction f inscrit une valeur dans un plage mémoire qui n'a pas été réservée pour. Pour corriger l'erreur, il faut modifier le code source : #include <stdlib.h> void f(void) int * x =malloc(10*sizeof(int)); x[9]=0; int main (void) f();

8 return 0; Une fois le code source modifié, l'analyse suivante fait ressurgir une nouvelle erreur : ==26025== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1) ==26025== malloc/free: in use at exit: 40 bytes in 1 blocks. ==26025== malloc/free: 1 allocs, 0 frees, 40 bytes allocated. ==26025== For counts of detected errors, rerun with: v La nouvelle analyse faite avec Valgrind fait référence à des réservations mémoire faites avec malloc qui n'ont pas été libérées avec l'instruction free. Pour corriger ce problème, il faut libérer l'espace mémoire réservé pour le tableau. Il peut donc mettre en évidence des problèmes tels que les fuites de mémoire, la non utilisation de blocs alloués ou l'utilisation de blocs non définis ainsi que le dépassement de tableau en mémoire. Valgrind permet donc une gestion correcte de la mémoire utilisée par un programme ce qui devient très important lorsque la mémoire disponible pour l'exécution du programme est limitée. Conclusion Ce TP nous a permis de nous familiariser avec les outils d'analyses dynamiques de programmes. Contrairement, à l'analyse statique, l'analyse dynamique de programme ne s'appuie pas directement sur le code source, mais sur du code compilé. Les outils de type profiling permettent d'optimiser les programmes en vérifiant les différents passages dans les fonctions, en parallèle du nom des fonctions appelantes. Le profiling en C permet également de voir un aperçu du temps d'exécution de la fonction. Les outils de vérification de réservations mémoire comme l'option Xhrunprof et Valgrind permettent d'éviter des bug, comme les débordements de tableaux, ou les libérations de zones mémoire qui pourraient ne pas être détecter lors des phases de tests.