J'exécute actuellement un script de modélisation statistique qui effectue une ANOVA phylogénétique. Le script fonctionne correctement lorsque j'analyse l'ensemble de données complet. Mais quand je prends un sous-ensemble, il commence à analyser mais se termine rapidement avec un défaut de segmentation. Je ne peux pas vraiment comprendre en cherchant sur Google si cela pourrait être dû à un problème de ma part (par exemple, un exemple de jeu de données trop petit pour l'analyse) et/ou un bogue dans le script ou si cela a quelque chose à voir avec mon système Linux. J'ai lu que cela avait à voir avec l'écriture de données dans la mémoire, mais pourquoi tout va bien avec un ensemble de données plus volumineux? J'ai essayé de trouver plus d'informations en utilisant Google, mais cela a rendu les choses plus compliquées.
Merci de clarifier à l'avance !
Réponse acceptée :
(tl;dr :Il s'agit presque certainement d'un bogue dans votre programme ou d'une bibliothèque qu'il utilise.)
Un défaut de segmentation indique qu'un accès mémoire n'était pas légal. Autrement dit, sur la base de la requête émise, le processeur émet un défaut de page car la page demandée n'est pas résidente ou dispose d'autorisations incompatibles avec la requête.
Après cela, le noyau vérifie s'il ne sait tout simplement rien de cette page, si elle n'est pas encore en mémoire et qu'il devrait la mettre là, ou s'il doit effectuer une manipulation spéciale (par exemple, copier sur -les pages d'écriture sont en lecture seule, et ceci valide défaut de page peut indiquer que nous devons le copier et mettre à jour les autorisations). Voir Wikipedia pour les erreurs mineures, majeures (par exemple, la pagination à la demande) et les erreurs de page invalides.
L'obtention d'une erreur de segmentation indique le cas non valide :non seulement la page n'est pas en mémoire, mais le noyau n'a également aucune action corrective à effectuer car le processus n'a logiquement pas mappé cette page de son espace d'adressage virtuel. En tant que tel, cela indique presque certainement un bogue dans le programme ou dans l'une de ses bibliothèques sous-jacentes - par exemple, une tentative de lecture ou d'écriture dans la mémoire qui n'est pas valide pour le processus. Si l'adresse était valide, cela aurait pu causer une corruption de la pile ou griffonner d'autres données, mais lire ou écrire un un la page mappée est interceptée par le matériel.
La raison pour laquelle cela fonctionne avec votre ensemble de données plus grand et non avec votre ensemble de données plus petit est entièrement spécifique à ce programme :il s'agit probablement d'un bogue dans la logique de ce programme, qui n'est déclenché que pour l'ensemble de données plus petit pour une raison quelconque (par exemple, votre ensemble de données peut avoir un champ représentant le nombre total d'entrées, et s'il n'est pas mis à jour, votre programme peut lire aveuglément dans la mémoire non allouée s'il ne fait pas d'autres vérifications).
C'est plusieurs ordres de grandeur moins probable que d'être simplement un bogue logiciel, mais un défaut de segmentation peut également être un indicateur de problèmes matériels, comme une mémoire défectueuse, un processeur défectueux ou votre matériel trébuchant sur des errata (à titre d'exemple, voir ici).
En relation :Debian – Automatisation de l'installation de packages Debian 8 individuels avec des invites interactives ?L'obtention d'erreurs de segmentation en raison d'un matériel défaillant entraîne souvent un comportement qui fonctionne parfois, bien qu'un mauvais bit dans la RAM physique puisse être mappé de la même manière lors d'exécutions répétées d'un programme si vous n'exécutez rien d'autre entre les deux. Vous pouvez principalement exclure cette possibilité en démarrant memtest86 + pour vérifier la RAM défaillante et en utilisant un logiciel comme Prime95 pour tester votre CPU (y compris les unités d'exécution FP math FMA).
Vous pouvez exécuter le programme dans un débogueur comme gdb et obtenir la trace au moment de l'erreur de segmentation, ce qui indiquera probablement le coupable :
% gdb --args ./foo --bar --baz
(gdb) r # run the program
[...wait for segfault...]
(gdb) bt # get the backtrace for the current thread