I'm writing a Vuforia app and I've adjusted the code ordering somewhat from the samples. Firstly, I am loading some target/augmentation classes in from Java in JNI_OnLoad; next, I am pulling in data from these classes as the data becomes ready; finally, I'm running up QCAR in the normal way.
The lifecycle I've used is largely identical to the one in the VideoPlayback sample, except for the class loading in a different place. I've also abstracted a lot of the nuts and bolts of OpenGL drawing, trackable management and so on into a class to simplify the code relying on JNI calls. This second change is now pretty mature and, I'm fairly certain, not the cause of the problem I'm experiencing.
The problem is that when this modified code loads in its original app wrapper, it loads fine, but now that I've pasted it into the final application, it crashes often as it starts up. The crash seems to occur when the screen is active during startup; if it starts up while paused, it doesn't crash.
I've inserted log statements into all my functions, so I am reasonably certain the crash is coming from the library and not my code, as every function call is flagged. The log looks like this:
02-24 18:22:55.356: D/WorldMapVFActivity(9141): textures: 302-24 18:22:55.371: D/dalvikvm(9141): GC_FOR_ALLOC freed 5595K, 23% free 42581K/55084K, paused 16ms, total 17ms02-24 18:22:55.376: I/dalvikvm-heap(9141): Grow heap (frag case) to 45.930MB for 2865296-byte allocation02-24 18:22:55.396: D/dalvikvm(9141): GC_FOR_ALLOC freed <1K, 18% free 45379K/55084K, paused 20ms, total 20ms02-24 18:22:55.561: D/dalvikvm(9141): GC_FOR_ALLOC freed 16K, 18% free 45363K/55084K, paused 17ms, total 17ms02-24 18:22:55.566: I/dalvikvm-heap(9141): Grow heap (frag case) to 48.647MB for 2865296-byte allocation02-24 18:22:55.586: D/dalvikvm(9141): GC_FOR_ALLOC freed 0K, 17% free 48162K/57884K, paused 18ms, total 18ms02-24 18:22:55.621: D/dalvikvm(9141): GC_FOR_ALLOC freed <1K, 17% free 48162K/57884K, paused 17ms, total 17ms02-24 18:22:55.626: I/dalvikvm-heap(9141): Grow heap (frag case) to 51.379MB for 2865296-byte allocation02-24 18:22:55.651: D/dalvikvm(9141): GC_FOR_ALLOC freed 0K, 17% free 50960K/60684K, paused 18ms, total 18ms02-24 18:23:05.026: D/WorldMapVFActivity(9141): textures: 402-24 18:23:05.026: D/WorldMapVFActivity(9141): augmentations complete02-24 18:23:07.596: I/QCAR(9141): RUN POINT 0902-24 18:23:07.596: I/QCAR(9141): RUN POINT 1002-24 18:23:07.601: D/VuforiaARActivity(9141): VideoPlayback::onResume02-24 18:23:07.601: D/VuforiaARActivity(9141): QCAR resumption did not die.02-24 18:23:07.601: D/VuforiaARActivity(9141): Camera running.02-24 18:23:07.601: D/VuforiaARActivity(9141): GLSurfaceView had resume event.02-24 18:23:07.601: D/VuforiaARActivity(9141): Startup screen.02-24 18:23:07.601: D/VuforiaARActivity(9141): Reloaded movies.02-24 18:23:07.606: I/AR(9141): QCAR has been initialized successfully02-24 18:23:07.606: I/AR(9141): QCAR SDK version 2.5.702-24 18:23:07.621: I/Choreographer(9141): Skipped 2448 frames! The application may be doing too much work on its main thread.02-24 18:23:07.781: A/libc(9141): Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 9141 (bp.learninglens) The initial part is the Java code loading textures and pumping out the byte arrays. RUN POINT 09 and RUN POINT 10 are in the call to setActivityPortraitMode (which I should probably get rid of since the activity is landscape only, but anyway). All the calls labelled VuforiaARActivity (my abstract Activity class that handles most of the Vuforia lifecycle stuff) after that are events in onResume() including QCAR.onResume(), the call to updateApplicationStatus(APPSTATUS_CAMERA_RUNNING) and the onResume() lifecycle event for the GLSurfaceView. The ANR is probably caused by the textures loading synchronously, which is something I'm intending to deal with anyway. My questions are:- Are there any known conditions that can cause QCAR to stop? For example, does it have a problem with the GLSurfaceView trying to call rendering events before it is ready? How do I test for this? I haven't seen any calls to my own native rendering function before this crash: all the functions have log events, eg LOG("Java_com_package_name_here_VuforiaARRenderer_renderFrame");
- Could synchronous texture loading for large numbers of textures cause this problem? (I'm already planning to deal with this so it would be a nice freebie!)
Thanks!
Intermittent native crash just after QCAR initialization
Hi, in order to spot the issue, one would need to analyze in detail and debug your full application code, which is not possible via this Forum, as you can imagine.
Intermittent native crash just after QCAR initialization
I've actually been investigating this in parallel with your comments (and I appreciate your point about the detailed debugging); I've basically come to the conclusion that it's a race condition caused by the QCAR.init() function.
Intermittent native crash just after QCAR initialization
I would say you can try many different things, as long as you respect this general pattern:
1. only create and add the GLSurfaceView after QCAR.init() has completed 100%
Intermittent native crash just after QCAR initialization
OK, that makes sense. I'll try adding an mIsResumed boolean and hitting the GLSurfaceView#onResume() method immediately if it's created while resumed, then locking the other elements of the QCAR startup to an mGLIsResumed boolean to enforce strict ordering.