Speicherleck mit JNI zum Abrufen des Werts von String aus Java-Code

Lesezeit: 3 Minuten

Benutzer-Avatar
rperez

Ich verwende GetStringUTFChars, um den Wert einer Zeichenfolge mithilfe von JNI aus dem Java-Code abzurufen und die Zeichenfolge mithilfe von ReleaseStringUTFChars freizugeben. Wenn der Code auf JRE 1.4 ausgeführt wird, gibt es kein Speicherleck, aber wenn derselbe Code mit einer JRE 1.5 oder einer höheren Version ausgeführt wird, erhöht sich der Speicher. Dies ist ein Teil des Codes

msg_id=(*env)->GetStringUTFChars(env, msgid,NULL); 
opcdata_set_str(opc_msg_id, OPCDATA_MSGID, msg_id);
(*env)->ReleaseStringUTFChars(env, msgid,msg_id); 

Ich kann den Grund für das Leck nicht verstehen. Kann jemand helfen?


Dies liegt daran, dass, wenn ich den Rest des Codes kommentiere, aber diesen Teil belasse, das Speicherleck stattfindet. Dies ist ein Teil des Codes, den ich verwende

JNIEXPORT jobjectArray JNICALL Java_msiAPI_msiAPI_msgtoescalate( JNIEnv *env,
                                                                 jobject job,
                                                                 jstring msgid,
                                                                 jlong msgseverity,
                                                                 jstring msgprefixtext,
                                                                 jint flag )
{
  opcdata       opc_msg_id;   /* data struct to store a mesg ID        */

  const  char            *msg_id;
  int           ret, ret2;
  jint val;
  val=67;
  jstring str=NULL;
  jobjectArray array = NULL;
  jclass sclass=NULL;
  /* create an opc_data structure to store message ids of */
  /* messages to escalate                                 */
  if ((ret2=opcdata_create(OPCDTYPE_MESSAGE_ID, &opc_msg_id))!= OPC_ERR_OK)
  {
    fprintf(stderr, "Can't create opc_data structure to store message. opcdata_create()=%d\n", ret2);
    cleanup_all();
  }

  //////////////////////////////////////////////////////////
  msg_id=(*env)->GetStringUTFChars(env,msgid,NULL);
  opcdata_set_str(opc_msg_id, OPCDATA_MSGID, msg_id);
  (*env)->ReleaseStringUTFChars(env, msgid, msg_id);
  ret=opcmsg_ack(connection,opc_msg_id);
  //////////////////////////////////////////////////////////

  if(flag==0 && ret==0)
  {
    sclass = (*env)->FindClass(env, "java/lang/String");
    array = (*env)->NewObjectArray(env, 2, sclass, NULL);
    str=(*env)->NewStringUTF(env,"0");
    (*env)->SetObjectArrayElement(env,array,0,str);
    (*env)->DeleteLocalRef(env, str);
    str=(*env)->NewStringUTF(env,"0");
    (*env)->SetObjectArrayElement(env,array,1,str);
    (*env)->DeleteLocalRef(env, str);
  }

  opcdata_free(&opc_msg_id);

  if(ret!=0)
    return NULL;
  else
    return(array);
}

In der obigen ist, wenn ich die Abschnitte zwischen ///// kommentiere, sehe ich kein Speicherleck.

  • Scheint in Ordnung zu sein, woher wissen Sie, dass dies die Ursache für Ihr Leck ist?

    – Mike Tunnicliffe

    27. Mai 2009 um 14:08 Uhr

  • Ich stimme fd zu – bitte posten Sie einige Informationen darüber, woher Sie wissen, dass dies das Leck ist. Haben Sie Profilerdaten, die darauf hindeuten?

    – Lawrence Dol

    27. Mai 2009 um 18:05 Uhr

  • Es kann sein, dass die freigegebene Zeichenfolge nicht sofort von der Garbage Collection erfasst wird. Daher beobachten Sie eine Zunahme der Speicherauslastung. Sie können auch versuchen, nur den Aufruf opcdata_set_str() oder opcmsg_ack() auszukommentieren und prüfen, ob immer noch Speicherverluste auftreten.

    – akarnokd

    12. Juni 2009 um 13:45 Uhr

  • Was ist bitte der Prototyp (Deklaration) für die Funktion opcdata_set_str?

    – Eric Nicolas

    10. September 2014 um 12:29 Uhr

  • … und was bewirkt es? Ich würde sagen, das Leck ist in dieser Funktion. Gibt es eine ergänzende Maßnahme, die Sie ergreifen sollten, um dieses Datenelement freizugeben?

    – Benutzer207421

    6. Juni 2015 um 23:42 Uhr

Veröffentlichung Reihe Objekt.

(* env) -> DeleteLocalRef (env, array);

1227930cookie-checkSpeicherleck mit JNI zum Abrufen des Werts von String aus Java-Code

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy