VTHandler in EGLFS breaks GDB Remote Debugging

stjosh · 7 Jul 2016, 07:20

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.

SGaist · 7 Jul 2016, 07:23

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.

stjosh · 7 Jul 2016, 07:26

@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.

SGaist · wrote on 7 Jul 2016, 20:52

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.

stjosh · wrote on 13 Jul 2016, 09:28

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

stjosh · wrote on 19 Jul 2016, 06:14

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. :)

SGaist · wrote on 19 Jul 2016, 07:08

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

stjosh · wrote on 20 Jul 2016, 05:09

Sure, an env variable would work fine for me.

SGaist · wrote on 20 Jul 2016, 20:35

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

Julien Carbonnier · wrote on 3 Aug 2016, 14:54

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.

Thanks,

Here it's a part of gdb log.

>909-exec-run
 Process AW_APP created; pid = 1370
>library-loaded,id="/lib/ld-linux-armhf.so.3",target-name="/lib/ld-linux-armhf.so.3",host-name="/opt/fsl-imx-fb/4.1.15-1.2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/lib/ld-linux-armhf.so.3",symbols-loaded="0",thread-group="i1"
Library /lib/ld-linux-armhf.so.3 loaded
>909^running
dNOTE: ENGINE RUN AND INFERIOR RUN OK
sRunning.
dState changed from EngineRunRequested(7) to InferiorRunOk(11) [master]
dINFERIOR STARTED
sDémarrage de l'application
>*running,thread-id="all"
dNOTE: INFERIOR STILL RUNNING IN STATE InferiorRunOk.

>~"\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"
dNOTE: INFERIOR SPONTANEOUS STOP
sStopped.

> 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.
>914^done