当段故障发生时未调用信号处理程序时? [英] When signal handler is not called when segment fault occurs?

问题描述

下面是我程序的操作方法，在某些情况下由于段错误的发生而导致程序终止时未调用注册处理程序.

Below is the operation method of my program, and there was a case where the registered handler was not called when the program was terminated due to the occurrence of a segment fault.

是否存在在发生段故障时可以终止注册处理程序而不调用该处理程序的情况?

Is there a case where the registered handler can be terminated without being called when a segment fault occurs?

1. 初始化程序A时，通过signal()函数注册处理程序.(SIGSEGV，SIGABRT，SIGFPE，SIGTERM)
2. fork()->程序B中的程序A的waitpid()
3. 老龄化
4. 由于A程序中的未知原因而发生段错误
5. B程序的等待状态被传递给段故障(11).
6. 在A程序中注册的处理程序不会被调用并结束.

推荐答案

格式正确，定义明确的C ++应用程序永远不会导致段错误.

A well-formed, well-defined C++ application will never result in a segfault.

段错误是未定义行为的结果；但是当发生未定义的行为时，根据定义，您不能期望任何特定的结果或行为.您不希望由于未定义的行为而发生段错误，即使发生这种情况，您也不能指望 SIGSEGV 处理程序将完全产生任何预期的结果.

A segfault is a result of undefined behavior; but when undefined behavior occurs, by definition you can not expect any specific result or behavior. You have no expectation that a seg fault will occur as a result of undefined behavior, and even if occurs you cannot expect that the SIGSEGV handler will produce any expected result, at all.

可以给出的示例数没有限制.例如，假设segfault处理程序尝试删除在segfault之前创建的临时文件.太糟糕的是，未定义的行为除了导致段错误外，还导致存储临时文件名的缓冲区损坏.segfault处理程序失败.或者，甚至更好的是，损坏的文件名缓冲区恰巧与另一个文件的名称匹配，并且错误地将其删除.如果您以root用户身份运行，并且偶然的损坏的文件名缓冲区偶然包含"/bin/bash"，则您已经将计算机变成了无法启动的砖块.

The number of examples that can be given has no limit. Let's say, for example, the segfault handler attempts to remove a temporary file that gets created before the segfault. Too bad, the undefined behavior resulted in corrupting the buffer that stored the name of the temporary file, in addition to causing a segfault. The segfault handler fails. Or, even better, the corrupted filename buffer happened to match the name of another file, and it gets deleted by mistake. If you were running as root, and the corrupted filename buffer by chance ended up containing "/bin/bash", you've just turned your machine into an unbootable brick.

许多其他可能性也可能发生，只限于一个人的想象力.您没有描述sigsegv处理程序尝试执行的操作，但这无关紧要.无论尝试执行什么操作，都不能保证始终有效.为时已晚，到调用它时，已经发生了未定义的行为，并且从那时起您就不会发生任何事情.

Many other possibilities can also happen, limited only to one's imagination. You did not describe what your sigsegv handler attempts to do, but it doesn't matter. Whatever it tries to do it has no guarantee of always working. It is too late, by the time it gets invoked undefined behavior already happened, and you have no expectation of anything happening, from that point on.

因此，无论segfault处理程序尝试执行什么操作，它都无法保证可以完成其任务.到段错误处理程序被调用时，程序其余部分的状态及其数据是未定义和未指定的.

So, whatever the segfault handler attempts to do, it has no guarantee, whatsoever that it can accomplish its task. By the time the segfault handler gets invoked the state of the rest of the program, and its data, is undefined and unspecified.

这就是为什么当存在导致段错误的错误时，正确的处理方法是找出导致段错误的原因，找到错误并进行修复.任何通过捕获信号和清理来纠正情况的尝试，充其量都无法保证总是成功.

Which is why when there's a bug that results in a segfault, the correct way to handle it is to figure out the reason for the segfault, find the bug and fix it. Any attempt to remedy the situation by catching the signal and the cleaning up is, at best, a crapshoot has no guarantee of always succeeding.

这篇关于当段故障发生时未调用信号处理程序时?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！