Многопоточное приложение висит на _dl_sysinfo_int80

Question

У меня есть многопоточное приложение, которое висит на вызове _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> > ()

Есть идеи, что может быть причиной этого?

Answer 1

int 80 - это программное прерывание для системного вызова на уровне ядра. Я предполагаю, что pthread вызывает ядро, которое зависает. Может быть множество причин, по которым все ваши потоки зависают на мьютексе, например так:
- Мьютекс заблокирован другим потоком, который вышел без снятия блокировки
- Мьютекс заблокирован одним из потоков, который печатает его, и не был объявлен рекурсивным
- Мьютекс вообще никогда не инициализировался
- Мьютекс был поврежден из-за плохого указателя, проблемы со стеком, общего типа повреждения памяти.

Answer 2

Быстрый просмотр исходного кода glibc показал мне, что:

• _dl_sysinfo_int80, как уже упоминалось, это вызов int $0x80 (вызов в ядро);
• __lll_mutex_lock_wait представляется одной из функций пользовательской части половины реализации futex .

Это означает, что все потоки, заблокированные в этой трассировке стека или подобные, на самом деле ожидают какой-то объект синхронизации pthread (возможно, мьютекс pthread). Все причины, приведенные в ответе @ SoapBox, могут быть причиной.

Нет необходимости смотреть на сторону ядра этого системного вызова, если только вы не подозреваете, что select не работает .

Answer 3

SoapBox прав - вам придется подключить отладчик ядра, чтобы выяснить, какая половина ядра имеет стеки вызовов, и выяснить, что действительно блокирует