记一次程序卡住，触发看门狗重启问题

1.问题现象

程序主要为摄像机定时拍照上传的业务，正常态的地运行。
红框为TCP发送数据打印，是问题的重要信息点（后话），但不是每次都出。
run_times为没有喂狗，触发的内核计数，15s一个周期，7次则触发最终重启。

2.程序情况

2.1看门狗机制

芯片平台为RV1126；
①/dev/watchdog 看门狗节点 close后，fd没有，无法喂狗，会触发看门狗重启
②echo V > /dev/watchdog 之后，内核会自动喂狗，不会触发看门狗重启

复现后，15*7 = 105s内进行排查，如时间不够，需尽快echo V > /dev/watchdog，让内核去继续喂狗，保留现场，防止重启，也通过这样来看看时间长了之后，是用户态能够恢复，还是会掉电，或者一直处于内核态。

2.2网络传输方式

（1）TCP协议
（2）IO非阻塞类型
（3）已设置发送缓冲区大小，为33K，接收缓冲区8192字节
（4）发送数据采用循环send方式，对返回值进行缓冲区满检查
（5）缓冲区满的超时时间为60s,超时返回-2

3.排查信息

由于不好复现，后台定时运行shell命令，抓信息状态
每秒刷新一次进程状态：

top -d 1

每秒运行一下指定的shell命令：

watch -n 1 "date ; cat /proc/<pid>/syscall; cat /proc/<pid>/stack; cat /proc/<pid>/wchan"

3.1主程序CPU占用率

（1）每次抓拍点使用编解码资源时，CPU占用率最高,25%左右
（2）正常无任务情况下，main进程的CPU占用率是0~2%左右之间变化的

（3）出问题时，main进程的CPU占用率一直为0

此刻之后，一直为0，这之后27s，开始出现内核run_times计数打印

3.2进程状态

3.3内存占用

3.4网络传输情况

netstat -nat

发送缓冲区大小卡住

3.5系统调用、内核堆栈情况

①进程休眠时,内核当前运行的函数：

cat /proc/pid/wchan

—>结果显示futex_wait_queue_me

②查看系统调用过程，显示的为一系列系统调用号：

cat /proc/pid/syscall

系统调用号在对应的OS上的.h文件，在RV1126平台内核里为：
arch/sh/include/uapi/asm/unistd_32.h
—>结果显示

③进程的内核堆栈信息（需要内核编译开启CONFIG_STACKTRACE）：

cat /proc/pid/stack

—>结果显示0 0xffff,没有啥有用信息
可惜当时没有交叉编译的pstack、strace、perf之类的工具

4.问题出现全过程回溯

（1）设备进行读图片文件，进行TCP传输，传输过程出现网络异常中断（设备端不知晓），非阻塞式地写入数据到发送缓冲区
（2）发送超时后，封装的发送接口返回-2
（3）调用第三方Easylog日志记录接口前，只检查了ret <= 256，导致调用日志接口时，数据长度为-2
（4）而Easylog记录16进制数据的接口为unint16类型，这样-2，16进制FFFE，变成无符号的65534
（5）Eaylog写16进制数据很慢，长时间占用锁，其他调用Easylog的地方就会卡住，另外也长时间频繁磁盘IO，进行系统调用
（6）所以表现出来就是main应用进程CPU占用一直为0
（7）应用程序中的喂狗代码无法运行，不喂狗导致触发看门狗重启

5.补充

将看门狗应用中涉及Easylog调用的输出关掉后，进行再次模拟复现问题后，确实不会触发看门狗重启了，但过一段时间仍会因Easylog长期占用IO资源，触发系统重启了

6.总结

（1）此问题为各产品共性问题，其他产品尽快同步修复，对于4G网络一般不容易出，网络异常中断、上传速度很慢情况出现；网络中断分为网路的物理链路层断开，包括网线断开、供网设备断电、平台服务器断电等；传输速度慢为相对的，主要代码逻辑上的触发，受网络上传速度和上传文件分包大小两者的共同影响。
（2）对于排查此类问题，还是缺乏一些准备工作：程序中有些便于排查的内核选项没有打开，
也没有一些用于获取信息状态的工具软件，应该各芯片平台编译好，常备。
（3）对于记录打印信息的Easylog代码，调用时要注意，不能写入过量的数据，比如此次问题，写入了大量的上传文件数据，这种属于异常触发，没有必要记录
（4）Easylog库内要做数据长度检查，防止不了解的开发人员或者异常传参
（5）Easylog模块需要再回顾，优化，目前来看比较占用IO资源、性能

7.技术拓展

（1）对于锁占用、死锁情况，可以通过valgrind工具获取运行过程中锁占用时长信息
（2）查看CPU状态占用率为0的情况，不一定表示完全休眠，本次问题就是，可以通过查看进程的上下文切换次数，/proc/pid/status结果中的voluntary_ctxt_switches、nonvoluntary_ctxt_switches信息