在Linux中处理SIGSEGV？

Question

我需要在我的Linux应用程序中处理SIGSEGV。原因是在生成core-dump之前必须进行一些清理(3-partry lib)。更重要的是，清理必须在调用线程的上下文中执行，而不能在信号处理程序中执行。因此，我计划在信号处理程序中将控制传递给调用线程，在清理完成后，然后使用raise(SIGSEGV)生成核心转储。

真正的问题似乎是，无论我使用post_sem还是其他一些工具，signal_handler都无法将控制权传递给调用线程。有什么办法来处理这个案子吗？有没有可能劫持SIGSEGV，然后在SIGSEGV处理程序中返回到另一个线程执行一些清理？

信号(SIGSEGV，signal_handler)；

signal_handler() { ...post_sem()；... }

调用thread() { wait_sem()；clean_up()；... }

Answer 1

您想要在SIGSEGV (即严重错误)后进行清理...我觉得这有点奇怪，因为，1)如果你在调试应用程序，你应该把所有东西都保存在核心文件中，这样你就可以准确地确定发生了什么；2)如果你有一个客户的发布应用程序(比方说)，well...it不应该SIGSEGV :) (无论如何都不是我的问题，只是说……)

在话题上，

我认为您可以尝试在所有线程中阻止SIGSEGV，除了您试图在其中执行清理的线程；这将使操作系统将信号传递到该特定线程。我能想到的其他解决方案是类似setjmp() / longjmp()的方法(不过还没有对它们进行任何测试)。

注意，一旦你的程序获得了SEGV，你就处于摇摇欲坠的境地(例如，你的清理可能也会失败，并产生另一个SEGV等等)，所以你应该考虑直接使用内核崩溃。

Answer 2

遇到SIGSEGV后，不可能可靠地运行任何代码。有时你可能会逃脱惩罚，但你不能相信你的程序会像预期的那样工作。例如，如果你有一个SIGSEGV，因为一个损坏的堆，如果你的第三方库正在清理任何内存，你就会有问题。

为了得到一个可靠的解决方案，我会考虑你是否真的需要运行清理代码，或者是否有其他方法来处理这种情况(在下一次启动时检查不干净的关机，...)。

Answer 3

我认为你不应该尝试运行任何清理内存中状态的东西，特别是将它写入磁盘，如果成功，你就会导致数据损坏。

如果可能，记录一些状态信息可能有助于调试，但您不应该依赖于能够做到这一点。

相反，在记录状态信息之后，程序应该返回到默认处理程序(和转储核心等)，或者调用_exit并退出而不进行任何清理。

如果需要在崩溃后重新启动清理工作，请在下一次启动时进行清理。