Add support for Android 5.0

Question

Add support for Android 5.0

Opened this issue 10 years ago · 16 comments

There's no "libcorkscrew" in Android 5.0. Instead, there's a C++-based "libbacktrace.so".
here's a sample code to use it:

include "backtrace/Backtrace.h"

int btdump(int sig, struct siginfo * info, void * ctx) {

    //Backtrace* t = Backtrace::Create(getpid(),0,NULL );
    void* libbacktrace = dlopen( "libbacktrace.so", RTLD_LOCAL );
    if ( !libbacktrace ) 
        return -1;
    Backtrace* (*create)(int,int,void*);
    *(void**)&create = dlsym( libbacktrace, "_ZN9Backtrace6CreateEiiP12BacktraceMap" );
    if ( !create ) 
        return -1;
    Backtrace* t = create(getpid(), 0, NULL );
    if ( !t ) 
        return -1;

    int ret = t->Unwind(0, (ucontext*)ctx);
    if ( !ret ) {
        return -1;
    }
    int count = t->NumFrames();

    DUMP( "backtrace:" );
    for ( int i=0; i<count; i++ ) {
        std::string line = t->FormatFrameData(i);
        DUMP( "\t%s",line.c_str());

    }
    return 0;
}

Answer 1 · 2014-12-14T21:08:36.000Z

Darn, thanks, I'll have a look. (By the way, what a terrible idea to rewrite in C++ something which was working and was very simple. Dynamically loading C++ is a real pain in the ass -- C++ is generally a pain in the ass at low-level -- What a terrible and idiotic idea you had, Google!)

Answer 2 · 2014-12-15T22:09:39.000Z

C++ is not that bad... and if you create an extern "C" creator method, then its as easy to start as a standard C method... and the benefit is that once you have the object, virtual methods work seemlessly - no need to bind them one by one...

Answer 3 · 2015-03-09T05:11:12.000Z

Any update on this?

Answer 4 · 2015-03-09T06:22:04.000Z

How about the "libunwind.so" which shipped with 5.0?

Answer 5 · 2015-03-10T21:37:08.000Z

libunwind.so is there.

-- dror.

On Mon, Mar 9, 2015 at 8:22 AM, Jayatubi notifications@github.com wrote:

How about the "libunwind.so" which shipped with 5.0?

—
Reply to this email directly or view it on GitHub
#15 (comment).

Answer 6 · 2015-03-11T06:02:27.000Z

Yep, I'm lagging a bit, but anyway unwind support is already amost there in coffeecatch, I probably just need to dynamically load it.

Answer 7 · 2015-03-11T06:06:19.000Z

Is there any way to make libunwind to work with sigaction? All the samples I could found on the internet are about the current stack only.

Answer 8 · 2015-03-11T06:09:06.000Z

And I've made the libcorkscrew works on Android 5, because I need unwind_backtrace_signal_arch, by extract the code from AOSP and compile it statically into my project. It works well but I saw some issues about libcorkscrew here: https://groups.google.com/d/msg/android-platform/VKlX7sNEV10/2XQNqy5awjkJ

Answer 9 · 2015-03-11T19:14:37.000Z

Darn, of course the Android libunwind.so is not the "classical" gcc-style libunwind (_Unwind_Backtrace() et al.) but with a totally different API. Lollipop is a definitely real pain in the ***.

"Backward compatibility ? Who cares!"

Stay tuned, I'll have to dig in this new exotic API!

[rant]

I'm still puzzled that the inane libbacktrace API has been pushed as the new official one

