什么时候处理SIGSEGV信号是有意义的？

Question

在这里和那里搜索我发现了一些被认为是有效的案例，但是他们都没有给出一个好的（或任何）解释，为什么这是最好（或唯一）的选择。

以下是案例：

1. 尝试在崩溃前进行某种清理。
2. 向用户提供友好的错误报告，并可能会向您发送错误报告。
3. 用于调试。
4. 尝试执行程序的完全恢复。

以下是我对案件的看法：

1. SIGSEGV信号不应该首先存在，但是那时还有Murphy定律，并且有一些资源可以在程序崩溃后隐含地释放操作系统（我正在考虑信号量）或共享内存）。
2. 再次，有墨菲定律。当出现问题并显示用户发送自动报告的许可时显示对话对用户和开发人员来说都是非常好的。 （我不记得我使用的程序的任何错误报告是否曾提到过分段错误。我想我现在会开始注意到。）
3. 我从来没有想过这个选项。调试器和核心转储看起来更有效。
4. 据我所知，这是不可能的或不合逻辑的，因为程序状态已损坏，使得执行不可预测（这是针对（1），（2）和（3）的另一个好的论据）。但我不知道是否有一个非常具体的案例可能实际上有意义。这让我想起了支持在生产软件中解决断言的论点：有时错误执行比没有执行更好，有时候是航空软件等。

所以：

• 处理SIGSEGV信号有什么好的理由吗？
• 以上任何一种情况确实有效吗？为什么或为什么不呢？
• 为什么我们首先允许处理SIGSEGV？

Answer 1

你有一个程序应该一直运行24/7处理内容（例如处理消息），它使用第三方组件进行一些处理。此第三方组件有时会失败并出现SIGSEGV。

显然，最好的长期解决方案是让供应商修复组件或使用其他组件，但短期解决方案是记录错误并继续。