Important: Please read the Qt Code of Conduct -

VTHandler in EGLFS breaks GDB Remote Debugging

  • We are developing an application running on an ARM embedded system using the EGLFS platform. When upgrading Qt from 5.4.1 to 5.5.1, we found that remote debugging the application on the target platform was misbehaving, i.e., pausing execution or setting / removing a breakpoint while the application is running was not possible anymore, instead, the debugger exited with the message "Inferior 1 (process XXX) exited with code 1".

    After hours of searching, I finally found the following Qt commit, adding a handler for SIGINT and exiting the application in void QFbVtHandler::handleInt(). Since GDB seems to send a SIGINT to the application when pausing or setting / removing a breakpoint, this is where things seem to go wrong.

    I could fix this issue for now by creating a patch to qfbvthandler.cpp, simply undefining VTH_ENABLED.

    • Is this the correct approach to go? Or is there another way of preventing qfbvthandler.cpp to catch the signal and exit?

    Btw, even though qfbvthandler.cpp has been changed again for Qt 5.6 and upwards (see QtBug 48384 and this Qt commit), I assume that this would also be the case in these versions. I however do not have the toolchain at hand to verify this assumption.

  • Lifetime Qt Champion

    Hi and welcome to devnet,

    If you can't upgrade to 5.6 or more recent, then you can also take the latest patch and apply to your tree rather that disabling the handling altogether.

  • @SGaist Thanks for your follow-up. Well, sure I could apply the patch, but as I said, I'm pretty sure it would not change the basic problem. Only the way how signals are catched has changed with Commit f191ba9d71bd910f205a2f41c5ac6c0d959439ed, but not the fact that the application terminates on SIGINT, i.e., the _exit(1); is still there in the handleInt() method. Thus, receiving a SIGINT from GDB will still quit the application that is being debugged.

  • Lifetime Qt Champion

    Then I'd add e.g. a check on an environment variable that disable the current handling of SIGINT so you can activate it while debugging and otherwise let the application run as intended.

    In any case i'd recommend opening a bug on the bug report system to make the devs aware of the behavior change.

  • Ok, thanks for your follow-up. I'v created QTBUG-54733. Let's see what the dev team thinks about this issue.

  • Ok, seems to be a bug indeed, i.e., the Qt Dev Team has acknowledged it and is looking for a solution. I'll have to live with my dirty workaround for now. :)

  • Lifetime Qt Champion

    What about my suggestion to have an environment variable that disable the app exit part while debugging ?

  • Sure, an env variable would work fine for me.

  • Lifetime Qt Champion

    Since you currently have to implement it, you could make a submission to get it included in Qt :)

  • Hi,

    I found your topic and i have a problem with a SIGSEGV at the start of qt application when i used gdb.
    Your patch work with a previous problem i have with breakpoints but no with this one so have you an idea ?

    I'm using an imx6 platform with EGLFS and when upgrading Qt from 5.3.2 to 5.5.1, I can't start a debug.
    I try to backtrace in qtcreator but i can't find anything to help.


    Here it's a part of gdb log.

     Process AW_APP created; pid = 1370
    Library /lib/ loaded
    dState changed from EngineRunRequested(7) to InferiorRunOk(11) [master]
    sDémarrage de l'application
    >~"\nProgram received signal "
    >~"SIGSEGV, Segmentation fault.\n"
    >~"0x4dca9e24 in ?? ()\n"
    >*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x4dca9e24",func="??",args=[]},thread-id="1",stopped-threads="all",core="0"
    > 914bt full
    >&"bt full\n"
    >~"#-1 0x4dca9e24 in ?? ()\n"
    >~"No symbol table info available.\n"
    >&"warning: Unable to restore previously selected frame.\n"
     Unable to restore previously selected frame.

Log in to reply