死锁而在信号处理程序的多线程进程退出

Question

有两个线程的过程。当主线程接收SEGV，从信号处理程序我曾经使用pthread_kill和使用I用来捕获辅助经纱处于睡眠状态这个内部信号，这样我现在可以做强制性清理和堆栈跟踪转储一些内部信号发送到其它辅助线程成从主线程文件与现在单线程处理的思想，（如其他辅助线程处于休眠状态）。

但是，一旦我遇到的是，虽然主线程退出，过程中遗留（不退出），似乎存在两个线程之间死锁状态。

请帮我，为什么和这部分代码是造成僵局。

提前致谢！！

Auxiliary Thread stack:

Thread 2 (Thread 0x7fc565b5b700 (LWP 13831)):
#0  0x00007fc5668e81fd in nanosleep () from /lib64/libc.so.6
#1  0x00007fc566915214 in usleep () from /lib64/libc.so.6
#2  0x00000000009699a2 in SignalHandFun() at ...........
#3  <signal handler called>
#4  0x00007fc56691820a in mmap64 () from /lib64/libc.so.6
#5  0x00007fc5668a5bfc in _IO_file_doallocate_internal () from /lib64/libc.so.6
#6  0x00007fc5668b386c in _IO_doallocbuf_internal () from /lib64/libc.so.6
#7  0x00007fc5668b215b in _IO_new_file_underflow () from /lib64/libc.so.6
#8  0x00007fc5668b38ae in _IO_default_uflow_internal () from /lib64/libc.so.6
#9  0x00007fc566894bad in _IO_vfscanf_internal () from /lib64/libc.so.6
#10 0x00007fc5668a2cd8 in fscanf () from /lib64/libc.so.6
..... 
......
.....
#15 0x00007fc567259806 in start_thread () from /lib64/libpthread.so.0
#16 0x00007fc56691b64d in clone () from /lib64/libc.so.6
#17 0x0000000000000000 in ?? ()

Main Thread stack:

Thread 1 (Thread 0x7fc5679c0720 (LWP 13795)):
#0  0x00007fc56692878e in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007fc5668b504b in _L_lock_1309 () from /lib64/libc.so.6
#2  0x00007fc5668b3d9a in _IO_flush_all_lockp () from /lib64/libc.so.6
#3  0x00007fc5668b4181 in _IO_cleanup () from /lib64/libc.so.6
#4  0x00007fc566872630 in __run_exit_handlers () from /lib64/libc.so.6
#5  0x00007fc5668726b5 in exit () from /lib64/libc.so.6
#6  0x00000000009698e3 in SignalHandFun() at ....
#7  <signal handler called>
#8  0x000000b1000000b0 in ?? ()
#9  0x0000000000000000 in ?? ()

Answer 1

我假设你将信号发送到另一个线程，因为你要做到这一点无法与异步信号安全函数来完成一些工作。

问题是，如果你的信号处理函数，对所需的任何锁定（比如在你的情况下，内部libio列表锁），然后试图获取同一个锁将无限期地阻止任何线程一个线程：您不能从返回您SIGSEGV处理程序，因此锁将永远不会再次锁定变为可用，并且没有线程等待锁将取得进展。在你的情况下，exit功能需要获取libio列表锁，因为它要经过所有打开的文件流的列表，并冲洗它们，而一个线程打开一个新的文件获取锁，同时它把名单上的新文件。

虽然这是一个实现细节和可能可以想象里面的glibc在未来的一些（远）点来解决（我们已经取得了相对较近的小改进，也不会在你的情况帮），唯一的办法是，你在决赛前致电​​_exit进程退出过程中的glibc，清理后，你需要做的。根据你的情况，有可能从你注册为尽可能早的atexit处理这样做，但是这取决于你的应用。

至于崩溃处理程序，我们在这里发表了一些建议：

• Using the fork function in signal handlers

本文重点围绕fork，但僵局的问题是相当多，你的情况是相同的。