Pthread“管理器”线程因获取信号 33 而崩溃答案

【问题标题】：Pthread "manager" thread crashed due to get signal 33Pthread“管理器”线程因获取信号 33 而崩溃
【发布时间】：2014-02-04 23:16:49
【问题描述】：

我在使用 pthread 库的嵌入式 linux 上有 linux 应用程序。 pthread“管理器”线程有时会收到信号 33 并崩溃。

我怎么知道是谁在发送信号？

跟踪日志：

...
18:15:07 getppid()                      = 30
18:15:07 poll([{fd=31, events=POLLIN}], 1, 2000) = 0
18:15:09 getppid()                      = 30
18:15:09 poll([{fd=31, events=POLLIN}], 1, 2000) = 0
18:15:11 getppid()                      = 30
18:15:11 poll([{fd=31, events=POLLIN}], 1, 2000) = 0
18:15:13 getppid()                      = 30
18:15:13 poll([{fd=31, events=POLLIN}], 1, 2000) = -1 EINTR (Interrupted system call)
18:15:13 --- SIGRT_1 (Unknown signal 33) @ 0 (0) ---
18:15:13 getppid()                      = 30
18:15:13 wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], WNOHANG|__WCLONE, NULL) = 68
18:15:13 --- SIGSEGV (Segmentation fault) @ 0 (0) ---

【问题讨论】：

标签： pthreads embedded-linux

【解决方案1】：

信号 33 由 pthreads 库在内部使用（它被称为 SIGSETXID，每当进程的 uid 或 gid 之一发生更改时，它都会由库为每个线程引发）。

它不应该导致线程崩溃。为什么你认为这个信号是负责任的？

【讨论】：

更新了我的帖子。添加了 strace 日志。
@Grey：看起来您的其他线程之一最初遇到了段错误，然后导致整个进程终止。尝试在 gdb 下运行进程或捕获核心文件以加载到 gdb 中。
我会听取你的建议。谢谢！
有一些像 libbacktrace 这样的库，会利用这个信号来展开目标进程。所以基本上它是一个特定于实现的信号。