QProcess is blocking UI and destroyed while app running

[KejPi]

Hello All,

I am facing strange issues with QProcess (Qt 5.12.12) on MacOS and Linux. I am running long process (DFU programming) that takes about 10-15 seconds to complete. I have actually 2 problems:

• Application UI stops responding while process is running
• When the process finishes I get this message

(0): QProcess: Destroyed while process ("/Applications/STMicroelectronics/STM32CubeProgrammer/STM32CubeProgrammer.app/Contents/MacOs/bin/STM32_Programmer_CLI") is still running.

The class and thus QProcess instance is destroyed when application exits.

I do not know if this is relevant but process is started from timer timeout slot when DFU device is detected, I do not wait for a process to finish, I rely on finished signal. My assumption was that the process runs separately from main window thread and thus is should not block anything. It seems that these issues are not existing on Windows, only on MacOS and Linux.

Although these issues are happening, it seems that the process finishes correctly with exist status QProcess::NormalExit

Releavant pieces of the code:

// header
class DfuProgramming : public QObject
{
    Q_OBJECT
    // ....
private:
   QProcess m_dfuProcess;
   QTimer * m_detectDfuTimer;
}

// source
DfuProgramming::DfuProgramming(QObject *parent) : QObject(parent)
{
    // ...
    connect(&m_dfuProcess, QOverload<int, QProcess::ExitStatus>::of(&QProcess::finished), this, &DfuProgramming::dfuFinishedSlot);
    connect(m_detectDfuTimer, &QTimer::timeout, this, &DfuProgramming::dfuEvent);
    //...
}

void DfuProgramming::dfuEvent()
{
    //...
    m_dfuProcess.start(cmd);
}

What am I doing wrong? Is there any principal issue?

[Christian Ehrlicher]

Please use a debugger to see where exactly the program is blocking. I doubt it's during start().
Also make sure the timer is a single shot timer so the slot is only called once.

[JonB]

@KejPi
As @Christian-Ehrlicher has said.

The UI should only block if you call m_dfuProcess.waitForFinished(). Otherwise if your running process is very intensive it might make the system/desktop "sluggish", but not blocked.

If you allow your calling process to exit before the subprocess has finished then you will get the "process is still running" message. If you intend it to finish then you must make it do so; if you intend it to outlive the calling process then you need to use startDetached().

[KejPi]

It does not block during start(). Actually if I connect to QProcess::readyReadStandardOutput signal, it gets called 3 times before it stops responding. The time when application is unresponsive it actually the time when programmer is erasing and programming attached device. During that time I gen no STDOUT from the process altough there is quite a lot of messages from the process.
I have reduced the code so only start() is called and no other method of QProcess is used but the result is the same.
The QProcess is destroyed on application exit thus there is no reason for "process still running" message.

Ideally I woudl like to continuously capture process stdout using QProcess::readyReadStandardOutput signal thus startDetached() is not suitable.

[JonB]

@KejPi said in QProcess is blocking UI and destroyed while app running:

The QProcess is destroyed on application exit thus there is no reason for "process still running" message.
Ideally I woudl like to continuously capture process stdout using QProcess::readyReadStandardOutput signal thus startDetached() is not suitable.

You cannot have both of these. If you want to read stdout then as you say you cannot use startDetached(), you must use start(). And in that case you must terminate the subprocess, by whatever means, before you destroy the QProcess, else you will get that warning message. "there is no reason for "process still running" message." --- this is what Qt does, you can't alter it.

[Christian Ehrlicher]

@KejPi said in QProcess is blocking UI and destroyed while app running:

ctually if I connect to QProcess::readyReadStandardOutput signal, it gets called 3 times before it stops responding

And where does it get stuck there exactly? Inside the Qt code or do you do a blocking read? Please show the code and the backtrace.

[KejPi]

It seems that the problem is somewhere in my app, it is currently not clear where but minimal example I was trying to prepare to share here is working as expected. However full app does not work and I cannot even stop the code to see where it is stuck :-(

EDIT: rootcause found - another timer was calling the same executable but with waiting for result. This was causing problem as the second process was waiting for the first to complete (this is limitation of the executable I am running).