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

我正在信号处理程序中使用“backtrce（）”和“backtrace\u symbols\u fd（）”函数生成用于调试的回溯（GDB不可用）

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

为什么我不能从手臂上的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;
}

对于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，您将得到调试 返回过去中止（）的信息

这可能是相关的，但是-lc_g在我的编译器上不起作用（ld:cannotfind-lg_c）

如果我生成一个seg错误（例如，将crashme（）函数改为使用“char*p=NULL；*p=0；”而不是双自由度），则回溯在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\u CHECK\u0:没有错误消息（忽略双自由！）

MALLOC_CHECK_u2;=1:错误消息，但程序仍在继续

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

我的交叉编译器报告： gcc版本4.6.1（Sourcery CodeBench Lite 2011.09-70）

---

目标设备的linux内核版本为3.8.8

您似乎已经做了充分的研究，知道您需要编译器命令行中的开关

-funwind tables

和

-fasynchronous unwind tables

。实际上，它们中的任何一个似乎都足够了，但如果没有它们，回溯显然根本不起作用。现在，不是吗像SIGABRT这样的东西的麻烦在于回溯必须遍历由libc函数生成的堆栈帧，如

abort

和

gsignal

，并且失败，因为lib不是用这些开关中的任何一个构建的（在我所知的任何发行版中）

尽管请求Sourcery CodeBench的维护人员使用该选项构建他们的发行版是很好的，但唯一直接的解决方案是自己构建libc，并设置其中一个或两个标志（以我的经验，仅设置

-funwind tables

就足够了）。如果在捕获未处理的异常时还需要堆栈跟踪（通过

std:：set_terminate

），则还需要重建libstdc++

在我的工作场所，这两种情况都需要回溯（SIGABRT和未处理的异常），并且由于libstdc++是工具链的一部分，我们自己重新构建了工具链。该工具使这项工作相对容易。在配置实用程序

/ct ng menuconfig

中，我们进入了

目标选项部分
并编辑了
目标CFLAGS
（设置构建变量Target\u CFLAGS）到
-funwind表
。生成的工具链（更具体地说，使用生成的工具链构建中的libc和libstdc++）在几乎所有情况下都为我们提供了完整的回溯

我发现有一种情况我们仍然无法得到完整的回溯：如果崩溃发生在最初在汇编中编写的函数中，例如
memcpy
（不幸的是，这种情况并不少见）。可能需要将某些选项传递给汇编程序，但我没有时间进一步研究。
这是因为在ARM上的glibc中，通过信号处理程序进行解卷是不正确的。几年前，我对此进行了深入研究，并设法做到了。最困难的部分是在当时的情况很简单，几乎微不足道

我把这篇文章发布到glibc邮件列表上，作为对一个关于这个问题的老帖子的回复，希望glibc开发人员能够以我的独立补丁作为指南，在glibc中正确地修复它，但这从未发生过

最近我又对它进行了一次测试：结果表明，这个问题在glibc中仍然没有得到解决，而且由于glibc的更改，我的解决方案不再有效。更新：我已经解决了它！
你看了吗：它给出了一个如何在不需要gdb的情况下使用回溯的示例。请告诉我这是否有帮助，谢谢。@Kozmik是的，已经有了基本上都是这样（见问题和随附的示例代码）。但是，对于由双重自由引起的ABRT，它不能正常工作。你能尽可能简短地说明你的要求吗？我对你的问题有点困惑，你到底在寻求什么帮助。“如何（在ARM平台上）”对于由双重空闲引起的中止信号，我是否得到有用的回溯跟踪？”。使用“backtrace（）”函数，我只得到三个帧，一个来自信号处理程序，两个来自libc，这是没有用的，因为我试图找出（在我的代码中）的位置双重释放正在发生。请注意，当代码在我的Ubuntu桌面上运行时，反向跟踪确实正常工作，因此ARM编译器似乎存在问题。您可以尝试使用MALLOC_CHECK________________________________________
 # 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]
#