java.lang.VerifyError und Android 2.3

Monkey Forums/Monkey Bug Reports/java.lang.VerifyError und Android 2.3

Volker(Posted 2013) [#1]
This code crashes under Android 2.2 (Samsung Galaxy Tab) and under Android 2.3.3 in the emulator.
It does it while loading the TimelineFX library in LoadLibrary().
Works fine in Html5, XNA and Android 4.x.
I've played with the heap size settings of the virtual machine. The code works with heap size 32 or 64, but with 16 (standard) it crashes.
All files needed: http://skopia.de/BRLfiles.rar

E/AndroidRuntime(10461): FATAL EXCEPTION: GLThread 10

E/AndroidRuntime(10461): java.lang.VerifyError: com.monkeycoder.monkeygame.bb_loaders

E/AndroidRuntime(10461): at com.monkeycoder.monkeygame.c_TFXManager.p_LoadLibrary(MonkeyGame.java:5516)




marksibly(Posted 2013) [#2]
It break here too on 2.3.3 emulator, but I get an OutOfMemoryError instead.

I've tracked it down to the loading of the XML file (which doesn't seem that big to me) but I doubt there's much I can do - it fails on an allocation of 512K bytes, even though there's apparently 2M free. Not sure if this is an old android bug or what.

Perhaps you could streamline the XML? But even if you did and got it working, you've still 'only' got 2M to play with after that so it's probably not much help...

You could also try reading the XML 'bit by bit' using a filestream instead of using LoadString, but again I think the low memory would catch up with you sooner or later anyway.


AdamRedwoods(Posted 2013) [#3]
512K is a lot for heap size. those heap limits will get you every time.

ways to get around:
1. if you really need the bigger heap, i believe Android 2.3 allows a "largeHeap" request in the manifest.

2. if you move data load to the DataBuffer (which uses ByteBuffer), you can see if ByteBuffer.allocate() will allocate off the heap (unsure on this one).
http://stackoverflow.com/questions/5670862/bytebuffer-allocate-vs-bytebuffer-allocatedirect


marksibly(Posted 2013) [#4]
[edit]
Ignore...
[/edit]


AdamRedwoods(Posted 2013) [#5]
oh you're right heap size is around 16-24mb, not sure what i was thinking.
plus, that heap will grow and freeMemory() doesn't show that limit, i think maxMemory() does.

unless there's some magic manifest setting to fix things.

heh, NDK


marksibly(Posted 2013) [#6]
Yeah, my freeMemory code was flawed - this seems to give more believable results:

	public static int FreeMemory(){
		System.gc();
		return (int)( Runtime.getRuntime().maxMemory()-Runtime.getRuntime().totalMemory()+Runtime.getRuntime().freeMemory() );
	}


But it indicates that the 512k byte allocation fails when there's 6M free, which could mean severe fragmentation? Or (IMO more likely) there's a bug somewhere in older Android...

One thing that fixes it is reducing 'max particles' - 1000 works here, while some higher values cause an OutOfMemory in other parts of the app. Particle is a pretty heavyweight class so this will have quite an effect.