Question

我们正在使用Live555 WIS-Streamer在嵌入式Linux系统上通过网络在RTSP上传输视频。

在一个特定系统上，我们看到WIS-Streamer卡在TASK_UNINTERRUPTIBLE状态; 从命令行：进程的ps状态显示为DW，WIS进程的子进程都列为Z僵尸状态。

一旦我们处于这种状态，除了重启（不可取）之外，看起来我们无能为力。但是，我们真的很想找到这个的根本原因 - 我怀疑在流媒体中它挂在阻塞send电话或某些事情上。我们能做些什么，无论是在代码中还是通过命令行等，试图缩小被阻止的内容？

作为一个例子，我已经尝试查看netstat（netstat -alp）的输出，看看是否有悬挂套接字附加到被阻塞/僵尸线程的PID但无效。

使用更多信息进行更新：

它没有破坏CPU，top列表被阻止＆amp;僵尸线程为0％mem / 0％CPU / VSZ 0。

我尝试过关于系统的其他事情：

/ proc / status / for main＆amp;子线程 546是父项，被阻止：

$> 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

儿童：

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

来自/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

更新时更新：

我感觉SysV-IPC消息队列或信号量调用可能会挂起 - 我们的系统由进程间消息队列保持在一起（至少40％未在此发明，由Elbonian Code Slaves编写，作为其中一部分）一个可怕的可怕的SDK），可以陷阱不谨慎。我已经重新设置了几个信号量获取/释放程序，我怀疑这些程序不完全是水上运动（实际上可能只是防松鼠）而且会关注事物 - 不幸的是它平均需要12个小时才能运行特定的测试设置可以导致这种失败。

Answer 1

来自Documentation for sysrq：

＆＃39; W＆＃39; - 转储处于不间断（阻塞）状态的任务。

observableArray

显示有关控制台上被阻止任务的大量信息（也应通过echo w >/proc/sysrq-trigger查看）;特别是内核堆栈跟踪有助于解决问题。

诊断进程陷入D状态（不间断睡眠/阻塞IO）

1 个答案: