FAQ CConsultez toutes les FAQ

Il s'agit d'une erreur très courante qui se produit lorsque votre programme essaie de lire ou d'écrire dans une zone mémoire qui ne lui a pas été attribuée par le système d'exploitation.

Par défaut, un programme en langage machine a accès sans restriction à la totalité du plan mémoire de la machine. C'est de cette façon que fonctionnaient les anciennes architectures telles que les 8 bits, la plupart des microcontrôleurs et les ordinateurs compatibles PC en mode réel (notamment sous D.O.S.). Néanmoins, si ce programme s'avère défectueux et se met à écrire de manière incontrôlée dans la mémoire vive, il peut écraser ce qui s'y trouve : ses propres données, les données sur le disque ou encore le système d'exploitation.

Puisqu'un programme en langage machine est, par définition, exécuté directement par le microprocesseur, sans couche intermédiaire, il n'est pas possible de mettre en place un contrôle logiciel pour empêcher un tel programme de mal se comporter. Pour remédier à cela, les architectures modernes embarquent un dispositif électronique placé soit directement au sein du microprocesseur, soit dans l'unité de gestion de la mémoire permettant de vérifier si les adresses mémoire présentées sur le bus sont comprises dans des limites fixées à l'avance. Si ce n'est pas le cas, une « exception » est déclenchée. Celle-ci provoque un renvoi immédiat vers un sous-programme du système d'exploitation qui, en l'absence d'instructions spécifiques, met fin au programme fautif.

Notez également que le système d'exploitation alloue une plage de travail au processus qui l'organise ensuite comme bon lui semble. Cela signifie qu'il mettra fin à un programme essayant d'écrire sur les autres processus, mais qu'il le laissera faire s'il écrase ses propres données. Ainsi, un logiciel qui ne plante pas n'est pas forcément correct pour autant. Des données invalides peuvent apparaître après coup, et un programme réputé fonctionnel peut devenir défectueux sans explication lorsqu'il est compilé sur une autre architecture.

En langage C, une erreur de segmentation est provoquée dans la grande majorité des cas par un pointeur invalide. Elle peut également être le fait d'un dépassement de tableau ou d'un débordement de pile.

Lorsque vous êtes confrontés à une erreur de segmentation, lancez votre programme dans un débogueur. Ce dernier s'arrêtera automatiquement à la ligne provoquant le crash. Examinez la ligne incriminée et voyez si elle utilise un pointeur (où l'adresse d'une variable obtenue avec l'opérateur « & », par exemple). Il est très probable que la valeur de celui-ci soit incorrecte, obsolète, ou qu'elle référence un objet trop petit pour recevoir ce qu'on veut lui affecter. Grâce au débogueur, vous pouvez rapidement déterminer l'origine du crash, en affichant la valeur du pointeur ou de l'index du tableau incriminé à la ligne où le débogueur s'est arrêté.

Le débogueur ne vous aidera pas toujours, notamment si le l'erreur de segmentation est provoquée par une corruption de la mémoire ayant eu lieu plus tôt dans l'exécution du programme.

Pour cela, il existe un autre type de programmes, les analyseurs de mémoire, qui eux vont vous permettre de détecter les erreurs liées à la mémoire (même si cela ne provoque pas de plantage) ainsi que des fuites de mémoire.

Sous Linux, vous avez valgrind. Sous Windows, l'équivalent est Dr Memory. Vous pouvez aussi utiliser MTuner.

Le code suivant provoque une erreur de segmentation :

1
2
3
char * ptr; 
  
strcpy (ptr,"Test");

Le code suivant provoque une erreur de segmentation :

1
2
3
4
5
6
int buffer[256], i; 
  
for (i=0 ; i<512 ; i++)  
{ 
    buffer[i] = 0; 
}

Le code suivant provoque une erreur de segmentation :

1
2
3
4
void f() 
{ 
    f(); 
}