How can I avoid Fatal signal 11 crash in Vuforia for Android?

Question

I am working on the FrameMarkers sample application with ~30 small markers, rendering simple 2D planes. My app has a few GUI buttons that when clicked, will change the displayed textures (between yellow or grey). This part works, but there is a problem where sometimes the app crashes and gives the following error:

11-22 12:52:36.361: A/libc(7197): Fatal signal 11 (SIGSEGV) at 0x00000010 (code=1), thread 7278 (Thread-527)

This is an example of how I switch grey textures to yellow:

// First, set the textures in the texture array
for (int i=0;i<30;i+2) {
    mTextures.set(i, textureYellow);
}

// Reinitialize the renderer
deinitApplicationNative();
initApplicationNative(mScreenWidth, mScreenHeight);
mGlView.queueEvent(new Runnable() {
    public void run() {                             
        mRenderer.initRendering();
    }
});

That is the suggested way to switch textures at run-time (see here), and I have it running inside FrameMarkers.java (it is triggered by a button click from another Activity through a Handler). I should reiterate that the app doesn't crash on every texture change. On each run it crashes at a different point, but I have isolated the problem to be somewhere in the process of changing textures and re-initializing the renderer (as it seems to happen after a button press).

• What could be causing this to crash so infrequently?
• Is there a safer way to change textures during run time in a Vuforia application?

Running this on Android 4.3.

Answer 1

I seem to have solved this error. Indeed, the code in my original post is the correct way to switch textures during run-time (this has been confirmed by the admins on the Vuforia forums).

The problem was a threading issue. I had retrieved code for the GUIManager class from the Dominoes sample application to add buttons and other elements to the screen. That class uses a Handler to receive messages and then perform appropriate GUI-related tasks.

The problem is that you have to ensure initApplicationNative() is called on the Main thread, while mRenderer.initRendering() is called on the GLThread. Not only that, but if the array of textures is changing at any point between the initApplicationNative() call and the mRenderer.initRendering() calls, it can cause a failure in the native code (there are some assert() calls).

There is some more information about Threading in Vuforia here: https://developer.vuforia.com/forum/faq/android-which-methods-are-called-ui-vs-opengl-thread

I believe that there were timing issues, as well as sometimes functions were called on the wrong thread. To make my program work, I removed the Handlers from FrameMarkers.java and GUIManager.java, and called all of my texture-updating code from the Main thread.

This ensures that deinitApplicationNative() and initApplicationNative() are always called from the Main thread, whereas mGlView.queueEvent() ensures that the GL code runs on that thread.