Placing breakpoint kills child processes on remote debug
-
Hi,
I have a console application which executes some child processes with QProcess. I mainly remote debug this application. While running the debug session, If I put a breakpoint anywhere, the running child processes got killed even though the application never stops at that breakpoint. App loop continues to run as is.
Have you ever encountered something like this? If yes, did you found any solution?
Regards,
-
Hi,
I have a console application which executes some child processes with QProcess. I mainly remote debug this application. While running the debug session, If I put a breakpoint anywhere, the running child processes got killed even though the application never stops at that breakpoint. App loop continues to run as is.
Have you ever encountered something like this? If yes, did you found any solution?
Regards,
@MuratUrsavas
Platform? Debugger?gdbhas a couple of follow fork settings, just make quite sure you are set to stay in parent not follow children in your settings (that's supposed to be the default, but check)? -
Using Qt 5.15.0, on Ubuntu 20.04 host machine. Target machine is Raspbian Kernel 5.4 (armhf). I'm using GDB Multi-Arch.
I'll look at follow fork settings. Additionally I've made sure that the "debug all child processes" option is not selected in Qt Creator as it makes everything worse.
-
You're right @JonB , the correct place to look at the root cause is forking.
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_25.html
This page says why the problem ocurres:
"If you have set a breakpoint in any code which the child then executes, the child will get a SIGTRAP signal which (unless it catches the signal) will cause it to terminate."
Let's find out how this can be prevented.
-
You're right @JonB , the correct place to look at the root cause is forking.
https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_25.html
This page says why the problem ocurres:
"If you have set a breakpoint in any code which the child then executes, the child will get a SIGTRAP signal which (unless it catches the signal) will cause it to terminate."
Let's find out how this can be prevented.
@MuratUrsavas
Are you saying the child process is not some random, third-party program but one which actually uses the same source code as you have in the parent where you have the breakpoints? -
Are you saying the child process is not some random, third-party program
Yes, other programs are also developed by me with Qt and executed on demand.
but one which actually uses the same source code as you have in the parent where you have the breakpoints?
They don't share the same source code and I don't have an intention to debug child processes at this point. Only the parent program is debugged and I'm adding breakpoints in that source.
Note: I've found a way to ignore SIGTRAP signal but it didn't work. This could be something different.
-
Really confused at this point. If I run the secondary software manually it can dodge SIGTRAP and continues its way normally. But if I start it with its own source code via GDB, it is terminated with SIGTRAP signal exception message.
