ephase/cours
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

TD7 part 1 corrections

Browse source
This commit is contained in:
Yorick Barbanneau 2023-04-28 00:30:12 +02:00
parent d4fb4c586a
commit b52709be62
1 changed files with 20 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

23
content/secu_logicielle/td7-analyse_statique_dynamique/index.md
View file

@ -95,6 +95,11 @@ valgrind --leak-check=full --show-leak-kinds=all ./test-reachable-leak
==14383== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
```
En observant le code de notre programme nous pouvons voir que `*c` est un
**pointeur global** (dans le sens variable globale). Dans le `main()`, il prend
l'adresse d'une zone de mémoire créée avec `malloc`. **Cette zone mémoire n'est
pas libérée**, ainsi elle reste accessible à la fin du programme.
## Partie 3
Effectivement, `cppcheck` nous averti à propos d'une zone mémoire créée mais non
@ -132,6 +137,11 @@ Avec l'option `--track-origins=yes` suggérée par sa première exécution,
[...]
```
Valgrind n'averti de ce problème que lors de la première utilisation de la
variable, ici dans `printf()`. C'est un comportement normal : c'est lors de
**l'accès en lecture de cette varible** que Valgrind peut déterminer cet accès
se fait alors que la variable n'est pas initialisée.
## Partie 4
Lors du lancement du programme `test-undefined`, nous pouvons constater que la
@ -146,7 +156,7 @@ Comme nous l'avons vu en cours, nous sommes en présence d'un cas non définis p
la norme C.
*Valgrind* lui de fait part d'aucun problème, il ne se soucis pas du type de la
variable `i` mais de même espace qu'elle occupe en mémoire. Et il **n'a pas
variable `i` mais de l'espace qu'elle occupe en mémoire. Et il **n'a pas
changé**.
``` shell
@ -260,8 +270,15 @@ l'option `-fno-common` n'est pas activée par défaut. Sans cette option il n'es
pas possible pour lui de détecter le problème : il ne sais définir les limites
des données globales non initialisés (stockées dans le segment *BSS*)
*Valgrind* ne se plaint pas et pour cause: nous se sommes toujours pas en
présence d'un problème de fuite de mémoire.
le module *Memcheck* de Valgrind ne détecte pas les erreurs de type
*out-of-bound* sur la pile, c'est une limitation documentée par l'équipe de
dévellopement :
> Unfortunately, Memcheck doesn't do bounds checking on global or stack arrays.
> We'd like to, but it's just not possible to do in a reasonable way that fits
> with how Memcheck works. Sorry.
[source](https://valgrind.org/docs/manual/faq.html#faq.overruns)
### Question 3