[SOLVED] Problem with cmd process

[jsulm]

@JonB "If the calling process exits, the detached process will continue to run unaffected." - https://doc.qt.io/qt-5/qprocess.html#startDetached
So, the QProcess destructor will not terminate the detached process as it is detached.
"this ~QProcess() behaviour is a bit problematic" - in what way? If you use startDetached() then the destructor doesn't matter. If you use exec() then I don't see why ~QProcess() terminating process is a problem? At the end it's your job as developer to select the right approach.

[JonB]

@jsulm

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

That describes what happens if the calling process exits. It does not state it countermands what I quoted from ~QProcess(), which states it kills & waits. The question (my question) is what happens, which "wins", if you do not use new but have a "global" scoped QProcess globProc variable (not *globProc), initiate glocProc.startDetached(), and then exit your program. To me the docs are unclear....

Can I try this myself? No, because I'm stinky Python, and there are no variables, only heap pointers....

[jsulm]

@JonB And there are static methods in QProcess to execute a process without even creating a QProcess instance.

[jsulm]

@JonB said in Problem with cmd process:

That describes what happens if the calling process exits

Yes, and if an application exits ~QProcess() will be called (at least if it exits normally)...
It's the whole point of startDetached() - it detaches the QProcess instance from the started process. Just try.

[JonB]

@jsulm
Ah!! (And you don't think those create an instance internally?). OK, so if I use static QProcess::startDetached() that really should not call ~QProcess, even on program exit?

It's the whole point of startDetached() - it detaches the QProcess instance from the started process.

Just because a process is detached that does not mean you cannot wait on or kill it, does it? It just means things like it's in its own session.

But it should not matter as the process is detached and the destructor should NOT terminate it.

OK, but I don't get that from the docs! Maybe we read them differently. I'm also having a deeper think about C++ static, too long now of having to do Python... :(

Time for me to have a play....

[jsulm]

@JonB said in Problem with cmd process:

And you don't think those create an instance internally?

I don't know. But it should not matter as the process is detached and the destructor should NOT terminate it.

[JonB]

@jsulm
Just to confirm your interpretation.

From Python/PySide2, from a terminal if I run an interactive python3 and do

>>> from PySide2.QtCore import QProcess
>>> p = QProcess(); p.start("./script")

and then exit the python session (python will auto-delete everything created), I get a message

QProcess: Destroyed while process ("./script") is still running.

But if I use

>>> p = QProcess(); p.startDetached("./script")
# or
>>> QProcess.startDetached("./script")

no message, and I continue to see ./script's output after the python session has exited.

[jsulm]

@JonB said in Problem with cmd process:

no message, and I continue to see ./script's output after the python session has exited.

This is expected, isn't it? As stated in the documentation. ~QProcess() is called in both cases.

[JonB]

@jsulm

This is expected, isn't it? As stated in the documentation. ~QProcess() is called in both cases.

Expected by you apparently, but not by me. If ~QProcess() is called, docs state

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

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

If it said "but not when started via (non-static) QProcess::startDetached()" then I would be happy. Like I said, perhaps different doc interpretation between you & me.

[jsulm]

@JonB Well, again:
"If the calling process exits, the detached process will continue to run unaffected." - https://doc.qt.io/qt-5/qprocess.html#startDetached

And you even confirmed this behaviour by yourself :-)

You can upload a patch fixing ~QProcess() documentation.

[JonB]

@jsulm
I already wrote above: "calling process exits" does not tell you whether ~QProcess() is or is not called. In C++, if I glob_dangling = new QProcess(); exit(0); C++ cleanup does not call ~QProcess(), does it?

But when ~QProcess() is called for whatever reason, https://code.woboq.org/qt5/qtbase/src/corelib/io/qprocess.cpp.html#_ZN8QProcessD1Ev has

QProcess::~QProcess()
{
    Q_D(QProcess);
    if (d->processState != NotRunning) {
        qWarning().nospace()
            << "QProcess: Destroyed while process (" << QDir::toNativeSeparators(program()) << ") is still running.";
        kill();
        waitForFinished();
    }

so presumably somewhere qProcess->startDetached() ends up causing d->processState = NotRunning.

[jsulm]

@JonB If allocated on the stack destructor ALWAYS is called if app is closing in a clean way. If allocated on the heap you have to delete it. I'm sure Python has clean memory management and deletes what it allocates (so destrcutor is called).

[JonB]

@jsulm said in Problem with cmd process:

If allocated on the heap you have to delete it. I'm sure Python has clean memory management and deletes what it allocates (so destrcutor is called).

Indeed exactly. So from C++ you have the choice to new somewhere and not delete, thereby avoiding destructor being called on exit. In Python you can't help destructor being called. Hence my requirement to understand ~QProcess.

As I said, I think we're just differing over what Qt docs might care to say in ~QProcess entry about what happens when pProcess->startDetached() was called. We'd better leave it at that :)

[Cimmy]

Thanks to all.
Sorry for my (many!) mistakes but i'm a beginner in c++ and qt programming.

[JonB]

@Cimmy
The "going out of scope" is a nasty problem which many people fall foul of, so don't worry :)

I should also apologise for getting this thread into a detailed discussion of an area I was interested. For you, follow @jsulm's advice about moving the QProcess variable out of the slot function and into a class member variable, and you should be good!