Android Studio 1.3 RC3 NDK Debugging help. Break Points not getting hit.

[Kyle Peplow]

Hello,

This is my first Android project and I'm attempting to do my work in C++. I noticed Android Studio has finally decided to support stronger NDK support so I attempted to get all this setup.

So far I can get the NDK teapot example working and running on my two 32bit arm based android devices as well as my own project. I hit a snag when I needed to hunt down a seg fault and none of my break points are getting hit. I've tried this in the teapot demo thinking maybe my configs for gradle or something else was causing the issue. 

Has anyone had luck with this? Is there extra leg work to get this working? 

I really would rather do my work in Android Studio as opposed to migrating over to Eclipse or using an expensive tool like the many visual studio GDB plugins since I'm on a tight budget at the moment (plus sanity is nice).

[Simon Taylor]

You'll need to set up a separate "native debug" run configuration in Studio. Currently I'm using the Android Studio 1.3 RC3 on the canary channel on OS X Yosemite.

Near the run button on the toolbar, there's a dropdown that lets you select the configuration to run. Drop it down, click Edit Configurations, click the + button at the top left of the list view and select "Android Native".

To fix the warning about JNI debugging support, I added this in my build.gradle:

android.buildTypes {
  debug {
    isJniDebuggable = true
  }

}

Then when your native configuration is selected, clicking the debug button should fire up the app, and show a "native debug" view with a console. For me it takes around 10 seconds until the console indicates that the debugger has successfully connected. From that point on, native breakpoints work for me. If the crash is early on in your app you may want to add a sleep in onCreate to give the debugger time to connect.

I've also managed to get breakpoints on both Java side and native side working - details here:

https://groups.google.com/forum/#!topic/adt-dev/egn8UScwQXQ

Hope that helps!

Simon

[Kyle Peplow]

Hey Simon,

Followed your instructions above, definitely filled in a missing step. 

When I try to attach to process however I'm still not hitting break points. on the C++ side of things. I have a very loose and likely inaccurate understanding of cross platform debugging. I've read some information with regards to gdbserver and have seen a few projects online that seem to include an binary for their target hardware in the project to be pushed out with the app. Is it possible that this is a missing link in my project?

[Simon Taylor]

The "attach to process" is just to enable Java-debugging on a project that wasn't started in debug mode. I only use that to get both C++ and Java breakpoints working.

