什么时候最好在看门狗线程中导致段错误而不是正常退出以停止进程？

Posted 2023-02-14

【中文标题】什么时候最好在看门狗线程中导致段错误而不是正常退出以停止进程？

【英文标题】：When is it preferable to cause a segfault in a watchdog thread versus exiting normally to stop a process?

【发布时间】：2021-12-13 17:32:19

【问题描述】：

我想知道曾经是否有充分的理由以所述方式退出看门狗线程，而不是使用exit() 退出。在我遇到的让我想到这个问题的代码中，段错误是由使用奇怪的行 *(char **)0 = "watchdog timeout"; 取消引用空指针引起的。

除非我弄错了，否则调用exit() 的线程会终止整个进程。我将段错误解释为错误，而不是预期的行为，但也许有时需要它。

void *watchdog_loop(void *arg) 
    time_t now;
    while(foo) 
        sleep(1);
        now = current_time();
        if (watchdog_timeout && now - bar > watchdog_timeout) 
            raise(SIGSEGV); //something went wrong
        
    
    return NULL;

【问题讨论】：

不能保证段错误。使用exit()。

如果你想引发分段错误，那么我认为至少raise(SIGSEGV) 可能是一个更好的主意。

如果你有一个实际的硬件看门狗，你通常会通过向它写入不正确的值来重置它。在 PC 上，您所做的一切都毫无意义。

我认为这也没有道理。我质疑的不是我的工作。

我编辑了我的问题以澄清我的初衷并回应这些 cmets

【参考方案1】：

与退出非零相比，有意设置看门狗循环段错误是否更理想？

永远不希望引发未定义的行为，这就是示例代码所做的。特别要注意的是，该代码不需要导致将段错误传递给进程，尽管它可能在某些系统上可靠地这样做。

然而，人们可能更喜欢通过信号而不是调用exit() 来终止进程，以便在不执行任何应用程序或库清理代码的情况下实现终止。对于看门狗来说，这是一个合理的目标。然而，即使在那种情况下，

raise() 或 abort() 函数已定义会导致将信号传递给进程。

SIGSEGV 似乎是一个奇怪的信号选择。 SIGABRT、SIGTERM 或 SIGKILL 中的任何一个对我来说都更有意义。其中，

SIGKILL 不是由 C 语言规范指定的，而是由 POSIX（可能还有其他）指定的。在 POSIX 系统上，SIGKILL 不能被阻塞或捕获，因此它是一个非常好的候选信号，可以尽可能快且可靠地终止进程。

SIGABRT 被abort() 函数使用，它也努力克服程序对以这种方式终止的阻力。这是用于触发故意异常程序终止的最自然的标准函数。

SIGTERM 可以被捕获和/或阻塞，但与SIGKILL 不同的是，它是由 C 语言规范定义的，因此更具可移植性。但我真的看不出比 SIGABRT 有任何优势，除非您打算允许处理它。

另一种选择是 _exit() (POSIX) 或 _Exit() (C99 或更高版本)。这些执行的关闭比您通过信号终止时所期望的要干净，但不执行大多数清理代码。打开的文件会被关闭，父进程会观察进程以失败状态正常终止，而不是被信号杀死而终止。

【讨论】：

"请注意，不需要该代码来导致将段错误传递给进程" 您可以对此进行扩展吗？您是说线程中的段错误可能不会影响主进程吗？我同意你的观点，不希望引发未定义的行为，这就是我对这个话题感兴趣的原因。有时，巫术和无知之间似乎只有一线之隔，尤其是对于像我这样没有经验的人。

@qq4，我是说取消引用空指针会导致未定义的行为。 一般，UB 的表现不一定涉及SIGSEGV 被传递给进程。可能会传递不同的信号（例如SIGBUS），或者程序可能在没有接收到信号的情况下崩溃，或者数据可能被写入某个地址（甚至可能是地址 0），或者可能什么也不会发生。这在机器类和 C 实现中可能相当一致，但并非普遍一致。