Android Jni AttachCurrentThread Memory leakage

Starting with this problem, I was so arrogant that I had to locate it for almost two days.

 

Jni Memory leakage is really difficult to locate.

 

Symptom

Let's talk about the results first. I am working on online video applications. The data has to be dropped from C to the Java layer. During the test, I found that I had memory when I was running a machine for a few hours. The following error was reported:

07-10 19:31:46. 871: E/dalvikvm-heap (3756): Out of memory on a 126-byte allocation.
07-10 19:31:46. 871: I/dalvikvm (3756): Can't dump thread 5041: threadObj not set
07-10 19:31:46. 871: E/dalvikvm (3756): Out of memory: Heap Size = 32775KB, Allocated = 29914KB, Bitmap Size = 0KB, Limit = 32768KB
07-10 19:31:46. 871: E/dalvikvm (3756): Extra info: Footprint = 32711KB, Allowed Footprint = 32775KB, Trimmed = 468KB
07-10 19:31:46. 871: W/dalvikvm (3756): cocould not allocate message string "(null)" while throwing internal exception (Ljava/lang/OutOfMemoryError ;)

 

Then, you may find that the video data memory is not leaked. I used a reusable memory block, and if the video data is leaked, each frame of data is as large as 640*480. It will take a while and it will not be able to run for several hours. Then, my brother tried to check out all kinds of tools. Why didn't I learn about the instruments on Xcode? Anyway, I didn't have any results after analyzing them for a long time. After commenting on the codes, it was found that the problem was caused by the jni layer. Okay, I finally found out that it was AttachCurrentThread, Nima, groose. This is a Bug.

 

It is reasonable to say that this is all I have to do every time I throw data from C to Java (I just want to write a rough description)

Void paoshuju (char * buf, int size)

{

AttachCurrentThread

// Copy the memory here.

// DetachCurrentThread

}

This is what my brother did, and then the memory was leaked. It was a Bug.

 

Solution

Well, I'll get a global variable. Each thread only AttachCurrentThread once, stores env as the global variable, and then returns DetachCurrentThread when the thread ends.

In this way, the problem is solved.

However, the sequelae of this solution must be very clear about the thread called for each interface, otherwise the program will crash