Qt application severe hangs on process->start()

sprkxr

Qt application severe hangs on process->start()，the main process freezes severely. The Instruments tool shows that the CPU usage is almost 100% when process->start () is called, and severe hang occurs at the same time.

MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
, ui(new Ui::MainWindow)
{
ui->setupUi(this);
timer = new QTimer();
connect(timer, &QTimer::timeout, this, &MainWindow::Read);
QPushButton *button = new QPushButton("按钮", this);
connect(button, &QPushButton::clicked, this, &MainWindow::OnBtnClicked);
}

void MainWindow::Read()
{
QThread *th = QThread::create([=] {
QSharedPointer<QProcess> process(new QProcess);
QStringList arg;
arg << "ls"<< "-l";
process->start("bin/zsh", arg);
qDebug()<<arg;
});
connect(th, &QThread::finished, th, &QThread::deleteLater);
th->start();
}
void MainWindow::OnBtnClicked()
{
Read();
timer->start(8000);
}

sprkxr

MacX86 Monterey13.6.1
Qt5.15.8

JonB

@sprkxr said in Qt application severe hangs on process->start():

arg << "ls"<< "-l";
process->start("bin/zsh", arg);

For a start this is not a correct command. For one thing, bin/zsh is not the path to zsh. For another, try zsh ls -l from a terminal and even then you will see it does not do what you (apparently) think it does. Correct your command.

Also remove using thread.

As for "hang/freeze", try system("ls -l") and compare behaviour.

For this particular command you have no need to invoke zsh:

arg << "-l";
process->start("ls", arg);

will do it, and more efficiently.

sprkxr

Thanks for your reply，the command here is just a test, in fact even doing a bare start will cause the above problem
for example:
QString macEnv = qgetenv("SHELL");
process->start(macEnv, QStringList());
or
process->start("Other executable files such as adb"， QStringList())

remove using thread still cause the above problems.

In addition, the same project runs on both winx86 and Mac arm64 without any problems, only under mac x86 there is a serious problem of freezing.

JonB

@sprkxr
Please try my (two) suggestions:

As for "hang/freeze", try system("ls -l") and compare behaviour.

For this particular command you have no need to invoke zsh:

arg << "-l";
process->start("ls", arg);

sprkxr

system("ls -l")
also causes severe hang,and repeated calls crash my project. The Xcode instrument tool shows that the CPU usage is almost 100% when the system and process->start commands are executed.

arg<<"-l";
process->("ls", arg)
still causes freezes and severe hang，and the program will print out QProcess::Destroyed while process ("ls") is still running

In addition,this is a demo that is part of a larger project

JonB

@sprkxr said in Qt application severe hangs on process->start():

system("ls -l")
also causes severe hang,and repeated calls crash my project

So now you know it has nothing to do with Qt or QProcess. Goodness knows what your issue is, I don't use Macs.

and the program will print out QProcess::Destroyed while process ("ls") is still running

Wait a minute! Why do you have:

QSharedPointer<QProcess> process(new QProcess);

?

QSharedPointer will delete the pointer it is holding when it goes out of scope, provided no other QSharedPointer objects are referencing it.

So your QProcess *process goes out of scope at the end of the function and is destroyed while the sub-process is still running. Which is bad. Don't know how that related to you testing system(), but try getting rid of that.

sprkxr

It seems that the problem is caused by MacX86 itself.

The difference is that:
The repeated use of system () will cause the crash and serve hang, but there is no serious freezing in a very short time before the crash.

The process->start() will not crash but severely hangs at the same ti
me.

The CPU usage detected by the Xcode instrument is almost 100% in both modes.

jeremy_k

@JonB said in Qt application severe hangs on process->start():

So your QProcess *process goes out of scope at the end of the function and is destroyed while the sub-process is still running. Which is bad.

...for some definition of bad.

QProcess::~QProcess():

Destructs the QProcess object, i.e., killing the process.

Note that this function will not return until the process is terminated.

JonB

@sprkxr
If you have not removed your QSharedPointer<QProcess> then your tests with QProcess are invalid.

system("ls -l") can be equated with QProcess as

QProcess proc;
proc.start("/bin/zsh" /* or maybe "/bin/sh" here */, { "-c", "ls -l" ) );
return proc.waitForFinished(-1);

so that ought behave like system().

