Take the 2-minute tour ×

Perhaps I am attempting to do something I ought not.

I'm running a block of code in the emulator. It looks (more or less) like this: http://pastie.org/1291380

This is to construct a live wallpaper background. I pass in a bitmap, color palette, and tile array.The size of my bitmap is 256 x 256. getRedPal / getGreenPal / getBluePal essentially does a call to Color.red() / Color.green() / Color.blue() in order to get the rgb color components of a palette object.

The loops chug along; I get all the way to the point where the j value of drawInC hits 32, before the emulator crashes and burns:

11-11 15:34:44.032: INFO/distort_bmp(598): DrawInC: i: 0 j: 32

11-11 15:34:44.032: INFO/distort_bmp(598): DrawTiles: i: 0 j: 0





After which I get a dump file sent to /data/tombstones . Here is the dump (but I sincerely don't find anything in it worth any value, just a bunch of memory addresses): http://pastie.org/1291394

I added android:vmSafeMode="true" to my tag after reading elsewhere that that could solve a problem. This is on 2.2, using bitmap.h.

Personally I am dubious of that

jbyte* buffer = 
(*env)->GetByteArrayElements(env, arr, &isCopy)

call; I plucked that code from the net somewhere, as I was totally unable to get values from my byte array "arr."

Any ideas?

EDIT After manipulating my loop iterators (I shortened the number of loops), I now get an informative error:

"ReferenceTable overflow (max=512)"

JNI local reference table summary (512 entries):
  509 of Ljava/lang/Class; 164B (3 unique)
2 of Ljava/lang/String; 28B (2 unique)
   1 of [Ljava/lang/String; 28B
Memory held directly by tracked refs is 576 bytes
Failed adding to JNI local ref table (has 512 entries)

That "509 of java.lang.class" doesn't look too right to me...how can I optimize my code here?

share|improve this question
I haven't taken the time to read all your code but some googling shows that the error you're getting can be caused by not freeing up variables... code.google.com/p/android/issues/detail?id=8676#c5 Not sure if that' any help (yeah that's about blutooth but it's not a BT issue) –  Basic Nov 12 '10 at 22:09
add comment

2 Answers

up vote 2 down vote accepted

From that error message, it appears that some bit of native code has called a function that returns a Class object, and has done so 509 times. 507 of those calls returned one particular class.

JNI local references let the GC know that native code is looking at an object, and therefore that object can't be collected even if there are no references to it elsewhere. These local refs are released when the native code returns to the VM. If the native code does a lot of work without returning, it's possible to overflow the local ref table.

You probably just need to add a DeleteLocalRef somewhere. My guess is you need to add one at the end of DrawTile, because of the GetObjectClass call. Better yet, move those GetMethodID calls to a one-time setup function. (They do string searches to find the method, making them not especially quick.)

For more info see JNI Tips.

share|improve this answer
Well, I pulled out the GetMethodID calls, and am instead passing the jmethodId directly to DrawTiles. I also changed my array allocation to GetByteArrayRegion--but I'm still getting the crash. Hm, hm. –  GJTorikian Nov 13 '10 at 0:12
Are you getting the ReferenceTable overflow crash, or just a native crash (with a debuggerd stack dump in logcat)? I was only addressing the ref table overflow (which I describe as a "VM abort" rather than a crash). –  fadden Nov 19 '10 at 0:43
add comment

i think this might be a memory problem. do you release the arrays?

if you get arrays with


you must release the array on the c-side it after each procedure or you will fill your memory till you get over the limit (limit size depends on android version and/or manufacturer but is to my knowledge max 48MB per app)

(*env)->ReleaseByteArrayElements(env, arr, &isCopy, 0);

see here: http://www.iam.ubc.ca/guides/javatut99/native1.1/implementing/array.html

btw, this method does copy the arrays from java to a new memory block in c, you work there and at the end its copied back to java (which memory might have been moved to another location till then). for performance improvement you might look at https://groups.google.com/forum/?fromgroups#!msg/android-ndk/phDP5zqiYY4/BFMw4zTme8IJ

share|improve this answer
add comment

Your Answer


