CMAKE_BUILD_TYPE Release: strange results - android

We are creating an Android app to compare execution time between ART and native code. We are using Android Studio and CMake for compiling C/C++.
When in CMakeList.txt we set the flag
set(CMAKE_BUILD_TYPE Release)
in some algorithms (Primality Test and Fibonacci) the execution time drastically drop to 0ms for all different input.
Here the native lib
bool flag = false;
extern "C" JNIEXPORT void JNICALL Java_javacpp_cmr_com_sdkvsndk_MainActivity_cancel(JNIEnv *env, jobject obj) {
flag = true;
}
extern "C" JNIEXPORT jlong JNICALL Java_javacpp_cmr_com_sdkvsndk_MainActivity_primalityTest(JNIEnv *env, jobject obj, jlong r) {
if(r < 0) return -1L;
timeval start, stop;
long long t;
gettimeofday(&start, NULL);
bool prime = true;
unsigned long long sr = (unsigned long long) sqrt(r);
for (unsigned long long i = 2; (i < sr) && prime; i++) {
if (flag) return -1;
if (r % i == 0) prime = false;
}
gettimeofday(&stop, NULL);
t = (stop.tv_sec - start.tv_sec) * 1000;
t += (long long) ((stop.tv_usec - start.tv_usec) / 1000)
return (jlong) t;
}
flag is a flag that is set true when we terminate the asyncTask that execute the algorithm.
I can not figure how this is possible. Any suggestion? Thank you.

This is because by default your CMake project is build with Debug type. In this type the debugging information is generated as well as optimisations are disabled (-O0 -g flags to gcc).
This is to enable you to step trough your C++ code line by line as it was written by you. If you change the type to Release the optimisations are turned on and the debug info is not included with the binary.
The optimisations make the code run so fast, no matter how well you think you wrote something, the compiler is still ahead of you and will make it better. Those optimisations however will show erratic behaviour when the code is debugged, lines executed out of order, or not at all, variables not showing in watches or shown wrong, this is not nice for debugging.
The missing debug info means the binary is lighter but if you need to debug it better practice some assembly since any information on what line of C++ resulted in these assembly instructions is lost. As a side note there is also RelWithDebugInfo build type in case you really need to debug the optimised code.
Normally the Android Studio should take care of the appropriate build type for you so there is no need to fiddle with that.

You can dump the compilation commands used to build the C/C++ source files using:
set(CMAKE_EXPORT_COMPILE_COMMANDS ON) in the CMakeLists.txt which will create a compile_commands.json in the build directory.
You can try different combination of the "CMAKE_BUILD_TYPE" and save the generated compile_commands.json for different build types for different compiler flags for optimizations, debugging etc.

Related

Android development: updating code to more recent NDK?

I have a problem with some code that has been written for Android NDK 10d. It's not my code, but I'd like to fork and recompile this project. But I run into problems with the current NDK (19c). I have seen the code snippet in other projects as well, but I couldn't find a proper way to update this section. Maybe someone here has an idea or could explain what the problem is exactly?
Code:
JNIEXPORT jint JNICALL Java_jackpal_androidterm_TermExec_createSubprocessInternal(JNIEnv *env, jclass clazz,
jstring cmd, jobjectArray args, jobjectArray envVars, jint masterFd)
{
const jchar* str = cmd ? env->GetStringCritical(cmd, 0) : 0;
String8 cmd_8;
if (str) {
cmd_8.set(str, env->GetStringLength(cmd));
env->ReleaseStringCritical(cmd, str);
}
...
int ptm = create_subprocess(env, cmd_8.string(), argv, envp, masterFd);
return ptm;
}
I get the following error (referring to cmd_8.set(str, env->GetStringLength(cmd));):
process.cpp:210:19: error: cannot initialize a parameter of type 'const char16_t *' with an lvalue of type 'const jchar *' (aka 'const unsigned short *')
cmd_8.set(str, env->GetStringLength(cmd));
^~~
So I guess parameter types changed with newer versions of NDK? Do I need a type conversion somewhere? I guess there are just updated functions/calls to this in newer versions, but I couldn't find any documentation (also didn't know what to look for).
Any ideas?
The compiler in r19 is less forgiving than the one from r10. The parameter types did not change, but the recent clang requires that you add explicit cast:
cmd_8.set((const char16_t*)str, env->GetStringLength(cmd));
This said, your project may have a worse problem, as explained #Richard Critten. If it relies upon libutils and other Android private libraries, it will not work on Android Marshmallow and higher.

