我在信号处理程序中使用' backtrce()'和' backtrace_symbols_fd()'函数来生成用于调试的回溯(GDB不可用)。

它们在x86桌面版(Ubuntu)上可以正常工作,但是在目标设备(基于ARM)上的上Abort信号的回溯(由于双重释放错误)仅显示三帧:信号处理程序,而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中的内容(无用)!

我发现一个邮件列表帖子说:



这可能是相关的,但是-lc_g在我的编译器上不起作用(ld:找不到-lg_c)。

如果我生成段错误(例如,将crashme()函数更改为使用“char * p = NULL; * p = 0;”而不是double free,则backtrace在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

最佳答案

看来您已经做了大量研究,知道您在编译器命令行中需要-funwind-tables-fasynchronous-unwind-tables开关。实际上,它们中的任何一个似乎都足够,但是如果没有它们的回溯,显然根本行不通。现在,类似SIGABRT之类的问题是回溯必须遍历由libc函数(例如abortgsignal)生成的堆栈帧,并且失败,因为该lib不是用那些开关(我知道的任何发行版)构建的。

虽然很高兴请Sourcery CodeBench的维护者使用该选项构建其发行版,但唯一的直接解决方案是自己构建libc,并同时设置两个或两个标志(根据我的经验,仅-funwind-tables就足够了)。如果在捕获未处理的异常(通过std::set_terminate)的情况下还需要堆栈跟踪,则还需要重建libstdc++。

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

我发现一种情况下,我们仍然没有得到完整的回溯:如果崩溃发生在最初用汇编语言编写的函数中,例如memcpy(不幸的是,这种情况并不罕见)。也许需要将一些选项传递给汇编器,但是我没有时间进一步研究。

关于c - 在ARM平台上没有SIGABRT信号的回溯吗?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/31528824/

10-13 03:16