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

Question

我在信号处理程序中使用 '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 中的一些东西（没用）！

我发现了一个邮件列表帖子，上面写着：

如果你链接调试 C 库，-lc_g，你会得到调试 信息返回到 abort()。

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

如果我生成 seg 错误，则回溯在 ARM 上可以正常工作（例如，将 crashme() 函数更改为使用“char *p = NULL; *p = 0;”而不是 double free。

对于获取回溯的其他方法有什么想法或建议吗？

[--编辑--]

我按照 cmets 中的建议尝试了一些 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 这样的东西的问题在于，回溯必须遍历由 libc 函数（如 abort 和 gsignal）生成的堆栈帧，并且失败是因为该 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（不幸的是，这种情况并不少见）。也许需要将某些选项传递给汇编器，但我没有时间进一步研究。

Answer 2

这是因为在 ARM 上的 glibc 中通过信号处理程序展开的操作被破坏了。几年前我已经对此进行了深入研究，并设法找到了create a working standalone fix。困难的部分是在 glibc 中挖掘异常处理的未记录内容，之后修复很简单，几乎是微不足道的。

我将其发布到 glibc 邮件列表，作为对有关此问题的旧线程的回复，希望 glibc 开发人员将我的独立修复作为指导以正确地在 glibc 中修复它，但这从未发生过。

最近我又测试了一次：发现问题在 glibc 中仍然没有修复，并且由于 glibc 的变化我的修复不再有效。 更新：我已经修好了！