Contexte
Le matériel moderne à usage général comprend une « unité de gestion de la mémoire » (ou MMU). Cette fonctionnalité matérielle est utilisée par des systèmes d’exploitation comme Linux pour mettre en œuvre la protection de la mémoire, c’est-à-dire pour empêcher différents processus d’accéder à la mémoire des autres ou de la modifier (sauf de manière strictement contrôlée par le biais d’API spécifiques). Cela simplifie le dépannage et augmente la résilience car les processus sont soigneusement contenus et séparés les uns des autres.
Un signal de « violation de segmentation » est envoyé à un processus dont l’unité de gestion de la mémoire a détecté une tentative d’utilisation d’une adresse mémoire qui ne lui appartient pas.
Cause fréquente : erreur de programmation
Si un processus tente d’accéder à la mémoire par le biais d’un pointeur qui n’a pas été correctement initialisé, ou qui pointe vers une mémoire qui a été précédemment désallouée, cela entraînera probablement un segfault. Dans ce cas, le segfault se produit avec un processus ou un binaire spécifique, éventuellement dans un ensemble spécifique de circonstances.
Pour traiter ce type de segfault, commencez par appliquer tous les service packs et mises à jour de maintenance pertinents. Ensuite, si le problème est toujours reproductible avec le code actuel, essayez de capturer un dump du noyau de l’application pour analyse. Vous trouverez des détails à ce sujet dans le TID 3054866 – Comment obtenir des dumps de noyau d’application.
Si le binaire problématique est fourni par Novell dans le cadre du produit, ouvrez une demande de service auprès des services techniques de Novell, en fournissant
- une description des circonstances dans lesquelles le core dump a été généré,
- un rapport supportconfig -v pour le système affecté (page d’accueil de supportconfig), et
- le fichier core dump lui-même, s’il est inférieur à 50 Mo. S’il est plus grand, attendez que la demande de service soit assignée à un ingénieur, puis travaillez avec l’ingénieur pour le transférer.
Si le binaire problématique a été fourni par une tierce partie, contactez le service d’assistance de cette partie pour obtenir de l’aide.
Cause commune : binaire et bibliothèques mal assortis
Des pannes peuvent se produire avec des processus qui combinent des binaires et des bibliothèques partagées qui ne sont pas (entièrement) compatibles. Cela peut se produire, par exemple, lorsqu’une bibliothèque est mise à jour d’une manière qui modifie l’ABI (interface binaire d’application) de la bibliothèque, mais que le numéro de version interne de la bibliothèque n’est pas mis à jour pour refléter cela. Un binaire qui a été construit contre une ancienne version de la bibliothèque peut commencer à présenter des défauts de segmentation lorsqu’il est chargé contre la nouvelle version.
Ce cas peut être difficile à reconnaître, et il n’existe pas de liste d’étapes pour le traiter. Lorsque ce cas est suspecté, voici quelques éléments à prendre en compte :
- Vérifier la corruption des fichiers du système (par exemple en utilisant le fichier rpm-verify.txt dans un rapport supportconfig -v)
- Vérifier les paramètres du système qui concernent les bibliothèques partagées, comme les fichiers de configuration /etc/ld.so.conf et /etc/ld.so.conf.d/* et les variables d’environnement LD_LIBRARY_PATH et LD_PRELOAD.
- Utilisation de l’outil objdump pour vérifier que le binaire ne contient pas de chemin de recherche de bibliothèque intégré (RPATH).
Cause commune : problème de matériel ou de configuration matérielle
Lorsque les segfaults se produisent fréquemment, ou avec différents processus, ou sans schéma clair, cela peut indiquer que le matériel d’un système (sous-système de mémoire) est problématique, ou que les paramètres de configuration du système de bas niveau sont inappropriés. Veuillez vous référer au TID 3301593 – Le système Linux se bloque ou est instable pour plus d’informations sur la façon de gérer cette situation.