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

Question

在这里和那里搜索我发现了一些据称有效的案例,但是他们都没有给出一个好的(或任何)解释为什么这是最好的(或唯一的)选择.

以下是案例:

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

以下是我对案例的看法:

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

所以:

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

Answer 1

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

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