Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QEventDispatcherWin32::processEvents freezes in DispatchMessage



  • Hi everyone,

    As the title suggest, I have a freeze in my application in

    QEventDispatcherWin32::processEvents
    

    line 828 of qeventdispatcher_win.cpp

    I must mention that i am using Qt 5.6 with MinGW 4.9.2 32bits

    The freeze occurs after a particular external executable is closed, which yields a DLL call on my application side. The DLL calls seems to go fine, then the program returns to the Qt processing loop and goes on until it reaches that line. DispatchMessage freezes on the first call (i could not spot any endless loop)
    After the DLL call, nothing more is done in my code : it is the last instruction i wrote that is executed before the freeze.

    What may be the cause of this behavior ?

    Here is the stack context before I step in DispatchMessage. I assume 'msg' here hold invalid value and makes the Windows function go nuts but why ?
    176fe61c-273d-4a63-8e48-4f18fef45f0c-image.png

    Thank you a lot for you help and have a great day :)



  • My bad, i had forgotten to unlock a mutex in that early return... :/
    However the cause of the DispatchMessage invalid call i spotted in the debugger remains unclear to me.
    Thanks anyway


  • Lifetime Qt Champion

    Hi and welcome to devnet,

    Can you explain what that call does ?



  • The DLL is used for getting access to textures on the graphics card that have been allocated by other programs. With the API, one can create either senders or receivers. A receiver is linked to a sender by knowing the sender's name.

    To receive a texture, a receiver must call receive texture with a set of arguments, one of which being the sender's name. The ReceiveTexture function then returns a boolean that indicates success or failure : if the sender gets deleted, ReceiveTexture will fail and I call the API to release the receiver. After that, my program freezes as described above.

    But instead of releasing the receiver I tried to set a flag so it isn't used anymore and the problem remains the same : the issue is tied to the failure of receiving the texture.

    c55faaba-a17a-4d66-84d6-59a4ede1fd0f-image.png

    if (m_receiverInitialized) {
        unsigned width(m_width), height(m_height);
        GLint currentFBO(0);
        // create a backup of the current context, make our context current and get functions pointer (gl)
        BEGIN_OPENGL_PTR(m_glContext, m_surface)
        gl->glGetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &currentFBO);
    
        if(!m_spoutHandle->ReceiveTexture(m_senderName, width, height, m_texture, GL_TEXTURE_2D, true, static_cast<GLuint>(currentFBO))){
            qDebug() << "Failed to receive texture from Spout sender";
            m_receiverInitialized = false;
            m_width = 0;
            m_height = 0;
            // restore the context that was current before we did BEGIN_OPENGL if there were any
            END_OPENGL
            return;
            /* program returns to the thread's event processing loop and freezes after a DispatchMessage call */
        }
        // [...]
    }
    

    I am receiving the texture into a local one which i allocated myself.

    If you want me to ask the creator of 'Spout' (the library i use) anything about what's involved inside (if you have suspicions) i can.

    Thanks a lot



  • My bad, i had forgotten to unlock a mutex in that early return... :/
    However the cause of the DispatchMessage invalid call i spotted in the debugger remains unclear to me.
    Thanks anyway


Log in to reply