The quitBlockingProcess() test examines different types
of process quitting and illustrates differences in
behavior.
Change-Id: I9209f00576e03eef66fbdf5665351138ed437ac9
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Round 1 - focus on headers.
For classes with initial in range [D-G].
Try to keep the same separators between different kind of headers.
Change-Id: Id42cd7b3743a816f75cecb6b576c0e37cb057473
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
Do not return false from QtcProces::waitForStarted if the process is
already running. This causes mayor issues on windows since QProcess
directly emits started and therefore switches to the running state after
calling QProcess::start.
Change-Id: I4604b08a59918d3df11c8a174b57e1e483e78a0d
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
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>
After the required depth of recursion is met, the most
nested process waits for one seconds and crashes.
Change-Id: I8d9b359459fc7aa1983734685e5c5f19eb49ee94
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Don't invoke subcreator test in order to run a custom process.
Run a separate executable instead. The advantages are:
1. Faster test running (no need for QTest specific code path
when running subprocess).
2. Don't use std::exit() from subprocesses as it doesn't
clean up properly. Use qApp->exit() instead.
3. This should support returning NormalExit and proper
exit code of subprocess in case the code wasn't 0.
Change-Id: I1395bd8a7873c95a594c3e054087f00c55a15376
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
