Using Eclipse for Android C/C++ Debugging

Yes. You can use Eclipse for debugging of C/C++ code. I personally prefer cgdb but if you want to debug in Eclipse here is how.

See my previous spot how to set up cgdb debugger if you think it will suit you.

See my blog spot how to set up Eclipse for compiling and editing C/C++ code.

0) Prerequisities

You need Eclipse with CDT installed.
See my previous spot how to do it.

You also need Android ndk. Download it from http://developer.android.com/sdk/ndk/index.html and unpack it somewhere.

1) In Eclipse open your Android project which contains C/C++ code that you want to debug.

For this tutorial I’ve created simple MyAndroidProject.

2) Set android:debuggable=”true”. Set android:targetSdkVersion=”9″.

android:debuggable is a property of <application> tag in your AndroidManifest.xml. You can set it either directly in xml or in Application tab as in the screenshot.

android:targetSdkVersion=”9″ is a property of <uses-sdk> tag in your AndroidManifest.xml. You can set it either directly in xml or in Manifest tab as in the screenshot.

3) Run your application in debug mode and try to run ndk-gdb from console

To run application in debug mode press debug button (green bug/spider button in toolbox). In console go to your project directory and run ndk-gdb. It should succeed. If it fails you have to resolve the problem. Running ndk-gdb does not only ensure us that we are doing everything right so far, but also creates app_process, gdb.setup and libc.so files in obj/local/armeabi/ subdirectory of our project. Those files will be needed in later steps.

4) Create C/C++ debug configuration

Click on combo-box like down arrow next to debug button. Pop-up menu will appear and then select Debug Configurations…

In Debug Configurations window select C/C++ Application and press New button as advised on the right pane.

5) Set name of the debug configuration, and fill information on Main tab.

Select Standard Create Process Launcher by clicking on the blue Select other… link at the bottom of the window.

In C/C++ Application entry fill the path to the app_process binary which is located in obj/local/armeabi/ subdirectory of your project.

6) Click on Debugger tab and fill information about debugger.

Choose gdbserver Debugger as a Debugger.

It’s good idea to set initial breakpoint to some function but Android projects do not contain main function so fill some appropriate function name in Stop on startup field (I filled Java_com_example_map_MyAndroidProject_doSomething but you can see only Java_com_exam on the screenshot).

Set path to GDB debugger. The debugger is distributed with the Android ndk. Its located at toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb.

Set path to GDB command line. This path should point to obj/local/armeabi/gdb2.setup file inside your project. You don’t have gdb2.setup file there yet but you will create one in a while.

7) Click on the Connection tab (so you are in Debugger->Connection section of your C/C++ debug configuration) and fill information about connecting gdb with gdbserver.

Choose TCP as a type of connection and choose 5039 as a Port number.

8) Finally click Apply to save all the information about your C/C++ debug configuration.

This will save your new C/C++ debug configuration. Later, when running your application in debug mode you can choose in combo box associated with Debug button what debug configuration you want to use. Now you have two debug configurations. Android Java one which was created automatically for you when you’ve created Android project. And C/C++ one you’ve just created.

9) Go to the obj/local/armeabi/ subdirectory of your project and copy gdb.setup file to gdb2.setup file. Remove target remote :5039 line from gdb2.setup.

Eclipse don’t like target remote :5039 line in gdb setup file because it wants to enter this command internally (that is why you configured port 5039 in the previous step). Because the gdb.setup file is recreated by ndk scripts you have to copy it to the gdb2.setup and point Eclipse to the gdb2.setup file (we did this in step 6).

10) Go to the directory with Android ndk and copy ndk-gdb to ndk-gdb-eclipse. Remove execution of gdb command from ndk-gdb-eclipse.

Original content of ndk-gdb (Android NDK, r5):

if [ -n "$OPTION_EXEC" ] ; then
    cat $OPTION_EXEC >> $GDBSETUP
fi
$GDBCLIENT -x `native_path $GDBSETUP`


Content of ndk-gdb-eclipse:

if [ -n "$OPTION_EXEC" ] ; then
    cat $OPTION_EXEC >> $GDBSETUP
fi
## $GDBCLIENT -x `native_path $GDBSETUP`

Eclipse will run the gdb binary itself. So we have to remove the execution of gdb from ndk-gdb. To save original content it is good idea to copy the ndk-gdb to ndk-gdb-eclipse.

