Memory leak in native code

[TheOne]

I have a small library of native functions. When I use the library, I
notice that the virtual memory size of java process keeps increasing to
the point that the system's OOM killer is invoked.

Following is the most frequently executed portion of my code:

jbyteArray jbaKey =
static_cast<jbyteArray>(env->GetObjectField(jobjUpdateRec, key_fid));
jbyte *arrKey1 = env->GetByteArrayElements(jbaKey, NULL);

char *arrKey2 = (char *)&currentKey;
if(blEnableRecordLevelLogging)
syslog(...);
for( int i = 0; i < sizeof(reckey_t); i++)
{
arrKey1 = (jbyte)arrKey2;
}
env->ReleaseByteArrayElements(jbaKey, arrKey1, 0);

Initially I was using JNI_COMMIT instead of 0 at the last argument for
env->ReleaseByteArrayElements() which was responsible for the leak.
Even after I changed it I am observing memory leak so I suspect that I
am doing something wrong in my code. Maybe I am supposed to free the
jbaKey. But I don't know how to do that and also not sure whether it is
required. Please advise.

Thank in advance
Sudarshan

 

[Chris Uppal]

Even after I changed it I am observing memory leak so I suspect that I
am doing something wrong in my code. Maybe I am supposed to free the
jbaKey. But I don't know how to do that and also not sure whether it is
required.

I can't see anything wrong with your code (except the lack of error checking
and bounds checking -- hope you do have proper checks in your real code and
just removed them to keep your post short). You are releasing the resources
correctly. There should be no need to release the object handle (jbaKey)
provided your JNI code is only called from Java (i.e. as a native method, so
the local reference(s) will be cleaned up when it return).

-- chris

 

[TheOne]

I can't see anything wrong with your code (except the lack of error checking
and bounds checking -- hope you do have proper checks in your real code and
just removed them to keep your post short). You are releasing the resources
correctly. There should be no need to release the object handle (jbaKey)
provided your JNI code is only called from Java (i.e. as a native method, so
the local reference(s) will be cleaned up when it return).

I think thats right. I tried to isolate the JNI part from the rest of
the application and it does not show me any traces of leak. I have
absolutely no idea why the JVM's virtual memory keeps increasing! My
java program uses lots of DirectByteBuffers which wrap huge shared
memory areas. Do you think it could cause some trouble? Are there any
known bugs in JDK 1.5.0_06-b05 related to memory leak in JNI or
something...

 

[Chris Uppal]

I have
absolutely no idea why the JVM's virtual memory keeps increasing! My
java program uses lots of DirectByteBuffers which wrap huge shared
memory areas. Do you think it could cause some trouble?

My guess is probably not. Not unless the size of the leak is comparable with
the size of your DirectByteBuffers themselves (which, since they are large and
you use lots of them, you would presumably have noticed earlier when your
program almost instantly ran out of memory ;-)

IIRC, DDBs do have a way of, not so much "leaking", as mis-managing memory.
The memory they use is reclaimed by garbage collection, but the GC is not
sensitive to the memory area that the underlying buffer is allocated from -- it
is only aware of the DDB object itself (a small wrapper object). As long as it
is happy that it has enough "normal" (heap) memory, it may not be too bothered
about cleaning up the DDB objects. But it doesn't know that the DDB objects
represent an expensive (big, and not inexhaustible) OS-level resource. So you
can end up either using more of the OS-level resource than you should, or even
running out entirely (which, confusingly, provokes an ordinary out-of-memory
exception) while the GC is still happy that there's plenty of memory available.

I can only suggest that you spend some time with one of the memory profiling
tools (I can't recommend any specific one).

Are there any
known bugs in JDK 1.5.0_06-b05 related to memory leak in JNI or
something...

I don't know of any myself, but I don't follow the bug-lists so I could easily
have missed something.

-- chris