进程线程卡在 __pthread_enable_asynccancel ()
Process threads stuck with __pthread_enable_asynccancel ()
我正在调试 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
= 240
($orig_eax = 240
是 SYS_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 = 240`
您的卡住线程在 futex()
系统调用中,可能在 malloc()
内获取的内部 glibc 锁上(syslog()
调用在内部分配内存)。
造成这种僵局的原因尚不明确,但我有两个建议:
如果您在程序中的任何位置从信号处理程序调用 syslog()
(或任何其他非 AS 安全函数,如 printf()
),这可能会导致死锁像这样;
您可能被 Linux 3.14 中引入并在 3.18 中修复的 bug in futex()
所困扰。该错误也被反向移植到 RHEL 6.6,因此在 CentOS 中也会存在一段时间。此错误的影响是导致进程无法从 FUTEX_WAIT
中唤醒,而它们本应如此。
我正在调试 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
= 240
($orig_eax = 240
是 SYS_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 = 240`
您的卡住线程在 futex()
系统调用中,可能在 malloc()
内获取的内部 glibc 锁上(syslog()
调用在内部分配内存)。
造成这种僵局的原因尚不明确,但我有两个建议:
如果您在程序中的任何位置从信号处理程序调用
syslog()
(或任何其他非 AS 安全函数,如printf()
),这可能会导致死锁像这样;您可能被 Linux 3.14 中引入并在 3.18 中修复的 bug in
futex()
所困扰。该错误也被反向移植到 RHEL 6.6,因此在 CentOS 中也会存在一段时间。此错误的影响是导致进程无法从FUTEX_WAIT
中唤醒,而它们本应如此。