我有一个多线程应用程序挂在对_dl_sysinfo_int80()的调用上。根据gdb,所有线程都停留在此调用中。
堆栈跟踪的顶部如下所示:
#0 0x002727a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x004f23de in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2 0x004ef00b in _L_mutex_lock_35 () from /lib/tls/libpthread.so.0
#3 0x092828ac in construction vtable for std::ostream-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > ()
知道可能导致这种情况的原因吗?
答案 0 :(得分:1)
int 80是进行内核级系统调用的软件中断。我的猜测是pthread正在调用挂起的内核。为什么所有线程都会挂在这样的互斥锁上可能有很多原因:
- 互斥锁被另一个没有释放锁的线程锁定
- 互斥锁被一个正在键入的线程锁定以锁定它并且未被声明为递归
- 互斥体从未被初始化
- 互斥锁已被错误的指针,堆栈问题,某些其他类型的一般内存损坏所破坏。
答案 1 :(得分:0)
SoapBox是对的 - 你将不得不连接一个内核调试器来找出callstack的内核一半并找出真正阻塞的内容
答案 2 :(得分:0)
快速浏览glibc源代码向我展示:
_dl_sysinfo_int80
,作为已经提到的另一个答案,是对int $0x80
的调用(调用内核); __lll_mutex_lock_wait
似乎是futex实施的一半用户空间的功能之一。这意味着在该堆栈跟踪中阻塞的所有线程或类似的线程实际上正在等待某种pthread同步对象(可能是pthread互斥锁)。 @ SoapBox回答的所有理由都可能是原因。
除非您怀疑select is broken,否则无需查看该系统调用的内核端。