Develop Reference

How to symbolize stack traces of a stripped shared library

I have a crash report for my app from Google Play services which looks like this:
backtrace:
#00 pc 00000000001b46a0 library.so
#01 pc 0000000000604464 library.so
#02 pc 0000000000c8ed1c library.so
I also have a .map file for library.so which helps me to locate function names and transform stacktrace into more readable format:
backtrace:
#00 pc 00000000001b46a0 library.so foo()
#01 pc 0000000000604464 library.so bar()
#02 pc 0000000000c8ed1c library.so zoo()
But manually resolving function names is error-prone and it doesn't give me the line numbers is source code which caused the crash.
I've considered an idea to store an unstripped version of library.so when publishing new version so that I could use ndk-stack tool, but AFAIK function addresses for stripped and unstripped binaries are differ.
So my question is it possible to continue publishing stripped binary and have means to automatically symbolize stack traces with line numbers?
Any suggestions will be greatly appreciated

ndk-stack is exactly built for this purpose, don't worry. You feed the unstripped library.so to it, and get the best stack trace you can achieve!
Make sure that you don't mix debug/releas versions, and keep the unstripped version for every binary that goes into production (or make sure that you can reliably rebuild such unstripped version for the corresponding git tag).

Android caffe built demo shows error

Being new to Android NDK Caffe, I would like to use built version in my Android project. I tried to run this built sample demo, but while running, it showed the following:
03-26 14:46:35.697 2800-3042/com.sh1r0.caffe_android_demo A/libc﹕ Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 3042 (AsyncTask #1)
(the app crashed)

I can see that the sigsev signal is thrown through android AsyncTask.
The problem could come from this function.
caffeMobile.predictImage(strings[0])[0]; //line 160 of MainActivity
This signal comes from JNI and it is very difficult to know where is the problem unless you can debug natively (through ndk) the app. The caffe-sample is not configured to debug on native method.
Try this issues to manage the error:
Ensure that your image path in this string[0] arrays are not empty. and exists.
Ensure that the other caffeMobile functions are able to exec without
problems, for example:
caffeMobile = new CaffeMobile();
caffeMobile.setNumThreads(4);
caffeMobile.loadModel("/sdcard/caffe_mobile/bvlc_reference_caffenet/deploy.prototxt", "/sdcard/caffe_mobile/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel");
If you are able to execute the other functions, probably your image path is not correct, check.
If you are not able to execute loadModel or setNumThreads function, probably the apk is not loading libjni.so library correctly , or the jni bridge is not able to locate jni functions.

Google Developer Console Crash Reading for cocos2dx crashes

I have some stack traces in my Crash Tab in Developer Console, I was wondering how to read and debug them. The code is in cocos2dx so its really not human readable.
I know the technique with the ndk-stack where it tell you the class and line number etc. but can it be applicable in this scenario since I don't have the obj/local/armeabi folder with me.
adb logcat | ndk-stack -sym ./obj/local/armeabi is the command which I am talking about.
Is there any other solution to solve this problem, so that I can see what crashes users are experiencing.
Thank you.
A stack trace from the application. How can we trace this? And its crashing on just one device. Galaxy Tab 3 10.1 with such logs.
Build fingerprint:
'samsung/santos103gxx/santos103g:4.2.2/JDQ39/P5200XXUANC1:user/release-keys'
pid: 11321, tid: 11321, name: ldhelloworld >>> com.test.helloworld
<<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000005
Stack frame #00 pc 0002b098 Stack frame #01 pc 00000020
Crash dump is completed

Heap Corruption - SEGV_MAPERR in Android Native code

I am trying to create a small library for stream AES encryption, I started my work based on Facebook Conceal project (https://github.com/facebook/conceal), just changing some things and improving the wrapper around the native to support ciphers with padding.
It is working and it can decipher files without problems but I get random Heap Memory Corruptions when I work with large streams, and after a lot of time debugging I have been unable to find the error.
Here is my code:
https://gist.github.com/frisco82/9782725
I have tried to find memory allocation or free problems but there are almost no malloc or free, and jni call should be safe, the same goes for openssl ones (I have compiled my own but conceal provided ones also fail)
CheckJni does not warn about anything and while the context handling is a bit out of the box it doesn't seem broken (indeed Android conscrypt seems to use something similar).
Also if someone can point me to a Android native AES multistep (multiple update calls) library I will switch to that and forget this.
The error varies from time to time but it is usually similar to his:
03-26 10:33:02.065: A/dalvikvm(2475): ### ABORTING: DALVIK: HEAP MEMORY CORRUPTION IN mspace_malloc addr=0x0
03-26 10:33:02.065: A/libc(2475): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 2494 (AsyncTask #1)
03-26 10:33:02.205: I/DEBUG(933): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-26 10:33:02.205: I/DEBUG(933): Build fingerprint: 'generic_x86/google_sdk_x86/generic_x86:4.4.2/KK/999428:eng/test-keys'
03-26 10:33:02.205: I/DEBUG(933): Revision: '0'
03-26 10:33:02.205: I/DEBUG(933): pid: 2475, tid: 2494, name: AsyncTask #1 >>> com.proton <<<
03-26 10:33:02.205: I/DEBUG(933): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
Full stack traces:
http://pastebin.com/f6mDuQEj

It is working and it can decipher files without problems but I get
random Heap Memory Corruptions when I work with large streams.
From above line it looks to me that your program is clearly overwriting the memory which was allocated implicitly or explicitly by your code. I was trying to understand your code however it was not clear to me. But I tried to look from memory corruption scenario and found that your program does have malloc/free call which might lead to memory overrun.
EVP_CIPHER_CTX *ctx = (EVP_CIPHER_CTX*) malloc(sizeof(EVP_CIPHER_CTX));
EVP_CIPHER_CTX_init(ctx);
EVP_CIPHER_CTX *ctx = (EVP_CIPHER_CTX*) malloc(sizeof(EVP_CIPHER_CTX));
EVP_CIPHER_CTX_init(ctx);
I tried to check the layout of the EVP_CIPHER_CTX structure but it was not available in your code. But I saw that these pointers are getting used in various context within your program. Now you should check that under which scenario your buffer can be overwritten as some places you have used different keyLength and depending on this your program is executing different function. I think you may want to review these codes and see whether overflow is possible!!!....
As your application would be running on android based system where we can not run any dynamic tool(Valgrind/WinDBG/Pageheap..) so I guess you need to review your code by putting some log at important place and see where you are overwriting.
Hope above information would be useful for you to understand your problem.

After all I was able to work around this problem, EVP_CipherUpdate (or jni ReleaseByteArrayElements) sometimes overflow the output buffer causing the heap corruption, nothing in my code was wrong and also it was not a problem with the caller as replacing EVP_CipherUpdate with a memcpy call with the same parameters worked as expected and there was no heap corruption.
So the solution was adding some extra length to the output buffer sent to nativeUpdate and the error was gone.
I have made the full working version of the library for others to use at:
https://github.com/frisco82/conceal

ndk-stack not working

I am invoking ndk-stack as follows:
cat file_temp | ~/workspace/android-ndk-r6b/ndk-stack -sym /home/xyz/trunk/apk/obj/local/armeabi/
It finds the crash fingerprint but fails to show me the stack analysis. The error printed is:
ndk-stack: elff/elf_file.cc:102: static ElfFile* ElfFile::Create(const char*): Assertion `read_bytes != -1 && read_bytes == sizeof(header)' failed. Stack frame #00 pc 43121300 Aborted
Any ideas?
Thanks.

This is the ndk-stack program being unable to read the unstripped version of your shared libraries.
The specific crash occurs because a file exists matching the module name, but it's not large enough to contain an ELF header.
Things to do:
Check that the files contained in the directory supplied via -sym are correct (and not truncated).
Remove truncated files or files smaller than a few hundred bytes.
If you're curious, the source code for ndk-stack is in the android source tree under ndk/sources/host-tools/ndk-stack