【问题标题】:backtrace_symbols fails to print the very function that has caused the signalbacktrace_symbols 无法打印导致信号的函数
【发布时间】:2014-02-13 16:38:24
【问题描述】:

我正在为我的 C++ 应用程序实现一个简单的崩溃记录器:

static void handler(int, siginfo_t * info, void *) {
    void *array[1000];

    switch (info->si_signo) {
    case SIGILL:
        Logger() << "Received SIGILL";
        break;
    case SIGSEGV:
        Logger() << "Received SIGSEGV";
        break;
    case SIGBUS:
        Logger() << "Received SIGBUS";
        break;
    case SIGSYS:
        Logger() << "Received SIGSYS";
        break;
    default:
        break;
    }

    // get void*'s for all entries on the stack
    const size_t size = backtrace(array, 1000);

    // print out all the frames
    char ** symbols = backtrace_symbols(array, size);
    for(size_t i = 0; i < size; ++i)
    {
        Logger() << symbols[i];
    }

    free(symbols);
    exit(EXIT_FAILURE);
}

struct sigaction SignalAction;
SignalAction.sa_flags = SA_SIGINFO;
SignalAction.sa_sigaction = handler;
sigemptyset(&SignalAction.sa_mask);
sigaction(SIGSEGV, &SignalAction, NULL);
sigaction(SIGBUS, &SignalAction, NULL);
sigaction(SIGILL, &SignalAction, NULL);

我还没有在 Linux 上测试它,但是在 OS X 上,我感兴趣的特定跟踪项,即导致信号的那个,没有被打印(条目号2):

: " Received SIGSEGV" 
: " 0   App                       0x0000000100253d15 _ZL7handleriP9__siginfoPv + 229" 
: " 1   libsystem_platform.dylib  0x00007fff8ff0f5aa _sigtramp + 26" 
: " 2   ???                       0x000000000000000c 0x0 + 12" 
: " 3   App                       0x000000010000dfa7 _ZN11CMainWindow13initShortcutsEv + 231" 
: " 4   App                       0x000000010000d059 _ZN11CMainWindowC2EP7QWidget + 1001" 
: " 5   App                       0x00000001000091d9 main + 6217" 
: " 6   App                       0x00000001000070a5 _start + 227" 
: " 7   App                       0x0000000100006fc1 start + 33" 

为什么会发生这种情况,我可以解决这个问题吗?

P。 S. 这是一个调试版本。没有实际的段错误,它是用raise(SIGSEGV) 模拟的。 raise 是从方法调用的,而该方法又是从 MainWindow::initShortcuts 调用的。

【问题讨论】:

  • 你期望输出是什么,你怎么知道这个跟踪是错误的?可能发生堆栈损坏(弄乱了回溯)或进程实际上试图跳转到地址 0xC(由于内存损坏、编程错误等)。
  • 好吧,既然您使用的是 C++,您也可以从 std::exception 派生,在该派生异常类的构造函数中的 std::liststd::strings 中构建您的堆栈跟踪信息,并抛出该派生类。正如答案所示,您永远不能依赖信号处理程序来提供正确的堆栈跟踪。
  • @AndrewMedico:请参阅更新后的问题(页脚 - P.S. 部分)。

标签: c++ macos stack-trace callstack signal-handling


【解决方案1】:

使用信号处理程序构建崩溃记录器的想法存在根本缺陷。来自sigaction man page的“注意”部分:

以下函数要么是可重入的,要么是不可中断的 信号并且是异步信号安全的。因此应用程序可以调用 它们不受限制地来自信号捕获功能:

[…省略异步信号安全函数列表…]

上面列表中没有的所有函数都被认为是不安全的 信号方面。也就是说,此类函数的行为 从信号处理程序调用时未定义。不过总的来说, 信号处理程序应该只设置一个标志;大多数其他 操作不安全。

backtrace()backtrace_symbols()free()exit() 都不能在信号处理程序中安全调用。几乎可以肯定,Loggeroperator&lt;&lt; 中的内容也是不安全的。

至于为什么信号激发函数没有在回溯中,这显然是由内核如何设置信号处理程序上下文引起的。通过检查调用语句和函数序言构造的堆栈帧来获得回溯。信号处理程序不会像正常的函数调用一样被调用,因此没有特别的理由期望堆栈帧链会正确设置。

事实上,可以使信号处理程序在与普通代码完全不同的堆栈上运行。见sigaltstack()

【讨论】:

【解决方案2】:

条目号 2 具有非常特殊的地址。它是0x000000000000000c,你必须知道有中断描述表。根据http://en.wikipedia.org/wiki/Interrupt_Descriptor_Table 可能是堆栈故障。

然而,正如 Ken 指出的那样,做你正在做的事情是不好的。这就像试图记住当你的主动脉被撕裂时撞到你的汽车的车牌一样。你可以这样做,但有什么用呢?

也许不如尝试学习如何使用 strace http://en.wikipedia.org/wiki/Strace

【讨论】:

  • Strace 似乎无法满足我的需求。
  • 嗯,据我了解,此跟踪日志,堆栈故障是由 : " 3 App 0x000000010000dfa7 _ZN11CMainWindow13initShortcutsEv + 231" 引起的,处理器查找中断描述符表(条目 2)并跳转到处理 libsystem_platform.dylib 中的此信号的过程(条目 1 ) 再次调用您的代码(条目 0),因为您设置了自己的信号处理程序。 IDT 是中断处理程序的跳转指令列表。
  • 没有堆栈错误。有SIGSEGV 信号。它不是通过ZN11CMainWindow13initShortcutsEv 发送的,而是通过从那里调用的另一种方法发送的。
  • 调试构建,没有优化。不应该被内联。
  • 你错了。没有优化 = 没有内联,否则您将无法正确调试。
猜你喜欢
  • 2011-10-19
  • 2014-07-14
  • 1970-01-01
  • 2022-10-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多