11) Now you are done. Put breakpoint in Java code after the execution of System.loadLibrary() and start your application in Debug mode.

Start your application in debug mode by clicking on Debug button. It will automatically choose Android debug mode. Later you will have to take care to choose Android Java debugging configuration by clicking on combo arrow associated with the debug button.

The reason that breakpoint should be after System.loadLibrary() call is that our C/C++ code will be already loaded in that point and we can set breakpoints in it.

12) When execution reach the breakpoint run ndk-gdb-eclipse from your project directory and start debugging in C/C++ debug mode.

Go to the directory with your project and run ndk-gdb-eclipse. This will start server-part of the debugging infrastructure. Now click on the combo arrow associated with the debug button in Eclipse and choose Debug Configurations… Choose your C/C++ debug configuration and click Debug button.

The C/C++ debug configuration will be added to recently used debug configurations so later you don’t have to walk into the Debug Configurations… window again and you can choose between Android Java debug configuration and C/C++ debug configuration by just clicking on the combo arrow associated with debug button in Eclipse. However always make sure which debug configuration you are about to execute as this is where mistakes happen very often (at least for me).

After you’ve started C/C++ debug configuration click Resume button (or press F8). The application should resume its run and stop on C/C++ breakpoint (if you have one).

13) Now you are debugging the C/C++ code. Have fun!

Try to set some breakpoints in C/C++ code, etc.

Note on running ndk-gdb-eclipse

You have to run ndk-gdb-eclipse every time before starting C/C++ debug session. This script starts the gdbserver binary on device/emulator so gdb (run by Eclipse) can connect to it.

I made several attempts to force Eclipse to run ndk-gdb-eclipse script itself on start of C/C++ debug session. The most logical point is to write small script which will run ndk-gdb-eclipse without parameters (or with –force parameter) and then run gdb from Android ndk toolchain with all the parameters. This script can be used as GDB debugger command in the Debugger tab. But even if this script (and ndk-gdb-eclipse inside) was run successfully, the resulting connection of gdb and gdbserver always broke apart.

Final note and thanks!

This tutorial is heavily inspired by Sequoyah Project native debug tutorial. See http://www.eclipse.org/sequoyah/documentation/native_debug.php

Many thanks to you guys.

About these ads
This entry was posted in Android and tagged , , , , . Bookmark the permalink.

