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
11-11 15:34:44.032: INFO/distort_bmp(598): DrawTiles: i: 0 j: 1
11-11 15:34:44.032: INFO/distort_bmp(598): DrawTiles: i: 0 j: 2
11-11 15:34:44.032: INFO/distort_bmp(598): DrawTiles: i: 0 j: 3
11-11 15:34:44.032: INFO/distort_bmp(598): DrawTiles: i: 0 j: 4
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?
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.