Comment résoudre «Erreur de segmentation (core dumped)»

J'utilise Ubuntu 14.04.

Après avoir installé certaines applications, j'ai rencontré une erreur de segmentation (core dumped).

Qu'est-ce que ça veut dire ? Comment puis-je résoudre ce problème?

Par exemple :

Après avoir installé chrome-stable, lorsque je le lance à partir du terminal, je rencontre cette erreur.

Qu'est-ce que ça veut dire?

Voir AU: Qu'est-ce qu'un défaut de segmentation? et aussi ce qui a quelques exemples comment le reproduire, SO: Qu'est-ce que la faute de segmentation? . la description la plus simple que je puisse vous fournir (peut-être pas parfaite):

Le programme a tenté d'accéder à une zone mémoire en dehors de sa propre section. OS le bloque.

Quelques cas: Lecture de valeur avec pointeur initialisé, Sortir de la plage dans un tableau, Appel de fonction (lorsque la compatibilité descendante n'est pas maintenue), ...

Cependant il n'est pas toujours facile de trouver la cause avec de gros programmes ou ceux qui relaient sur d'autres librairies de projet. Et la plupart des cas se retrouvent avec un rapport de bogue, soit pour le programme cible, soit pour ses dépendances (projet en amont ou package de distribution en aval).

Comment puis-je résoudre ce problème?

Si vous n'avez effectué aucune configuration / installation personnalisée et que toutes les mises à jour ont été installées. Déclencher un rapport de bogue , voir Comment signaler un bogue?

Si open source pris en charge par Ubuntu, utilisez ubuntu-bug( apport-bug). Pour les sources fermées tierces, consultez leurs pages d'aide sur la façon de signaler les bogues et de collecter les données associées.

Remarque: Si vous avez même un peu d'expérience en programmation, il est recommandé de faire de votre mieux pour le résoudre vous-même. Il existe de nombreux rapports de bogues inactifs depuis des années. Ou au moins collectez suffisamment de données de débogage pour résoudre le problème avant de le signaler.

Quelques outils utiles pour le débogage

1. apport-bug logs / core dump / backtrace

   Si vous n'avez pas de message d'erreur avant l'erreur de segmentation. Exécutez-le avec --saveoption et recherchez le journal de suivi:

   apport-bug program-cmd --save bug-report_output.txt
   

2. gdb tracer / déboguer le code source

   Si cela n'a pas fonctionné, utilisez gdb:

   $ gdb program-cmd
   (gdb) run
   (gdb) backtrace
   

   Si vous obtenez un message d'erreur, vérifiez le Web, le tableau de bord et dans le suivi des bogues du projet en amont s'il y a des cas similaires.

   Pour certains utilisateurs avancés ou qui suivent le parcours d'apprentissage ac / c ++, ils pourraient télécharger les -dbgpackages de symboles correspondants . Ensuite, vous pouvez utiliser gdbpour suivre le flux du programme à travers la source et obtenir la fonction / instruction exacte qui soulève l'erreur d'exécution.

3. strace traçage des appels système

   Un autre outil qui peut aider est strace, je l'aime. C'est vraiment un outil puissant.

   Il se présente:

   Dans le cas le plus simple, straceexécute la commande spécifiée jusqu'à sa sortie. Il intercepte et enregistre les appels système qui sont appelés par un processus et les signaux qui sont reçus par un processus. Le nom de chaque appel système, ses arguments et sa valeur de retour sont imprimés sur l'erreur standard ou dans le fichier spécifié avec l'option -o.

   straceest un outil de diagnostic, d'instruction et de débogage utile. Les administrateurs système, les diagnosticiens et les dépanneurs le trouveront inestimable pour résoudre les problèmes avec des programmes pour lesquels la source n'est pas facilement disponible car ils n'ont pas besoin d'être recompilés pour les retrouver. Les étudiants, les pirates et les trop curieux découvriront que l'on peut en apprendre beaucoup sur un système et ses appels système en traçant même les programmes ordinaires. Et les programmeurs trouveront que, puisque les appels et les signaux système sont des événements qui se produisent à l'interface utilisateur / noyau, un examen attentif de cette limite est très utile pour l'isolement des bogues, la vérification de l'intégrité et la tentative de capture des conditions de concurrence.

   ^{La source: man strace}

4. ltrace suivi dynamique des appels de bibliothèque

   ltraceest un programme qui exécute simplement la commande spécifiée jusqu'à sa sortie. Il intercepte et enregistre les appels de bibliothèque dynamique qui sont appelés par le processus exécuté et les signaux qui sont reçus par ce processus. Il peut également intercepter et imprimer les appels système exécutés par le programme.

   Son utilisation est très similaire à strace(1).

   ^{La source: man ltrace}