什么是__lll_lock_wait_private，什么会在调用malloc_consolidate时导致挂起？
什么是__lll_lock_wait_private，什么会在调用malloc_consolidate时导致挂起？
提问于 2020-04-06 12:27:50
我使用了两个线程，但是它们被困在下面的堆栈跟踪中：
线程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通过Threads getting stuck with few threads at point "in __lll_lock_wait"，我了解到，如果我们无法获得互斥锁，就会调用__lll_lock_wait()，因为还有其他东西(在本例中，我猜线程2)仍在锁定它。
但是Thread 2也被固定在给定的堆栈跟踪中，而且由于它们没有调试符号，所以我无法检查谁是互斥对象的所有者。所以我的问题是：
，
- ，__lll_lock_wait_private ()
- 的用途/原因是什么，有什么提示，问题在哪里？在没有调试symbols.
- Several时间的情况下，我已经看到malloc_consolidate()在linux上挂起。这是一个众所周知的尚未解决的问题吗？
Stack Overflow用户
回答已采纳
发布于 2020-04-06 16:09:28
线程2的框架6和7表示已经安装了自定义信号处理程序。框架5表示它正在尝试编写文件(std::ofstream?)。
这是不允许的。信号处理程序中几乎不允许使用，而绝对不允许使用iostreams。
假设您在一个像malloc_consolidate这样的函数中，它可能必须触及全球舞台，并且需要一个锁才能做到这一点，然后就会出现一个信号。如果在信号处理程序中分配内存，则还需要相同的锁，该锁已被持有。线程2本身就是死锁。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/61059870
复制相关文章
相似问题
腾讯云开发者
