Android内部_Unwind_Backtrace sigaction [英] Android _Unwind_Backtrace inside sigaction

问题描述

我试图在我的Android NDK应用程序中捕获诸如SIGSEGV之类的信号以进行调试. 为此，我设置了一个称为的提示.

I am trying to catch signals such as SIGSEGV in my Android NDK app for debugging purpose. For that, I have set up a sigaction that is called.

我现在正在尝试获取通话堆栈.问题在于_Unwind_Backtrace仅适用于当前堆栈，并且sigaction在其自己的堆栈中运行.

I am now trying to get the stack of the call. The problem is that _Unwind_Backtrace only works on current stack and sigaction runs inside its own stack.

那么，有没有办法获取接收到信号的执行指针的堆栈? (基本告诉_Unwind_Backtrace展开当前堆栈以外的其他堆栈吗?)

So, is there a way to get the stack of the execution pointer that received the signal? (Basically tell _Unwind_Backtrace to unwind another stack than the current?)

我应该指出:

• 不能使用backtrace()和backtrace_symbols()，因为这些功能未在Android NDK中提供

• Using backtrace() and backtrace_symbols() is not an option since those functions are not delivered in the Android NDK

我正在使用GDB调查本地设备上的崩溃.我不想替换GDB，当我向他发送测试版本时，希望能够从客户端接收有意义的堆栈跟踪.

I am using GDB to investigate crashes on my local devices. I do not want to replace GDB, I want to be able to receive meaningful stack traces from the client when I send him a test build.

我曾尝试按照fadden的建议从系统/核心使用Android的libcorkscrew，但是当我使用它的unwind_backtrace_signal_arch函数时，却得到了一个奇怪的回溯，并不代表崩溃.

I have tried using Android's libcorkscrew from system/core as proposed by fadden but when I use it's unwind_backtrace_signal_arch function, I get a strange backtrace that do not represent the crash.

推荐答案

您可以使用pthread_getattr_np和pthread_attr_getstack获取堆栈基地址，但是真正需要的是崩溃时的PC和SP.在Linux上，您可以将它们从ucontext中拉出.

You can get the stack base address with pthread_getattr_np and pthread_attr_getstack, but what you really need is the PC and SP at the time of the crash. On Linux, you can pull these out of the ucontext.

如果在配置信号处理程序时设置了SA_SIGINFO标志，则处理程序功能将获取三个参数，而不是一个.第三个void*自变量是ucontext指针.对于此问题的可接受答案解释得更多.

If you set the SA_SIGINFO flag when you configure the signal handler, your handler function gets three arguments instead of one. The third void* argument is a ucontext pointer. The accepted answer to this question explains a bit more.

一旦您拥有了所有可以展开的堆栈.如果您不介意超越NDK提供的功能，则Android的 libcorkscrew 具有可以展开堆栈并输出结果的函数. debuggerd守护程序使用它来将本机崩溃转储到日志文件中.

Once you've got all that you can unwind the stack. If you don't mind stepping outside the bounds of what the NDK provides, Android's libcorkscrew has functions that can unwind stacks and output the results. This is used by the debuggerd daemon to dump native crashes to the log file.

知道debuggerd记录的本机崩溃会在/data/tombstones/中生成堆栈转储可能很有用.文件权限使普通应用无法访问它，但是在经过修改的设备上，您只需将其拉出并发送即可.

It may be useful to know that native crashes logged by debuggerd generate stack dumps in /data/tombstones/. The file permissions render it inaccessible to normal apps, but on a modified device you could just pull these out and send them.

这篇关于Android内部_Unwind_Backtrace sigaction的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！