我正在调试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 = 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 $5 = 240`
答案 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
唤醒进程。