Question

我正在使用＆＃39; backtrce（）＆＃39;和＆＃39; backtrace_symbols_fd（）＆＃39;函数在信号处理程序中生成用于调试的回溯（GDB不可用）。

它们在x86桌面（Ubuntu）上工作正常，但目标设备上的（基于ARM）中止信号的回溯（由于双重自由错误）仅显示三帧：信号处理程序和libc中的两个，这对调试我们的代码没有用！在SEGV上回溯（例如使用坏指针）产生良好的回溯。

为什么我无法对ARM上的ABRT信号进行有用的回溯？

[为清晰起见而编辑的问题]

这是一个简单的测试程序，用于演示问题：

#include <execinfo.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

// Signal hangler to catch seg fault:
void handler_segv(int sig) {
    // get void*'s for all entries on the stack
    void *array[10];
    size_t size;
    size = backtrace(array, 10);
    fprintf(stderr, "Error: Signal %d; %d frames found:\n", sig, size);
    // print out all the frames to stderr
    backtrace_symbols_fd(array, size, STDERR_FILENO);
    exit(1);
}


void crashme()
{
  // Deliberate Error: Abort (double free):
  char *test_ptr = malloc(1);
  free(test_ptr);
  free(test_ptr);
  // Deliberate Error #2: Seg fault:
  //char * p = NULL;
  //*p = 0;
}

void foo()
{
    fprintf(stdout, "---->About to crash...\n");
    crashme();
    fprintf(stdout, "---->Crashed (shouldn't get to here)...\n");
}



// Main entry point:
int main(int argc, char *argv[])
{
    fprintf(stdout, "Application start...\n");

    // Install signal handlers:
    fprintf(stdout, "-->Adding handler for SIGSEGV and SIGABRT\n");
    signal(SIGSEGV, handler_segv);
    signal(SIGABRT, handler_segv);

    fprintf(stdout, "-->OK. Causing Error...\n");
    foo();
    fprintf(stdout, "-->Test finished (shouldn't get to here!)\n");
    return 0;
}

这是针对x86编译的，如下所示：

gcc -o test test-backtrace-simple.c -g -rdynamic

对于ARM：

arm-none-linux-gnueabi-gcc -o test-arm test-backtrace-simple.c -g -rdynamic -O0 -mapcs-frame -funwind-tables -fasynchronous-unwind-tables

我已经为ARM使用了各种编译器选项，如在与ARM上生成回溯相关的其他帖子中所述。

在x86桌面上运行时，它会生成具有大量调试的预期输出，结束于：

Error: Signal 6; 10 frames found: 
./test(handler_segv+0x19)[0x80487dd]
[0xb7745404] 
[0xb7745428]
/lib/i386-linux-gnu/libc.so.6(gsignal+0x4f)[0xb75b0e0f]
/lib/i386-linux-gnu/libc.so.6(abort+0x175)[0xb75b4455]
/lib/i386-linux-gnu/libc.so.6(+0x6a43a)[0xb75ed43a]
/lib/i386-linux-gnu/libc.so.6(+0x74f82)[0xb75f7f82]
./test(crashme+0x2b)[0x8048855] 
./test(foo+0x33)[0x804888a]
./test(main+0xae)[0x8048962]

（即我的处理程序生成的后跟踪，我的函数调用在底部）。

然而，当在ARM平台上运行时，我得到：

