处理线程卡在__pthread_enable_asynccancel()

时间:2016-09-08 19:19:10

标签: c pthreads syslog

我正在调试CentOS平台上的多线程TCP服务器应用程序的问题。应用程序突然停止处理连接。甚至在日志文件中也看不到使用syslog记录的事件。就好像应用程序变成了黑洞。

我用信号11杀死了进程以获得核心转储。在核心转储中,我观察到所有线程都卡在相似的模式中。

例如:

Thread 19 (Thread 0xb2de8b70 (LWP 3722)):
#0  0x00c9e424 in __kernel_vsyscall ()
#1  0x00c17189 in __pthread_enable_asynccancel () from /lib/libpthread.so.0
#2  0x080b367d in server_debug_stats_timer_handler (tmp=0x0) at server_debug_utils.c:75 ==> this line as a event print with syslog(...)

所有大多数帖子都在尝试进行syslog(...)打印,但却遇到了__pthread_enable_asynccancel ()

__pthread_enable_asynccancel ()正在做什么以及它为什么不回来?

这是来自提到的帖子的信息注册:

(gdb) info reg
eax            0xfffffe00       -512
ecx            0x80     128
edx            0x2      2
ebx            0x154ea3c4       357475268
esp            0xb2de8174       0xb2de8174
ebp            0xb2de81a8       0xb2de81a8
esi            0x0      0
edi            0x0      0
eip            0xc9e424 0xc9e424 <__kernel_vsyscall+16>
eflags         0x200246 [ PF ZF IF ID ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)

(gdb) print $orig_eax
$1 = 240

$orig_eax = 240SYS_futex

其中一个线程状态如下所示:

    Thread 27 (Thread 0xa97d9b70 (LWP 3737)):
#0  0x00c9e424 in __kernel_vsyscall ()
#1  0x00faabb3 in inet_ntop () from /lib/libc.so.6
#2  0x00f20e76 in freopen64 () from /lib/libc.so.6
#3  0x00f96a55 in fcvt_r () from /lib/libc.so.6
#4  0x00f96fd7 in qfcvt_r () from /lib/libc.so.6
#5  0x00a19932 in app_signal_handler (signum=11) at appBaseClass.cpp:920
#6  <signal handler called>
#7  0x00f2aec5 in sYSMALLOc () from /lib/libc.so.6
#8  0x0043431a in CRYPTO_free () from /usr/local/lr/packages/stg_app/5.3.8/lib/ssl/libcrypto.so.10
#9  0x00000000 in ?? ()

(gdb) print $orig_eax $5 = 240`

1 个答案:

答案 0 :(得分:1)

你遇到的线程在futex()系统调用中,可能在malloc()内的内部glibc锁上(syslog()调用在内部分配内存)。

造成这种僵局的原因并不明显,但我有两点建议:

  • 如果从程序中任何位置的信号处理程序中调用syslog()(或任何其他非AS安全函数,如printf()),可能会导致此类死锁; < / p>

  • 您可能被Linux 3.14中引入并在3.18中修复的bug in futex()所咬。这个bug也被反向移植到RHEL 6.6,所以在CentOS中也会存在一段时间。这个错误的结果是导致进程无法从FUTEX_WAIT唤醒进程。