instead of QTEST_MAIN. Reduces the initialization that is done by the Qt
test applications, and can also reduce interference with normal OS
operations like the current window loosing focus.
Change-Id: If88f289281aa1c8703ac7d4dbe0799d067c16588
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
Currently, as a result of many refactorings, the QtcProcess
is designed so that if you want to customize the behavior
you should implement custom ProcessInterface subclass.
Adding virtual methods directly to QtcProcess caused tons of
unpredicted side effects and nasty bugs, which were hard to
track and hard to fix, as provided fixes were usually fixing
particular case while introducing regressions in not related
code paths.
Consider also aggregating QtcProcess object instead of
deriving from it when some additional methods are required.
This patch removes the last virtual methods from QtcProcess API
and makes the class final in order to prevent from adding
any new virtual methods to this class in the future.
This commit message should make it clear that having subclasses
of QtcProcess is not a desired design. It's a post-mortem
conclusion. So: don't derive from QtcProcess - we mean it!
Change-Id: I1e43ed45be326b366422fd7db6e05ba48ea5fb98
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>
This test introduced some additional private API to QtcProcess.
This makes refactorings of QtcProcess harder, as we need to
handle this artificial code working.
We have a real lineCallback() test instead which doesn't
employ this private API.
Change-Id: Idbc314210cecc2044e1ccc298e5d3e0a9747e811
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
Ensure that when waitForFinished() didn't timeout
but the process has terminated, it returns true,
like QProcess does, in contrary to what QProcess'
documentation says.
Change-Id: I6af5034f4df7fc2e14a83bab74334a8abefe7a0f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Behave the same as QProcess in this circumstances.
Change-Id: If8175ccb7102d6a561584ee73c2e5c5844f2770d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
warning: C4996: 'setmode': The POSIX name for this item is deprecated.
Instead, use the ISO C and C++ conformant name: _setmode. See online
help for details.
...same for 'fileno'
Change-Id: I85090b65532b17b535914b88de835d718f654f6a
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Now it's possible to run the test outside of directory
where the test is located.
Change-Id: I2a2c693d382917ac7b84488c8ccf161538b58238
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use SUB_CREATOR_PROCESS macro for registering subprocess'
main() function.
Invoke registered subprocesses by a call to
invokeSubProcessIfRequired().
Substitute subTestCase env variables with TestCase subclasses.
This should make the code even more readable.
Amends bbb0270fb1
Change-Id: Id63b15841ea539f367dab4972a6ecbb298d277e7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Introduce SubCreatorConfig class that helps setting up
a Creator subprocess. This limits the code repetition.
Introduce SUB_CREATOR_PROCESS(subProcess) macro to easily define
environment variables referred to Creator subprocesses.
This macro also forward declares the subProcessMain()
function.
Match names of main subprocess functions with their
corresponding environment variables.
Group subProcessMain() functions near the corresponding
test function for clarity.
Change-Id: Ib4365cf18fddc1527ebc99accee1fbb974bbf7a1
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
In my case Qt is persistently showing the following warning
at startup of every application:
Warning: Ignoring WAYLAND_DISPLAY on Gnome.
Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
There is no easy solution here, as even when I run this test
with -platform xcb option, then this test is running
another instance of Creator that doesn't have this option
passed. Since QTest's internal main function parses the
argv options and filters out those recognized by Qt itself,
calling QCoreApplication::arguments() doesn't return
the originally passed -platform xcb option.
The solution here is simple - we ignore initial lines
in callback (so we filter out the initial warnings
generated by Qt) and wait for first expected line.
The final check of parsed line numbers should prevent
the case when we have filtered out all the lines.
Change-Id: Ideff0dc7c409b6e3ad81ec13577cb67e5211d5df
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Introduce Utils::Singleton class and
Utils::SingletonWithOptionalDependencies class template
that helps implementing singletons that depend on other
singletons. It's guaranteed that whenever singleton B depends
on singleton A, than A is always created before B is being
created, and that the order of destruction is always
opposite to the order of creation.
Dependencies of singleton are listed as template arguments
for SingletonWithOptionalDependencies class template.
The first argument of SingletonWithOptionalDependencies
class template is always a singleton class itself.
Prepare a common interface for all singleton subclasses:
SingletonSubClass *SingletonWithOptionalDependencies::instance();
Make instantiating singletons and its dependencies thread-safe.
Create singletons on demand (only if some code needs them).
It's not needed anymore to explicitly instantiate
all required singletons in tests.
Make it possible (and thread-safe) to instantiate ProcessReaper
and LauncherInterface singletons in non-main threads.
Make the following dependencies between existing singletons:
SshConnectionManager depends on:
-> LauncherInterface depends on:
-> ProcessReaper
Change-Id: Iefaacab561c2b3dcf07e7fafbb87339ea6a15278
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Before we were receiving the following warning when detroying the
QtcProcess while still running:
QProcess: Destroyed while process ("[program_name]") is still running.
With the new implementation it won't appear anymore since terminating
running QtcProcesses is done internally by the reaper.
Change-Id: I14a0de136f463966cb1e4c43c5cb26b4de47e7ce
Reviewed-by: hjk <hjk@qt.io>
Reuse ProcessReaper inside process launcher.
Automatically reap all internal QProcesses of QtcProcess
(either direct child of QtcProcess in QProcessImpl
or indirectly inside process launcher).
Make ProcessReaper work again on QProcess instead of on
QtcProcess, so it may still be reused for non-QtcProcesses.
Change-Id: I950cac5cec28f17ae97fe474d6a4e48c01d6aaa2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
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>
Similar to QT_RESTRICTED_CAST_FROM_ASCII to avoid the need for
decorations in user code.
At the same time, drop some convenience constructors and functions
in CommandLine and Icon essentially serving the same purpose.
Change-Id: Ida4e5ac19c2da0a4298a97b2a8e1511d56bbb79d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- Pass everything through the codec.
- Always emit even incomplete last lines when the process finishes.
- Don't store raw output when line-wise processing is requested.
Change-Id: I5cc30ad0d7ab79387bfb00b48ff957468a1bd004
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
