The problem
I'm trying to debug native (c++) code that is called from Java code (MainActivity.OnCreate) in simple android application. I'm using lldb for debugging and build the native code using cmake.
The debug works as expected until I try to step into native language function, then one of these happens:
1. The debugger steps into the function and allows making further steps, but there is no cursor, no normal stack trace, and no variable watches. The only thing in stack trace is the name of the cpp file and memory adress (instruction pointer maybe?) that increases with every step that I take. It looks to me as no debug symbols were loaded.
2. The step suceeds as it should and for a brief moment I can catch a glimpse of correct stack trace. But then the lldb crashes, the stack changes and the cursor is at art_sigsegv_fault. When I continue, I simply get a message that debugger was disconnected. The app continues to run as it should.
Additionally, I've noticed that at the moment of crash the debugger attempts to collect data from variables and never actually suceeds. The variables that are successfully resolved are a JNI pointer and jobject, while the others are jstring.
Miliseconds before the crash:
After the crash:
What I've tried
Made sure that symbols are not stripped from .so files, by adding
packagingOptions{
doNotStrip "**/*.so"
}
Made sure that CMAKE_CXX_FLAGS have -O0 -ggdb in them (no code optimization, debug compile)
Made sure that in Project Structure there is debug build, with properties Debuggable, Jni Debuggable, and Renderscript Debuggable set to true.
I believe that I've tried all the possible options that I've found here, hence a new question that may seem repetitive at first.
Related
I am running into a problem while working on unit testing my system that I don't even know how to approach debugging. My code operates either on a linux machine with mock input or on an android device. I am using Google Test to run unit tests on it. I have it set up so that a call to "$ make all" will run my unit tests on both the linux machine and through adb shell on my device. This part is working fine.
However, when I introduce a test with EXPECT_DEATH(...) in it, the linux build runs the same as usual but the android build stops at that test and appears to freeze (I have to Ctrl + C to stop execution). As I said, I'm not at all sure how to try to fix this problem as I can't seem to get any output or error messages from it.
If you have any suggestions please let me know. If there is critical information I'm leaving out about my build, comment and I can add that in.
Edit:
When I run the function that I'm expecting to die outside of EXPECT_DEATH the same behavior occurs. This indicates that the assert in the function is working and EXPECT_DEATH is not doing what it should to handle that.
Before: (Works fine on Linux build but not on Android build)
EXPECT_DEATH(pObj->fxn(deathlyParam), "");
After: (Same result on Android build; core dump error due to assert on Linux build which is what I would expect both times from the Android build)
EXPECT_EQ(pObj->fxn(deathlyParam), 0);
For reference, fxn() looks something like this:
int fxn(int param)
{
assert(param != deathlyParam);
...
}
In light of this, it looks more like assert is acting improperly and not causing the error it should be. Therefore, EXPECT_DEATH has nothing to expect.
OK I figured it out. The problem was indeed arising from the assert in my function and not from EXPECT_DEATH. I don't know if this is just a feature of the project I'm working on (which had been developed for some time before I got to it) or if it is true of any Android build but NDEBUG was undefined, as in a release build. When I added "APP_OPTIM := debug" to my Application.mk file, it worked perfectly.
I am still a little confused why an assert would seemingly halt execution when NDEBUG is undefined. Aren't asserts supposed to be ignored entirely in release builds?
Credit to this question and answer for the solution.
I am trying to debug native code on Android using ndk-gdb, with mixed results.
When the debugger hits a breakpoint, I am able to get a nice stack trace using 'bt'.
Hhen typing 'info source', ndk-gdb tells me that the file I have hit the breakpoint in is "Compiled with DWARF 2 debugging format".
The problem arises when I enter 'info args' to get the function argument values. ndk-gdb then states that: "No symbol table info available.".
Any input to the cause of this problem would be appreciated.
It's strange that it says that about the file being compiled with DWARF 2 format, because the flags you provide there indicates it is only specifying -g, which should get GCC 4.8 to produce DWARF 4 format. Which also is consistent with the error you are seeing. Add the flag -gdwarf-2 and the NDK debugger (which is not yet at version 7.5) should be able to deal with the symbols.
I picked this up from one of the answers to this question: Debugging with gdb on a program with no optimization but still there is no symbol in the current context for local variables
I was able to use the native debug functionality until recently. I've been coding in java and went back to the native code but now I can't native debug. It will run and with the previously working debug config but I get a Null Pointer error on launch right when it would be attaching:
'Launching [debug config]' has encountered a problem.
An internal error occurred during 'Launching [debug config]'.
java.lang.NullPointerException
The app will run on the device, but won't hit breakpoints. Anyone seen this, it's driving me nuts?
Turns out this was due to the manifest "debuggable" being set to false. When you don't run native it tells you exactly that. With native, you get the absolutely useless error. I'll put in an enhancement request.
The conversion of my Android application to the iPhone ObjectX environment as described in the XMLVM user manual works almost fine on my MAC, but I end up with 3 errors in the resulting XCode:
The first two errors simply relate to missing files, namely:
org_w3c_dom_Node.h
android_app_DatePickerDialog_OnDateSetListener.h
These are clearly not files from the converted Android application. Where can I get these from?
The third is an error that keeps coming up in the file
java_lang_String.h
The error message is:
typedef NSMutableString java_lang_String: redefinition as different kind of symbol
This error has been reported before in the XMLVM user group but as far as I know has never been answered sufficiently.
About the first error:
this is part of the Android API that has not yet been implemented.
This is the reason why it can't find the files.
Now, the second problem is not actually an error, but a warning and shouldn't stop you form compiling.
If it does, it means that in your project you have set the option to make errors from these types of warnings.
You can safely turn this off and completely ignore this warning.
Pretty self explanatory. I compiled a native c++ exe using the ndk. When I run the app, it gets a SIGSEGV, seg faults and exits. There is no stack trace or cpu context in the logcat.
Why? Any suggestions on how to fix it?
there are two tools you can use to debug your sigsev. ndk-stack and arm-linux-androideabi-addr2line located into your $NDK dir.The first help you to filter the stacktrace and addr2line translates program addresses into file names and line num. Check into your $NDK dir, for the documentation.
You're all wrong, you need to enable logging to logcat for STDIO and STDERR.
http://developer.android.com/tools/debugging/debugging-log.html#viewingStd