I'm using the NDK to compile libusb (both from the prebuilt one supplied at: https://github.com/monaka/libusb-android) as well as using his changes to compile the latest available (libusb-1.0.8). It appears to load and the initial call to "init()" does not return an error. However, when I try to make the basic call into the library to list devices (from the sample lsusb code included in libusb) I get a crash. Using the NDK-provided "arm-eabi-addr2line" and the address which the dump provides as the fault, I've tracked it down to being that the device listing method in libusb gets an "unknown status" from the device it finds which causes the "usbi_log()" method to be called within which the crash occurs. The NDK tools don't give me line numbers so that's all the details I have for where the error is occurring.
libusb source repo: http://git.libusb.org/?p=libusb.git;a=summary;js=1
I am making a simple JNI call into libusb from a dead-simple Action, though I don't have any reason to think this is part of the issue. It is a very basic .h (from javah) file and .c file which copies the action of the provided "lsubs" sample program and the Action class does nothing but make the call in the onLoad() method.
I also get a crash when running in the emulator. Also unplugged device (a Nexus One) to disable debugging (also disabled in Applications->Development on device) and to have USB bus (theoretically) empty (of at least external physical devices) and get same crash.
Device and emulator Android version: 2.2
NDK version: r5b
ADK version: r10
Host OS: OSX
Thank you for any help you can provide!
If you install an ssh daemon on the phone, then you can ssh into it with port forwarding and run gdbserver and connect to that from gdb on the pc.
You may want to build a command line executable test first, before hooking it up to your java app.
Related
I am developing a fully native application in using C++ and pure CMake as the build system - no Android Studio involved at all (proof of concept here)
The code builds, apk is generated and can be installed and run via ADB without issue but I cannot get gdbserver64 to attach to the process for debugging.
More details:
App is built against SDK/NDK API level 30
Attempting to debug on an Android 11 emulator instance without Google Play
I can run adb root just fine
Image already includes gdbserver and gdbserver64, attempting to use those
Developer options and USB debugging enebled in emulator
App has android:debuggable="true" in manifest
But every time I try gdbserver64 :5039 --attach $(pidof my.app.id)
I get /bin/sh: <app_pid>: inaccessible or not found
What am I missing? And no, I cannot just move to Android Studio - this is a cross platform project that needs to be buildable using only CMake.
According to my observation, this may be a bug of prebuilt gdbserver. It treats the parameter after --attach as a program name and tries to start it.
It's not really an answer, but in similar configuration to yours I got same error message and unable to overcome this. For me, switching to lldb helped, see e.g.
I would like to know how I can debug an Android app by using lldb.
I mean using lldb from console not over Android Studio.
From what I found out, Android Studio is doing this:
Pushing the app to the device
Starting this app
Pushing lldb-server to the device
Starting lldb-server on the remote device
Forwarding the ports
Connecting to the local port which is forwarded to the device
I would like to achieve the same using lldb from the console.
Let's say I have already lldb-server on the remote device (because Android Studio did this already for me), what do I need to do is to connect to an App using lldb from the console?
Never tried, but maybe this could help:
LLDB remote debugging
Debugging C++ native libraries in Android using command line
Additionally:
ensure that APK's native libraries (lib*.so) are having debug info/symbols. I pull the apk locally, locate .so file, and check the output of binutils nm utility. When you get familiar with your .so files only checking the size of the .so file could be enough.
one can debug by attaching to a running process/application (attach) and in some cases you need to debug application on application start (run).
in some debugging cases phone/emulator requires root access (file manipulations)
if you manage to debug C++ libs within Android Studio - check Debug+Console and Debug+LLDB output tabs to find interesting commands/options/steps
the procedure looks quite complicated and fragile - arm yourself with patience, don't ignore warnings and don't skip steps.
I'm interested in learning about the Android runtime (ART) and I'd like to be able to put a debugger on it so I can step through the code. I have an AOSP build that I've been running on an emulator.
What's the best way to attach and run source? Should I just use gdbserver on the emulator? Are there any IDEs that people use for native debugging?
Looks like you figured this out, but just for completeness, here's a link to some official documentation which basically covers what you said: http://source.android.com/devices/tech/debug/index.html
If you want to debug native code, you're going to need the source, which of course means getting the AOSP. After you've setup the AOSP, do the following:
In your AOSP directory, run "choosecombo". Select "debug" and pick an "eng" build of your choice.
Build the AOSP
Start the emulator (ie: on Linux, "emulator &")
adb shell into the emulator and run "setprop debug.db.uid 32767". This prevents debuggerd from attaching to a process that it thinks has halted and causing problems. See system/core/debuggerd/debuggerd.cpp in the AOSP for more info.
In the same shell that you built the AOSP, run "gdbclient [process name]". This will attach and load the debugging information for the process you are interested in. You can also attach to a pid, but you will end up having to load the symbol information yourself.
Enjoy debugging native Android platform code
I am trying to debug a mixed code on Android (Java/C/C++). My target device is Vizio 1008. The code runs on the emulator and I can debug it from Eclipse using GDB. However, I cannot do this on the real device.
After days of struggling with this I localized the problem:
When GDBSERVER starts on the device (successfully), it immediately quits with the message:
"Unknown register d0 requested". Therefore, no debugging session is possible. I also tried DS-5 debugger from ARM. GDBSERVER stays connected, but exits on the connection attempt from the remote debugger. I tried GDBSERVER debug output, but it does not provide any useful info.
Even more strange, I tried any version of GDBSERVER I could get, and all of them behave like this. However, I found GDBSERVER from one of old versions of Google NDK (3 or 4 versions back). And this version WORKS!!! But, the debugger (on the host) dies very soon (segmentation fault), even I know that program is OK.
I looked at GDBSERVER source code, and, as it looks like, this error relates to the startup sequence, when GDBSERVER inspects the hardware. Probably, it relates to floating point co-processor, but I am not sure, as this error message is pretty generic.
If it matters, I am devloping on Windows using Google NDK. The code is 99% C/C++ with Java shell and a few functions implemented in Java (threaded HTTP calls). Again, the application works on the device and can be debugged (both Java and C/C++) on the emulator. I also can debug Java portion on the device.
Does anybogy know what it could be? And how to fix that? Is it Vizio?
Thank you in advance.
Sounds similar to a problem i encountered trying to do native debugging. The problem was that the arm processor used in the device supported both the vfp/neon instruction set as well as the iwmmx instruction set and appearantly gdbserver assumes the two are mutually exclusive.
To fix you'll need to mess with the gdbserver source unfortunately. Following is a fix from link. You'll need to edit the file linux-arm-low.c in the gdbserver source tree:
static void
arm_arch_setup (void)
{
arm_hwcap = 0;
if (arm_get_hwcap (&arm_hwcap) == 0)
{
init_registers_arm ();
return;
}
/* gdbserver assumes that only one of VFP or IWMMXT is available, which may
not be true. In that case, gdbserver fails at run-time with "Unknown
register d0 requested". For now, pretend IWMMXT is missing when both are
available. */
if ((arm_hwcap & HWCAP_VFP) && (arm_hwcap & HWCAP_IWMMXT))
arm_hwcap &= ~HWCAP_IWMMXT;
The exact location of where you have to change the code depends on the gdb(server) version though. I know for a fact it is slightly different in the case of gdb 7.7. After you changed it this way you should build it with gcc from the ndk, so it gets linked against bionic and stuff. I do not have exact instructions for that, because I didn't do it myself.
I should stress that this is ultimately more of a workaround than a proper fix. I do not know how gdbserver patched this way behaves when running code that actually contains iwmmx instructions. At least you'll probably not be able to get register dumps of iwmmx registers.
so I'm trying to compile a program on an ARM emulator (Quem and the laungauge is C) for use on an Android phone. This is because I can't get build-essentials and/or cmake on my android phone, but I do have Terminal Emulator and Busybox.
Anyways, I compiled the program last night (Took forever!) and when I tried to run it on Android today It was originally saying Permission Denied (Even though I have SU), I found out that it was because I need to have it as executable, but since the sdcard was a FAT32, I wasn't able to use chmod. So I mounted /system, and copied over the binary to there after chmod 777'ing it. And now it gives me ./myprogram: not found even though it is clearly there.
Doing some reading, people are saying it could mean there are missing libraries, but Android doesn't have the ldd command so I don't know how to find out what it's missing. Also, might be a game breaker, but I found out that my phone is on an ARMv7 where as the emulator is ARM926EJ-S will this make a difference?
Any input is great!
I makes little sense (IMHO) to compile on the emulator. It makes more sense to use a cross compiler to build your application and its dependencies. Please search for info on using the NDK.