Debugging 所有线程都运行SIGSEGV处理程序时崩溃

我们在嵌入式MIPS系统中开发了一个运行在Linux3.4.11上的用户空间进程。该进程使用pthread创建多个（>10）线程。该进程有一个SIGSEGV信号处理程序，该处理程序生成一条日志消息，该消息将发送到我们的日志文件。作为这个流的一部分，它获取一个信号量（坏，我知道…）

在我们的测试过程中，这个过程似乎挂起了。我们目前无法为目标平台构建gdb，因此我编写了一个CLI工具，它使用ptrace来使用ptrace_PEEKUSR提取寄存器值和用户数据

令我惊讶的是，我们所有的线程都在崩溃处理程序中，试图获取信号量。这（显然？）表明信号量上存在死锁，这意味着线程在持有信号量时死机。当我挖掘堆栈时，当信号处理程序开始运行时，几乎所有线程（除了一个）都处于阻塞调用（recv、poll、sleep）中。在MIPS上手动重建堆栈是一件痛苦的事，所以我们还没有完全完成。一个线程出现在MALOC调用的中间，对我来说，它是由于堆损坏而崩溃的。 有几件事尚不清楚：

1） 假设一个线程在malloc中崩溃，为什么所有其他线程都在运行SIGSEGV处理程序？据我所知，SIGSEGV信号被传送到故障线程，不是吗？这是否意味着我们的每一个线程都崩溃了

2） 查看MIPS的sigcontext结构，它似乎不包含被访问的内存地址（badaddr）。还有别的地方有吗？我在任何地方都找不到它，但我觉得奇怪的是，它不可用

---

当然，如果有人能提出继续分析的方法，我们将不胜感激

是的，假设您已正确捕获线程状态，则所有线程可能依次崩溃

siginfo\u t

有一个

si\u addr

成员，该成员应为您提供故障地址。您的内核是否填充了它是另一回事

---

进程内崩溃处理程序总是不可靠的。您应该使用进程外处理程序，并设置

kernel.core\u模式来调用它。在当前内核中，不需要将核心文件写入磁盘；您可以从标准输入读取核心文件，也可以只映射僵尸进程的进程内存（当内核调用崩溃处理程序时，该内存仍然可用）。
所有线程都崩溃了，这不奇怪吗？为什么只有一个有问题的线程不能得到SIGSEGV？这完全取决于内存损坏。如果共享数据已损坏，那么很容易发生所有线程依次崩溃的情况。我猜您对损坏的看法是正确的。根据您的
siginfo\u t
提示，我在堆栈中搜索
00b
（自SIGSEGV-signal 11起）在崩溃的
$sp
上方不久发现了这一点：
0000000b | 0000 | 0000 | 0000 | 0010 88 | 0000 | 0000 | 0000
是进程中另一个线程的PID，而不是崩溃的线程。此外，根据SIGSEGV的

siginfo\u t根本没有PID。所以我很困惑。。。我误解了吗？