C++ gdb 你能找到持有内部 glibc 锁的线程吗

我认为我的问题不是this question的重复，this question描述了如何找到哪个线程拥有pthreadmutex_t.我想知道如何找到内部glibc锁的所有者，我不认为它与pthread_mutex_t相同.考虑从我的应用程序中提取的回溯中的以下线程，它是挂起的(可能是死锁的？):

Thread 1 (Thread 0x7f8478e1b700 (LWP 24662)):
#0  0x00007f847cf277fc in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007f847cea350c in _L_lock_5314 () from /lib64/libc.so.6
#2  0x00007f847ce9c108 in _int_free () from /lib64/libc.so.6
... <unnecessary details which lead up to this thread calling free> ...
#11 0x00007f847db18ea5 in start_thread () from /lib64/libpthread.so.0
#12 0x00007f847cf19b0d in clone () from /lib64/libc.so.6

我可以使用任何类似于链接的问题或this other webpage的技巧来找出哪个线程持有内部glibc锁吗？

其他详细信息:

注意:此回溯是从客户端的核心文件生成的，因此我不能自己简单地测试GDB命令，否则我会try 更多地使用它.

程序中还有一堆其他线程；我不会全部复制它们，但我确信调用fork()的这个线程持有锁:

Thread 4 (Thread 0x7f8479724700 (LWP 24775)):
#0  0x00007f847cee0b12 in fork () from /lib64/libc.so.6
...
#6  0x00007f847db18ea5 in start_thread () from /lib64/libpthread.so.0
#7  0x00007f847cf19b0d in clone () from /lib64/libc.so.6

我怀疑fork()可能需要与free()相同的锁，但我想确定这一点，并尽可能了解更多有关内部libc状态的信息.

这个问题的"xy"部分(我真正想知道的是)是为什么线程4似乎没有进展.我不知道，我正在与客户合作了解更多信息，但他们说程序被困在这里3个小时后才注意到并终止了它.我想把这个问题集中在用gdb调试内部glibc方面.

注意:我知道在多线程进程中使用fork()的危险:在调用exec()之前，子进程只能调用异步信号安全函数.无论如何，我的问题不是关于子元素，而是关于父母.