在共享库中处理信号的惯用方法

Question

我有一个共享库，偶尔通过设计扔 sigsegv 。我可以找出 sigsegv 是否是由我引起的，然后将其处理。但是，在实现其他分支时（即，当它不是我的 sigsegv ）时，我遇到了一些问题。我的主要问题是，如果将处理程序设置为 sig_dfl ，该怎么办。这是我要制作通用的当前代码（因为目前仅支持一些信号，并且依赖于 linux 的默认行为，而不仅仅是任何POSIX）：

void call_next_sighandler(struct sigaction* act, int signo, siginfo_t* info, void* context)
{
  if (act->sa_flags & SA_SIGINFO)
  {
    if (act->sa_sigaction)
    {
      act->sa_sigaction(signo, info, context);
    }
  }
  else
  {
    if (act->sa_handler == SIG_IGN)
    {
      return;
    }
    else if (act->sa_handler == SIG_DFL)
    {
      // we only support a few signals, all of which just dump core:
      //       SIGFPE       P1990      Core    Floating-point exception
      //       SIGSEGV      P1990      Core    Invalid memory reference
      //       SIGTRAP      P2001      Core    Trace/breakpoint trap
      //
      // Therefore we just unregister ourselves and let the process crash

      sigaction(signo, act, nullptr);
      return;
    }
    else
    {
      act->sa_handler(signo);
    }
  }
}

struct sigaction old_sigsegv;
void handle_sigsegv(int signo, siginfo_t* info, void* context)
{
  if (is_my_sigsegv(context))
    handle_my_sigsegv(context);
  else
    call_next_sighandler(&old_sigsegv, signo, info, context);
}

我遇到的另一个问题是如何我将旧信号处理程序存储在自己的模块中。如果在我之后加载了另一个模块，并且他们也决定处理信号会发生什么？他们只需将我的信号处理程序存储在其模块和链条中。但是，这意味着当我卸载时，他们的信号处理程序将调用无效的内存。或作为替代方案，如果我将收到的旧处理程序注册，则删除了新模块的处理程序。我唯一能提出的解决方案是分配我卸载时不会消失的可执行内存，但是真的没有更好的方法吗？

Answer 1

在审查了标准和其他人的实施之后，我决定进行自我援助。

最合适的图书馆解决方案

根本不会处理信号注册混乱。只需揭露库用户必须调用的“信号处理程序”，然后返回是否处理信号。信号处理程序是过程 - 全球的，因此可以将其视为主要可执行文件的资源。图书馆不应该自己处理他人的资源。虽然这可能会给使用您的库的人带来一些头痛，但最终是最灵活的解决方案。

我最终获得了一个相当简单的功能原型：

LIB_EXPORT int lib_handle_signal(int signo, siginfo_t* info, void* context);

并记录了用户必须在几个信号上调用它。

，

由于我的库的主要用户是C＃可执行文件（由于信号安全功能的限制，您无法编写信号处理程序），因此我仍然必须处理这个问题，除了在单独的库中 相当被认为是主要可执行文件的“一部分”。

默认操作

POSIX信号的默认操作为。对于异常或正常的终止处理程序而言，简单地避开自己并让过程崩溃是一个适当的解决方案，而默认被忽略的解决方案可以简单地忽略。

链接和卸载

解决此问题的最简单方法绝不会卸载。虽然我还没有找到真正的POSIX解决方案，但是有一个简单的方法可以在大多数Unices上起作用：

static void make_permanently_loaded()
{
  static char a_variable_in_the_module;
  // this is not POSIX but most BSDs, Linux and Mac have it
  Dl_info dl_info;
  memset(&dl_info, 0, sizeof(dl_info));
  int res = dladdr(&a_variable_in_the_module, &dl_info);
  assert(res && dl_info.dli_fname);
  // Leak a reference to ourselves
  void* me = dlopen(dl_info.dli_fname, RTLD_NOW | RTLD_NODELETE);
  assert(me);
}

其他实施方式，

虽然我在这里并没有真正发现类似的问题，因此，有一些实现遇到的问题与我做到了，并尽了最大的努力来处理它们。

libsigsegv

libsigsegv简单>和甚至不会尝试将其链接到以前注册的任何内容：

sigaction (sig, &action, (struct sigaction *) NULL);

它也无法处理卸载，如果您将其卸载，则您的过程将中止，然后引起Sigsegv，即使加载之前，您已注册了Sigsegv处理程序。

它可以通过不注册自身并让信号再次发生，从而处理与我相似的未手电信号，这将导致正常或异常的终止。

openjdk/hotspot

java带来 libjsig 挂钩信号和 sigaction 。当JRE安装信号处理程序时，Libjsig会退回旧的。当其他人正在安装信号处理程序以信号表明JRE先前安装的信号时，它只会保存新的（并返回以前的旧旧产品）。预计JVM将实施实际的链接，旧处理程序只需要从Libjsig查询。这种方法具有可堆叠的优点 - 可以加载多个不同版本的libjsig，它们将起作用。但是，不幸的是，库的单个副本只能由JRE（或类似）的单个副本使用，因此，如果您不确定没有人会尝试将JRE加载到相同的过程。但是，您可以为您的目的“分叉”它，并简单地将其重命名为IT副本，从而使在同一过程中的JRE旁边加载安全。

热点JVM实现包含信号处理并实际打电话（链接）libjsig保存的处理程序。不幸的是，默认的操作处理分支未能实现，因为它决定将所有意外信号作为意外的信号投掷。但是，蒙版处理代码对于其他任何实施链接的人都非常有用。

libjsig无法解决卸载问题 - 预计库将永远不会卸载。您可以从答案的早期部分添加反卸载代码，以确保是这种情况。

CLR

我没有深入审查它，因为它具有最复杂的操作。

clr Windows异常处理模型）在POSIX信号的顶部以及类似于JRE的单个链接。可以为您的代码范围注册您自己的SEH放松和异常处理信息，因此，如果您不介意提取CLR依赖性，那么这可能值得研究。

结构化异常处理是Windows上的标准异常处理方法，该方法指定了一种放松的信息格式。当收到硬件异常时，堆栈将根据所提供的信息解开，并调用与每个返回地址的代码范围相关的语言处理程序，他们可能会决定处理是否处理异常。这意味着异常（信号）是属于任何代码的“资源”（只要较低的框架不会因编写不正确的过滤功能而偶然地捕获它），与 *NIX的process-global方式不同。 我个人认为这是一种更明智的方法。