Qt application severe hangs on process->start()

[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).

[sprkxr]

Very, very feeling to all who answered my question. Although my problem was solved using another method, I'm still trying to figure out the root cause of the problem, so if anyone has encountered the same problem and figured out what the problem is, I'd appreciate it if you could let me know.

[jeremy_k]

Yup, there is a qWarning(). Its presence predates the modularization project, and the oldest repo clone I have at the moment. As such, I can't tell if the warning and the behavior in question were from the same author. There are other qWarnings() that don't appear to indicate a problematic condition.

Compare this to the documentation for QThread::~QThread() prior to 6.3, which clearly indicates a "bad" situation.

Note that deleting a QThread object will not stop the execution of the thread it manages. Deleting a running QThread (i.e. isFinished() returns false) will result in a program crash.

Qt developers, or "the trolls", aren't a hive mind. The people who work on it have differing, and changing, and sometimes outright conflicting opinions. Sometimes they make mistakes.