segmentation-fault - 什么时候处理 SIGSEGV 信号有意义？

Question

到处搜索，我发现了一些据称有效的案例，但没有一个很好地(或任何)解释为什么这是最好的(或唯一的)选择。

以下是案例:

尝试在崩溃之前执行某种清理。

向用户提供友好的错误报告，并可能将错误报告发回给您。

使用它进行调试。

尝试对您的程序执行完全恢复。

以下是我对案例的看法:

SIGSEGV 信号一开始就不应该存在，但又是墨菲定律，有些资源在程序崩溃后操作系统不会隐式释放(我在考虑信号量或共享内存)。

再次，有墨菲定律。在出现问题时显示对话框并请求用户许可以发送自动报告对于用户和开发人员来说似乎都非常好。 (不过，我不记得我使用的程序的任何错误报告是否提到了段错误。我想我现在会开始注意到。)

我从来没有想过这个选项。调试器和核心转储看起来是一种更有效的方法。

据我所知，这要么是不可能的，要么是不合逻辑的，因为程序状态已损坏，导致执行不可预测(这是反对(1)、(2)和(3)的另一个很好的论据)。不过，我不知道是否有一个非常具体的案例，这实际上可能有意义。这让我想起了支持在生产软件中关闭断言的论点:有时错误执行总比不执行好，有时是航空软件等。

所以:

处理 SIGSEGV 信号有什么好的理由吗？

上述情况是否确实有效？为什么或者为什么不？

为什么我们首先可以处理 SIGSEGV？

Answer 1

您有一个程序应该一直运行 24/7 处理内容(例如处理消息)，并且它使用第三方组件来进行一些处理。此第三方组件有时会因 SIGSEGV 而失败。

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