Qt application severe hangs on process->start()

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.

sprkxr

Bafflingly，I used this method

    [[NSProcessInfo processInfo]
    beginActivityWithOptions:NSActivityUserInitiated

to close the App Nap still did not solve the problem, and finally had to use NSTask successfully solved the problem.

SGaist

@sprkxr how did you use it ? It might be useful for other people :-)

sprkxr

I actually didn't find a solution to the problem I described above. I use NSTask instead of QProcess. I rewrote this part of the code and circumvented the problem. NSTask is a native Mac function similar to QProcess.

JonB

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

...for some definition of bad.

Hi Jeremy. Now that this issue is resolved for the OP. It was bothering me so I went back to check the behaviour of destructing a QProcess while a long-running start(...) process is still running, It is indeed true that destructor "kills" it, but per my vague recollection writes to the Application Output pane warning message QProcess: Destroyed while process ("find") is still running.. Which people have asked about in the past. So clearly Qt code thinks this is "bad", and expects you to e.g. terminate() it yourself before letting instance run out of scope. Just saying (for anyone reading this).