JNI memory leak aus byte-array

Ich habe ein java-Programm, dass nennt eine native Funktion um ein Vielfaches. Mein problem ist, dass diese Funktion ein Speicherleck hat, und alles, was, die ich tun, um loszuwerden, es zu einem memory dump. Jegliche Hilfe würde sehr geschätzt werden.

Dies ist mein code 

JNIEXPORT void JNICALL Java_class_method_getInput
(JNIEnv *env, jobject obj)
{
    if (inputIsAvailable)
    {

    int size = getBufferCurrentIndex();
    size -= getBufferReadIndex();
    size *= 2;

    char *finalSendArray = new char[size];

    getCommand(finalSendArray);

    jbyteArray byteArray = env->NewByteArray(size / 2);
    env->SetByteArrayRegion(byteArray, 0, size / 2, (jbyte*) finalSendArray);

    while(methodID == 0)
    {
        jclass cls = env->GetObjectClass(obj);
        methodID = env->GetMethodID(cls, "setCommand", "([B)V" );
    }

    env->CallVoidMethod(obj, methodID, byteArray);

    //env->ReleaseByteArrayElements(byteArray, (jbyte*) finalSendArray, JNI_ABORT);

Mein problem ist, dass die oben ^ code bewirkt, dass ein memory-dump, wenn es unkommentiert, wenn es nicht unkommentiert mein Programm läuft out of memory in Minuten

    env->DeleteLocalRef(byteArray);
    delete[] finalSendArray;
    }
}

jede Hilfe würde geschätzt werden. Danke!

Lassen Sie die byteArray zuerst, dann löschen Sie den zugrunde liegenden Speicher?
Habe meine Antwort löst Ihr Problem? Markieren Sie es als richtig, wenn Sie es Tat. Warum machst du das alles in C? Was bedeutet getCommand tun? Könnte es sein, erfolgt in java? jni ist teuer.
hey sorry das es so lange gedauert hat für eine Antwort, ich habe noch ein Leck irgendwo. Ich bin mir nicht sicher, wo. Ich bin mit c++ weil ich bin nur die Wiederverwendung von code, wurde bereits gebaut. Könnte es sein, neu in Java geschrieben, aber ich würde es vorziehen, nur halten es in seiner aktuellen Umsetzung.
Ich Wünsche mir, dass gearbeitet hatte... habe es aber leider nicht.
Tut mir Leid zu hören. Ich weiß wirklich nicht; der einzige Rat, den ich geben könnte, ist zu Lesen, die die JNI-Spezifikation sorgfältig durch und stellen Sie sicher, dass Sie verstehen, all die verschiedenen Leben und Abhängigkeiten.

InformationsquelleAutor Tyler Davis | 2013-09-06

  1. 3

    ReleaseByteArrayElements auch den Speicher frei, wenn Sie die JNI_ABORT param. Also, wenn du tust, das löschen und die Freigabe später, einer dieser Zeiger zeigt auf nicht initialisierten Speicher, wodurch die dump.

    Einer dieser arbeiten, ich ziemlich sicher, es ist die erste, die funktioniert.

    env->ReleaseByteArrayElements(byteArray, (jbyte*) finalSendArray, JNI_ABORT);
delete[] finalSendArray;

    Versuchen Sie dies, wenn die erste fehlschlägt.

    env->ReleaseByteArrayElements(byteArray, (jbyte*) finalSendArray, JNI_ABORT);
env->DeleteLocalRef(byteArray);

    Legen Sie eine print-Anweisung nach der ReleaseByteArrayElements, werden Sie sehen, dass das Programm ausgeführt wird, darüber hinaus den Befehl und stürzt sich auf die Freigabe/Delete[]

    Suche nach "Tabelle 4-10 Primitive Array-Release-Modi"

    die erste bewirkt, dass code *** glibc detected *** /usr/lib/jvm/java-7-openjdk-amd64/bin/java: double-free-oder corruption (fasttop): 0x00007fb8a4001030 *** code die zweite habe ich noch ein memory-leak. Ich werde sicherstellen, dass der Speicher Leck ist tatsächlich da
    Es könnte sein, in getCommand. Ist es nicht mehr abstürzt, jetzt an der gleichen Stelle?
    Die log-Dateien zeigen Sie auf die Funktion SetByteArrayRegion und es wirft den Fehler bad_alloc
    Konnte jede Ihrer Zuordnungen scheitern?(Rückgabe von null). Wie viel Arbeitsspeicher haben Sie zugeteilt, um die JVM? Überprüfen Sie, ob entweder die Zeiger sind NULL vor dem Aufruf setByteArrayRegion. Wenn Sie sind, drucken Sie etwas aus, in das Protokoll schreiben, oder werfen eine Ausnahme. Ist bad_alloc zu werfen auf die ersten JNI-Aufruf? oder nach einer Reihe?(mem leak)
    Könnte es sein, dass Sie out-of-heap-Speicher. Check out diese, um Sie zu erhöhen, stackoverflow.com/questions/1565388/increase-heap-size-in-java

    InformationsquelleAutor JustinDanielson

Schreibe einen Kommentar