Lorsqu'une application plante sans produire une erreur, y a-t-il un journal que je peux vérifier?

18

Parfois, il arrive que certaines applications plantent sans donner aucune erreur de sortie ( conky dans mon cas, c'est probablement une de ma configuration qui est incorrecte).

Y a-t-il quelque part un journal des erreurs que je peux vérifier pour comprendre pourquoi il est bloqué?

log

— Strae
source

14

Dépend de l'application. Différentes applications ont différents systèmes de journalisation; il n'y a pas un seul journal central qui contient toutes les sorties de tous les programmes qui s'exécutent sur votre système.

Cela étant dit, de nombreux programmes placent leurs fichiers journaux dans le répertoire /var/log. Le fichier /var/log/syslog(ou peut-être /var/log/messages), en particulier, contient la sortie du "logger système", qui est un service rendu disponible par le système que les programmes peuvent utiliser (s'ils le souhaitent) pour la journalisation. Mais tous les programmes ne l'utilisent pas. Surtout, vous trouverez des messages de services système de bas niveau dans ce fichier, pas les applications graphiques que vous utilisez probablement normalement.

Vous souhaiterez peut-être en savoir plus sur l'emplacement des fichiers journaux standard .

— David Z
source

6

les fichiers de plantage sont /var/log/crashes/utilisés pour utiliser avec proportion pour signaler les bogues. Vous pouvez extraire un vidage de mémoire avec apport-unpack, mettre ce vidage de mémoire dans gdb et découvrir la cause du blocage du programme.

Tout cela en supposant que vous êtes un programmeur. Si vous n'êtes pas ... eh bien, vous ne pouvez pas résoudre le problème de toute façon!

— maco
source

1

"Tout cela suppose que vous êtes un programmeur. Si vous n'êtes pas ... eh bien, vous ne pouvez pas résoudre le problème de toute façon!" avec l'open source, nous pouvons tous essayer de résoudre nos problèmes, à nos risques et périls évidemment;)

— Strae

@DaNiel: Pas vraiment! Si vous n'êtes pas un programmeur et que vous n'avez pas une bonne compréhension du code des applications, plus vous gâcherez avec le code avec lequel le buggier obtiendra probablement :)

— AntonioCS

1

Même si vous n'êtes pas programmeur, la recherche d'un vidage de mémoire peut parfois vous donner une idée du problème. Par exemple, il semble que ça plante dans une sorte de routine graphique - je devrais peut-être mettre à jour mon pilote d'affichage ...

— user1242

2

..et cela aide à décrire les erreurs dans les rapports de bogues / forums;)

— Strae

1

Connaissez-vous des non-programmeurs qui peuvent utiliser gdb? Je suis programmeur et je peux aller jusqu'à bt full"oh regardez une trace ... avec des symboles manquants ... devinez que je dois installer des symboles de débogage et essayer de reproduire le crash ..." J'ai une fois compris comment définir un point d'arrêt ... c'est le plus avancé que j'ai obtenu avec.

— maco

3

Pour conky, il pourrait également y avoir des entrées dans $HOME/.xsession-errors.

— qbi
source

2

Certaines applications ont des indicateurs qui peuvent être utilisés pour activer le débogage, tels que -d, -D, --debug, etc. Consultez la page de manuel de l'application ( man [my-app]) ou exécutez l'application avec l'indicateur -h pour voir si elle possède un tel option.

De nombreuses applications GUI écrivent dans $ HOME / .xsession-errors, c'est donc un bon endroit pour vérifier la sortie.

maco a raison que la répartition est probablement le moyen le plus sûr d'obtenir de bonnes informations de débogage. Parfois, cependant, il ne capture pas le crash.

Si tout le reste échoue, vous pouvez également en forcer les informations en exécutant l'application dans gdb. Ce serait quelque chose comme:

$ gdb my-app

(gdb) run

... faites tout ce qui est nécessaire pour le faire planter ...

(gdb) bt full

et partez de là.

Si vous suivez la route gdb, vous voudrez également installer des symboles, comme mentionné précédemment. Voir https://wiki.ubuntu.com/DebuggingProgramCrash pour des conseils de tenue de main.

— Bryce
source

La meilleure réponse pour moi sans aucun doute

— Claudix

1

vous pouvez y aller, /var/log/messages or crashespuis vous pouvez exécuter la grepcommande sur ceux-ci et rechercher l'application à laquelle vous recherchez les fichiers peut parfois devenir assez gros. Il renverra des informations pertinentes pour votre candidature. :)

— myusuf3
source

1

Si vous lancez votre application à partir d'un fichier de lancement .desktop, ajoutez l'option Terminal=trueà votre fichier .desktop. Cela ouvrira un terminal lorsque vous exécuterez le programme, la sortie sur le terminal sera similaire à ce que vous verriez si vous aviez exécuté le programme via la ligne de commande en premier lieu. De cette façon, lorsque l'interface graphique se bloque ou se bloque, vous pouvez voir quelle sortie de texte y conduisait.

— Selah
source

Qu'est-ce que cela fait? J'ai déjà cet ensemble et il n'enregistre rien de plus.

— Matt

J'ai essayé de répondre à votre question en modifiant ma réponse. Est-ce que cela a du sens?

— Selah