2011-09-05 3 views
5

Une application multithread se bloque et elle ne répond à aucune commande. J'ai essayé des choses suivantes sans chance:Comment faire pour déboguer un processus caché multithread sous Linux?

  1. Joindre un processus gdb (erreur: (gdb) attacher 6026 Fixation pour traiter 6026 ptrace. Opération non autorisée)
  2. gstack (gstack juste accroche comme ça

Existe-t-il un bon moyen de déboguer ce processus?

+0

Etes-vous en train d'attacher en tant que root, ou en tant qu'utilisateur qui a créé le processus, ou en tant qu'utilisateur? Avez-vous essayé d'exécuter le programme à partir de gdb avant qu'il n'atteigne le point où il se bloque? –

+0

@Jonatha Leffler J'ai exécuté ce processus en root et j'ai utilisé le même identifiant pour attacher le processus dans gdb. Ce n'est pas un processus de premier plan, c'est un processus démon. – Thangaraj

+0

OK; si elle s'exécute en tant que root et que vous essayez d'exécuter gdb en tant que root, alors ce n'est pas une simple question de privilèges (mais cela peut être complexe). Dans l'ensemble, ce que je ferais est de démarrer le démon dans gdb, en utilisant des options telles que 'set follow-fork-mode' et' set fork-detach-mode'. –

Répondre

6

Merci pour votre réponse. Le problème est au niveau du noyau. nous avons utilisé echo t>/proc/sysrq-trigger, qui consigne la pile de tous les processus en cours dans/var/log/messages. Cette trace de pile a aidé à analyser le problème. À partir de la trace de pile, le système de fichiers a signalé un événement attendu au nom du processus d'application à un autre processus (qui est à l'état inopérant) et attend la réponse indéfiniment. Ce qui entraîne l'état bloqué.

1

Probablement que quelqu'un d'autre trace déjà ce processus. Pour savoir qui fait cela, regardez le système de fichiers proc.

cat /proc/6026/status|grep TracerPid 
+0

Le champ TracePid est zéro – Thangaraj

+0

Ensuite, la raison en est un peu plus – ks1322

Questions connexes