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....? -
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.
-
@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 outimplied 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.
-
@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
And as answered previously ifsystem()
does not work correctly then it is not aQProcess
/Qt issue. (Did you trysystem()
in a totally minimal, non-GUI, command-line-only application to eliminate Qt UI from the issue? Or even removeQCoreApplication
completely and trysystem()
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?
-
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. -
@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?
-
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
-
-
@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-runningstart(...)
process is still running, It is indeed true that destructor "kills" it, but per my vague recollection writes to the Application Output pane warning messageQProcess: 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). -
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.
-
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.