Add support for Android 5.0

[dtr2]

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;
}

[xroche]

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!)

[dtr2]

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...

[dan-ryan]

Any update on this?

[Jayatubi]

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

[dtr2]

libunwind.so is there.

-- dror.

On Mon, Mar 9, 2015 at 8:22 AM, Jayatubi [email protected] wrote:

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

— Reply to this email directly or view it on GitHub https://github.com/xroche/coffeecatch/issues/15#issuecomment-77805758.

[xroche]

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

[Jayatubi]

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.

[Jayatubi]

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

[xroche]

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]

[dtr2]

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 [email protected] 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 https://github.com/xroche/coffeecatch/issues/15#issuecomment-78349161.

[xroche]

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 ?

[dtr2]

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 [email protected] 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 https://github.com/xroche/coffeecatch/issues/15#issuecomment-78429946.

[VioletGiraffe]

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?

[anyshu]

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.

[ennetys]

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

[dtr2]

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" [email protected] 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 https://github.com/xroche/coffeecatch/issues/15#issuecomment-153972048.