Restored the process channel mode members to ProcessSetupData and
StartProcessPacket and forward to the QProcess created in
LaunchSocketHandler. LaunchSocketHandler now avoids reading from stderr
for merged channels since it's guaranteed to not be available.
This avoids asserts in Qt 6.3.0 and warnings in Qt 6.3.1 while
preserving the original output order when an application has a mix of
stdout and stderr output.
Change-Id: I9f4541932cf9d8638b38658a5efea9cb5f1798f3
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Keep the setup data on stack instead on heap.
Task-number: QTCREATORBUG-27358
Change-Id: I0fffd525e2bd4f46533804e3b88fe5b330d02a91
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of readyReadStandard[Output/Error]() signals.
Get rid of readAllStandard[Output/Error]() accessors, as
this data is passed with readyRead() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I01341feba650e650761f97e90f83b6042c899251
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
And get rid of errorOccurred() and finished() signals.
Get rid of resultData() accessor, as this data is passed
with done() signal.
Task-number: QTCREATORBUG-27358
Change-Id: I677bbd174cceea6d8f5a989f961222c417992b60
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
ProcessLauncherImpl::terminate() was behaving the same as
ProcessLauncherImpl::kill() in case of process launcher
implementation - in both cases the launcher
immediately returned confirmation about receiving the
close request and was putting the corresponding
process into its reaper. However, the issue with this approach
is that we can't receive anymore any potential ready
read signal from the process being terminated after
a call to terminate().
The fix is to diverge the behavior of terminate()
and kill() of ProcessLauncherImpl. The behavior of kill()
remains the same, while terminate() just instructs the
process launcher to start termination without putting
the process into the reaper, yet.
Add a test that checks for any possible zombies.
We run the RecursiveBlockingProcess recursively. The most
nested process blocks. After a short wait we terminate
the outermost process. With this test we are trying to see
if terminating the middle process terminates also its
children and doesn't leave zombies.
Before we execute the test (and also by the end of this test)
we call Singleton::deleteAll() in order to ensure that reaping
of previously running processes has finished. We ensure the
number of running processtestapps is zero. Later, we ensure that
the leaf process was already started and the number of running
processtestapps equals the depth of recursion.
Fix apparent bug in getLocalProcessesUsingProc().
Change-Id: I7e2bc46ad5ca22f26620da86fbaf0fa00a7db3c3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should be useful when reimplementing ProcessInterface.
It replaces 4 virtual methods with just 1.
Task-number: QTCREATORBUG-27358
Change-Id: I2dafbfbc25f8f016ff2aa19c1a176335a4a7498c
Reviewed-by: hjk <hjk@qt.io>
It's internal method, not meant to be used outside.
It's only used in case of FailedToStart error.
Remove it also from ProcessInterface.
Leave it inside DefaultImpl and its subclasses only.
Remove m_errorString field from ProcessSetupData.
Change-Id: Ie605b95c2ff605ab1259045f1a5b16049207c1d3
Reviewed-by: hjk <hjk@qt.io>
Instead of relying QProcess to operate with MergedChannels, keep
the separate channels and merge inside QtcProcess.
Fixes: QTCREATORBUG-27196
Change-Id: I3039267fcd6d90f95f8212642e17049b87af1156
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't detect a call to QtcProcess::kill() from inside the
QtcProcess callback while awaiting inside QtcProcess::waitFor...().
That's not needed, since a call to kill() sends a stop message
to the process launcher, so we wait for confirmation
from process launcher instead. This may bring e.g. new
read data from the running process.
Fix a runBlockingStdOut() test so that when we write to the stdOut
from the running process we flush the unfinished line so that
it's not buffered inside the process.
Change-Id: I7944ac214d8cb9e10a71715a7ef8bfacab6df7c9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
...instead of ensuring in many functions that m_setup isn't null.
This amends 36c49cd2ea and
solves the issue for other functions like processId(),
exitCode(), etc...
Amends 36c49cd2ea
Change-Id: I986f7b30e90e5825ae2bb57b4bc2aa14f56e401f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
ProcessProxyInterface will be helpful when implementing
public subclasses of ProcessInterface, like
general ssh impl, linux specific impl, qnx specific, etc.
ProcessProxyInterface is sharing private data
between proxy and target.
Change-Id: I8350837bb5f770d6605b860b146604cba5e6b592
Reviewed-by: hjk <hjk@qt.io>
Drop it also from registerHandle() methods, as it wasn't
used there.
Change-Id: I34b72c38368b82f22d73314fe3cd429ed43cadbc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Also simplify the wording of a message.
Task-number: QTCREATORBUG-27055
Change-Id: I29df31f8484d451d8d8d1869ca3a1b182072d2c1
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Don't pass writeData, as that's available through
ProcessSetupData.
Change-Id: Ic55b21c6a3338168ee251bcc1c57594f50c52d2f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Use Utils::Environment for of environment.
Use Utils::FilePath for workingDirectory.
Change-Id: I6b717139f8ff7ddbd629fb22cf816b2303fb5e6a
Reviewed-by: hjk <hjk@qt.io>
In case the user called waitForReadyRead() and we have
received the finished signal instead (without receiving
readyRead signals in meantime), we should interrupt
the wait and return false, since there is no point to
wait for future readyRead signals from not running process.
Change-Id: Ib4a770aea6ed562a5bef197eaa51b20c146842f0
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Sometimes after creating QtcProcess we move it into a different
thread. In this case we should move all the children, too.
Without parent-child relation all the children will stay in the
old thread.
Change-Id: Ibde44d6153092a155dd2d200a7116a046910dddc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Remove the process in process launcher after error has appeared.
Remove unneeded stopStopProcedure as we are disconnecting from
process' signals inside removeProcess().
In order to behave as much similar to what QProcess does,
provide a test that:
- ensures the FailedToStart error is synchronously emitted
when waitForStarted is being executed
- ensures that process state is reset to NotRunning after
FailedToStart error
- 2nd call to start/waitForStarted doesn't block on
waitForStarted
Change-Id: I139354421d037739f1cc1a2685b66f1e5b6170c8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Instead of returning a pointer to LauncherSocket instance,
which might get deleted in meantime of just after,
route all calls to the LauncherSocket through the LauncherInterface.
Make all calls to LauncherInterface secured by the
instance mutex.
Change-Id: I751228de5f4263112471098ee08cc73a5245147e
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Move qDeleteAll into cpp file, as LauncherSignal is defined there.
Change-Id: I59ed1de2025c3f62196e1c676accf26b3fb813ac
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Assert that we are in NotRunning state when starting a process.
Otherwise we issue a warning and ignore the new call.
Change-Id: Ie8c007851aabb4b814c1fd49bc8d01f22eb1a563
Reviewed-by: hjk <hjk@qt.io>
Fix a race condition in the following scenario:
QtcProcess proc(...)
...
proc.start();
proc.waitForStarted();
if (!proc.waitForFinished()) {
// handle failure here
return;
}
// handle success
Move all the data into the caller's handle
and manage the QtcProcess state only from
inside caller's thread. This eliminates race
conditions when state changed from inside launcher's
thread while the caller's thread isn't notified
immediately.
For example: currently, when the launcher's thread receives
finished signal it doesn't change the process state
immediately, but posts a finished signal to be
dispatched in the caller's thread. When the caller's
thread dispatches the posted signal (inside flush() method)
it changes its state and posts the finished signal to the
outside world.
Don't flush all signals from waitForStarted(). Flush
only started signal in this case.
Change-Id: Ia39c4021bf43b8d0e8fcda789c367c096bfd032c
Reviewed-by: hjk <hjk@qt.io>
Get rid of <QtModule/qclass.h> style and use <QClass> directly,
like in all other places in Creator. Remove some unneeded
declarations.
Change-Id: I1b5630850c570e5d86df01a341f7352bc1971e48
Reviewed-by: hjk <hjk@qt.io>
Add some developer comments explaining which method
is designed to be called from a certain thread.
Add also some comments about in which thread
certain QObjects live in.
Change-Id: I38b10216cc29f8a86fd784e588e913407f0fb776
Reviewed-by: hjk <hjk@qt.io>
Pipe the error packet through the caller's handle and flush
it immediately if the caller was awaiting for any signal.
Stop awaiting for any signal when we have flushed error signal.
In this case return false from waitForSignal() method
in order to mimic the QProcess behavior.
Fixes: QTCREATORBUG-26136
Change-Id: Ie80b4a63bd19a6309d4791ad39a698bd91bb8967
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In case when QtcProcess::start() is being called very early,
just after the launcher socket was started but not ready yet,
a start is being delayed. In this case doStart() isn't
called directly from the caller's thread, but it will be
invoked later from the launcher's thread, when the socket is ready.
In this case we may have a deadlock, since calling
doStart(), sendPacket(), sendData() and finally handleRequests()
results in a synchonous chain of calls in launcher's thread,
so the mutex locked in sendData() will block synchronous call to
handleRequests(). In order to fix it we unlock the mutex
in sendData() before calling handleRequests().
Change-Id: I6c13994d0b05b624567c75ffbd2ac7cc0d77df61
Reviewed-by: hjk <hjk@qt.io>
Fix "runBlockingStdOut" autotest for tst_qtcprocess.
This crazy case relies on the fact that a blocking
call to waitForFinished() lets ReadyRead signals to
be processed in meantime and the handler for ReadyRead
may terminate the process. However, when no handler
for ReadyRead canceled the process, the blocking call to
waitForFinished() should return to the awaiting state
for the remaining time. From the caller's side everything
happens during a blocking invocation of waitForFinished().
So, in order to behave like this we implement waitForSignal()
in a loop. After we have flushed all the pending signals
we check if we have flushed the signal we were awaiting for.
If so, we break the loop, otherwise we continue. In order
to detect the case when the cancel was called during flushing
we set the m_awaitingShouldContinue flag before flushing.
The cancel() method clears this flag. Then after flushing
we check if the flag was cleared - in this case we don't
continue awaiting.
We reset the m_waitingFor state always after wait condition
finishes awaiting. Before, we didn't reset it when the
wait condition timed out.
Change-Id: I210f446659cabfd89bdfdd1fc8e8396d9470effc
Reviewed-by: hjk <hjk@qt.io>
