GlDrawElements crash after switching to QQuickView on Android device



  • Hi,

    I recently switched to a QQuickView for a project of mine. I have a 3D heightmap scene that's been working fine both on desktop and a Android device (Nexus 7). Before the switch to QQUickView, the scene rendered without issues on Android as well. Currently, it crashes with a segfault when calling glDrawElements(..) in the second frame, and I have no clue why it does that and calls to glGetError does not show anything of interest.

    It's a little strange, because the rendering code hasn't changed since I switched to QQuickView. I remember reading somewhere that QQuickView's GLContext gets pissy if it is not handed back in same state after the GUI call to beforeRendering() signal, but I wouldn't really know what could have messed it up.

    Here's the code that is causing issues. If I comment out the block or even just the glDrawElements call, everything works out ok, except for this part not being drawn.

    @void HeightMap::render(..)
    {
    m_program.bind();
    // setting some program uniforms...
    ...
    m_vao.bind();
    //m_indexBuffer.bind();
    //m_vertexBuffer.bind();
    funcs->glDrawElements(GL_TRIANGLE_STRIP, m_indexCount, GL_UNSIGNED_INT, 0);
    m_vao.release();
    //m_vertexBuffer.release();
    //m_indexBuffer.release();
    funcs->glActiveTexture(GL_TEXTURE0);
    m_program->release();
    assert(funcs->glGetError() == GL_NO_ERROR);
    }@

    Now, if I uncomment the vbo/index bind/release, it won't crash anymore, but will only draw the heightmap on frame 1, while drawing nothing on the next frames that follows. This further makes me believe there's any issue of state problem. As I said previously, this exact code rendered on my Android device previously when my window was not based on QQuickView. Both implementations work flawlessly on a desktop build.

    I've spent a lot of time trying to figure this out, and I'm not sure what to try anymore. There's really no meaningful error message and the debugger only shows assembler stack calls after crashing.



  • Any idea what I could try?



  • Here's a few error messages that I've noticed, though I'm not sure whether they are related or not, they seem severe..

    @D/OpenGLRenderer(13362): Enabling debug mode 0
    D/Qt (13362): fontdatabases\basic\qbasicfontdatabase.cpp:247 (static QStringList QBasicFontDatabase::addTTFile(const QByteArray&, const QByteArray&)): FT_New_Face failed with index 0 : 90
    W/Qt (13362): scenegraph\qsgcontext.cpp:438 (virtual void QSGRenderContext::initialize(QOpenGLContext*)): QSGContext::initialize: depth buffer support missing, expect rendering errors
    W/Qt (13362): scenegraph\qsgcontext.cpp:440 (virtual void QSGRenderContext::initialize(QOpenGLContext*)): QSGContext::initialize: stencil buffer support missing, expect rendering errors
    F/libc (13362): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 13383 (QSGRenderThread)@



  • Late response, but I figured out why it crashes like it does. I'm still not sure why exactly. I noticed the vao buffer id was 0 whenever I ran Android.

    Looking at the code at https://github.com/Vitallium/qt5/blob/master/qtbase/src/gui/opengl/qopenglvertexarrayobject.cpp I wonder if the step fails on finding "GL_OES_vertex_array_object" extension and just bugs out without telling me. Though wouldn't this kind of extension be pretty much available on most Android/iOS devices? I don't find it in the extension list on my Nexus 7 (using GL extension viewer),

    code from QOpenGLArrayVertexObject.cpp : create()
    @#if defined(QT_OPENGL_ES_2)
    if (ctx->hasExtension("GL_OES_vertex_array_object")) {
    vaoFuncs = new QVertexArrayObjectHelper(ctx);
    vaoFuncs->glGenVertexArrays(1, &vao);
    }
    #else@

    My workaround was to not use QOpenGLVertexArrayObject whenever I ran on devices that would flag QT_OPENGL_ES_2 and just manually bind vbo, ibo and do the enableAttribArray/setAttribArray for each buffer in my draw calls. Hopefully I can remove my #ifndefs in a later version and have all targets use vaos again.

    Hopefully this can be of help to other people struggling with the same issues in the future!


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.