Что такое __lll_lock_wait_private и что может вызвать зависание при вызове malloc_consolidate?

Question

Я использовал 2 потока, но они застряли со следующей трассировкой стека:

Поток 2:

(gdb) bt
#0 0x00007f9e1d7625bc in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00007f9e1d6deb35 in _L_lock_17166 () from /lib64/libc.so.6
#2 0x00007f9e1d6dbb73 in malloc () from /lib64/libc.so.6
#3 0x00007f9e1d6c4bad in __fopen_internal () from /lib64/libc.so.6
#4 0x00007f9e1dda2210 in std::__basic_file<char>::open(char const*, std::_Ios_Openmode, int) () from /lib64/libstdc++.so.6
#5 0x00007f9e1dddd5ba in std::basic_filebuf<char, std::char_traits<char> >::open(char const*, std::_Ios_Openmode) () from /lib64/libstdc++.so.6
#6 0x00000000005e1244 in fatalSignalHandler(int, siginfo*, void*) ()
#7 <signal handler called>
#8 0x00007f9e1d6d6839 in malloc_consolidate () from /lib64/libc.so.6
#9 0x00007f9e1d6d759e in _int_free () from /lib64/libc.so.6

_int_free вызывается в результате деструктора по умолчанию.

Тема 1:

(gdb) bt
#0 0x00007f9e2a4ed54d in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f9e2a4e8e9b in _L_lock_883 () from /lib64/libpthread.so.0
#2 0x00007f9e2a4e8d68 in pthread_mutex_lock () from /lib64/libpthread.so.0

Через Потоки застревают с несколькими потоками в точке "in __lll_lock_wait" Я узнаю, что __lll_lock_wait () вызывается, если мы не можем чтобы получить блокировку мьютекса, поскольку что-то еще (в этом случае я предполагаю, что поток 2) все еще блокирует его.

Но поток 2 также застрял с заданной трассировкой стека, и поскольку они не с отладкой символы, я не могу проверить, кто является владельцем мьютекса. Итак, мои вопросы:

1. Какая польза / причина __lll_lock_wait_private ()
2. Есть ли какой-нибудь намек, что и где может быть проблема? Без наличия символов отладки.
3. Несколько раз я видел зависание в случае malloc_consolidate () на linux .. Это хорошо известная и еще не решенная проблема?

Answer 1

Кадры 6 и 7 потока 2 предполагают, что был установлен специальный обработчик сигнала. Кадр 5 предполагает, что он пытается сделать что-то вроде записи в файл (std::ofstream?).

Это недопустимо. В обработчиках сигналов допускается очень мало, и определенно не iostreams.

Предположим, вы находитесь в функции, подобной malloc_consolidate, которая, возможно, должна коснуться глобальной арены и взять блокировку, чтобы сделать это, и сигнал приходит вместе. Если вы выделяете память в обработчике сигналов, вам также нужна такая же блокировка, которая уже удерживается. Сам поток 2 заблокирован.