Debugging Android NDK C/C++ code in Eclipse - breakpoints are not hit

Question

I downloaded Android SDK Bundle for Linux and Android NDK. ADT was installed, I installed CDT.

I created a Android project and added native support (jni). Then I wrote native function in java-code which exporting in c++ code. In c++ code I defined this function.

Java-code:

static {
    System.loadLibrary("test");
}

private native String get_text_from_cpp();

c++ code (h):

extern "C"{
   JNIEXPORT jstring JNICALL Java_com_example_test_MainActivity_get_1text_1from_1cpp(JNIEnv *, jobject);
}

c++ code (cpp):

JNIEXPORT jstring JNICALL Java_com_example_test_MainActivity_get_1text_1from_1cpp(JNIEnv * env, jobject){
    return env->NewStringUTF( "hello from C++" );
}

Code works without errors. But when I set breakpoint in c++ code it is not hit.

build-nkd NDK_DEBUG = 1 - are included

I followed this instructions http://tools.android.com/recent/usingthendkplugin

Android.mk in jni/ has LOCAL_CFLAGS := -g

I have read very much information but I could't customized Eclipse. Please, help anybody.

PS: I am sorry for my English is not my native language. I have difficulty in writing.

Add: Also during debug in console shows: "warning: Could not load shared library symbols for 95 libraries, eg /system/bin/linker. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? warning: Unable to find dynamic linker breakpoint function. GDB will retry eventurally. Meanwhile, it is likely that GDB is unable to debug shared library initializers or resolve pending breakpoints after dlopen()."

Answer 1

The trick I use is to put a usleep call as the very first native line in my debug code.

This makes your thread sleep and gives the debugger a chance to be ready for you.

#include <unistd.h>

.
.
.

#ifndef NDEBUG
usleep(5000 * 1000);
#endif

Answer 2

After struggling a lot to debug on Eclipse this is my recipe:

Do the usual steps:

• Add android.os.Debug.waitForDebugger(); before loading your native library. This might help.
• Add APP_OPTIM := debug in Application.mk
• Build with ndk-build NDK_DEBUG=1

Then, what I found different:

• Open a console and run:

adb pull /system/bin/linker <your_project_base_dir>/obj/local/armeabi/linker

Depending on your device you might have to write armeabi or armeabi-v7a . You only need to do it once (I noticed that running ndk-gdb manually was doing that. Executing that command manually the breakpoints started to work)

• Finally, to debug use the menu "Run -> Debug As -> Android Native Application"

Answer 3

You can use DS-5 CE Android Debug tool provided by ARM as a plugin to your eclipse. It works really well and provides a very good and easy UI for debugging. From my personal experience it is lots better than the traditional way of debugging the ndk app.

Please refer the below link which will provide you with the details of how to use the DS-5 debugger:

https://developer.arm.com/products/software-development-tools/ds-5-development-studio/resources/tutorials/android-native-app-debug-tutorial

Answer 4

Your app executes the JNI function very early, so that the debugger is not ready yet. Unfortunately, it takes a while for gdb to establish the remote connection, see http://visualgdb.com/documentation/appstartup

Instead of fighting the windmills, add a button to your activity, and call the same native method onClick() of that button - it will be easier to catch the breakpoint.

BTW, the warning about 95 libraries is perfectly normal. These are the system libraries which you don't want to debug, and don't have sources for.

Answer 5

consider adding:

android.os.Debug.waitForDebugger();

before your native call, this makes your app wait until the debugger attaches, could help you avoid sleeping / using a button.

Answer 6

I had this issue, and the only thing that worked for me was putting

Thread.sleep(2000);

before the JNI library is loaded. This gave enough time for the debugger to attach before the call to System.loadLibrary crashed the app. Helped me to locate the problem C++ code.