Providing a JVM for MediaStreamer2 Console Application on Android

I am working on an Android firmware for an embedded device which streams an encoded video signal using rtp. The underlying library is MediaStreamer2 because it comes with Android support, various codecs and libortp. Therefore I integrated libmediastreamer and its dependencies into my firmware build process.
As a second step, I wrote a simple Android command line application as a PoC which streams audio or video through the network. Unfortunatly, the first call to ms_init() fails due to:
bctbx-fatal-Calling ms_get_jni_env() while no jvm has been set using ms_set_jvm()
Digging a little deeper into the problem, it seems Androids version of libmediastreamer was designed from an NDK point of view: It can be called as a part of an Android app and therefore automatically gets a reference to the JVM (DVM?). Unfortunatly, this is not my use case.
I tried to to remove the dependencies (Querying Sdk version, hardware echo cancelation support, etc.) without success. So my next approach would be starting a VM manually and passing it to the library. I tried Oracles APIs like:
JNIEnv env;
JavaVM vm;
JavaVMInitArgs vm_args;
JavaVMOption options[4];
options[0].optionString = "-Djava.compiler=NONE";
options[1].optionString = "-verbose:jni";
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = 4;
vm_args.ignoreUnrecognized = TRUE;
jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args);
But the application quits with a simple "aborted". Nevertheless, I am not sure whether this is a way to go because its Android and Dalvik world.
Any suggestions?
It is possible to build executable for shell on Android on both rooted and non-rooted devices, see reference How to build an executable for Android shell
.
Try below code and build it using NDK to get an executable:
#include <jni.h>
#include <iostream>
#include <string>
using namespace std;
int main(int argc, char **argv) {
JavaVMOption jvmopt[1];
jvmopt[0].optionString = "-Djava.class.path=" + ".";
JavaVMInitArgs vmArgs;
vmArgs.version = JNI_VERSION_1_2;
vmArgs.nOptions = 1;
vmArgs.options = jvmopt;
vmArgs.ignoreUnrecognized = JNI_TRUE;
// Create the JVM
JavaVM *javaVM;
JNIEnv *jniEnv;
long flag = JNI_CreateJavaVM(&javaVM, (void**)
&jniEnv, &vmArgs);
if (flag == JNI_ERR) {
cout << "Error creating VM. Exiting...\n";
return 1;
}
/** ----------------------------------------------
* Put your own JNI related code from here if any.
* -----------------------------------------------
**/
javaVM->DestroyJavaVM();
return 0;
}
Do a check on <jni.h> about the interfaces you can use, e.g.
/*
* VM initialization functions.
*
* Note these are the only symbols exported for JNI by the VM.
*/
jint JNI_GetDefaultJavaVMInitArgs(void*);
jint JNI_CreateJavaVM(JavaVM**, JNIEnv**, void*);
jint JNI_GetCreatedJavaVMs(JavaVM**, jsize, jsize*);
You can refer to below to see if they are helpful:
how-to-create-a-jvm-instance-in-jni
https://calebfenton.github.io/2017/04/05/creating_java_vm_from_android_native_code/

PJSip Account Registration