76 Responses to Using Eclipse for Android C/C++ Debugging

  1. Graham says:

    I have tried following these instructions to debug one of the NDK example projects. However it seems to want a C/C++ project for the debug configuration and I am unclear how to set this up within the existing sample directory. There is no option for creating a project from existing source for a C/C++ project as there is for an Android project.

  2. Grubby says:

    hi,

    first of all thank you very much for your posts.
    i’m running from mac and i have one problem though: i don’t have the app_process, maybe because i’m deploying directly o a device? i’m trying to debug the OpenGL sample app that came with the Android NDK r6, which cannot run on the emulator.

    any advice would be appreciated.

    thanks

  3. yuli says:

    Amazing! I liked it! Spend the whole day to figure how to debug C on android, and this is the only tutorial which actually made sense/

    Followed to the letter, and all worked fine!

    One piece of advice – I started with HelloJni application which came with ndk_rev6

    Yuli

    • Grubby says:

      Hi Yuli,

      Did you deploy on the device or on the emulator.
      In either case, what did you complete on Step 5 for C/C++ Application path?

      Thanks,
      Grubby

  4. Grubby says:

    Nevermind, i’ve missed these yesterday :

    “Running ndk-gdb does not only ensure us that we are doing everything right so far, but also creates app_process”

    Sorry

  5. Dipraj says:

    Great ! Really very helpful !
    Out of several options I tried, this one worked the best. Another good thing is that this even works with ndk r6.

    Thanks a bunch Martin.

    Dipraj

  6. Claus says:

    Hi. Great tutorial but I run in into the same issue as Graham did.
    When I try to start the native debugging eclipse moans that this is not a C/C++ project.
    Do I need to convert the whole project to a CDT project ?
    Thanks for any hints,
    Claus

    • Claus says:

      Ok. Find the solution for this. I first need to create teh CDT project, resp. the “mixed” project.

      • jmallios says:

        Can you elaborate on this? Did you convert the project to C++, and if so, how?

      • Claus says:

        jmallios, i follow the instructions martin posted here:

        http://mhandroid.wordpress.com/2011/01/23/using-cgdb-with-ndk-debug-and-cgdb-tutorial/

        HTH,
        claus

      • jmallios says:

        So, after conversion to a C++ project and creating the C++ debug configuration, eclipse cannot find ndk-build when I debug.

        My environment is Mac OS X 10.6.8, Eclipse 3.7.1 with CDT 8.0.0.201109151620 and ADTools 12.0.0.v201106281929-138431, Android SDK 2.2 (version 8, Froyo), Android NDK r6b.

        To keep it simple, I’m trying to hit a breakpoint on the single line of C++ code in the NDK sample hello-jni.

        After following these instructions as best I can (clearly a different version of Eclipse according to the screenshots), I get the following console output when I try to Debug:

        **** Build of configuration Default for project HelloJni ****

        ndk-build all

        Cannot run program “ndk-build”: Unknown reason
        Error: Program “ndk-build” is not found in PATH

        PATH=[/usr/bin:/bin:/usr/sbin:/sbin]

        **** Build Finished ****

        Any ideas?

      • Claus says:

        so did you try to add ndk-build to your $PATH ?

      • jmallios says:

        Yes, but now when I debug the app using the new C++ debug config, I see:

        (no debugging symbols found)
        (no debugging symbols found)
        1-gdb-set confirm off
        1^done
        (gdb)
        2-gdb-set width 0
        2^done
        (gdb)
        3-gdb-set height 0
        3^done
        (gdb)
        4-interpreter-exec console echo
        4^done
        (gdb)
        5-gdb-show prompt
        5^done,value=”(gdb) ”
        (gdb)
        6-gdb-set auto-solib-add on
        6^done
        (gdb)
        7-gdb-set stop-on-solib-events 0
        7^done
        (gdb)
        8-gdb-set stop-on-solib-events 1
        8^done
        (gdb)
        9-target-select remote localhost:5039
        &”localhost:5039: Connection refused.\n”
        localhost:5039: Connection refused.
        9^error,msg=”localhost:5039: Connection refused.”
        (gdb)
        10-gdb-exit
        10^exit

        I’m confused about the exact sequence of events needed to hit a C++ breakpoint. I think I need eclipse to start the gdbserver itself on the emulator, meanwhile pausing execution until it connects…then resuming execution.

        The prescribed method seems to be setting a java breakpoint after the LoadLibrary call of the C lib, then opening a separate terminal and running ndk-gdb to start the server, then resuming in eclipse, but that seems ridiculous and slow for C development.

        Thx,
        Jason

  7. Jim says:

    I had a few more steps to get close to the same results, and fails in fine… In my case, gdb refuses to recognize the symbols and has no effect, though it gets connected properly…

    1) First of all, I had to add “LOCAL_CFLAGS := -Wall -g” in the project “jni/Android.mk” (btw this way I finally got C/C++ compilation warnings at last)

    2) Then, I had to comment out the line “$(hide) $(call cmd-strip, $(PRIVATE_DST))” in the “build/core/build-binary.mk” NDK installation folder, because it was stripping all the symbols from the the resulting JNI shared lib anyway (I spent some time on this one…)

    3) I do not understand why I have a different folder setup. May be I misconfigured my project, but my “app_process” is located in “./obj/local/armeabi-v7a/app_process” and not in “./obj/local/armeabi/app_process” as the rest of the world… I set up the other folders accordingly then, but I am somehowe unsure, especially since I fail to get the gas plant work at the end ;)

    4) Anyway, I can get Eclipse to connect to the debugger with the usual procedure (start Java debug with a breakpoint in System.loadLibrary, then ndk-gdb-eclipse, and finally start C++ debug.
    However almost every time, it complains and fails to load the symbols though. OK, I can tell it via gdb “file” option (just provide the path to the .so file). Then I can set/disables breakpoints in the C++ source, but they really have no effect. If I pause the C++ execution, then the Java side gets frozen, but I cannot do much more then continue execution.

    I’m getting out of ideas to have it work properly, may be some of you would have some nice advice of experience with these issues?

    Jim

    • Claus says:

      Did you try setting the pathes to the *.so files in gdb2.setup with “set solib-search-path”.
      As well as pathes to other source files with “directories”.
      HTH,
      Claus

      • Jim says:

        Thanks for your help, you probably are pointing in the right direction since the symbols are not loaded by default. I’m not sure what is the app_process that gets pulled from the device (it has np symbols btw). So I added an explicit “file obj/local/armeabi-v7a/myproject.so” in gdb2.setup, even though I guess Eclipse does or should usually do this on its own (I found nobody talking about this).

        ndk-gdb-eclipse –verbose tells me this though: “Using gdb setup init: /home/jeremie/workspace/smartgrappe/libs/armeabi-v7a/gdb.setup”, it seems to conflict with gdb2.setup as specified in eclipse. But may be it’s meaningless at this stage b/c the deal is first to get the gdb server up and ready if I understand.

        OK so the debugger really gets connected (as seen in adb logcat for example), and I start the C/C++ debugging configuration from Eclipse after having started the Java debug and breaked on System.loadLibrary.
        The eclipse debug console dumps a warning though:
        94-target-select remote localhost:5039
        &”warning: shared library handler failed to enable breakpoint\n”

        However it continues, dumps some thread infos (where symbols and line numbers are OK). Then it gets very slow dumping information about current breakpoints (~2sec per line), and finally pops up a dialog telling me “Target is not responding”, which locks in turn all the session including java debugging. No way to continue at all.

        Here is the end of the debug console in eclipse. At line 75+ it slows down to a halt. I entered none of the commands btw.

        74 info threads
        &”info threads\n”
        ~”* 1 Thread 1340 NonCopyable (this=0x1) at /home/jeremie/workspace/smartgrappe/jni/Base.h:79\n”
        74^done
        (gdb)
        75-stack-info-depth
        76-data-list-register-names
        77-data-list-register-names
        78-stack-list-frames 0 1
        79-break-insert /home/jeremie/workspace/smartgrappe/jni/imgprocessing.cpp:84
        80-break-insert /home/jeremie/workspace/smartgrappe/jni/imgprocessing.cpp:126
        81-exec-continue
        82 kill
        83-gdb-exit

        Hope someone can get me through…

  8. Jim says:

    My bad, the slow down / freeze went away after I rebooted the device :)

    Now my problem now seems unrelated to eclipse since I get the same issue with cgdb, so I’ll move my polluting thread to the sister page http://mhandroid.wordpress.com/2011/01/25/how-cc-debugging-works-on-android/

    If there is an admin here, he/she can delete my previous post to keep this page clean ;)

  9. Many thanks for the tutorial, works like a charm !

  10. Claus says:

    Hi,
    One more issue from my side: After I ran the GDB first time I changed a lot of function names.
    As well native functions wher I had set breakpoints. But now when I try to start the native part of the
    app, eclipse refers still to the old function names.

    I assume that this is cached somewhere, but I did not find the cache location, yet.
    If someone has a hint on this …

    Thanks, CLaus

  11. Kak0 says:

    Trying to get it working, unfortunately when I launch the debug configuration of the C/C++ app I get a ton of errors like
    “Error while mapping shared library sections:
    libstdc++.so: No such file or directory”,

    followed by “(no debugging symbols found)”

    and ends with “warning: Unable to find dynamic linker breakpoint function.
    GDB will be unable to debug shared library initializers
    and track explicitly loaded dynamic code.
    Cannot access memory at address 0x9620f0
    No symbol table is loaded. Use the “file” command.”

    Any clue about what it could come from ?

  12. stipus says:

    Thank you very much for your procedure ! It worked fine with ndk r6 !

    I first tried to debug my C++ Lib using __android_log_vprint(), but I quickly realized a real debugger would be a lot better …

    I searched for hours, tried several other procedures without success until I found and followed your procedure… it took me some time as:
    – some paths were different (“app_process” is located in “./obj/local/armeabi-v7a/app_process” and not in “./obj/local/armeabi/app_process” like Jim above)
    – the environment variable ANDROID_NDK_ROOT was not set on my system,
    – I did not select gdbserver in the C++ debug configuration (and as a result there was no connection tab with the port 5039 setting).
    – I was using stlport_static without running build/core/build-stlport.sh, and this produced warning messages that crashed the ndk-gdb and ndk-gdb-eclipse scripts (took me a long time to figure out this one!)

    Then I could set C++ breakpoints … find and fix my bugs !

    Thanks again :)

    • Tony says:

      How did you figure out that you had warning messages that were causing crashes? How exactly do you run ‘build/core/build-stlport.sh’ (I think you mean build/tools/build-stlport.sh)? I tried to run it and got errors. Is putting the following lines in my Application.mk the same:
      APP_STL := stlport_static
      STLPORT_FORCE_REBUILD := true
      ?

      Thanks.

  13. bowerymarc says:

    great guide — there’s no way in hell i would have figured out how to do that without this page – thanks. I did have to do some of the extras in some of the comments. #1 & 2 from Jim above
    – LOCAL_CFLAGS := -Wall -g
    – comment out the line “$(hide) $(call cmd-strip, $(PRIVATE_DST))” in the “build/core/build-binary.mk” NDK installation folder
    – added the extra paths though i’m not sure i needed to
    – build/core/build-stlport.sh since I’m using static stl – this was huge, as without doing it, the warning messages were piped into the next thing, in ndk_gdb script, thereby screwing the pooch.

    it is too bad that somehow ndk_gdb_exclipse can’t be made to run automatically, but i’m sure some eclipse expert out there will figure it out finally.

  14. Pingback: How to debug cocos2d-x and Java code using Eclipse | Plicatibu Software Development

  15. charley says:

    Dear all,
    I have done all the setups and also followed the others who have commented about the post…
    I get the following error finally

    Error while mapping shared library sections:
    /system/bin/linker: No such file or directory.
    Error while mapping shared library sections:
    libstdc++.so: No such file or directory.
    ……. and so on..
    I understand i need to link few libraries but am not clear about the steps ???
    Kindly guide.. any steps or pointers would be of great help…

    regards
    Charley

  16. Claus says:

    Hi,
    Is it also possible to do native debugging when using an external jar that has native components ?
    I have split my application into a pure Java application and an API project that has now the native stuff and just generates the *.jar and the *.so files. So i have no app_process file which I need to have in the debug configuration.
    Someone ever tried this ?
    Thanks,
    Claus

  17. grndvl1John says:

    I couldn’t get this to work at all. Would be nice if this was updated to newer versions of Eclipse, since none of these screen shots look like the Eclipse I am using. Also the location of the gdb.setup is not the same either.

    Thanks

    John

  18. Anuj Saluja says:

    I followed the steps to the T, but when I try to debug the C++ configuration, I get an error that it is not a valid C\C++ configuration. Any ideas?
    M

  19. Nick says:

    I managed to get this to work and can debug native code in the emulator. But how to debug on the device? I guess the debug configuration needs to be set up differently, but how. Thanks in advance.

  20. Regis says:

    Please, have a look to the question posted here: http://www.cocos2d-x.org/boards/6/topics/8512 and give an answer if you know how to solve this problem ! Thanks !

  21. Michael says:

    Thanks for such detailed instructions! I had an error with PATH variable too. And after almost 1,5 weeks found solution.
    Development IDE may hide system PATH and use it’s own instead. Detailed solution is here:
    How to solve problem with Motodev Eclipse for Android 3.1: wrong PATH It is for MOTODEV IDE, but Eclipse may have same thing.

  22. Simon says:

    Thanks for the tutorial. I found it difficult to get going, and even now while I think it works as expected in HelloJNI, it has odd segfaults and extreme slowness that have me unsure.

    I want to highlight what I found most difficult, as I think other people have had the same problem with the instructions here and at sequoyah:

    I was stuck wondering what was causing debug not to start, with message “connection refused” etc. My failure was not reading the instructions here precisely enough, making a few false assumptions.
    The steps 11 & 12 need to be reread a few times to realize – they tell you after setting up this new debug configuration and scripts etc –
    1. Start the Normal-Java-Android debug config, that is used for debugging java code, and stop that on a breakpoint
    2. then, run ndk-gdb-eclipse from the shell, (it runs for me with no output normally)
    3. only then, start the new android native debug configuration that we’ve been instructed to make
    4. After it seems to be running, continue the debug session in the normal java mode, such that breakpoints in native code should now be hit

    I think the steps are obvious once you recognize them, but when I was just trying to blindly follow steps I was missing what was actually been said, and I think other people were too.

  23. Henry says:

    I followed the steps and the comments on NDK r7b with Eclipse Indigo Windows 7 64-bit. It works on one of my project, but failed on my other project. Additional step I have to do is to uncheck the “Use full file path to set the breakpoints” checkbox in “Debugger” tab, I guess this is only needed for Windows operating system.

    I also experienced issues like “(no debugging symbols found)”, “cannot access address 0″, “cannot access address 0xfffffef8″, etc. Even with working project, the debugger seems too slow to use.

    With another project I got “Remote communication error: Bad file descriptor” error. Debugger cannot be launched successfully.

  24. Bruno Marques says:

    Hi!
    And thanks a lot for this tutorial.
    I still have a strange problem:
    When I start debugging the native code, I’ve got this message:

    >Error creating session
    >Cannot run program “C:\SDK\android-ndk-r8\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin\arm-linux-androideabi-gdb.exe”: Le fichier spécifié est introuvable.

    This file is the one I set in the “GDB Debugger” field, in the debugger options. And it’s a valid path (I can write this line in windows shell, and it execute the program…)

    Do you have an idea about my problem?

  25. Pingback: Crash in Android Native while changing to new Activity | PHP Developer Resource

  26. Virendra Shakya says:

    can you please tell what version of eclipse needs to be used? i don’t see any options in my eclipse (helios SR2) on mac.

  27. Tony says:

    Thank you for this tutorial as well as the previous tutorial “Using Eclipse for Android C/C++ Development”. Both were very helpful.

    After getting everything working (I think!), I was wondering about “Note on running ndk-gdb-eclipse”, so I thought I would try a slightly different approach, which seems to be working – at least on the version of Eclipse I am running (Indigo SR2) on a Mac.

    1. I made a new external tool to run ndk-gdb-eclipse: Run->External Tools->External Tools Configuration. Select Program, click “New”. Name: ndk-gdb-eclipse (or whatever you like), Location: (absolute path to ndk-gdb-eclipse – the script we made), Working Directory: (set to project directory), Arguments: –adb=(absolute path to adb).
    2. I made a new Launch Group to run the external tool and my C++ debug configuration: Run->Debug Configurations, select Launch Group, click “New”. Rename it to whatever you want. Click add, select “run” in Launch Mode dropdown, pick Programs->ndk-gdb-eclipse (or whatever you named it). Click add, select “debug” in Launch Mode dropdown, pick C/C++ Application->”MyAndroidProject C and CPP Debug” (or whatever you named your C++ debug config).
    3. That’s all. Follow all the other steps, but when you get to step 12 launch your new Launch Group.

  28. Guy says:

    Hi, I followed the post to the letter and got the same problems as mentioned above. The debugger can’t find the library. I saw that the “file” option of the gdb was mentioned. I saw in the gdb2.setup that such command already exists which tell the gdb where to find app_process and I added another line almost identical with the lib file. Now it is impossible to debug the application since it complains that the file does not exists, even that it appears at the same directory as app_process.

    my gdb2.setup looks like that:
    ———————————————————
    set solib-search-path ./obj/local/armeabi

    directory E:/Android/android-ndk-r8-windows/android-ndk-r8/platforms/android-14/arch-arm/usr/include jni E:/Android/android-ndk-r8-windows/android-ndk-r8/sources/cxx-stl/system

    file obj/local/armeabi/app_process
    file obj/local/armeabi/libhello-jni.so
    ———————————————————
    anyone can see the problem? (The only thing I thought of is that the library is deleted in the clean process and created after the gdb attempt to use it, but it doesn’t make much sense)

    Thanks,
    Guy.

  29. Uhh… my app targets API 8 (Android 2.2). Why do you say we should use android:targetSdkVersion=”9″? API 9 isn’t listed in SDK Manager (just API 8 and API 10=Android 2.3.3). I am also curious what android:debuggable=”true” does, given that Java debugging works without that attribute.

  30. Hmm, looks like I have to give up on this Eclipse debugging idea. After converting the project to C++, my program always crashes on startup! I can’t even reach step 3. LogCat spits out a whole lot of nonsense, I think the most relevant line is “signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 80b3d454″

    It’s a good thing I was modifying a backup copy of the project! Another weird thing is that after restarting Eclipse (Indigo), the C/C++ options are no longer accessible (the two C/C++ sections are missing from Project Properties). I retried the conversion a second time, with the same results (both times, the C/C++ options disappear after restarting.)

  31. Klodrik says:

    Thanks for the tutorial, would never have got this to work without it.
    I did get the error “no symbol table is loaded” when running the c/c++ debugging, fixed it by editing the gdb2.setup file. Changed the line “(path-to-ndk-folder)/platforms/android-14/arch-arm/usr/include (path-to-ndk-folder)/sources/cxx-stl/system/include jni”
    to
    “(path-to-ndk-folder)/platforms/android-9/arch-arm/usr/include (path-to-ndk-folder)/sources/cxx-stl/system/include jni”

  32. Tarun says:

    Can u give me a link to your tutorial in which i can debug the both j2me and c++ code simultaneously,as i am making a jar file of c++ code and adding it to the my j2me code,i want to debug both code simultaneously

  33. Haris says:

    Hi Martin thanks for your post…
    In my case Everything OK as you said other than the last step. First I ran the gdb server from my project root directory by the command “ndk-gdb-eclipse” and it is exiting without any error. But when I start debugging on c/c++ mode from the eclipse, I am getting the error like

    Target selection failed.

    Remote ‘g’ packet reply is too long: fcffffffc81783be10000000ffffffffe89e110000000000fffffffffc0000000000000014000000d42d9a42f84b5340688e12a8a01783bee32612a81cc5d0af10000020030205007574436f6e6e656374696f6e380000000000000054000000040000000000e0400700000000809c430000a04300809c430000c0410000b8410000f042000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004400000007000000000000000000000000000000000000000000000000000000000000000000f03f00000000000000800000000000000000000000000000000000000000000000000000000000000000b0f50c000000000000000000000000005bcf000000000000000000000000f03f0000000000000000000000000000f03f12000060

    Any Idea….?
    Thanks in advance………..

  34. Pingback: Android Nativ (C++) « Softwareplaudertäschchen

  35. abama7 says:

    Excellent document! All explained in detail, and saved a lot of time for a novice developer! Many thanks to the author!

  36. Pingback: Cannot step through code while debugging android NDK project video

  37. Pingback: Cannot step through code while debugging android NDK project | Code and Programming

  38. Pingback: debug ndk Jni that is a prt of andriod application : Android Community - For Application Development

  39. Krish says:

    I tried this on windows 64 bit (without and it works with some adjustments to paths.
    1. There is no app_process of windows. you need to get it from device and put it in libs folder yourself.
    2. The gdb.setup file does not need any changes.
    3. In my case, i had to edit the ndk-gdb.py file myself as it has wrong paths for utility executables( C:\Development\NDK\prebuilt\windows-x86_64 instead of C:\Development\NDK\prebuilt\windows) i essentially renamed the folder as per needs of the script.
    4. comment out last lines in ndk-gdb.py file.
    # gdbargs = [GDBCLIENT, ‘-x’, ‘%s’ % (GDBSETUP)]
    # if OPTION_TUI:
    # gdbhelp = subprocess.check_output([GDBCLIENT, ‘–help’]).decode(‘ascii’)
    # try:
    # gdbhelp.index(‘–tui’)
    # gdbargs.append(‘–tui’)
    # OPTION_TUI = ‘running’
    # except:
    # print(‘Warning: Disabled tui mode as %s does not support it’ % (os.path.basename(GDBCLIENT)))
    # subprocess.call(gdbargs)

  40. Meena says:

    Hi I tried this on windows 32 bit. I followed every step given in this site and while trying to debug am getting the error:

    Reading symbols from C:\Development\adt-bundle-windows-x86\android-ndk-r8d\workspace\Sample1\obj\local\armeabi\app_process…done.

    WARNING: no debugging symbols found in C:\Development\adt-bundle-windows-x86\android-ndk-r8d\workspace\Sample1\obj\local\armeabi\app_process.
    Either the binary was compiled without debugging information
    or the debugging information was removed (e.g., with strip or strip -g).
    Debugger capabilities will be very limited.
    For further information: http://wiki/Main/GdbFaq#No_debugging_symbols_found

    23-gdb-set confirm off
    23^done
    (gdb)
    24-gdb-set width 0
    24^done
    (gdb)
    25-gdb-set height 0
    25^done
    (gdb)
    26-interpreter-exec console echo
    26^done
    (gdb)
    27-gdb-show prompt
    27^done,value=”(gdb) ”
    (gdb)
    28-gdb-set target-async 0
    28^done
    (gdb)
    29-gdb-set auto-solib-add on
    29^done
    (gdb)
    30-gdb-set stop-on-solib-events 0
    30^done
    (gdb)
    31-gdb-set stop-on-solib-events 1
    31^done
    (gdb)
    32-target-select remote localhost:5039
    32^error,msg=”localhost:5039: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.”
    (gdb)
    33-gdb-exit
    33^exit
    Can anyone please help me. I do not know what is wrong?

  41. Tonya says:

    I am regular visitor, how are you everybody? This article posted at this web page is really pleasant.

  42. Pingback: Debugging native libraries for Android OS | BlogoSfera

  43. Pingback: Android NDK | codefail

  44. Amit Kumar says:

    Felt great when found this link configured all as described here still getting following error:

    Target selection failed.
    Remote communication error. Target disconnected.: No error.
    Remote communication error. Target disconnected.: No error.
    Remote communication error. Target disconnected.: No error.

    • Amit Kumar says:

      warning: .dynamic section for “D:/7zipAppCode/andro7z/obj/local/armeabi/linker” is not at the expected address (wrong library or version mismatch?)

  45. Amit Kumar says:

    warning: Could not load shared library symbols for 77 libraries, e.g. libstdc++.so.
    Use the “info sharedlibrary” command to see the complete listing.
    Do you need “set solib-search-path” or “set sysroot”?

    also getting these errors msg in console

  46. Amit Kumar says:

    Actually its missing sharedlibrary debugging information for libraries that I have not generated don’t know how to provide that information.
    Any Help is appreciated

  47. sbq says:

    Thanks for this tutorial. I followed it exactly and it worked for me first time on a device. I have not started using it over and over as I do development, yet. I got depressed around step 10 thinking “I have to do this every time? How will I remember?” If anyone figures out how to automate the launching of adb-gdb-eclipse that would be excellent. I may try the launch config described by Tony (May 29, 2012 at 21:52), it’s a little closer to automation.

  48. I have tried to debug native c on Android (eclipse on Mac)

    but get the following error:

    There is NO WARRANTY, to the extent permitted by law. Type “show copying” and “show warranty” for details. This GDB was configured as “–host=x86_64-apple-darwin –target=arm-linux-android”. For bug reporting instructions, please see: . Warning: /Users/eladb/MyWorkspace/Client/src/android/java/src/pcf: No such file or directory. Remote debugging from host 225.89.3.0 warning: while parsing target library list (at line 2): No segment defined for ..

    how can I fix this?

  49. Thank you for any other informative blog. The place else could I get that kind of information written in such an ideal way?
    I’ve a challenge that I’m just now running on, and I have been on the
    look out for such info.

  50. sleep aid says:

    I seldom comment, however i did a few searching and wound up here Using
    Eclipse for Android C/C++ Debugging | Android blog.
    And I do have a few questions for you if it’s allright. Could it be simply me or does it look like some of these remarks appear like written by brain dead individuals? :-P And, if you are writing on additional online social sites, I’d like to keep up with
    everything fresh you have to post. Would you list of every one of your community sites like your
    Facebook page, twitter feed, or linkedin profile?

  51. Marek says:

    Hi, i can’t connect to 5039. Please help !

  52. Heather says:

    I actually wonder as to why you named this particular
    blog, “Using Eclipse for Android C/C++ Debugging | Android blog”.
    In any event I really appreciated the blog!Thank you,Betsey

  53. Pingback: 【Win7下Android native code的编译和调试】 - Java - 开发者第1090472个问答

  54. Pingback: cannot access memory at address 0X1 after setting up gdb and eclipse to debug shared library from Android Application | Ask Programming & Technology

  55. sunhpj says:

    I got an error while starting ndk-gdb:
    ERROR: Could not extract package’s data directory. Are you sure that
    your installed application is debuggable?

  56. Rio says:

    This article is obsoleted, Android NDK plugin can debug its app directly.

  57. Thanks for sharing your info. I really appreciate your efforts and I am
    waiting for your further write ups thank you once again. how to
    hack facebook account

  58. Hi mates, pleasant piece of writing and pleasant urging commented here, I am
    genuinely enjoying by these.

  59. Pingback: Problems debugging C++ Android internal formula in Eclipse - Zufall

  60. Pingback: Fix Eclipse Cdt Error Launch Failed Binary Not Found Windows XP, Vista, 7, 8 [Solved]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s