Nous travaillons sur un système Linux embarqué utilisant Live555 WIS-Streamer pour diffuser de la vidéo sur RTSP sur un réseau.Diagnostic d'un processus bloqué à l'état D (IO ininterrompu/bloqué)
Sur un système particulier, nous voyons WIS-Streamer se coincer dans un état TASK_UNINTERRUPTIBLE; À partir de la ligne de commande: l'état ps du processus est représenté par DW, les enfants du processus WIS sont tous répertoriés sous la forme Z.
Il semble qu'il n'y ait rien que nous puissions faire une fois que nous sommes dans cet état, autre que le redémarrage (non souhaitable). Cependant, nous aimerions vraiment aller à la cause première de ceci - je suspecte que dans le serpentin il accroche sur un appel send bloquant ou quelque chose. Y a-t-il quelque chose que nous pouvons faire, soit dans le code, soit via la ligne de commande, etc. pour essayer d'affiner ce qui est bloqué?
Par exemple, j'ai essayé de regarder la sortie de netstat (netstat -alp) pour voir s'il y a des sockets pendantes attachées au PID du thread bloqué/zombie mais en vain.
Mise à jour avec plus d'informations:
Ce n'est pas rosser la CPU, top listes bloquées & fils de zombie comme 0% mem/0% CPU/VSZ 0.
D'autres choses que j'ai essayé poking sur le système:
/proc/état/pour les principaux sujets de l'enfant & 546 est le parent, qui est bloqué: 01
$> cat /proc/546/stat
Name: wis-streamer
State: D (disk sleep)
Tgid: 546
Pid: 546
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups:
Threads: 1
SigQ: 17/353
SigPnd: 0000000000000000
ShdPnd: 0000000000004102
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180006a02
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 997329
nonvoluntary_ctxt_switches: 2428751
Enfants:
Name: wis-streamer
State: Z (zombie)
Tgid: 581
Pid: 581
PPid: 546
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups:
Threads: 1
SigQ: 17/353
SigPnd: 0000000000000000
ShdPnd: 0000000000000102
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180006a02
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 856676
nonvoluntary_ctxt_switches: 15626
Name: wis-streamer
State: Z (zombie)
Tgid: 582
Pid: 582
PPid: 546
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups:
Threads: 1
SigQ: 17/353
SigPnd: 0000000000000000
ShdPnd: 0000000000000102
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180006a02
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 856441
nonvoluntary_ctxt_switches: 15694
Name: wis-streamer
State: Z (zombie)
Tgid: 583
Pid: 583
PPid: 546
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups:
Threads: 1
SigQ: 17/353
SigPnd: 0000000000000000
ShdPnd: 0000000000000102
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180006a02
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 856422
nonvoluntary_ctxt_switches: 15837
Name: wis-streamer
State: Z (zombie)
Tgid: 584
Pid: 584
PPid: 546
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 0
Groups:
Threads: 1
SigQ: 17/353
SigPnd: 0000000000000000
ShdPnd: 0000000000000102
SigBlk: 0000000000000000
SigIgn: 0000000000001004
SigCgt: 0000000180006a02
CapInh: 0000000000000000
CapPrm: ffffffffffffffff
CapEff: ffffffffffffffff
CapBnd: ffffffffffffffff
Cpus_allowed: 1
Cpus_allowed_list: 0
voluntary_ctxt_switches: 856339
nonvoluntary_ctxt_switches: 15500
Autres choses de /proc/ filesys:
$> cat /proc/546/personality
00c00000
$> cat /proc/546/stat
546 (wis-streamer) D 1 453 453 0 -1 4194564 391 0 135 0 140098 232409 0 0 20 0 1 0 1094 0 0 4294967295 0 0 0 0 0 0 0 4100 27138 3223605768 0 0 17 0 0 0 0 0 0
Mise à jour sur la mise à jour:
J'ai le sentiment qu'une file d'attente de messages SysV IPC ou un appel de sémaphore peut être tel suspendus - notre système est maintenu ensemble par des files d'attente de messages inter-processus (au moins 40% ne sont pas inventés ici, écrits par Elbonian Code Slaves dans le cadre d'un horrible SDK horrible) qui peuvent piéger les imprudents. J'ai re-jigged quelques routines de sémaphore get/release que je soupçonne étaient moins que complètement wateright (en fait probablement juste juste l'écureuil-preuve) et garderons un oeil sur les choses - malheureusement il faut en moyenne 12 heures de course sur une très configuration d'essai particulière pour induire cette défaillance.
Pouvez-vous exécuter le processus dans GDB? Vous pouvez également le contrôler en utilisant 'strace' pour voir quels sont les derniers appels système qu'il a utilisés. – alnet
La réponse à ces deux questions est "pas facile" - le système est un système embarqué, exécutant Busybox (un système Linux très réduit avec des fonctionnalités limitées) donc nous n'avons pas strace ou GDB et leur ajout pourrait être un gros problème . –
Vous pouvez également utiliser des impressions de journal dans votre processus pour vérifier si vous êtes pile dans un endroit que vous pensez. – alnet