是否有一个陷阱“段错误”？

你不能真的希望从段错误中恢复。 您可以检测到发生的情况，并尽可能转储出相关的应用程序特定状态，但无法继续此过程。 这是因为（其中包括）

• 失败的线程不能继续，所以你唯一的选择是longjmp或终止线程。 大多数情况下都不安全。
• 无论哪种方式，你可能会留下一个互斥锁/锁在锁定状态，导致其他线程永远等待
• 即使没有发生，你也可能会泄漏资源
• 即使你没有做这两件事情之一，当它失败的时候，被隔离的线程可能会使应用程序的内部状态不一致。 不一致的内部状态可能会导致数据错误或进一步的不良行为，从而导致更多的问题，而不是简单的退出

所以总的来说，除了以相当突然的方式终止这个过程之外，没有任何意义可以阻止它并做任何事情。 尝试将（重要的）数据写回光盘或继续做其他有用的工作是毫无意义的。 将状态转储到日志（有许多应用程序需要做）然后退出是有一定的意义的。

一个可能有用的事情可能是exec（）你自己的进程，或者有一个看门狗进程在崩溃的情况下重新启动它。 （注意：如果进程拥有> 1个线程，exec并不总是有明确的行为）

一些原因：

1. 提供更多应用程序特定的信息来调试崩溃。 例如，我在第三阶段处理文件“x”时坠毁。
2. 探测某些内存区域是否可访问。 这主要是为了满足嵌入式系统的API。 我们将尝试写入内存区域，并捕获段落错误，告诉我们内存是只读的。
3. 段错误通常源自MMU的信号，如果需要，操作系统使用该信号交换内存页。 如果操作系统没有这个内存页面，它就会把信号转发到应用程序上。

分段错误实际上是访问你没有权限访问的内存（或者是因为它没有被映射，你没有权限，无效的虚拟地址等等）。

根据潜在的原因，您可能想要陷阱和处理分段错误。 例如，如果你的程序通过一个无效的虚拟地址，它可能会记录该段错误，然后做一些损害控制。

段错误并不一定意味着程序堆已损坏。 读取无效地址（例如空指针）可能会导致段错误，但这并不意味着堆已损坏。 此外，根据C运行时，应用程序可能有多个堆。

如果您知道分段错误不是错误，那么可以通过捕获分段错误来实现非常先进的技术。 例如，您可以保护页面，使其不能读取它们，然后在读取完成之前捕获SIGSEGV以执行“神奇”的行为。 （请参阅TomaszWęgrzanowski“将自己的程序设计为趣味和盈利”作为您可能做的一个例子，但通常开销相当高，所以不值得做。）

类似的原理适用于捕获非法指令异常（通常在内核中）以模拟在处理器上未实现的指令。

例如，记录崩溃堆栈跟踪。

不，我认为这是浪费时间 – seg错误表示代码有问题，建议您通过检查核心转储和/或源代码来找到它。 有一次，我试图捕获一个seg故障，导致我进入了一个镜像的大厅，我可以通过简单地考虑源代码来避免这个镜像。 再也不。