Application start...
-->Adding handler for SIGSEGV and SIGABRT
-->OK. Causing Error...
---->About to crash...
*** Error in `/opt/bin/test-arm': double free or corruption (fasttop): 0x015b6008 ***
Error: Signal 6; 3 frames found:
/opt/bin/test-arm(handler_segv+0x24)[0x8868]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0xb6e6c150]
/lib/libc.so.6(gsignal+0x34)[0xb6e6af48]

backtrace（）只找到3帧，它们只是信号处理程序和libc中的东西（没用）！

我找到了一个邮件列表帖子说：

如果您链接到调试C库-lc_g，您将获得调试信息回过去abort（）。

这可能是相关的，但是-lc_g对我的编译器不起作用（ld：找不到-lg_c）。

如果我生成一个seg错误（例如，更改crashme（）函数使用＆＃34; char * p = NULL; * p = 0;＆＃34;而不是double free，则回溯在ARM上正常工作。

有关其他方法获得回溯的任何想法或建议吗？

[ - 编辑 - ]

我按照评论中的建议尝试了一些MALLOC_CHECK_选项，但唯一的影响是更改是否生成了中止。以下是ARM上三次运行的输出：

 # MALLOC_CHECK_=0 /opt/bin/test-arm
Application start...
-->Adding handler for SIGSEGV and SIGABRT
-->OK. Causing Error...
---->About to crash...
---->Crashed (shouldn't get to here)...
-->Test finished (shouldn't get to here!)


# MALLOC_CHECK_=1 /opt/bin/test-arm
Application start...
-->Adding handler for SIGSEGV and SIGABRT
-->OK. Causing Error...
---->About to crash...
*** Error in `/opt/bin/test-arm': free(): invalid pointer: 0x015b2008 ***
---->Crashed (shouldn't get to here)...
-->Test finished (shouldn't get to here!)


# MALLOC_CHECK_=2 /opt/bin/test-arm
Application start...
-->Adding handler for SIGSEGV and SIGABRT
-->OK. Causing Error...
---->About to crash...
Error: Signal 6; 3 frames found:
/opt/bin/test-arm(handler_segv+0x24)[0x8868]
/lib/libc.so.6(__default_sa_restorer_v2+0x0)[0xb6e24150]
/lib/libc.so.6(gsignal+0x34)[0xb6e22f48]
#

MALLOC_CHECK_ = 0：没有错误消息（忽略双重免费！）

MALLOC_CHECK_ = 1：错误消息，但程序继续

MALLOC_CHECK_ = 2：错误信息和ABRT信号;生成无用的回溯（这是默认行为！）

我的交叉编译器报告： gcc版本4.6.1（Sourcery CodeBench Lite 2011.09-70）目标设备有linux内核版本3.8.8

Answer 1

看来你已经做了足够的研究，知道你需要在编译器命令行中使用开关-funwind-tables和-fasynchronous-unwind-tables。在实践中，其中任何一个看起来都足够但很明显没有它们的回溯根本不起作用。现在，像SIGABRT这样的问题是回溯必须遍历由诸如abort和gsignal之类的libc函数生成的堆栈帧，并且因为lib不是用这些开关构建的而失败了（在我知道的任何发行中。）

虽然请求Sourcery CodeBench的维护者使用该选项构建他们的发行版会很好，但唯一直接的解决方案是自己构建libc，设置其中一个或两个标志（根据我的经验{{1} } 足够）。如果在捕获未处理的异常（通过-funwind-tables）时还需要堆栈跟踪，那么您还需要重建libstdc ++。

在我的工作场所，我们需要两种情况的回溯（SIGABRT和未处理的异常），并且由于libstdc ++是工具链的一部分，我们自己重建了工具链。工具crosstool-NG使这相对容易。在配置实用程序std::set_terminate中，我们输入了部分./ct-ng menuconfig并编辑了Target Options（将构建变量TARGET_CFLAGS设置为）Target CFLAGS。生成的工具链（更具体地说，使用生成的工具链构建中的libc和libstdc ++）几乎在所有情况下都为我们提供了完整的回溯。

我发现了一个案例，我们仍然没有获得完整的回溯：如果崩溃发生在最初用汇编编写的函数中，例如-funwind-tables（不幸的是，这不是不常见的事情）。也许某些选项需要传递给汇编程序，但我没有时间对此进一步调查。

Answer 2

这是因为在ARM上的glibc中中断了信号处理程序的展开。几年前，我已经对此进行了深入研究，并设法create a working standalone fix。困难的部分是在glibc中挖掘未记录的异常处理的肠道，之后该修复很简单。

我将此邮件发布到glibc邮件列表中，以回复有关此问题的旧帖子，希望glibc开发人员将我的独立修补程序作为指南来在glibc中进行适当的修复，但这从未发生。

最近我再次对其进行了测试：事实证明，该问题仍未在glibc中得到修复，并且由于glibc的变化，~~我的修复不再起作用~~。更新：我已修复它！

ARM平台上的SIGABRT信号没有回溯？

2 个答案: