gpt4 book ai didi

c - ARM 平台上没有来自 SIGABRT 信号的回溯?

转载 作者:IT王子 更新时间:2023-10-29 00:07:13 32 4
gpt4 key购买 nike

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

它们在 x86 桌面 (Ubuntu) 上运行良好,但在目标设备(基于 ARM)上,Abort 信号的回溯(由于 double-free 错误)仅显示三个帧:信号处理程序还有两个来自 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 中的东西(没有用)!

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

If you link with the debugging C library, -lc_g, you'll get debugging info back past abort().

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

如果我改为生成段错误(例如,将 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_CHECK_=0:无错误信息(double free 被忽略!)

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 之类的问题在于回溯必须遍历由 abortgsignal 等 libc 函数生成的堆栈帧,并且失败是因为该 lib 未构建使用这些开关中的任何一个(在我所知道的任何发行版中)。

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

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

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

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

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com