+ -
当前位置:首页 → 问答吧 → 用pthread_cancel杀死线程是不是会使正在运行的线程终止在任意位置?

用pthread_cancel杀死线程是不是会使正在运行的线程终止在任意位置?

时间:2010-10-16

来源:互联网

本帖最后由 Cyberman.Wu 于 2010-10-16 14:52 编辑

目前对于这部分的源代码没搞清楚具体是跑到哪部分的,uclibc中有三份实现,有一个是直接调用kill(),
而NTPL的那个没看明白。

想知道是否线程在内核态运行的时候也有可能会被直接杀死,有没有可能在内核态得到一些锁的情况下
直接被终止掉?目前遇到一个问题,一个进程是通过TAP和内核协议栈通信,另一个进程中有线程会动态
join/leave某些Multicast组,这些线程可以会被cancel掉。遇到几次负责从tap的字符设备读/写的
进程和使用Multicast的某个线程死锁在IGMP协议栈的某个mc_list_lock上,从现场分析发现当时的
状态是有一个读锁被释放,所以join的时候获取写锁就等待了,而另一个进程从外部收到网络数据之后
写入tap最终调用到IGMP的检查部分获取读锁了就锁死了(写锁优先,只要有写锁,读锁就等待)。

检查了读写锁的设计以及IGMP中对于锁的使用,应该是没问题的。

