文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

linux系统中用户态进程死循环的过程以及解决办法

2023-06-13 03:41

关注

本篇内容主要讲解“linux系统中用户态进程死循环的过程以及解决办法 ”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“linux系统中用户态进程死循环的过程以及解决办法 ”吧!

1、问题现象

业务进程(用户态多线程程序)挂死,操作系统反应迟钝,系统日志没有任何异常。从进程的内核态堆栈看,看似所有线程都卡在了内核态的如下堆栈流程中:

[root@vmc116 ~]# cat /proc/27007/task/11825/stack

[<ffffffff8100baf6>] retint_careful+0x14/0x32

[<ffffffffffffffff>] 0xffffffffffffffff

2、问题分析

1)内核堆栈分析

从内核堆栈看,所有进程都阻塞在 retint_careful上,这个是中断返回过程中的流程,代码(汇编)如下:

entry_64.S

代码如下:

ret_from_intr:
   DISABLE_INTERRUPTS(CLBR_NONE)
   TRACE_IRQS_OFF
   decl PER_CPU_VAR(irq_count)
   
   popq %rsi
   CFI_DEF_CFA rsi,SS+8-RBP    
   leaq ARGOFFSET-RBP(%rsi), %rsp
   CFI_DEF_CFA_REGISTER    rsp
   CFI_ADJUST_CFA_OFFSET    RBP-ARGOFFSET
   。。。
   retint_careful:
   CFI_RESTORE_STATE
   bt    $TIF_NEED_RESCHED,%edx
   jnc   retint_signal
   TRACE_IRQS_ON
   ENABLE_INTERRUPTS(CLBR_NONE)
   pushq_cfi %rdi
   SCHEDULE_USER
   popq_cfi %rdi
   GET_THREAD_INFO(%rcx)
   DISABLE_INTERRUPTS(CLBR_NONE)
   TRACE_IRQS_OFF
   jmp retint_check

这其实是用户态进程在用户态被中断打断后,从中断返回的流程,结合retint_careful+0x14/0x32,进行反汇编,可以确认阻塞的点其实就在
SCHEDULE_USER
这其实就是调用schedule()进行调度,也就是说当进程走到中断返回的流程中时,发现需要调度(设置了TIF_NEED_RESCHED),于是在这里发生了调度。
有一个疑问:为什么在堆栈中看不到schedule()这一级的栈帧呢?
因为这里是汇编直接调用的,没有进行相关栈帧压栈和上下文保存操作。

2)进行状态信息分析
从top命令结果看,相关线程实际一直处于R状态,CPU几乎完全耗尽,而且绝大部分都消耗在用户态:
[root@vmc116 ~]# top
top - 09:42:23 up 16 days,  2:21, 23 users,  load average: 84.08, 84.30, 83.62
Tasks: 1037 total,  85 running, 952 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.6%us,  2.2%sy,  0.2%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32878852k total, 32315464k used,   563388k free,   374152k buffers
Swap: 35110904k total,    38644k used, 35072260k free, 28852536k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                                    
27074 root      20   0 5316m 163m  14m R 10.2  0.5 321:06.17 z_itask_templat                                                                                                               
27084 root      20   0 5316m 163m  14m R 10.2  0.5 296:23.37 z_itask_templat                                                                                                                  
27085 root      20   0 5316m 163m  14m R 10.2  0.5 337:57.26 z_itask_templat                                                                                                                  
27095 root      20   0 5316m 163m  14m R 10.2  0.5 327:31.93 z_itask_templat                                                                                                                  
27102 root      20   0 5316m 163m  14m R 10.2  0.5 306:49.44 z_itask_templat                                                                                                                  
27113 root      20   0 5316m 163m  14m R 10.2  0.5 310:47.41 z_itask_templat                                                                                                                  
25730 root      20   0 5316m 163m  14m R 10.2  0.5 283:03.37 z_itask_templat                                                                                                                  
30069 root      20   0 5316m 163m  14m R 10.2  0.5 283:49.67 z_itask_templat                                                                                                                  
13938 root      20   0 5316m 163m  14m R 10.2  0.5 261:24.46 z_itask_templat                                                                                                                  
16326 root      20   0 5316m 163m  14m R 10.2  0.5 150:24.53 z_itask_templat                                                                                                                  
 6795 root      20   0 5316m 163m  14m R 10.2  0.5 100:26.77 z_itask_templat                                                                                                                  
27063 root      20   0 5316m 163m  14m R  9.9  0.5 337:18.77 z_itask_templat                                                                                                                  
27065 root      20   0 5316m 163m  14m R  9.9  0.5 314:24.17 z_itask_templat                                                                                                                  
27068 root      20   0 5316m 163m  14m R  9.9  0.5 336:32.78 z_itask_templat                                                                                                                  
27069 root      20   0 5316m 163m  14m R  9.9  0.5 338:55.08 z_itask_templat                                                                                                                  
27072 root      20   0 5316m 163m  14m R  9.9  0.5 306:46.08 z_itask_templat                                                                                                                  
27075 root      20   0 5316m 163m  14m R  9.9  0.5 316:49.51 z_itask_templat                                                                                                                  
...

3)进程调度信息
从相关线程的调度信息看:
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
发现相关线程的调度统计一直在增加,说明相关线程一直是在被调度运行的,结合其状态也一直是R,推测很可能在用户态发生了死循环(或者非睡眠死锁)。

这里又有问题:为什么从top看每个线程的CPU占用率只有10%左右,而不是通常看到的死循环进程导致的100%的占用率?
因为线程数很多,而且优先级都一样,根据CFS调度算法,会平均分配时间片,不会让其中一个线程独占CPU。结果为多个线程间轮流调度,消耗掉了所有的cpu。。
另一个问题:为什么这种情况下,内核没有检测到softlockup?
因为业务进程的优先级不高,不会影响watchdog内核线程(最高优先级的实时线程)的调度,所以不会产生softlockup的情况。
再一个问题:为什么每次查看线程堆栈时,总是阻塞在retint_careful,而不是其它地方?
因为这里(中断返回的时候)正是调度的时机点,在其它时间点不能发生调度(不考虑其它情况~),而我们查看线程堆栈的行为,也必须依赖于进程调度,所以我们每次查看堆栈时,正是查看堆栈的进程(cat命令)得到调度的时候,这时正是中断返回的时候,所以正好看到的阻塞点为retint_careful。

4)用户态分析
从上面的分析看,推测应该是用户态发生了死锁。

用户态确认方法:
部署debug信息,然后gdb attach相关进程,确认堆栈,并结合代码逻辑分析。
最终确认该问题确为用户态进程中产生了死循环。

到此,相信大家对“linux系统中用户态进程死循环的过程以及解决办法 ”有了更深的了解,不妨来实际操作一番吧!这里是编程网网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-人工智能
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