0

I'm trying to debug an issue in a Qt5 application where, for some reason, even after the application reaches its exit point (log message placed right before return 0 of int main shows), the process persists and when running "ps -e" and grepping for the process, it will show a process in the background.

Is there a way I can diagnose where this thread is in the background? All my log messages indicate that all Qt windows have been closed, and the "setQuitOnLastWindowClosed" flag is set to true. So the only thing I can think of is that a thread spawned by the application is still running in the background.

I should note that this does not ALWAYS happen. When the user exits the application normally, this does not happen. But when the machine detects a power cycle, it forces a close, but it seems something is missing in the code it runs in this case, so figuring out what's still running will help me find that.

The application was built in Qt5 and it's running on Scientific Linux 6.4 if that matters.

Darin Beaudreau
  • 375
  • 7
  • 30
  • Rather than describing your code, it would be more helpful if you showed your code. – JarMan Mar 11 '21 at 18:22
  • 1
    Build with debug information and attach the debugger when that happens again. Preferably use an IDE. Qt Creator is decent at attaching gdb to either local running processes or even to remote systems so that's one avenue of pursuit. The debugger - be it in the IDE or just plain gdb - will show you what threads are running, and you can pause them and see what they are doing (i.e. where they are stuck). – Kuba hasn't forgotten Monica Mar 11 '21 at 18:25
  • @JarMan There's far too much code to post. This isn't some small application, it's large-scale. – Darin Beaudreau Mar 12 '21 at 12:24
  • @Kubahasn'tforgottenMonica I can build with debug info, but I can't debug on the machine I compile on because the application runs on specific hardware that doesn't have debugging software available. I know, it's frustrating... – Darin Beaudreau Mar 12 '21 at 12:25
  • No "debugging software" needed - at least nothing major. Look what it takes to provide a gdbserver on your target. You'll probably go nowhere if you don't set it up sooner rather than later. I don't quite know why this wasn't done on day one. That's like the first thing you do when you get a new target going... Your target is supported by gcc or clang, so gdbserver not only exists for it, but is probably used by tens of thousands, easy. – Kuba hasn't forgotten Monica Mar 13 '21 at 02:22
  • @Kubahasn'tforgottenMonica Again, not something I can do, as the hardware this software runs on is a closed system. I can use GDB, but I can't attach source or anything, so the most it will tell me is that there IS a thread running, but I don't know how I would determine where that thread is. All I've been able to figure out is that there are 15+ threads still running in the background spawned from this process by using the "ps" command. – Darin Beaudreau Mar 15 '21 at 11:11
  • @Kubahasn'tforgottenMonica I wasn't necessarily looking for help with the code part of this problem. I was hoping someone knew of a way to identify WHERE these threads are coming from, whether from a Linux command, or some kind of trick with GDB. – Darin Beaudreau Mar 15 '21 at 11:13
  • `strace` might also help you and maybe give you a clue on where the thread is stucked https://stackoverflow.com/questions/14694582/stracing-to-attach-to-a-multi-threaded-process – Fryz Mar 23 '21 at 18:55

0 Answers0