【问题标题】:Using setjmp() and longjmp() to prevent segmentation fault in a program使用 setjmp() 和 longjmp() 防止程序中的分段错误
【发布时间】:2019-10-01 08:03:23
【问题描述】:

我使用setjmp()longjmp() 编写了一个程序来防止段错误,但是我编写的程序只能防止段错误发生一次(我在while 循环中运行我的代码)。

这是我的代码:

#include <stdio.h>
#include <setjmp.h>
#include <signal.h>

jmp_buf buf;

void my_sig_handler(int sig)
{
    if( sig )
    {
        printf("Received SIGSEGV signl \n");
        longjmp(buf,2);
    }
}

int main()
{
    while( 1)
    {
        switch( setjmp(buf) )                       // Save the program counter
        {
        case 0:
            signal(SIGSEGV, my_sig_handler);        // Register SIGSEGV signal handler function
            printf("Inside 0 statement \n");
            int *ptr = NULL;
            printf("ptr is  %d ", *ptr);            // SEG fault will happen here
            break;
        case 2:
            printf("Inside 2 statement \n");        // In case of SEG fault, program should execute this statement
            break;
        default:
            printf("Inside default statement \n");
            break;
        }
    }
    return 0;
}

输出

Inside 0 statement 
Received SIGSEGV signl 
Inside 2 statement 
Inside 0 statement 
Segmentation fault

预期输出

Inside 0 statement 
Received SIGSEGV signl 
Inside 2 statement 
.
.(Infinite times)
.
Inside 0 statement 
Received SIGSEGV signal
Inside 2 statement 

有人能解释一下为什么这只是第一次按预期运行吗?另外,我在这里缺少什么来按预期运行我的代码?

【问题讨论】:

  • 你调试了吗?为什么会出现分段错误?
  • 为什么要重复?分段错误通常是错失编写正确代码的机会。
  • @thebusybee 执行 printf() 时会出现 SEG 错误。但问题的全部要点是控制应该转到开关的情况 2(因为我在收到 SIGSEGV 信号时调用 longjmp())而不是 SEG 故障。
  • 那么,您阅读@melpomene 提供的URL 上的注释了吗?在第一个段错误之后,您的程序的行为是未定义。最好的办法是退出程序。

标签: c signals segmentation-fault setjmp


【解决方案1】:

长话短说:longjump(显然)不是异步信号安全功能,printf 也是。因此,从信号处理程序调用这些函数将导致未定义的行为。有关详细信息和异步信号安全函数列表,请参阅 man 7 signal-safety

最有可能发生的是longjump(buf, 2) 导致程序异常“转义”信号处理程序,这在执行第二个 switch 案例后导致另一个分段错误。由于发生了另一个分段错误,因此再次调用信号处理程序,并且您执行另一个longjump(buf, 2),回到原来的位置,导致另一个段错误,等等……无限期地。


编辑:正如下面 cmets 中的 Andrew Henle 所建议的,还有两个 POSIX 函数 sigsetjmp()siglongjmp()。然而,我更喜欢下面描述的方法,因为它对我来说看起来更干净,并且可以安全地从信号处理程序返回,将脏工作留给内核。

如果您希望您的代码按预期运行,您可以让您的信号在发生段错误时接收有关上下文的信息:

static void signal_handler(int sig, siginfo_t *info, void *ucontext) {
    /* Assuming your architecture is Intel x86_64. */
    ucontext_t *uc = (ucontext_t *)ucontext;
    greg_t *rip = &uc->uc_mcontext.gregs[REG_RIP];

    /* Assign a new value to *rip somehow, which will be where the
       execution will continue after the signal handler returns. */
}

int main(void) {
    struct sigaction sa;
    int err;

    sa.sa_flags = SA_SIGINFO;
    sa.sa_sigaction = signal_handler;

    err = sigemptyset(&sa.sa_mask);
    if (err)
        return 1;

    err = sigaddset(&sa.sa_mask, SIGSEGV);
    if (err)
        return 1;

    err = sigaction(SIGSEGV, &sa, NULL);
    if (err)
        return 1;

    /* ... */

    return 0;
}

这将允许您基本上在您想要的任何地方恢复执行,前提是您实际上知道在哪里准确恢复。但是,要将 rip 设置为正确的值,您可能必须使用通过内联 asm 或其他一些肮脏技巧定义的全局标签。

这样的东西应该工作(在我的机器上测试过):

/* In main, where you want to retums after SIGSEGV: */
asm voaltile ("checkpoint: .global checkpoint" : );

/* In your signal handler: */
asm volatile (
    "movabs $checkpoint, %0"
    : "=r" (*rip)
);

如果您想知道为什么这不是那么容易,那是因为它甚至不应该放在首位,这基本上是一种可憎的行为,除了可能会发现如何在最荒谬的方式。

您至少需要以下标头和功能测试宏才能使上述功能正常工作:

#define _GNU_SOURCE
#define __USE_GNU
#include <signal.h>
#include <ucontext.h>

请注意,这(当然)取决于架构和平台。

【讨论】:

  • POSIX 提供了sigsetjmp()siglongjmp(),它们往往在 OP 的预期用途中“更好”地工作。但即使这一切都从根本上被打破,因为以任何方式跳出信号处理程序都会导致未定义的行为 - 例如,如果进程获得SIGSEGV调用@987654342,则任何保护堆免受并发修改的锁都将挂起@ 在某些东西损坏了堆之后。
  • @AndrewHenle 啊,谢谢你的信息,我不知道。在这种情况下,这确实很有用。
  • @AndrewHenle:siglongjmp 不是信号处理程序中的“更好的longjmp”。相反,sigsetjmp/siglongjmp 只是保存/恢复信号掩码;否则,如果您跳出信号处理程序,则任何因在处理程序中而被屏蔽的信号(这取决于处理程序的设置方式)都将保持屏蔽状态。通常这没关系,而且自己保存和恢复信号掩码更安全,因为大多数 siglongjmp 实现都是在 wrong order 中完成的。
  • @MarcoBonelli:longjmpsiglongjmp 都可以从信号处理程序中使用,但仅当信号处理程序没有中断异步信号不安全函数(如果确实如此,则两者都不能使用)。一般来说,很难知道这一点,但您可以安排通过仔细屏蔽/取消屏蔽信号来确保这一点。对于像SIGSEGV 这样的同步信号,通常更容易(假设没有人用kill 异步向您发送一个;您可以通过检查处理程序中的siginfo_t 来避免这种情况)。
  • @R.. 否则,如果您跳出信号处理程序,任何因处于处理程序中而被屏蔽的信号(取决于处理程序的设置方式)都将保持屏蔽状态。 嗯,这“更好”,不是吗? ;-)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-12-10
  • 2021-10-30
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多