Debugging an android crash

-
So lets say one of your android app crashes and you get something like this in your logcat:

Here #00 tells us the address in the program counter. But this information is pretty useless. To translate into actual file and line numbers we can use a tool called addr2line. For NDK4 it is located at android-ndk-r4b/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin. For NDK5 it is at a different location. So we go to this location and run the tool:
addr2line -f -e mydroid/gingerbread_2.3.3_GINGERBREAD/modified/out/target/product/crespo/symbols/system/lib/libmedia.so 0004853a
This gives us the file and line numbers we are looking for. We use the code in the symbols directory because that has the unstripped version of the libraries.


Comments

Post a Comment

Popular posts from this blog

endmenu in different file than menu?

-
So I was adding my driver to the Linux kernel. Made a new Kconfig file and added 'menu' and 'endmenu' sections. But when I compiled the kernel I got an error saying 'endmenu in different file than menu'. Reason: There has to be a new line character after endmenu in your Kconfig file!
Read more

A binary with debug symbols with the Android NDK

-
First go into the Android.mk file in your jni folder and add this line: LOCAL_CFLAGS  += -g This is going to enable the debug compile option. You might have a separate option for logging more data. Next go into Application.mk and uncomment this line: APP_OPTIM := debug (or add it if it isnt there) This should be sufficient. Now when you run the ndk-build (You can run ndk-build V=1 to enable the verbose option), you should get the debuggable binaries. For some reason the binary I get in the libs/armeabi folder is not the debuggable one, this one has its debug options stripped out. To get the debug one grab it from obj/local/armeabi.
Read more

Multi Threading in Android

-
It is good practice to not do computation intensive work on the UI Thread. In fact starting from HoneyComb, you get a NetworkOnMainThread exception if you try and do any network processing on the main thread. So we should do background work in a new thread. One thing we need to consider is that only the UI thread can update the UI, so when our background thread wants to update the UI, we need a means to communicate between threads. Actually even your background thread can update the UI, but this is really dangerous and your app can crash! Android provides a lot of multi threading constructs for us. AsyncTask is by far the easiest way of multithreading in Android. When you create a new AsyncTask object the framework creates a new thread for you and provides methods to communicate with the UI. No threads, no handlers and no Executors (Because it uses these classes internally)! So why not use AsyncTask all the time? Well, because these are suited for background work that typically l...
Read more