应用软件出现了偶发两次卡死情况。记录下分析过程。
1 分析和验证
1.1 初步分析和验证过程
应用软件分析:
1、应用进程还在;
2、脚本未正常退出,kill掉脚本,软件恢复响应,使用到脚本相关功能又卡死,应用程序通过QProcess执行脚本正常;
3、怀疑system调用失败导致,同时发现串口无法输入,但插拔U盘有系统日志输出;
4、编写测试demo,通过网络SSH远程连接后运行,发现通过system执行脚本正常;
5、通过网络远程连接终端执行命令:echo "v" > /dev/console,发现终端无响应,只能按Ctrl+C结束等待,怀疑跟串口有关系;
6、放置一段时间后,串口终端突然好了,应用软件也恢复正常;
系统资源分析:
1、UI线程阻塞在系统函数system中的waitpid;
2、线程堆栈不存在竞争资源;
3、应用线程数28,系统限制的单进程最大线程数为64(通过编译环境/usr/include/bits/local_lim.h文件确认);
4、CPU和内存无异常;
5、dmesg未看到系统输出异常信息;
6、锁住的内存大小、文件描述符数量都未达上限;
1.2 初步分析结论
根据应用和系统层面的分析和验证,软件功能异常和卡死现象的原因是系统控制台/dev/console阻塞导致依赖其的相关应用和命令异常。进一步需要分析系统控制台/dev/console阻塞的原因。
1.3 进一步分析和验证过程
在Unix-like系统中,/dev/console 是一个特殊的设备文件,它代表系统的控制台。当/dev/console 阻塞时,意味着系统控制台无法正常处理输入和输出,这可能会影响到那些依赖于控制台输入输出的应用和命令,比如 echo 命令。
原理:
控制台作为标准输入输出:在Unix-like系统中,控制台通常被设置为标准输入输出设备(stdin, stdout, stderr)。这意味着,当你在终端中运行一个命令时,它的输出默认会发送到控制台,同样,它的输入也默认从控制台读取。
阻塞的概念:在操作系统中,"阻塞"通常指的是一个进程因为等待某些事件(如输入、输出、信号等)而暂停执行。当进程尝试向一个阻塞的设备文件写入数据时,它可能会被操作系统挂起,直到设备文件变为可写。
系统命令的交互:当你运行 echo 命令时,它试图将消息写入标准输出(通常是控制台)。如果 /dev/console 阻塞,echo 命令将无法完成这个操作,因此会被阻塞,直到 /dev/console 变为可写或者命令被强制终止。
理解:
想象控制台为一个管道:将 /dev/console 想象为一个管道,数据(输出)从一端进入,然后从另一端(屏幕)显示出来。如果管道被堵住(阻塞),数据无法流动,导致后续的数据也无法进入。
影响其他命令:由于很多命令默认使用控制台作为标准输出,/dev/console 的阻塞会导致这些命令无法正常工作。不仅仅是 echo,任何尝试写入控制台的命令都可能受到影响。
连锁反应:如果系统服务或守护进程依赖于向控制台写入日志或输出信息,它们也可能因为 /dev/console 的阻塞而出现问题,这可能导致更广泛的系统不稳定。
根据进一步分析,列出导致/dev/console阻塞的故障树:
系统:
1、有进程阻塞了/dev/console:需要复现的时候通过命令lsof、fuser来确认,目前没有现场无法排除;
2、文件系统问题:通过网络远程连接终端执行脚本正常证明了文件系统没有问题;
3、串口配置和驱动问题:偶发两次其他都是正常,且dmesg没看到错误信息,排除;
硬件:
1、串口问题:硬件检测了串口没有问题;
2、串口连接线问题:该问题只在一个测试同事那出现过两次,且是两台仪器分别出现的,共同点是使用了同一条串口线。该串口线长3m,是手工一段一段焊接的。因此可能会存在焊接不良、线材质量不佳或者长度过长导致信号问题。而且没有做屏蔽层,容易受周围环境或设备运行的干扰。
1.4 进一步分析结论
可能是系统方面原因,有进程阻塞了/dev/console,该原因需要复现后确认。也可能是串口连接线问题,该原因需要制作更长的串口线和制造干扰的情况下持续验证(待验证)。
2 修改方案
如果是进程阻塞了/dev/console,需要复现后继续分析,再考虑修改方案。如果是串口连接线问题,需要换一根质量有保障的串口线。
3 总结
根据应用和系统层面的分析,软件功能异常和卡死现象的原因是系统控制台/dev/console阻塞导致依赖其的相关应用和命令异常。系统控制台/dev/console阻塞的原因还未确定,最近的软件版本和其他测试同事未出现该问题,所以很大可能是串口线的问题,待后续有进展了继续更新。