For debugging just one side or the other, select the configuration in the drop down in the toolbar (in my test project they're called "app" for Java debugging and "Native Debug" for C++ side) and press the debug button rather than the play button.

For me when Native Debug is selected, this ends up opening a "Debug" view in Studio that has a console, and shows something like this at the end:

DEVICE SHELL COMMAND: cat /data/local/tmp/lldb-server | run-as com.example.hellojni sh -c 'cat > /data/data/com.example.hellojni/lldb/bin/lldb-server; chmod 700 /data/data/com.example.hellojni/lldb/bin/lldb-server'

DEVICE SHELL COMMAND: rm /data/local/tmp/lldb-server

DEVICE SHELL COMMAND: cat /data/local/tmp/start_lldb_server.sh | run-as com.example.hellojni sh -c 'cat > /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh; chmod 700 /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh'

DEVICE SHELL COMMAND: rm /data/local/tmp/start_lldb_server.sh

Now Launching Native Debug Session

Debugger attached to process 10205

So it is using an lldb server of some sort. The app starts running straight away, but it takes up to 10 seconds for the "debugger attached to process" line to show up in the log. From that point on, C++ breakpoints seem to work for me. I didn't have to set up and of the lldb_server stuff, I assume it is just part of that "Native Debug" configuration provided by Android Studio. Are you definitely on the canary channel and running the latest update, and using the experimental gradle plugin etc?

If you haven't seen this page yet, this link will be useful:

http://tools.android.com/tech-docs/android-ndk-preview

Simon

[Kyle Peplow]

I get as far as Now Launching Native Debug Session. 

The Debugger attached to process (ID#) is never output. 

I am currently running off the canary channel for my updates in the stable channel. There is a rc4 release in the preview channel I haven't pulled yet. 

Development being done on Windows 7

Current Version: Android Studio 1.3

Build number: AI-141.2095413

Android SDK Tools: 24.3.3

Android Platform Version : API 22: Android 4.1 (lollipop) revision 2.

There has to be something I'm missing. I don't think its my devices. Galaxy S5 and a rooted Nexus 7.

[Simon Taylor]

Hmm, I wonder if that's something to do with Windows vs Mac. I'm only using build tools 21.1.1 but I doubt that's the issue.

Do you get the same results with the samples from the git repository mentioned in the URL I gave last time? If so then I'm out of ideas. Good luck!

[Kyle Peplow]

Might be a platform thing. The more Unix based Mac might be more suited to googles needs for all I know. I did experience some weird break point hits with gdb last night with the program halting anywhere except where I was dropping break points and allowing me to inspect. 

I did download the teapot and native_activity samples from the URL as one of the first things I did. Those too are experiencing issues too sadly.

I may just have to weather development with logcat and the terminal till google can finish AS1.3 for full release. Hopefully that won't be too much longer.

[Simon Taylor]

Are you able to choose GDB or LLDB on the run configuration page? I've been using LLDB.

I've previously seen breakpoints hitting seemingly random places and think I traced it back to the debugger using symbols for a different ABI variant than the device is actually running with. Not sure if that issue is still around, but you could try this in build.gradle:

android.ndk {
    abiFilters = ["armeabi"]

}

Now I really am done with ideas!

Simon

[Kyle Peplow]

I have been switching between GDB and LLDB trying to see if I could get one or the other working. I only noticed GDB was doing something last night while I was trying to figure out why my screen was no longer clearing to blue after cleaning my code up and print outs weren't showing up. Local scope can be the devil.

I do have good news, I added the abiFilter you suggested and it is now stopping on my break points. SUCCESS! So GDB is working now, but I appear to be missing some frame data and I usually have to resume to the second break point before anything useful shows up. My guess is probably related to your aforementioned need to sleep the thread so the debugger can connect, seems to take about 3 seconds for me and my render loop is already initialized and running at that point.

Thank you! Probably would have shaved a few years off my life if I had to continue what I was doing. 

 

[马迪]

use Android Studio 1.3 stable version, the break point in cpp file still can not be triggered. Both abiFilters and isJniDebuggable were added. I don't know why.

I use win7 64bit.

在 2015年7月22日星期三 UTC+8上午6:37:22，Kyle Peplow写道：

[Johan Euphrosine]

There is an outstanding issue with the 1.3 release that prevent breakpoint to be hit during the startup of the application.

I believe this is already fixed with the studio-1.4-dev branch.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[Nate Hopkins]

I am having issues getting the debugger to connect.  I have tested with recent Hello_JNI and Teapot examples.  I have tried a 15 second delay in OnCreate, but it made no difference.  It hangs waiting for debugger.  Last line in the Debug console is Now Launching Debug Session.  I have tested on AS 1.3.1 and 141.2168647 (1.4-dev branch).  I am able to get the debugger attached and stop at breakpoints in Java using app config, but not in C++ using Native config.  Has anyone seen this issue?

[Lev Popovich]

The same case for me:

Waiting for device.

Target device: Nexus_5_API_21 [emulator-5554]

Uploading file

local path: C:\Users\1\AndroidStudioProjects\HelloJNI\app\build\outputs\apk\app-all-debug.apk

remote path: /data/local/tmp/com.example.hellojni

Installing com.example.hellojni

DEVICE SHELL COMMAND: pm install -r "/data/local/tmp/com.example.hellojni"

pkg: /data/local/tmp/com.example.hellojni

Success

Launching application: com.example.hellojni/com.example.hellojni.HelloJni.

DEVICE SHELL COMMAND: am start -D -n "com.example.hellojni/com.example.hellojni.HelloJni" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.example.hellojni/.HelloJni }

Waiting for process: com.example.hellojni

Client not ready yet.

DEVICE SHELL COMMAND: run-as com.example.hellojni mkdir /data/data/com.example.hellojni/lldb

DEVICE SHELL COMMAND: run-as com.example.hellojni mkdir /data/data/com.example.hellojni/lldb/bin

DEVICE SHELL COMMAND: cat /data/local/tmp/lldb-server | run-as com.example.hellojni sh -c 'cat > /data/data/com.example.hellojni/lldb/bin/lldb-server; chmod 700 /data/data/com.example.hellojni/lldb/bin/lldb-server'

DEVICE SHELL COMMAND: cat /data/local/tmp/start_lldb_server.sh | run-as com.example.hellojni sh -c 'cat > /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh; chmod 700 /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh'

Starting LLDB server: run-as com.example.hellojni /data/data/com.example.hellojni/lldb/bin/start_lldb_server.sh /data/data/com.example.hellojni/lldb /data/data/com.example.hellojni/lldb/tmp/platform.port1441082764840 "lldb process:gdb-remote packets"

Now Launching Native Debug Session

AS IDE 141.2218876 hangs under Windows 10