为什么 _exit 会失败？

Question

我正在寻找 C 语言中 abort() 函数的源代码，我遇到了这个：

abort.c:

/* Copyright (C) 1991-2019 Free Software Foundation, Inc.
   This file is part of the GNU C Library.
   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.
   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.
   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   <http://www.gnu.org/licenses/>.  */
#include <libc-lock.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sigsetops.h>
/* Try to get a machine dependent instruction which will make the
   program crash.  This is used in case everything else fails.  */
#include <abort-instr.h>
#ifndef ABORT_INSTRUCTION
/* No such instruction is available.  */
# define ABORT_INSTRUCTION
#endif
/* Exported variable to locate abort message in core files etc.  */
struct abort_msg_s *__abort_msg __attribute__ ((nocommon));
libc_hidden_def (__abort_msg)
/* We must avoid to run in circles.  Therefore we remember how far we
   already got.  */
static int stage;
/* We should be prepared for multiple threads trying to run abort.  */
__libc_lock_define_initialized_recursive (static, lock);
/* Cause an abnormal program termination with core-dump.  */
void
abort (void)
{
  struct sigaction act;
  sigset_t sigs;
  /* First acquire the lock.  */
  __libc_lock_lock_recursive (lock);
  /* Now it's for sure we are alone.  But recursive calls are possible.  */
  /* Unblock SIGABRT.  */
  if (stage == 0)
    {
      ++stage;
      __sigemptyset (&sigs);
      __sigaddset (&sigs, SIGABRT);
      __sigprocmask (SIG_UNBLOCK, &sigs, 0);
    }
  /* Send signal which possibly calls a user handler.  */
  if (stage == 1)
    {
      /* This stage is special: we must allow repeated calls of
         `abort' when a user defined handler for SIGABRT is installed.
         This is risky since the `raise' implementation might also
         fail but I don't see another possibility.  */
      int save_stage = stage;
      stage = 0;
      __libc_lock_unlock_recursive (lock);
      raise (SIGABRT);
      __libc_lock_lock_recursive (lock);
      stage = save_stage + 1;
    }
  /* There was a handler installed.  Now remove it.  */
  if (stage == 2)
    {
      ++stage;
      memset (&act, '\0', sizeof (struct sigaction));
      act.sa_handler = SIG_DFL;
      __sigfillset (&act.sa_mask);
      act.sa_flags = 0;
      __sigaction (SIGABRT, &act, NULL);
    }
  /* Try again.  */
  if (stage == 3)
    {
      ++stage;
      raise (SIGABRT);
    }
  /* Now try to abort using the system specific command.  */
  if (stage == 4)
    {
      ++stage;
      ABORT_INSTRUCTION;
    }
  /* If we can't signal ourselves and the abort instruction failed, exit.  */
  if (stage == 5)
    {
      ++stage;
      _exit (127);
    }
  /* If even this fails try to use the provided instruction to crash
     or otherwise make sure we never return.  */
  while (1)
    /* Try for ever and ever.  */
    ABORT_INSTRUCTION;
}
libc_hidden_def (abort)

看了一遍，看到这个，很迷茫：

_exit 被调用后有：

如果连这都失败了，请尝试使用提供的指令来崩溃 或以其他方式确保我们永远不会回来。

为什么_exit 会失败？ _exit 永远不会返回并终止程序。为什么_exit 无法终止程序？

Answer 1

有时在内存损坏的情况下会调用abort()。这可能会导致 _exit() 以某种方式失败。

或者操作系统中可能存在阻止_exit() 工作的错误。

或者程序链接到了替换_exit()的库。

所有这些事情都不太可能发生（在内存损坏的情况下，它很容易导致 abort() 本身失败），但 abort() 正在尝试涵盖所有基础。

Answer 2

在许多系统上，会运行一些本身不在“进程”中的代码。举个简单的例子，负责在进程之间执行任务切换的代码通常不能在旧进程或新进程中运行，而是在与任何一个都不相关的上下文中运行。尽管在这样的上下文中只应该调用少量的系统函数，exit() 和 abort() 都不在其中，但不应该发生的事实并不能保证它不会发生。有时可能会出现预期所有行动方案都不好的情况，但调用abort 可能被视为其中最不坏的情况。

如果在代码位于与任何可识别进程无关的上下文中时调用exit()，它将无法执行其正常职责。它的调用者不太可能为它可能返回的可能性做好准备，因此它最合乎逻辑的做法可能是调用abort()。另一方面，由于abort() 最自然的做法是调用exit() 来清理当前进程，这会产生致命的递归相互依赖。为了适应这种情况，abort 函数有一个专用的静态对象，用于确定它是否被递归调用，如果是，则尝试不同的方法来强制程序退出。 exit() 函数很可能也采用了类似的措施，因此如果某些清理操作触发了 abort()，然后调用 exit()，它将能够尝试执行清理的任何部分，该部分会跟随失败的部分。

请注意，如果正常的中止方法失败，让中止函数进入具有虚拟副作用的无限循环可能与任何其他操作过程一样好，但在某些情况下，无限循环会反复尝试执行 ABORT_INSTRUCTION可能会更好，因为其他监督子系统可能能够识别执行上下文何时卡在除了 ABORT_INSTRUCTION 之外什么都不做的循环中并采取适当的措施（例如，强制系统重新启动，取决于崩溃的代码一直在做什么） .