All I can say is that the behaviour you describe is so bad that likely Qt Creator would not work (it likely uses QProcess for, say, running the compiler etc.) and the whole Linux system would not work (if system() or equivalent cannot be used to spawn programs).

JonB

@jeremy_k said in Qt application severe hangs on process->start():

Note that this function will not return until the process is terminated.

Just for the record, I don't even believe this documentation is necessarily correct, at least not always (even if it is for OP's case). Try bool QProcess::startDetached(qint64 *pid = nullptr) and then destruct the QProcess instance or exit the calling process? I believe the sub-process should continue to run....?

sprkxr

Just now, system was called frequently, causing the crash, so I manually clicked here to try system () and process->start (). In my project, each time this function is called, it causes a freeze. (Before the modification, the process is invoked every 5 seconds to check the current status.), only when my project was moved to MAC x86, the problem does not occur on any other platform, it is really very puzzling

I don't know how I can put pictures here. I took a few screenshots of the demo running status using Xcode Instrument. You can clearly see that the cpu usage is very high, accompanied by severe hang and hang.

jeremy_k

@JonB said in Qt application severe hangs on process->start():

@jeremy_k said in Qt application severe hangs on process->start():

Note that this function will not return until the process is terminated.

Just for the record, I don't even believe this documentation is necessarily correct, at least not always (even if it is for OP's case). Try bool QProcess::startDetached(qint64 *pid = nullptr) and then destruct the QProcess instance or exit the calling process? I believe the sub-process should continue to run....?

Yes, but that is ~~spelled out~~ implied in the documentation:
QProcess::startDetached()

If the calling process exits, the detached process will continue to run unaffected.

The calling process can't exit (normally) if it is waiting for the callee to terminate, and the callee is allowed to continue running.

JonB

@jeremy_k
So the equally-spelled-out ~QProcess()

Destructs the QProcess object, i.e., killing the process.

Note that this function will not return until the process is terminated.

does not apply here, but is not mentioned here. So documentation can be contradictory/not accurate Just saying. Anyway it's not relevant to the on-going issue the OP is experiencing.

sprkxr

I use QProcess* process = new QProcess (); Retested previous steps.The problem persists.

JonB

@sprkxr
And as answered previously if system() does not work correctly then it is not a QProcess/Qt issue. (Did you try system() in a totally minimal, non-GUI, command-line-only application to eliminate Qt UI from the issue? Or even remove QCoreApplication completely and try system() without one?) In which case I am not sure you will get a solution here.

I don't know MacOS, but does it do something funny about "validating" when you try to run another program from code? Which a normal Linux would not do.

Is XCode an environment/debugger? Have you tested behaviour by invoking from the command-line, quite outside of XCode or any debugger? Have you tried compiling for Release just in case that is relevant?

sprkxr

Haha, I googled the description of Instrument.
Instrument in Xcode is a powerful tool for analyzing and optimizing iOS and macOS apps for performance issues. It provides multiple tools, including Time Profiler, Memory Graph, Energy Log, and Network Activity, to help developers understand performance bottlenecks and potential problems of applications.

You can perform the following operations by using the Instrument:

Performance analysis: Use the Time Profiler to trace and analyze the CPU usage of applications, helping identify performance bottlenecks and optimization opportunities.
Memory analysis: Use the Memory Graph to examine the memory usage of your application and find memory problems such as memory leaks and circular references.
Energy consumption analysis: Use the energy consumption analyzer (Energy Log) to monitor the energy consumption of applications and find out the codes and resources that consume much power.

JonB

@sprkxr
Yes, that is what "instrumentation" means. It can also cause "problems" in the execution of programs, sometimes. One issue it might have is that if you are instrumenting a program and that spawns a sub-process it might get "confused" about which one to follow.

I asked/suggested you try your application outside of any instrumentation, and preferably/possibly outside of XCode too, and see whether issues persist?

sprkxr

I restarted my mac and closed all other programs. Change QProcess to QProcess* process = new QProcess (); And tried system () and process->start then recompile my project, the problem persists, and system () for a short time before crashing 🙂 (I added the log to see the system executing my commands during this time) doesn't cause my project to freeze, QProcess doesn't cause a crash but every time it's called it causes the whole program to freeze.About every 5 seconds, it freezes for more than 1 second and closer to 2 seconds

mliberato-pax

Just found the solution to a similar problem I was having here, it was linked to macOS application hibernation called App Nap. Initial explanation of the problem was discovered here. In my python application I was able to utilize appnope to get around it.