This discussion is archived
8 Replies Latest reply: Jan 2, 2013 6:41 AM by gimbal2 RSS

Android crashing on JNI CallStaticObjectMethod

982373 Newbie
Currently Being Moderated
Hello there,

I'm trying to invoke a static method on Android and my app is crashing... the code is very simple, I ran out of ideas -- there isn't much I can think of that might be going on.

Here's the snippet:

char const *FileUtils::cachesDir() {
     JavaVM *vm = JniHelper::getJavaVM();
     JNIEnv *env;
     int status = vm->GetEnv((void **)&env, JNI_VERSION_1_4);
     if(status >= 0){
          jclass cls = env->FindClass("android/content/ContextWrapper");
          jmethodID method = env->GetMethodID(cls, "getFilesDir", "()Ljava/io/File;");
          jobject result = env->CallStaticObjectMethod(cls, method, NULL); **// <-- ***** CRASHES WITH java.lang.NullPointerException at android.content.ContextWrapper.getFilesDir(ContextWrapper.java:193) *****
          return "Found a result";
     }
     return "NULL";
}

Thougts?

Thanks and regards,
- Fabiano

Edited by: user10784680 on Jan 1, 2013 7:06 AM
  • 1. Re: Android crashing on JNI CallStaticObjectMethod
    982373 Newbie
    Currently Being Moderated
    Screenshot here -> https://s3.amazonaws.com/andyfabiano/jni-error.png
  • 2. Re: Android crashing on JNI CallStaticObjectMethod
    EJP Guru
    Currently Being Moderated
    Not nearly enough error checking here. You need to check the result of every JNI call: specifically, GetClass() and GetMethodID() could both have failed, yet you went ahead with CallStaticMethod() anyway. Don't do that.

    In any case you are passing a NULL to a method that is complaining about a NullPointerException. I suggest you don't do that either.
  • 3. Re: Android crashing on JNI CallStaticObjectMethod
    982373 Newbie
    Currently Being Moderated
    EJP -- absolutely agree!

    But here's the thing... I've tested the lines before the CallStaticObjectMethod invokation and they all work fine -- no crash and the returned objects seem to be valid.

    Regards passing a NULL as a parameter to CallStaticObjectMethod, your remarks also make sense, however when I omit the NULL, I get an even worse crash: a hairy SIGSERV with no Java stack trace...

    Any ideas?

    Thanks!
    - Fabiano
  • 4. Re: Android crashing on JNI CallStaticObjectMethod
    EJP Guru
    Currently Being Moderated
    What do you mean 'omit the NULL'? You have to supply an argument, and it has to be non-null by the looks of things.
  • 5. Re: Android crashing on JNI CallStaticObjectMethod
    982373 Newbie
    Currently Being Moderated
    The method signature does not require you to pass arguments.

    From jni.h:

    jobject (*CallStaticObjectMethod)(JNIEnv*, jclass, jmethodID, ...);

    I'm passing NULL as a sentinel to an empty list of variable arguments.

    Am I misinterperting the method signature?
  • 6. Re: Android crashing on JNI CallStaticObjectMethod
    EJP Guru
    Currently Being Moderated
    The method signature does not require you to pass arguments.
    So don't pass any arguments.
    I'm passing NULL as a sentinel to an empty list of variable arguments.
    Where did you get that from?
    Am I misinterperting the method signature?
    No but you have invented this concept of a NULL sentinel.

    What you are actually doing is passing NULL as an argument, to a method that doesn't take any arguments.
  • 7. Re: Android crashing on JNI CallStaticObjectMethod
    982373 Newbie
    Currently Being Moderated
    EJP wrote:
    What you are actually doing is passing NULL as an argument, to a method that doesn't take any arguments.
    Yes -- you are correct. However when I omit the NULL I get the following SIGSEGV:

    01-02 12:28:39.745: A/libc(17692): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree addr=0x5e6de000
    01-02 12:28:39.745: A/libc(17692): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 17709 (Thread-635)

    Screenshot -> https://s3.amazonaws.com/andyfabiano/sigserv.png
  • 8. Re: Android crashing on JNI CallStaticObjectMethod
    gimbal2 Guru
    Currently Being Moderated
    that is a memory overflow problem, somewhere some code is writing into memory it shouldn't be writing into; think of writing to an array index outside of the boundaries of the array size for example. Java does a nice boundary check for you, but in native code you're on your own. That can be any code causing the problem, not specifically there where you were just hacking something together. Perhaps you can figure something out by spamming some printfs to at least know which code is touched last.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points