Linux内核检测打印的结果如下:
  1. BUG: soft lockup - CPU#20 stuck for 61s! [ff0:5920]                             
  2. Modules linked in: driver                                                      
  3.                                                                                 
  4. Pid: 5920, comm:                  ff0, CPU: 20                                 
  5. r0 : 0x00000001 r1 : 0x01000100 r2 : 0x00000000 r3 : 0xcf10fc40               
  6. r4 : 0xc0dc0000 r5 : 0xe370f908 r6 : 0x00000007 r7 : 0x00010000               
  7. r8 : 0xe370f918 r9 : 0xe370f910 r10: 0xe370f904 r11: 0x010000ef               
  8. r12: 0xe370f930 r13: 0xe370f92c r14: 0xfd291a78 r15: 0xe370f948               
  9. r16: 0xe370f944 r17: 0xe370f940 r18: 0xe370f94b r19: 0xcf10fc58               
  10. r20: 0xe370f94c r21: 0xe370f949 r22: 0xe370f94a r23: 0x00000002               
  11. r24: 0x00000001 r25: 0x00000020 r26: 0x00000001 r27: 0xfd280058               
  12. r28: 0xcf10ffa8 r29: 0x00000000 r30: 0xf5b80f10 r31: 0xf5b80f00               
  13. r32: 0x010000ef r33: 0x00000008 r34: 0x00000000 r35: 0x00000000               
  14. r36: 0x00000000 r37: 0x00000000 r38: 0x00000000 r39: 0x00000000               
  15. r40: 0x00000000 r41: 0x00000000 r42: 0x00000000 r43: 0x00000000               
  16. r44: 0x00000000 r45: 0x00000000 r46: 0x00000000 r47: 0x00000000               
  17. r48: 0x00000000 r49: 0x00000000 r50: 0x00000000 r51: 0x00000000               
  18. r52: 0xf5b80f14 tp : 0x24190000 sp : 0xcf10fc38 lr : 0xfd05a9c0               
  19. pc : 0xfd2f4d88 ex1: 0x1   faultnum: 0x19   orig_r0: 0x00000000               
  20.                                                                                 
  21. Starting stack dump of tid 5920, pid 21462 (ff0) on cpu 20 at cycle 182026110474
  22.   frame 0: 0xfd2f4d88 __raw_write_lock_slow+0xa0/0x128 (sp 0xcf10fc38)         
  23.   frame 1: 0xfd05a9c0 ip_mc_inc_group+0x188/0x248 (sp 0xcf10fc48)               
  24.   frame 2: 0xfd2800a8 ip_mc_join_group.cold+0x1b0/0x1c0 (sp 0xcf10fc70)         
  25.   frame 3: 0xfd0a5188 do_ip_setsockopt+0x1260/0x1560 (sp 0xcf10fc90)            
  26.   frame 4: 0xfd2b4168 sys_setsockopt+0x150/0x170 (sp 0xcf10fe98)               
  27.   frame 5: 0xfd14e550 handle_syscall+0x2d0/0x320 (sp 0xcf10fec0)               
  28.   <syscall while in user mode>                                                  
  29.   frame 6: 0x32d260 (sp 0x9d66ec58)                                             
  30.   frame 7: 0x115620 (sp 0x9d66ec60)                                             
  31.   frame 8: 0x116328 (sp 0x9d66ec90)                                             
  32.   frame 9: 0x104b50 (sp 0x9d66f260)                                             
  33.   frame 10: 0x104e78 (sp 0x9d66f288)                                            
  34.   frame 11: 0x107c40 (sp 0x9d66f320)                                            
  35.   frame 12: 0xf4c68 (sp 0x9d66f338)                                             
  36.   frame 13: 0x22f28 (sp 0x9d66f378)                                             
  37.   frame 14: 0x312d78 (sp 0x9d66f4f0)                                            
  38.   frame 15: 0x3196f0 (sp 0x9d66f628)                                            
  39. Stack dump complete                                                            
  40. BUG: soft lockup - CPU#57 stuck for 61s! [mmd_net:816]                          
  41. Modules linked in: driver                                                      
  42.                                                                                 
  43. Pid: 816, comm:              mmd_net, CPU: 57                                 
  44. r0 : 0x01549816 r1 : 0x01000100 r2 : 0xe4aefc3c r3 : 0xe4aefc44               
  45. r4 : 0xe4aefc40 r5 : 0x00000000 r6 : 0x00000008 r7 : 0x00000001               
  46. r8 : 0x00000008 r9 : 0xe4aefc5c r10: 0xe4aefc58 r11: 0x00000008               
  47. r12: 0x00000000 r13: 0x00000000 r14: 0xc06ce530 r15: 0xd8352e91               
  48. r16: 0x23cee0ba r17: 0x01de1e87 r18: 0xa33d1a93 r19: 0x7ff52d6d               
  49. r20: 0xe4aefd5c r21: 0xe4aefd80 r22: 0xfd097d48 r23: 0x00000000               
  50. r24: 0x00000001 r25: 0x00000020 r26: 0xe4aefde0 r27: 0xfd5728c8               
  51. r28: 0xe4aefdd0 r29: 0x00000002 r30: 0x01549816 r31: 0xf5b80f10               
  52. r32: 0x8301a8c0 r33: 0x8301a8c0 r34: 0xe2130314 r35: 0x00000001               
  53. r36: 0x00000000 r37: 0x00000001 r38: 0x00000001 r39: 0x00000001               
  54. r40: 0xfd132580 r41: 0xe4aefb90 r42: 0xe2130320 r43: 0xe2130318               
  55. r44: 0xe3ce4840 r45: 0xf319cbc0 r46: 0x00000000 r47: 0x00000000               
  56. r48: 0x00000000 r49: 0x00000000 r50: 0x00000000 r51: 0x00000000               
  57. r52: 0xfcf00780 tp : 0x361f0000 sp : 0xe4aefc38 lr : 0xfd3ba100               
  58. pc : 0xfd3ba108 ex1: 0x1   faultnum: 0x19   orig_r0: 0x00000000               
  59.                                                                                 
  60. Starting stack dump of tid 816, pid 816 (mmd_net) on cpu 57 at cycle 18203972460
  61.   frame 0: 0xfd3ba108 __raw_read_lock_slow+0x50/0x90 (sp 0xe4aefc38)            
  62.   frame 1: 0xfd268318 ip_check_mc+0x48/0x1e0 (sp 0xe4aefc48)                    
  63.   frame 2: 0xfd346c38 ip_route_input.cold+0x90/0xe8 (sp 0xe4aefc68)            
  64.   frame 3: 0xfd0f9000 ip_rcv_finish+0x80/0x158 (sp 0xe4aefc90)                  
  65.   frame 4: 0xfd0a2848 netif_receive_skb+0x248/0x398 (sp 0xe4aefcb8)            
  66.   frame 5: 0xfd083bd0 process_backlog+0x110/0x300 (sp 0xe4aefce8)               
  67.   frame 6: 0xfd221a38 net_rx_action+0x138/0x328 (sp 0xe4aefd28)                 
  68.   frame 7: 0xfd0563f8 __do_softirq+0x138/0x220 (sp 0xe4aefd58)                  
  69.   frame 8: 0xfd097d48 do_softirq+0x88/0x110 (sp 0xe4aefd80)                     
  70.   frame 9: 0xfd3c9860 netif_rx_ni+0x68/0x88 (sp 0xe4aefd90)                     
  71.   frame 10: 0xfd217c30 tun_chr_aio_write.cold+0x58/0x280 (sp 0xe4aefda0)        
  72.   frame 11: 0xfd06a180 do_sync_write+0x118/0x1b0 (sp 0xe4aefdc8)               
  73.   frame 12: 0xfd537358 vfs_write+0x138/0x1a0 (sp 0xe4aefe78)                    
  74.   frame 13: 0xfd541a48 sys_write+0x80/0x108 (sp 0xe4aefe98)                     
  75.   frame 14: 0xfd14e550 handle_syscall+0x2d0/0x320 (sp 0xe4aefec0)               
  76.   <syscall while in user mode>                                                  
  77.   frame 15: 0xb7e64f80 (sp 0xbf86fbd8)                                          
  78.   frame 16: 0x11e80 (sp 0xbf86fbd8)                                             
  79.   frame 17: 0x12060 (sp 0xbf86fc28)                                             
  80.   frame 18: 0x12920 (sp 0xbf86fc40)                                             
  81.   frame 19: 0xb7e67c98 (sp 0xbf86fc98)                                          
  82.   frame 20: 0x10df8 (sp 0xbf86fe58)                                             
  83. Stack dump complete         
复制代码

作者: Cyberman.Wu   发布时间: 2010-10-16

本帖最后由 epegasus 于 2010-10-16 16:35 编辑

好问题.
我只能提供一些参考.
曾遇到过一个进程上下文中读设备寄存器  因为总线错误而指令异常导致进程终止的问题 也没释放锁 而其他进程阻塞
我觉得KILL信号应该更温柔些 即使是多处理器起码也得在进程内核态处于被切换下去的时候终止它  既然能被切换 就是可的抢占时候
抢占计数是系统直接可见的而且与进程相关  其他锁就没记录了 也就是系统根本不知道是哪个进程锁的 这个时候就管不了那么多了

作者: epegasus   发布时间: 2010-10-16