I am trying to add PJSip to a project I am working on. I have this method for registering my account but a 'Fatal signal 11' error occurs everytime.
Here is the method
public int setRegistration() {
int status = pjsuaConstants.PJ_FALSE;
/* Register to SIP server by creating SIP account. */
int[] accId = new int[1];
accId[0] = 1;
String uName = getUserName();
String passwd = getPassword();
String server = getSIPServer();
pjsua_acc_config acc_cfg = new pjsua_acc_config();
pjsua.acc_config_default(acc_cfg);
acc_cfg.setId(pjsua.pj_str_copy("sip:" + uName + "#" + server));
acc_cfg.setReg_uri(pjsua.pj_str_copy("sip:" + server));
acc_cfg.setCred_count(1);
acc_cfg.getCred_info().setRealm(pjsua.pj_str_copy(server));
acc_cfg.getCred_info().setScheme(pjsua.pj_str_copy("digest"));
acc_cfg.getCred_info().setUsername(pjsua.pj_str_copy(uName));
acc_cfg.getCred_info().setData_type(pjsip_cred_data_type.PJSIP_CRED_DATA_PLAIN_PASSWD.swigValue());
acc_cfg.getCred_info().setData(pjsua.pj_str_copy(passwd));
Log.d("status", "acc is adding..");
status = pjsua.acc_add(acc_cfg, pjsuaConstants.PJ_TRUE, accId);
Log.d("status", "acc is added");
if (status == pjsuaConstants.PJ_SUCCESS) {
status = pjsua.acc_set_online_status(accId[0], 1);
Log.d("acc_set_online_status returned stauts=", String.valueOf(status));
} else {
Log.d("Error status=", String.valueOf(status));
}
return status;
}
I receive the error on the status = pjsua.acc_add(acc_cfg, pjsuaConstants.PJ_TRUE, accId); line. I know that the username, server, and password are not null. I have looked at multiple questions relating to this and no use.
How can I register my account?
Thanks
*****EDIT******
After tracking down this through blogs and forums I got passed this error but received another. The reason this error occurred was because pjsua_init was never successful. It was successful because it gave me this error
11-04 10:19:20.973: E/AndroidRuntime(2961): FATAL EXCEPTION: main
11-04 10:19:20.973: E/AndroidRuntime(2961): java.lang.UnsatisfiedLinkError: Native method not found: org.pjsip.pjsua.pjsuaJNI.init:(JLorg/pjsip/pjsua/pjsua_config;JLorg/pjsip/pjsua/pjsua_logging_config;JLorg/pjsip/pjsua/pjsua_media_config;)I
11-04 10:19:20.973: E/AndroidRuntime(2961): at org.pjsip.pjsua.pjsuaJNI.init(Native Method)
11-04 10:19:20.973: E/AndroidRuntime(2961): at org.pjsip.pjsua.pjsua.init(pjsua.java:812)
I have received this warning as well
No implementation found for native Lorg/pjsip/pjsua/pjsuaJNI;.init (JLorg/pjsip/pjsua/pjsua_config;JLorg/pjsip/pjsua/pjsua_logging_config;JLorg/pjsip/pjsua/pjsua_media_config;)I
Why isn't this a native method? I am looking into the libraries I have called but other than that I don't know why this isn't working.
Any help on this matter would be great.
Thanks
PJ Code
pjsua.java
public synchronized static int init(pjsua_config ua_cfg, pjsua_logging_config log_cfg, pjsua_media_config media_cfg) {
return pjsuaJNI.init(pjsua_config.getCPtr(ua_cfg), ua_cfg, pjsua_logging_config.getCPtr(log_cfg), log_cfg, pjsua_media_config.getCPtr(media_cfg), media_cfg);
}
pjsuaJNI.java
public final static native int init(long jarg1, pjsua_config jarg1_, long jarg2, pjsua_logging_config jarg2_, long jarg3, pjsua_media_config jarg3_);
pjsua_wrap.cpp
SWIGEXPORT jint JNICALL Java_org_pjsip_pjsua_pjsuaJNI_init(JNIEnv *jenv, jclass jcls, jlong jarg1, jobject jarg1_, jlong jarg2, jobject jarg2_, jlong jarg3, jobject jarg3_) {
jint jresult = 0 ;
pjsua_config *arg1 = (pjsua_config *) 0 ;
pjsua_logging_config *arg2 = (pjsua_logging_config *) 0 ;
pjsua_media_config *arg3 = (pjsua_media_config *) 0 ;
pj_status_t result;
(void)jenv;
(void)jcls;
(void)jarg1_;
(void)jarg2_;
(void)jarg3_;
arg1 = *(pjsua_config **)&jarg1;
arg2 = *(pjsua_logging_config **)&jarg2;
arg3 = *(pjsua_media_config **)&jarg3;
result = (pj_status_t)pjsua_init((pjsua_config const *)arg1,(pjsua_logging_config const *)arg2,(pjsua_media_config const *)arg3);
jresult = (jint)result;
return jresult;
}
{"init", "(JLorg/pjsip/pjsua/pjsua_config;JLorg/pjsip/pjsua/pjsua_logging_config;JLorg/pjsip/pjsua/pjsua_media_config;)I", (void*)& Java_org_pjsip_pjsua_pjsuaJNI_init},
EDIT 2
So after working on this I have gotten to a point of frustration. I am not seeing what I am doing wrong so I will put my entire process here to see if someone has a suggestion.
I start by getting the pjsip library: svn co http://svn.pjsip.org/repos/pjproject/trunk pjproject
run `./configure --prefix=/usr/local
make dep & make
sudo make install
I then get the pjjni code svn checkout svn://svn.code.sf.net/p/pjsip-jni/code/ pjsip-jni-code
I follow the Makefile instructions
After Makefile runs successfully (after some code cleanup) I have 2 .so files (libpjsua_jni.so and libpjsua_jni_x64.so)
Create jni folder with Android.mk file and .so libraries
Run ndk-build (How to load another .so file in your android project?)
Add to ADT
Close project. Change native support from Java to Android. Open project
(Convert existing project into Android project in Eclipse?)
Add that project to my TestPJ project (Android -> Library -> Add)
Call System.loadLibrary("pjsualib") -- Name of the new lib.so
Receive Error
11-22 13:55:44.784: W/dalvikvm(11464): No implementation found for native Lorg/pjsip/pjsua/pjsuaJNI;.swig_module_init:()V
11-22 13:55:48.792: W/dalvikvm(11464): Exception Ljava/lang/UnsatisfiedLinkError; thrown while initializing Lorg/pjsip/pjsua/pjsuaJNI;
11-22 13:55:51.417: E/AndroidRuntime(11464): java.lang.UnsatisfiedLinkError: Native method not found: org.pjsip.pjsua.pjsuaJNI.swig_module_init:()V
11-22 13:55:51.417: E/AndroidRuntime(11464): at org.pjsip.pjsua.pjsuaJNI.swig_module_init(Native Method)
11-22 13:55:51.417: E/AndroidRuntime(11464): at org.pjsip.pjsua.pjsuaJNI.(pjsuaJNI.java:1450)
Any help would be great. Thanks!
An example of project which explores JNI calls from Java and from C can be found here.
The error mentioned in the question (java.lang.UnsatisfiedLinkError: Native method not found: org.pjsip.pjsua.pjsuaJNI) means one of the following problems:
- wrong native method name or/and its arguments/return value. If you have access to native code of the library than you can fix it. According to the error message and JNI considerations native method must have name Java_org_pjsip_pjsua_pjsuaJNI_init(JNIEnv *env, jobject obj, ..), where env is a pointer to JVM interface, obj is a "this" pointer and the remaining arguments can be determined from java init method of pjsuaJNI class of package org.pjsip.pjsua. Simple parameter types must be jint, jstring etc. Also return value must be correct as well. Fixing all these allows to use this method from pjsuaJNI class. Additional details can be found from Oracle Documentation to Oracle Documentation to Java 6 JNI (or Java 7 if you're using android 4.4).
- wrong java method name/signature/class name or package name. This case is almost reverse to the first one. Again, according to the mentioned error name of the method must be "init", class name pjsuaJNI and package org.pjsip.pjsua. If at least one of them is wrong the mentioned exception will happen. Signature or parameters must also be correct. In the boundaries of this error it can be considered as a parameters of the method (in addition in native JNIEnv* and jobject appears). So also must be checked and fixed if necessary.
In case of call from native code to java signature can be considered as a representation of java method with parameters as a string and can be viewed with javap -s *.class command applied to java *.class file. And in the last warning from question this signature of the method can be seen.
Also to use method pjsip library must be loaded with System.loadLibrary() in some static section of the Java class.
Unfortunately, this problem happens at runtime (it would be nice if it happened during compilation time).
It's a bit late but I'll try to help on this. I think that your problem should be related to your native method not been surrounded by extern "C"{} and name mangling in C++.
If you don't declare one native C function as extern "C", C++ build mangles it and JNI mechanism can not find native method matching provided signature. On the other hand, declaring it as external C function, the builder creates both, mangled and unmanged, versions and JNI can find the proper one.
Hope this helps.

Android NDK: getting the backtrace

I'm developing the native application that works with Android via the NDK.
I need to call the backtrace() function when there is a crash. The problem is that there is no <execinfo.h> for the NDK.
Is there any other way to get that back trace?
Android have no backtrace(), but unwind.h is here to serve. Symbolization is possible via dladdr().
The following code is my simple implementation of backtrace (with no demangling):
#include <iostream>
#include <iomanip>
#include <unwind.h>
#include <dlfcn.h>
namespace {
struct BacktraceState
{
void** current;
void** end;
};
static _Unwind_Reason_Code unwindCallback(struct _Unwind_Context* context, void* arg)
{
BacktraceState* state = static_cast<BacktraceState*>(arg);
uintptr_t pc = _Unwind_GetIP(context);
if (pc) {
if (state->current == state->end) {
return _URC_END_OF_STACK;
} else {
*state->current++ = reinterpret_cast<void*>(pc);
}
}
return _URC_NO_REASON;
}
}
size_t captureBacktrace(void** buffer, size_t max)
{
BacktraceState state = {buffer, buffer + max};
_Unwind_Backtrace(unwindCallback, &state);
return state.current - buffer;
}
void dumpBacktrace(std::ostream& os, void** buffer, size_t count)
{
for (size_t idx = 0; idx < count; ++idx) {
const void* addr = buffer[idx];
const char* symbol = "";
Dl_info info;
if (dladdr(addr, &info) && info.dli_sname) {
symbol = info.dli_sname;
}
os << " #" << std::setw(2) << idx << ": " << addr << " " << symbol << "\n";
}
}
It may be used for backtracing into LogCat like
#include <sstream>
#include <android/log.h>
void backtraceToLogcat()
{
const size_t max = 30;
void* buffer[max];
std::ostringstream oss;
dumpBacktrace(oss, buffer, captureBacktrace(buffer, max));
__android_log_print(ANDROID_LOG_INFO, "app_name", "%s", oss.str().c_str());
}
Here is some working and complete code that implements dump_stack() by starting with Eugene Shapovalov's answer and does symbol lookups and C++ name demangling right on the device. This solution:
works with the NDK r10e (you don't need the complete Android AOSP source tree)
does NOT require any extra third-party libraries (no libunwind, libbacktrace, corkscrew, CallStack)
does NOT depend on any shared libraries being installed on the device (e.g. corkscrew, which got axed in Android 5)
does NOT force you to map addresses to symbols on your development machine; all symbol names are revealed on the Android device in your code
It uses these facilities, which are built into the NDK:
<unwind.h> header that is in the NDK toolchain/ dirs (NOT libunwind)
dladdr()
__cxxabiv1::__cxa_demangle() from <cxxabi.h> (see STLport note below)
So far, I tested this only with an arm-based Android 5.1 device and I called it only from my main program (not from a signal handler). I was using the default ndk-build which chooses gcc for the arm platform.
Please comment if you are able to make this work
on other Android OSes
from a SIGSEGV handler on crash (my goal was simply to print a stack trace on assertion failure)
using clang toolsets instead of gcc
Note the r10e NDK has <unwind.h> code for many architectures in both gcc and clang toolsets so the support looks broad.
The C++ symbol name demangling support depends on an __cxxabiv1::__cxa_demangle() function that comes from the C++ STL that is included with the NDK. This should work as-is if you are doing your Android build with the GNU STL (APP_STL := gnustl_static or gnustl_shared in Application.mk; see this page for more info). If you are currrently using no STL at all, simply add APP_STL := gnustl_static or gnustl_shared to Application.mk. If you are using STLport, you have to enjoy a special kind of fun (more below).
IMPORTANT: for this code to work, you must not use the -fvisibility=hidden gcc compiler option (at least in your debug builds). That option is commonly used to hide symbols from prying eyes in release builds.
Many people have noted that the ndk-build script strips symbols from your NDK .so whilst copying it to the libs/ directory of your project. That is true (using nm on the two copies of the .so gives very different results) HOWEVER this particular layer of stripping amazingly does not prevent the code below from working. Somehow even after stripping there are still symbols (as long as you remembered not to compile with -fvisibility=hidden). They show up with nm -D.
Other posts on this topic have discussed other compiler options like -funwind-tables. I didn't find that I needed to set any such option. The default ndk-build options worked.
To use this code, replace _my_log() with your favorite logging or string function.
STLport users see special notes below.
#include <unwind.h>
#include <dlfcn.h>
#include <cxxabi.h>
struct android_backtrace_state
{
void **current;
void **end;
};
_Unwind_Reason_Code android_unwind_callback(struct _Unwind_Context* context,
void* arg)
{
android_backtrace_state* state = (android_backtrace_state *)arg;
uintptr_t pc = _Unwind_GetIP(context);
if (pc)
{
if (state->current == state->end)
{
return _URC_END_OF_STACK;
}
else
{
*state->current++ = reinterpret_cast<void*>(pc);
}
}
return _URC_NO_REASON;
}
void dump_stack(void)
{
_my_log("android stack dump");
const int max = 100;
void* buffer[max];
android_backtrace_state state;
state.current = buffer;
state.end = buffer + max;
_Unwind_Backtrace(android_unwind_callback, &state);
int count = (int)(state.current - buffer);
for (int idx = 0; idx < count; idx++)
{
const void* addr = buffer[idx];
const char* symbol = "";
Dl_info info;
if (dladdr(addr, &info) && info.dli_sname)
{
symbol = info.dli_sname;
}
int status = 0;
char *demangled = __cxxabiv1::__cxa_demangle(symbol, 0, 0, &status);
_my_log("%03d: 0x%p %s",
idx,
addr,
(NULL != demangled && 0 == status) ?
demangled : symbol);
if (NULL != demangled)
free(demangled);
}
_my_log("android stack dump done");
}
What if you are using STLport STL instead of GNU STL?
Sucks to be you (and me). There are two problems:
The first problem is that STLport lacks the __cxxabiv1::__cxa_demangle() call from <cxxabi.h>. You will need to download two source files cp-demangle.c and cp-demangle.h from this repository and place them in a demangle/ subdirectory under your source, then do this instead of #include <cxxabi.h>:
#define IN_LIBGCC2 1 // means we want to define __cxxabiv1::__cxa_demangle
namespace __cxxabiv1
{
extern "C"
{
#include "demangle/cp-demangle.c"
}
}
The second problem is more nasty. It turns out there's not one, not two, but THREE different, incompatible types of <unwind.h> in the NDK. And you guessed it, the <unwind.h> in STLport (actually it's in the gabi++ library that comes along for a ride when you choose STLport) is incompatible. The fact that the STLport/gabi++ includes come before the toolchain includes (see your ndk-build output's -I options) means that STLport is preventing you from using the real <unwind.h>. I could not find any better solution than to go in and hack the filenames inside my installed NDK:
sources/cxx-stl/gabi++/include/unwind.h to sources/cxx-stl/gabi++/include/unwind.h.NOT
sources/cxx-stl/gabi++/include/unwind-arm.h to sources/cxx-stl/gabi++/include/unwind-arm.h.NOT
sources/cxx-stl/gabi++/include/unwind-itanium.h to sources/cxx-stl/gabi++/include/unwind-itanium.h.NOT
I'm sure there's some more elegant solution, however I suspect switching the order of the -I compiler options will probably create other problems, since STLs generally want to override toolchain include files.
Enjoy!
backtrace() is a non-standard Glibc extension, and even then somewhat shaky on ARM (you need to have built everything with -funwind-tables, I think, and then have a somewhat new Glibc?)
As far as I know, this function is not included in the Bionic C library used by Android.
You could try pulling the source for Glibc backtrace into your project, and then rebuilding the interesting things with the unwind table, but it sounds like hard work to me.
If you have debug info, you could try launching GDB with a script that attaches to your process, and prints a backtrace that way, but I have no idea if GDB works on Android (although Android is basically Linux, so that much id fine, the installation details may be problematic?) You may get further by dumping core somehow (does Bionic support that?) and analysing it after-the-fact.
Here is a crazy one-line method for getting a fantastically detailed stack trace that includes both C/C++ (native) and Java: abuse JNI
env->FindClass(NULL);
As long as your app is compiled debug, or otherwise uses Android's CheckJNI, this erroneous call will trigger Android's built-in JNI checker which will produce a gorgeous stack trace on the console (from the "art" log source). This stack trace is done inside Android's libart.so using all the latest technologies and bells and whistles that are not easily available to lowly NDK users like us.
You can enable CheckJNI even for apps that are not compiled debug. See this google FAQ for details.
I do not know if this trick works from a SIGSEGV handler (from SIGSEGV you might get a stack trace of the wrong stack, or maybe art will not be triggered at all) but it is worth a try.
If you need a solution that makes the stack trace available in your code (e.g. so you can send it over the net or log it), see my other answer in this same question.
You can use the CallStack:
#include <utils/CallStack.h>
void log_backtrace()
{
CallStack cs;
cs.update(2);
cs.dump();
}
Results will need de-mangling by c++filt or something similar:
D/CallStack( 2277): #08 0x0x40b09ac8: <_ZN7android15TimedEventQueue11threadEntryEv>+0x0x40b09961
D/CallStack( 2277): #09 0x0x40b09b0c: <_ZN7android15TimedEventQueue13ThreadWrapperEPv>+0x0x40b09af9
you#work>$ c++filt _ZN7android15TimedEventQueue11threadEntryEv _ZN7android15TimedEventQueue13ThreadWrapperEPv
android::TimedEventQueue::threadEntry()
android::TimedEventQueue::ThreadWrapper(void*)
Here is how you capture backtrace on 32-bit ARM, using libunwind, that is bundled with modern Android NDKs (such as NDK r16b).
// Android NDK r16b contains "libunwind.a" for armeabi-v7a ABI.
// This library is even silently linked in by the ndk-build,
// so we don't have to add it manually in "Android.mk".
// We can use this library, but we need matching headers,
// namely "libunwind.h" and "__libunwind_config.h".
// For NDK r16b, the headers can be fetched here:
// https://android.googlesource.com/platform/external/libunwind_llvm/+/ndk-r16/include/
#include "libunwind.h"
struct BacktraceState {
const ucontext_t* signal_ucontext;
size_t address_count = 0;
static const size_t address_count_max = 30;
uintptr_t addresses[address_count_max] = {};
BacktraceState(const ucontext_t* ucontext) : signal_ucontext(ucontext) {}
bool AddAddress(uintptr_t ip) {
// No more space in the storage. Fail.
if (address_count >= address_count_max)
return false;
// Add the address to the storage.
addresses[address_count++] = ip;
return true;
}
};
void CaptureBacktraceUsingLibUnwind(BacktraceState* state) {
assert(state);
// Initialize unw_context and unw_cursor.
unw_context_t unw_context = {};
unw_getcontext(&unw_context);
unw_cursor_t unw_cursor = {};
unw_init_local(&unw_cursor, &unw_context);
// Get more contexts.
const ucontext_t* signal_ucontext = state->signal_ucontext;
assert(signal_ucontext);
const sigcontext* signal_mcontext = &(signal_ucontext->uc_mcontext);
assert(signal_mcontext);
// Set registers.
unw_set_reg(&unw_cursor, UNW_ARM_R0, signal_mcontext->arm_r0);
unw_set_reg(&unw_cursor, UNW_ARM_R1, signal_mcontext->arm_r1);
unw_set_reg(&unw_cursor, UNW_ARM_R2, signal_mcontext->arm_r2);
unw_set_reg(&unw_cursor, UNW_ARM_R3, signal_mcontext->arm_r3);
unw_set_reg(&unw_cursor, UNW_ARM_R4, signal_mcontext->arm_r4);
unw_set_reg(&unw_cursor, UNW_ARM_R5, signal_mcontext->arm_r5);
unw_set_reg(&unw_cursor, UNW_ARM_R6, signal_mcontext->arm_r6);
unw_set_reg(&unw_cursor, UNW_ARM_R7, signal_mcontext->arm_r7);
unw_set_reg(&unw_cursor, UNW_ARM_R8, signal_mcontext->arm_r8);
unw_set_reg(&unw_cursor, UNW_ARM_R9, signal_mcontext->arm_r9);
unw_set_reg(&unw_cursor, UNW_ARM_R10, signal_mcontext->arm_r10);
unw_set_reg(&unw_cursor, UNW_ARM_R11, signal_mcontext->arm_fp);
unw_set_reg(&unw_cursor, UNW_ARM_R12, signal_mcontext->arm_ip);
unw_set_reg(&unw_cursor, UNW_ARM_R13, signal_mcontext->arm_sp);
unw_set_reg(&unw_cursor, UNW_ARM_R14, signal_mcontext->arm_lr);
unw_set_reg(&unw_cursor, UNW_ARM_R15, signal_mcontext->arm_pc);
unw_set_reg(&unw_cursor, UNW_REG_IP, signal_mcontext->arm_pc);
unw_set_reg(&unw_cursor, UNW_REG_SP, signal_mcontext->arm_sp);
// unw_step() does not return the first IP,
// the address of the instruction which caused the crash.
// Thus let's add this address manually.
state->AddAddress(signal_mcontext->arm_pc);
// Unwind frames one by one, going up the frame stack.
while (unw_step(&unw_cursor) > 0) {
unw_word_t ip = 0;
unw_get_reg(&unw_cursor, UNW_REG_IP, &ip);
bool ok = state->AddAddress(ip);
if (!ok)
break;
}
}
void SigActionHandler(int sig, siginfo_t* info, void* ucontext) {
const ucontext_t* signal_ucontext = (const ucontext_t*)ucontext;
assert(signal_ucontext);
BacktraceState backtrace_state(signal_ucontext);
CaptureBacktraceUsingLibUnwind(&backtrace_state);
exit(0);
}
Here is a sample backtrace testing app with 3 implemented backtracing methods, including the method shown above.
https://github.com/alexeikh/android-ndk-backtrace-test
If you just want a few (eg 2 - 5) topmost call frames and if your GCC is recent enough, you might consider using some return address or frame address builtins.
(But I don't know much about Android, so I could be wrong)

Dynamically Generating Dalvik Bytecode into a running Dalvik/Android application

This question has been asked(and answered) many times about dynamically generating and loading java bytecodes at runtime into a running Dalvik VM, but is there any way to load dex files/bytecodes into an app at runtime?
Thanks
The Dalvik team would like to build a first-class runtime code generation library. We're tracking the feature request as Android bug 6322. Unfortunately, we have a very long list of performance and correctness issues, so I can't give you a timeline for when we'll spend time on this issue.
There are some alternatives, but they will all take some work:
Run your application on a standard JVM and exercise all runtime code generation there. Dump the .class files from memory to files, and then run dx on those files. If you're quite sophisticated, you could integrate all of this work into your build.
Include the open source dx tool as a project library, and execute it programatically from within your application, possibly in your application's classloader. This will bloat your application's binary.
is there any way to load dex
files/bytecodes into an app at
runtime?
Look at DexFile and DexClassLoader.
A related answer suggests Dexmaker for dynamic Dalvik bytecode generation.
I have used ASM and BCEL to generate Java classes and then I have converted them to Dex files.
Finally I have created jar files to load dynamically on device.
You can check out my code :)
https://github.com/sciruela/android
If inside any C or C++ program, you want to load and call into the DEX classes, you can see how the Dalvik VM is started, inside the AndroidRuntime - for example frameworks/base/cmds/app_process/app_main.cpp:
status_t app_init(const char* className, int argc, const char* const argv[])
{
LOGV("Entered app_init()!\n");
AndroidRuntime* jr = AndroidRuntime::getRuntime();
jr->callMain(className, argc, argv);
LOGV("Exiting app_init()!\n");
return NO_ERROR;
}
As "jr" AndroidRuntime is already started, callMain() will be called:
status_t AndroidRuntime::callMain(
const char* className, int argc, const char* const argv[])
{
JNIEnv* env;
jclass clazz;
jmethodID methodId;
LOGD("Calling main entry %s", className);
env = getJNIEnv();
if (env == NULL)
return UNKNOWN_ERROR;
clazz = findClass(env, className);
if (clazz == NULL) {
LOGE("ERROR: could not find class '%s'\n", className);
return UNKNOWN_ERROR;
}
methodId = env->GetStaticMethodID(clazz, "main", "([Ljava/lang/String;)V");
if (methodId == NULL) {
LOGE("ERROR: could not find method %s.main(String[])\n", className);
return UNKNOWN_ERROR;
}
<...>
env->CallStaticVoidMethod(clazz, methodId, strArray);
return NO_ERROR;
}
From above, we can see how the DEX classes' codes are loaded and CallStaticVoidMethod() will start interpreting the DEX codes.

Categories

Resources