C++: unusable for C-only code, require uncool non-standard symbol mangling for dynamic load
Use of C++ objects absolutely everywhere (hey! this API will be used in case of crashes, and possibly within signal handlers, so let's allocate dozens of C++ objects because it is always safe to do that in a signal-safe way! yes, trust me!)
Use of std::string (you wanted to use this API in pure C ? Nope!) even to store symbol names

[/rant]

Answer 10 · 2015-03-11T22:20:30.000Z

Also, if you look at stack traces on L devices, you'll see that it fails to
unwind the stack in many cases. usually 2 lines of stack (or one) and
that's all
Also, by default they have the processes un-dumpable. In order to collect
stack traces of my code, I add to the program:
prctl(PR_SET_DUMPABLE, 1);
without which, the debuggerd can't do anything.

-- dror.

On Wed, Mar 11, 2015 at 9:14 PM, Xavier Roche notifications@github.com
wrote:

Darn, of course the Android libunwind.so is not the "classical"
gcc-style libunwind (_Unwind_Backtrace() et al.) but with a totally
different API. Lollipop is a definitely real pain in the ***.

"Backward compatibility ? Who cares!"

Stay tuned, I'll have to dig in this new exotic API!

[rant]

I'm still puzzled that the inane libbacktrace API has been pushed as the
new official one

C++: unusable for C-only code, require uncool non-standard symbol
mangling for dynamic load

Use of C++ objects absolutely everywhere (hey! this API will be used
in case of crashes, and possibly within signal handlers, so let's allocate
dozens of C++ objects because it is always safe to do that in a signal-safe
way! yes, trust me!)

Use of std::string (you wanted to use this API in pure C ? Nope!)
even to store symbol names

[/rant]

—
Reply to this email directly or view it on GitHub
#15 (comment).

Answer 11 · 2015-03-12T06:24:36.000Z

Also, if you look at stack traces on L devices, you'll see that it fails to unwind the stack in many cases. usually 2 lines of stack (or one) and that's all

Even with code built with -funwind-tables ?

Answer 12 · 2015-03-12T08:18:30.000Z

Didn't check. I'm talking about stack traces of arbitrary code, not code
that was compiled specifically to allow backtraces...

-- dror.

On Thu, Mar 12, 2015 at 8:24 AM, Xavier Roche notifications@github.com
wrote:

Also, if you look at stack traces on L devices, you'll see that it fails
to unwind the stack in many cases. usually 2 lines of stack (or one) and
that's all

Even with code built with -funwind-tables ?

—
Reply to this email directly or view it on GitHub
#15 (comment).

Answer 13 · 2015-04-09T11:52:01.000Z

Not sure if it's anything new to you, but this code works on my Android 5.0 Nexus. Just include <unwind.h> and no dynamic library loading required: http://stackoverflow.com/a/28858941/634821

The problem is, I don't know how to get the actual stack trace. The signal handler is called on a separate stack.

P. S. Could there be any issues with calling exit(EXIT_FAILURE); in COFFE_CATCH block? You say it shouldn't have an exit point, but since we've already crashed, I don't see any repercussions.

P. P. S. A quote from the manual in coffeecatch.h: "you must not use local variables before the complete try/catch/end block, or define them as volatile." Does it mean I can neither use local variables nor define them volatile, or that I must define them volatile if I want to use them before the block?

Answer 14 · 2015-07-07T05:24:53.000Z

Hi dtr2,
I used your sample code to catch call stack during crash. And an error occurred which "W/libbacktrace( 7610): virtual bool BacktraceThread::Unwind(size_t, ucontext_t*): tgkill 0 failed: Invalid argument", could you help to check what's problem?
I tested on Nexus 5 Android 5.02 and 5.1.

Thanks.

Answer 15 · 2015-11-05T06:49:04.000Z

Hi dtr2,
I work on Android 5.1.1. I have one question?
how to use the function "int btdump(int sig, struct siginfo * info, void * ctx)"?
Contretely, how can I get the parameter "ctx"? In the ucontext.h file(android platform), I do not find the function getcontext(..). if ctx == null, failure will be returned when calling UnWind function.

This puzzle me a lot.
Thanks

Answer 16 · 2015-11-07T19:58:35.000Z

Sorry didn't see your email earlier.

I need to see if i can test it. I no longer work on this jni based
project...
On Nov 5, 2015 8:49 AM, "ennetys" notifications@github.com wrote:

Hi dtr2,
I work on Android 5.1.1. I have one question?
how to use the function "int btdump(int sig, struct siginfo * info, void *
ctx)"?
Contretely, how can I get the parameter "ctx"? In the ucontext.h
file(android platform), I do not find the function getcontext(..). if ctx
== null, failure will be returned when calling UnWind function.

This puzzle me a lot.
Thanks

—
Reply to this email directly or view it on GitHub
#15 (comment).