JPCT crashed while debugging

zammbi · June 14, 2012, 05:24:00 AM

JPCT crashed when I resumed from debugging. Using the current stable version.

Quote06-14 15:20:35.014: ERROR/AndroidRuntime(32289): FATAL EXCEPTION: GLThread 4465
java.lang.IndexOutOfBoundsException: Invalid index 5, size is 5
at java.util.ArrayList.throwIndexOutOfBoundsException(ArrayList.java:251)
at java.util.ArrayList.get(ArrayList.java:304)
at com.threed.jpct.World.draw(World.java:1319)
at com.threed.jpct.World.draw(World.java:1074)
at nz.co.nuffie.android.crichq.threedimensional.World3dBase.renderWorld(World3dBase.java:678)
at nz.co.nuffie.android.crichq.threedimensional.World3dBase.onDrawFrame(World3dBase.java:732)
at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java:1463)
at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1217)
06-14 15:20:35.022: WARN/ActivityManager(195): Force finishing activity nz.co.nuffie.android.crichq/.threedimensional.OfflineViewWorld3dActivity

Edit: Actually this might be my fault. Looks like it might be a threading issue.

EgonOlsen · June 14, 2012, 08:20:41 AM

This usually happens if you fiddle around with the collection of objects in a world in parallel to the rendering.

zammbi · June 18, 2012, 12:15:44 AM

Yeah I was filtering PolyLines on the UI thread. Now fixed, no more crashes now.

I'm wondering if you can add some kind of debug flag so these can be picked up earlier? If the app is on the wrong thread it will crash the app or give a warning.

EgonOlsen · June 18, 2012, 08:20:47 AM

I would like to, but it would kill performance. I would have to check for the right thread in almost every method.

zammbi · June 18, 2012, 09:02:56 AM

If its a debug flag(default off) I don't see the problem?

EgonOlsen · June 18, 2012, 10:01:35 AM

It's still either a method call or at least an if to detect the debug state. It wouldn't matter on the desktop, but it will on Dalvik. Dalvik is still bad at calling methods and can't inline anything.

zammbi · June 18, 2012, 10:21:30 AM

One boolean check extra per method is going to see a drop in performance? Couldn't you could leave out sensitive methods? Some would be better then nothing.
As for slow debugging I wouldn't mind, I just want to do a test every once and a while.
But I guess if it hurts the engine too much then yeah, I can live without it.

EgonOlsen · June 18, 2012, 11:41:56 PM

The other problem (apart from the performance drop) is, that it might be totally legal to call methods from other threads. Either if you synchronize the calls or if you call them on completely different objects. It doesn't hurt to fiddle around with objects that are not part of the world to prepare them for being added, for example. I don't think that i want to remove this option by forcing a one-thread policy. jPCT-AE is very much like Swing in this regard.