ndk-stack can not get full stack

Question

I wrote a piece of code, in order to test the ndk-stack Here is the code fragment

libtest.so

    std::vector<int> testVec;

    testVec.at(500);

But I get was incomplete stack

********** Crash dump: **********
Build fingerprint: 'MI/casablanca_icntv/casablanca:4.2.2/CADEV/1253:user/release-keys'
pid: 24989, tid: 24989  >>> com.ktcp.video <<<
signal 11 (SIGSEGV), fault addr deadbaad
Stack frame #00  pc 0001a852  /system/lib/libc.so: Routine ????:0
Stack frame #01  pc 00018190  /system/lib/libc.so (abort): Routine ????:0
Stack frame #00  pc 0001a852  /system/lib/libc.so: Routine ????:0
Stack frame #01  pc 00018190  /system/lib/libc.so (abort): Routine ????:0
Stack frame #00  pc 0001a852  /system/lib/libc.so: Routine ????:0
Stack frame #01  pc 00018190  /system/lib/libc.so (abort): Routine ????:0
Stack frame #00  pc 0001a852  /system/lib/libc.so: Routine ????:0
Stack frame #01  pc 00018190  /system/lib/libc.so (abort): Routine ????:0
^C^C

In the stack did not see my code, incomplete stack

How to fix it

Answer 1

0xdeadbaad was used by Bionic libc to indicate a deliberate abort. You can see a call to abort() on the fragment of stack you do get. I'm guessing you're triggering an assertion failure (which would show up in logcat).

On some versions of Android, in some circumstances, you don't get a good trace from abort(). Part of the problem is that the function was tagged with the noreturn attribute so the compiler wouldn't spit out complaints when you did something like this:

int foo(int x) {
    if (x == 0) {
        return 12345;
    } else {
        abort();
    }
}

If abort() returned, this method would return an undefined value. On ARM, the return address lives in the LR register, and is preserved on the stack if necessary... but if the function doesn't return, then there's no need to save the return address, so the compiler is allowed to throw it away. This works out great until you want to have that address for the stack trace. If LR gets re-used, and the old value wasn't spilled to the stack, it's simply gone.

I think there might have been a release where the compiler issue was fixed, but some assembler meta-data was wrong, leading to similar trouble.

Recent versions of Android should not exhibit this behavior. Recent versions also replaced access to 0xdeadbaad with the more traditional SIGABRT, so you no longer see this particular crash signature.

(FWIW, you can see an attempted workaround for noreturn in 4.2.2 (see comments). It worked in earlier versions of the system.)

Answer 2

it says signal 11 (SIGSEGV), fault addr deadbaad, where 0xDeadBaad (dead, bad) is likely what is stored by default into uninitialized memory (it's an old pun). So it tries to read or execute uninitialized memory.