tobast/inf301-debug_segfaults
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Poly: update with remarks

Browse source
This commit is contained in:
Théophile Bastian 2021-11-22 15:41:11 +01:00
parent 2b831dc3f2
commit 1bfb8b9eb9
2 changed files with 17 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
poly/meta.yml
View file

@ -4,8 +4,8 @@ author: "Théophile Bastian \\texttt{<theophile.bastian@inria.fr>}"
date: "\\vspace{-1em}" date: "\\vspace{-1em}"
lang: fr lang: fr
geometry: geometry:
- top=2cm - top=1.5cm
- bottom=2cm - bottom=1.5cm
- left=2cm - left=2cm
- right=2cm - right=2cm
pagestyle: empty pagestyle: empty

25
poly/poly.md
View file

@ -2,9 +2,12 @@
Une *segfault* -- *segmentation fault*, ou *erreur de segmentation* -- apparaît Une *segfault* -- *segmentation fault*, ou *erreur de segmentation* -- apparaît
quand un programme essaye d'accéder à une zone mémoire qui ne lui est pas quand un programme essaye d'accéder à une zone mémoire qui ne lui est pas
allouée. C'est une erreur fréquente dès lors qu'on manipule des pointeurs, et allouée\footnote{À noter que si une segfault est toujours due à un accès à de
elle est plus difficile à corriger qu'un bug classique -- en tout cas quand on la mémoire non allouée, l'inverse n'est pas vrai : parfois, un tel accès ne
n'a pas les bons réflexes ! résulte pas en une segfault, et peut par exemple corrompre une autre variable
du programme.}. C'est une erreur fréquente dès lors qu'on manipule des
pointeurs, et elle est plus difficile à corriger qu'un bug classique -- en tout
cas quand on n'a pas les bons réflexes !
Elle arrive par exemple dans les cas suivants : Elle arrive par exemple dans les cas suivants :
@ -117,11 +120,9 @@ nous indique, de bas en haut, que :
* on crash (segfault) * on crash (segfault)
La première ligne nous indique la position du bug, les lignes suivantes nous La première ligne nous indique la position du bug, les lignes suivantes nous
indiquent d'où on vient dans le programme. indiquent d'où on vient dans le programme. C'est certes peu d'informations (la
ligne de l'erreur seulement -- pas la variable concernée, etc), mais c'est déjà
C'est certes peu d'informations (la ligne de l'erreur seulement -- pas la mieux que juste `Segmentation fault (core dumped)`, et souvent suffisant.
variable concernée, etc), mais c'est déjà mieux que juste `Segmentation fault
(core dumped)`, et souvent suffisant.
# Si c'est plus compliqué : gdb # Si c'est plus compliqué : gdb
@ -151,8 +152,8 @@ Program received signal SIGSEGV, Segmentation fault.
`gdb` nous dit qu'on a une *segfault* dans `afficher_liste`, ligne 20 de `gdb` nous dit qu'on a une *segfault* dans `afficher_liste`, ligne 20 de
`exemple.c` -- rien de nouveau. Il nous donne les valeurs des arguments de `exemple.c` -- rien de nouveau. Il nous donne les valeurs des arguments de
cette fonction (`taille=3`, et une adresse pour `tete`). Mais surtout, *on cette fonction (`taille=3`, et une adresse pour `tete`). Mais surtout, *on
reste en mode interactif* ! On peut lui demander la même chose qu'à `valgrind`, reste en mode interactif* ! On peut lui demander ce que `valgrind` affichait spontanément,
savoir d'où on vient : la *backtrace* (savoir d'où on vient) :
```GDB ```GDB
(gdb) backtrace (gdb) backtrace
@ -166,6 +167,10 @@ On peut lui demander d'afficher des valeurs *au moment du crash* :
2 2
(gdb) print cur (gdb) print cur
(liste_t *) 0x0 (liste_t *) 0x0
(gdb) print &(liste->suivant) # On peut écrire des expressions C compliquées
(struct liste **) 0x5555555592a0
(gdb) print liste->suivant->valeur + 42 - taille # aussi compliquées qu'on veut
41
``` ```
...ou la même chose, mais dans `main`, au moment de l'appel de fonction : ...ou la même chose, mais dans `main`, au moment de l'appel de fonction :